追风赶月莫停留,平芜尽处是春山。这篇文章主要讲述Android Clean Architecture中的登录流程相关的知识,希望能为你提供帮助。
我希望使用Clean Architecture实现一个简单的Firebase身份验证android应用程序,因此根据Firebase文档,用户可以检查他是否已登录
@Override
public void onStart() {
super.onStart();
// Check if user is signed in (non-null) and update UI accordingly.
FirebaseUser currentUser = mAuth.getCurrentUser();
updateUI(currentUser);
}
所以我很困惑,因为它应该放在这个条件,如果它在UseCase或Presenter中,在相同的源对象的帮助下独立调用
就像是
public interface FirebaseAuthDataSource {
Single<
User>
loginUser(String username, String password);
Single<
User>
isUserLoggedIn();
}
public class LoginUserUseCase {
public Observable<
ResponseValues>
buildUseCase(RequestValues requestValues) {
return firebaseAuthDataSource.loginUser(username,password);
}
}
public class LoginPresenter{
public void onStart(){
firebaseAuthDataSource.isUserLoggedIn()
.subscribe(LoginView::navigateToMenuScreen);
}
}
所以这些条件是否符合商业逻辑?还是Flow逻辑?
答案根据Bob叔叔的说法,UI不应该对数据库有任何了解。这些条件属于框架层,其中所有数据库都应该是。通信通过UseCase和数据访问接口。
如果这对您来说太费劲,那么您也可以将未来可能发生变化的敏感部分转移到“清洁架构”。但那只是我的个人意见。我希望这能帮到您
另一答案在Clean Architecture中,您将尽可能多的逻辑放入用例层,即交互者。通过在用例层中定义的接口抽象出对数据库等细节的访问,并在框架/接口适配器层中实现。演示者应该尽可能简单 - 理想情况下只有“数据转换器”。
在这种情况下,交互者将决定何时进行登录检查并使用firebase DB的接口执行它。交互者还将决定登录检查失败时会发生什么。
【Android Clean Architecture中的登录流程】如果你想了解更多关于实现演示者的信息,请查看我的帖子:https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/
推荐阅读
- Android(将片段和弹出窗口的点击事件中生成的变量传递给活动的方法)
- 在Android 4.x中显示矢量图形
- android super.onBackPressed()计时
- Android P onStart在onActivityResult之前调用
- 如何在我的活动中设置Android铃声()
- 自动更改活动(Android中的横向和纵向模式)
- Android - 为什么人们反复引用内联静态上下文,而不是在Method()中传递一次()
- 从广播接收器android调用活动方法()
- 使用Android按钮切换到不同的Activity