看下我的mvvm代码结构:
1 生命周期控制类:
public abstract class MvvmFragment<V extends IView, VM extends ViewModel> extends BaseFragment {
2 view类
public class DsNaviView extends DsBaseNaviView<FragmentNaviBinding> implements IBaseNaviViewTest {
interface OnViewAction{
void onClick();
void onLongClick();
}
交互事件的处理放到fragment里了(fragment也主要是调用viewmodel来处理),view只负责提供页面数据的展示
3 viewmodel类
public class NaviViewModel extends BaseNaviViewModel implements IRouteResultCallBack, IPosSwitchParallelRoadObserver, IPosParallelRoadObserver {
数据控制给到 ViewModel ,viewmodel 处理完后通过 MutableLiveData传递对象到 fragment里,
fragment通过绑定MutableLiveData通知来进行view的更新。
至于引导中各种后台数据上报还是放到放到服务中去,通过observer 或eventbus通知到 viewmodel里
4 有待思考的地方
fragment现在负责了view的交互事件,以及生命周期变化时候对view的控制,以及对 viewmodel的数据的更新。
整体改造后,感觉清晰了很多。
view:更新显示
viewmoel 数据的组装整理并通过 MutableLiveData传出去
fragment 生命周期相关的操作在这里发起,事件触发在这里发起。
有待确认点:
1 我也在像是不是让view和viewmodel各自监听lifecicle自己处理?但想来这样会导致混乱,统一放到fragment里更好吧。
2 这个主要没有通过框架对代码的流程和编写进行限制,我在考虑是否在搞一层限制以下。