Android模块开发框架 LiveData+ViewModel

时间  2019-12-04
标签 android 模块 开发 框架 livedata+viewmodel livedata viewmodel 栏目 Android 繁體版
原文   原文链接

Android模块开发框架 LiveData+ViewModel

前言

为什么选择LiveData+ViewModel

  • LiveData+ViewModel是Android Architecture Component开发组件的一部分，主要的目的是为了解决android开发过程当中的由于Activity及Fragment生命周期引发的一些常见问题，譬如：内存泄露，异步任务引发空指针，横竖屏切换界面刷新问题，固然它的做用远不止于此，好比：LiveData的观察者模型能够保障界面在第一时间更新到最新的数据（固然你的LifecycleOwner必须是Alive状态），解决了多端写入数据的同步问题；使用LiveData实现View和VM的自动绑定（一般这个绑定的数据流向是单向的，VM->View）．另外值得一提的是，AAC框架内部维护了一个ViewModel的内存缓存池，而且会监听Activity或Fragment的生命周期，在destory的时候自动清空缓存．所以，对于开发者而言，只须要聚焦在业务开发，几乎不用对接生命周期接口．
  • 感兴趣的同窗能够去看看官方的详细文档和Demo

MVP仍是MVVM？

  • mvvm相比mvp最大的区别就是实现了v和vm(p)的自动绑定，mvp中的v和p之间存在较多的接口依赖，不利于扩展及测试，mvvm一般存在一个Binding中介层，经过注解＋apt（或反射）的方式，解除v和vm直接的接口依赖，固然mvvm相比于mvp的进步不只仅是代码解耦，也是从＂面向功能接口编程＂到＂响应式编程＂的思想转变，一切皆是数据（指令）流（ui<->数据<->model）
  • 官方推荐使用MVVM框架，结合DataBinding依赖注入框架实现View和VM的双向绑定，考虑到使用DataBinding依赖于xml布局配置，且有较大的理解成本，咱们此次没有采用严格意义上的MVVM框架，而是选择折中方案：
    • VM->View：经过LiveData实现数据的单向流动
    • View->VM：依然采用传统的接口实现，可是全部的执行结果都依赖LiveData回传给View

经典的依赖原则

clean_architecture_reloaded_main.png | center | 608x339

  • 一个框架的好坏，一般会有如下几个衡量指标：
    • 是否能够解决当前的业务问题
    • 是否具有好的可扩展性
    • 是否具有好的可测试性
    • 是否遵循模块化设计原则
    • 逻辑，界面，数据是否分离
  • 固然，还有更多的衡量指标，咱们在这里不一一列举，上图所示的是一个圆环依赖结构，从内到外分别是：业务数据->业务逻辑层->接口适配层->界面，遵循＂依赖倒置原则＂，内部圆圈不能依赖外部圆圈

框架介绍

模块的内部层级

clean_architecture_reloaded_layers.png | center | 482x372

  • 听从单向依赖原则，咱们的模块内部也划分了一下三个层级，从下往上分别是：
    • 数据层：
      • 主要用来提供界面展现及交互所须要数据，一般会定义获取数据的策略接口，选择不一样的实现（DB，内存，网络等）
      • 不依赖其余层级，被逻辑层依赖
    • 逻辑层（领域层）
      • 这一层跟业务强相关，包含复杂的业务逻辑，譬如：获取数据，提交数据，数据存储策略的选择及数据融合等
      • 依赖数据层，被展现层依赖
    • 展现层（表现层）
      • 这一层的主要工做有如下几个：
        • 构建用户可见的界面
        • 为界面展现提供必要的数据
        • 接收并处理用户交互事件
      • 复杂的业务逻辑都委派给逻辑层（领域层）来处理，这里的ViewModel能够理解成一个接口适配器，只负责创建与View之间的通讯渠道，而后传递数据或接受指令，自身并不处理复杂的业务逻辑
      • 依赖逻辑层（领域层）

各层级介绍

展现层：使用LiveData实现MVVM的单向绑定

clean_architecture_reloaded_mvvm_app.png | center | 422x202

  • View与VM之间的通讯有两种
    • View->VM，一般是用户交互行为产生的一些指令（可能携带一些数据，譬如：用户登陆行为会携带帐号密码）
    • VM->View，一般是界面展现所须要的数据（也多是状态，譬如：加载数据失败，展现一个Toast提示等）
  • 咱们来举一个简单的案例，一个列表界面，须要刷新数据并展现，会有如下几个必要步骤：
    • 首先，View持有一个ViewModel实例（本身实例化，或则外部传参均可以）
    • 经过ViewModel获取一个LiveData对象（同一类LiveData在ViewModel内只能有一个实例），并开始观察这个LiveData对象（俗称subscribe）
    • ViewModel接收到＂刷新数据＂的指令，委派给具体的UseCase来执行
    • UseCase从数据源获取到数据，写入到LiveData
    • LiveData通知全部观察者（固然，会先判断observer依附的LifecycleOwner是否alive），其中就包括View
    • View从LIveData中获取到最新的完整的数据列表，刷新展现界面

逻辑层：UseCase处理复杂逻辑

usecase.png | center | 434x411

  • 前面已经提到了，usecase主要用来处理复杂的业务逻辑，减轻ViewModel负担
  • BaseUseCase能够看作是一个模板方法类（固然这个模板不必定适用全部业务场景），内部会作一些＂线程调度＂＂LiveData赋值＂等业务无相关的操做，具体的业务逻辑交给子类实现
  • 这里有一个Either<Failure, T>返回值，这个是java 8函数式编程的一个特性，相似于c语言里的union（共同体），主要用来以类型安全的方式返回两个（或多个）值，感兴趣的同窗能够自行google

数据层：Repository策略

clean_archictecture_reloaded_repository.png | center | 373x313

  • 定义一个获取（读／写）数据的策略接口，实现不一样的数据读写策略，也能够是多个策略的组合使用，根据具体的业务场景来决定，最大的好处就是可扩展性好，逻辑层（领域层）不用关心数据具体从哪里来

使用指南

如何界定一个独立的子模块

  • 模块划分有两种典型的思路，＂按功能用途分模块＂，＂按业务特性分模块＂，前者的一个常规作法就是按照Model，View，Present(Controler)等角色对文件进行分组，这样作最大的弊端就是不利于业务拆分及多人协做编程，因此，咱们推荐按照＂业务特性分模块＂，譬如：主界面，详情页，登陆页等都是一个相对独立的模块
  • 而后，如何界定一个独立的子模块，须要知足下面几个条件：
    • 相对独立的界面展现（android里的一个Activity或一个Fragment）
    • 相对独立的数据来源（你的界面渲染所须要的数据，能够经过独立的数据仓库获取，譬如：独立的服务端api接口，独立的数据表）
    • 用户交互产生的影响尽量的收敛在界面内（譬如：下拉刷新产生的数据只用来渲染当前页面）
    • 具有一个闭环的生命周期（模块使用的内存是可回收的，不建议用单例来实现跨模块内存共享）
  • 简单归纳就是：若是一个模块在脱离其余模块的状况下，依然能以缺省的方式独立运行，那么它就是一个相对独立的模块

搭建一个子模块

  • 咱们以一个列表界面为例子，运行效果：

device-2018-05-23-202059.png | center | 345x613

  • 按照如下步骤开发
    • Step1 数据层：数据仓库实现
      • 定义数据Bean
      public class HotContentItem {

    public String id;
    public String name;
    public String desc;
    public long timeStamp;
}
复制代码
      • 数据仓库策略实现（数据是本地mock的）
      public class HotContentNetRepository {

    //mock数据
    public Either<? extends Failure, List<HotContentItem>> refreshNew() {
        try {
            Thread.sleep(1000L);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Either<? extends Failure, List<HotContentItem>> result;
        Random random = new Random();
        boolean success = random.nextInt(10) > 3;
        if (success) {
            result = Either.right((mockItemList(0)));
        } else if (random.nextInt(10) > 3) {
            result = Either.right(Collections.<HotContentItem>emptyList());
        } else {
            result = Either.left(new NetworkFailure());
        }
        return result;
    }
｝
复制代码
    • Step2 逻辑层：数据仓库选择及使用
      • 省略列这一步，按照业务需求实现不一样的数据仓库组合使用
    • Step3 逻辑层：实现UseCase（示例代码：刷新数据）
    public class HotContentRefreshNew extends BaseUseCase<List<HotContentItem>, Void> {

    private HotContentNetRepository mNetRepository;

    public HotContentRefreshNew( MutableLiveData<List<HotContentItem>> data, MutableLiveData<Failure> failure) {
        super(data, failure);
        mNetRepository = new HotContentNetRepository();
    }

    @Override
    protected Either<? extends Failure, List<HotContentItem>> loadData(Void aVoid) {
        //从网络获取数据
        Either<? extends Failure, List<HotContentItem>> result = mNetRepository.refreshNew();
        if (result.isRight() && CollectionUtil.isEmpty(result.right())) {
            Failure failure = new RefreshNewFailure(RefreshNewFailure.CODE_DATA_EMPTY, "Data is empty!");
            result = Either.left(failure);
        }
        return result;
    }

    @Override
    protected Failure processFailure(Failure failure) {
        ...
    }
}
复制代码
    • Step4 展现层：UI框架选择
      • 示例界面是做为一个TabLayout的一个Page页，所以这里选择＂具有生命周期View＂做为的UI框架，这是个自定的View，实现了LifecycleOwner接口（参考了LifecycleActivity和LifecycleFragment的实现逻辑）
      public abstract class BaseLifecycleView extends FrameLayout implements LifecycleOwner {

    private final LifecycleRegistry mRegistry = new LifecycleRegistry(this);
    private ViewModelStore mViewModelStore = new ViewModelStore();

    public BaseLifecycleView(@NonNull Context context) {
        super(context);
    }

    protected abstract void onCreate();

    protected abstract void onDestroy();

    @Override
    public Lifecycle getLifecycle() {
        return mRegistry;
    }

    @Override
    @CallSuper
    protected void onAttachedToWindow() {
        super.onAttachedToWindow();
        mRegistry.handleLifecycleEvent(Event.ON_CREATE);
        onCreate();
        if (getVisibility() == View.VISIBLE) {
            mRegistry.handleLifecycleEvent(Event.ON_START);
        }
    }

    @Override
    @CallSuper
    protected void onDetachedFromWindow() {
        super.onDetachedFromWindow();
        mRegistry.handleLifecycleEvent(Event.ON_DESTROY);
        mViewModelStore.clear();
        onDestroy();
    }

    @Override
    @CallSuper
    protected void onVisibilityChanged(@NonNull View changedView, int visibility) {
        super.onVisibilityChanged(changedView, visibility);
        Event event = visibility == View.VISIBLE ? Event.ON_RESUME : Event.ON_PAUSE;
        mRegistry.handleLifecycleEvent(event);
    }

    @Override
    @CallSuper
    public void onStartTemporaryDetach() {
        super.onStartTemporaryDetach();
        State state = mRegistry.getCurrentState();
        if (state == State.RESUMED) {
            mRegistry.handleLifecycleEvent(Event.ON_STOP);
        }
    }

    @Override
    @CallSuper
    public void onFinishTemporaryDetach() {
        super.onFinishTemporaryDetach();
        State state = mRegistry.getCurrentState();
        if (state == State.CREATED) {
            mRegistry.handleLifecycleEvent(Event.ON_START);
        }
    }

    protected <T extends ViewModel> T getViewModel(@NonNull ViewModelProvider.NewInstanceFactory modelFactory, @NonNull Class<T> modelClass) {
        return new ViewModelProvider(mViewModelStore, modelFactory).get(modelClass);
    }

}
复制代码
    • Step5 展现层：定义本身的LiveData和ViewModel
    public class HotContentViewModel extends BaseViewModel<List<HotContentItem>> {

    private HotContentRefreshNew mRefreshNew;

    public HotContentViewModel() {
        refreshNew();
    }

    public void refreshNew() {
        AssertUtil.mustInUiThread();
        if (mRefreshNew == null) {
            mRefreshNew = new HotContentRefreshNew(getMutableLiveData(), getMutableFailure());
        }
        //经过usecase执行具体的刷新操做
        mRefreshNew.executeOnAsyncThread(null);
    }

   ...
}
复制代码
    • Step6 展现层：关联V和VM
    public class HotContentView extends BaseLifecycleView {

    private HotContentViewModel mViewModel;

    private SwipeRefreshLayout mSwipeRefreshLayout;
    private AutoLoadMoreRecycleView mRecyclerView;
    private HotContentAdapter mContentAdapter;

    public HotContentView(@NonNull Context context) {
        super(context);
        视图对象初始化
        ...
        mRecyclerView.setLoadMoreListener(new LoadMoreListener() {
            @Override
            public void onLoadMore() {
                HotContentItem lastOne = CollectionUtil.lastOne(mViewModel.getData().getValue());
                if (lastOne == null) {
                    mRecyclerView.completeLoadMore("No more data");
                } else {
                    mViewModel.loadHistory(lastOne);
                }
            }
        });
        ...
        mSwipeRefreshLayout.setOnRefreshListener(new SwipeRefreshLayout.OnRefreshListener() {
            @Override
            public void onRefresh() {
                //刷新数据
                mViewModel.refreshNew();
            }
        });
    }

    @Override
    protected void onCreate() {
        mViewModel = getViewModel(new NewInstanceFactory(), HotContentViewModel.class);
        mViewModel.getData().observe(this, new Observer<List<HotContentItem>>() {
            @Override
            public void onChanged(@Nullable List<HotContentItem> hotContentItems) {
                //刷新数据成功
                mContentAdapter.setItemList(hotContentItems);
                mSwipeRefreshLayout.setRefreshing(false);
                ...
            }
        });
        ...
    }

    @Override
    protected void onDestroy() {
    }

}
复制代码

遇到的问题

  • 复杂的UI交互指令如何传达给ViewModel
    • 在本文开头＂MVP仍是MVVM＂框架选型中咱们已经提过，目前并无使用到MVVM的精髓＂DataBinding＂，而是经过LiveData观察者模式实现V->VM的单向绑定（即：数据能够从VM自动流向V，可是V的操做指令没法自动传递给VM），所以，复杂交互（譬如：下拉刷新，滚动加载更多）仍是须要经过传统的MVP思惟在VM中定义功能接口提供给V来调用
  • 除了数据以外，还有状态会影响界面展现
    • 理想状态下，VM提供一个LiveData给View使用，这个LiveData包含了View渲染须要的所有数据，可是不少状况下View并不会只依赖单一类型数据，譬如：下拉刷新操做，会有如下三种结果返回：列表数据，空数据，失败．对于＂列表数据＂咱们能够经过LiveData通知View作总体刷新，可是＂空数据＂＂失败＂的状况也须要在界面上有所提示，而这两个返回值是不能影响当前的＂列表数据＂（即：不影响当前的列表展现），而应该看作是独立与数据以外的＂指令＂更合适，它们最大的特征就是＂一次性＂，不须要像＂列表数据＂那样存储处理（能够理解成是给界面消费的一次性事件）
    • 再回到LiveData，LiveData主要用来存储相对持久的数据，而且任什么时候候View从LiveData获取的数据都必须是＂完整的＂能够用来直接渲染界面的，回到上面＂下拉刷新＂的例子，若是咱们将＂空数据＂＂失败＂也经过LiveData封装，而后由View来观察这个LiveData（自定义一个Observer），在收到对应的＂指令＂通知的时候处理＂界面提示＂，这样彷佛也能知足VM->View的状态通知需求，问题来了，因为Observer的生命周期极可能会比LiveData的生命周期更短（取决于Observer依赖的LifecycleOwner）（好比：Observer的生命周期和ViewPager里的某一个View一致，LiveData的生命周期和Activity一致），那么当View被复用的时候会再次观察同一个LiveData，而后自动收到LiveData的通知，获取LiveData最新的数据（譬如：＂失败＂指令），刷新界面（提示＂刷新失败＂），这样就会很奇怪了，明明没有刷新动做，无缘无故提示＂刷新失败＂
    • 解决办法仍是回到＂指令＂的特征＂一次性＂，定义一个DisposableLiveData，每次执行setData（会通知观察者，也就是View）以后当即将data置空，这样下次再getData时候就会返回null，而不是一个＂未预期的数据＂
      • 代码实现很简单
      public class DisposableLiveData<T> extends MutableLiveData<T> {

    @Override
    public void postValue(T value) {
        super.postValue(value);
        if (value != null) {
            super.postValue(null);
        }
    }

    @Override
    public void setValue(T value) {
        super.setValue(value);
        if (value != null) {
            super.postValue(null);
        }
    }    
复制代码
      • 示例代码：
      public class HotContentView extends BaseLifecycleView {

    private HotContentViewModel mViewModel;
    private SwipeRefreshLayout mSwipeRefreshLayout;


    public HotContentView(@NonNull Context context) {
        super(context);
        ...

        mSwipeRefreshLayout.setOnRefreshListener(new SwipeRefreshLayout.OnRefreshListener() {
            @Override
            public void onRefresh() {
             &emsp;&emsp;//刷新数据
                mViewModel.refreshNew();
            }
        });
    }

    @Override
    protected void onCreate() {
        mViewModel = getViewModel(new NewInstanceFactory(), HotContentViewModel.class);
      &emsp;...
        mViewModel.getFailure().observe(this, new Observer<Failure>() {
            @Override
            public void onChanged(@Nullable Failure failure) {
                //处理失败提示
                if (failure instanceof RefreshNewFailure) {
                    mSwipeRefreshLayout.setRefreshing(false);
                    ToastManager.getInstance().showToast(getContext(), ((RefreshNewFailure)failure).getMessage(),
                        Toast.LENGTH_SHORT);
                }
                ...
            }
        });
    }

    @Override
    protected void onDestroy() {
    }

}
复制代码
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程