简短的回答:
以下是我们的做法:
- 对于简单的“正常”内容(例如打开设备摄像头的按钮或打开另一个
Activity
/UIViewController
操作背后没有任何逻辑的按钮) -ActivityA
直接打开ActivityB
. ActivityB
如果需要,现在负责与应用共享逻辑层进行通信。
- 对于任何更复杂或依赖逻辑的东西,我们使用 2 个选项:
ActivityA
调用 some 的方法,UseCase
该方法返回一个enum
orpublic static final int
并相应地采取一些行动 -OR-
- Said
UseCase
可以调用ScreenHandler
我们之前注册的方法,该方法知道如何Activities
使用一些提供的参数从应用程序中的任何位置打开 common。
长答案:
我是一家公司的首席开发人员,该公司使用 java 库用于应用程序的模型、逻辑和业务规则,这两个移动平台(Android 和 iOS)都使用 j2objc 实现。
我的设计原则直接来自 Uncle Bob 和 SOLID,在设计包含组件间通信的整个应用程序时,我真的不喜欢使用 MVP 或 MVC,因为你开始将每个应用程序Activity
与 1 和只有 1链接,Controller
这有时是可以的,但大多数时候你最终会得到一个控制器的上帝对象,它往往会像View
. 这可能导致严重的代码异味。
我最喜欢的处理方式(也是我认为最干净的方式)是将所有内容分解为UseCases
每个处理应用程序中的 1 个“情况”。当然,您可以拥有一个Controller
处理其中几个的,UseCases
但它所知道的只是如何委派给这些UseCases
,仅此而已。
此外,如果此操作是简单的“带我到地图屏幕”或类似的任何操作,我看不到将 an 的每个操作链接Activity
到Controller
坐在逻辑层中的原因。的角色Activity
应该是处理Views
它所持有的,并且作为生活在应用程序生命周期中的唯一“智能”事物,我认为它没有理由不能调用下一个活动本身的开始。
此外,Activity/UIViewController
生命周期过于复杂且彼此差异太大,无法由通用 java 库处理。这是我认为是“细节”而不是真正的“业务规则”的东西,每个平台都需要实现和担心,从而使 java lib 中的代码更加稳固,不易更改。
同样,我的目标是让应用程序的每个组件都尽可能地符合 SRP(单一职责原则),这意味着将尽可能少的东西链接在一起。
所以一个简单的“正常”东西的例子:
(所有例子都是虚构的)
ActivityAllUsers
显示模型对象项的列表。这些项目来自调用AllUsersInteractor
- aUseCase controller
在后台线程中(这反过来也由 java lib 处理,并在请求完成时调度到主线程)。用户单击此列表中的一项。在这个例子中,ActivityAllUsers
已经有了模型对象,所以打开ActivityUserDetail
是一个直接调用这个数据模型对象的包(或其他机制)。如果需要进一步的操作,新活动ActivityUserDetail
负责创建和使用正确的。UseCases
复杂逻辑调用示例:
ActivityUserDetail
有一个标题为“添加为朋友”的按钮,单击该按钮会调用以下回调onAddFriendClicked
方法ActivityUserDetail
:
public void onAddFriendClicked() {
AddUserFriendInteractor addUserFriend = new AddUserFriendInteractor();
int result = addUserFriend.add(this.user);
switch(result){
case AddUserFriendInteractor.ADDED:
start some animation or whatever
break;
case AddUserFriendInteractor.REMOVED:
start some animation2 or whatever
break;
case AddUserFriendInteractor.ERROR:
show a toast to the user
break;
case AddUserFriendInteractor.LOGIN_REQUIRED:
start the log in screen with callback to here again
break;
}
}
更复杂的调用示例
ABroadcastReceiver
在 Android 或AppDelegate
iOS 上会收到推送通知。这被发送到NotificationHandler
java lib 逻辑层中的哪个。在NotificationHandler
构造一次的构造函数中,App.onCreate()
它需要一个ScreenHandler
interface
您在两个平台上实现的构造函数。解析此推送通知并在 中调用正确的方法ScreenHandler
以打开正确的Activity
.
底线是:尽可能保持View
愚蠢,保持Activity
足够聪明以处理自己的生命周期和处理自己的观点,并与自己的沟通controllers
(复数!),其他一切都应该写(希望测试-首先 ;) ) 在 java 库中。
使用这些方法,我们的应用程序目前在 java lib 中运行了大约 60-70% 的代码,下一次更新有望将其提高到 70-80%。