ViewModel +数据绑定中的最佳做法和模式. ViewModel中的ObservableField是否可以? [英] Best practices and patterns in ViewModel + Data Binding. Is ObservableField in ViewModel OK?

问题描述

通过示例，我发现了使用Android体系结构组件实现MVVM的2种方法.

Looking through the samples I seen 2 approaches to MVVM using Android Architecture Components.

第一种方法:

1. ViewModel提供了LiveData
2. Activity订阅LiveData
3. 当名为Activity的观察者将数据设置为ViewModel ObservableField时.
4. 整个ViewModel被传递给绑定.

5. 在xml中，您只需将ObservableField设置为值

1. ViewModel provides LiveData
2. Activity subscribes to LiveData
3. When observer called Activity is setting data to ViewModel ObservableField.
4. Whole ViewModel is passed to binding.

5. In xml you just set ObservableField as value

<ProgressBar
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_gravity="center"
    app:visibleGone="@{viewmodel.listLoading}"/>

<android.support.v4.widget.SwipeRefreshLayout
    android:id="@+id/swiperefresh"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:refreshing="@{viewmodel.listRefreshing}"
    app:onRefreshListener="@{() -> viewmodel.refreshList()}"
    app:visibleGone="@{!viewmodel.listLoading}">

优点:我不需要传递状态(例如正在加载")，因为我在ViewModel中将listLoading ObservableField更新为:

Pros: I don't need to pass state (for example "loading"), as I update listLoading ObservableField in ViewModel as this:

val listLoading = ObservableBoolean(false)
/** other observable fields go here **/

val list: MutableLiveData<List<Item>> = MutableLiveData()

  fun loadList() {
        listLoading.set(true)
        repo.getList { items ->
            list.value = items
            listLoading.set(false)
        }
    }

缺点:这种方法是否有缺点?

Cons: Are there any cons in this approach?

第二种方法:

1. ViewModel提供了LiveData
2. Activity订阅LiveData
3. 将名为Activity的观察者传递给绑定
4. 仅将需要的对象(pojo)传递给绑定

1. ViewModel provides LiveData
2. Activity subscribes to LiveData
3. When observer called Activity is passed to binding
4. Only needed object (pojo) is passed to binding

优点:这种方法有优点吗?

缺点:应该从ViewModel返回状态.在此来自Google的示例中，数据包装在Resource中对象.

Cons: State should be returned from ViewModel. In this sample from Google data is wrapped in Resource object.

第一种方法用于另一个示例应用来自Google

我想从具有更多使用Android数据绑定和Android Arch组件经验的开发人员那里了解两种模式的优缺点.

I would like to know what are pros and cons of both patterns from developers with more experience working with Android Data Binding and Android Arch Components.

推荐答案

您应考虑将视图逻辑与业务逻辑分开.

You should consider splitting view-logic with business-logic.

由于您有一个使用数据绑定和AAC进行处理的ViewModel，因此还应该将视图内部的逻辑(布局)分开.

Since you have a ViewModel using databinding and AAC to handle that you should also seperate the logic inside your view (layout).

只需将两个变量传递到您的布局即可.一个是VievModel，它可以像按按钮并处理逻辑一样处理业务逻辑，第二个是View(片段).

Just pass two variables to your layout. One is the VievModel which handle business-logic like pressing a button and processing the logic, the second one is the View (fragment).

之后，您可以使用

app:onRefreshListener="@{() -> yourViewFragment.refreshList()}"

，如果当前没有订阅视图，请避免出现上下文泄漏"或无效的解决方案.

and avoid having "context leaks" or a not working solution if there's currently no view subscribed.

由于onRefreshListener绑定到一个片段，因此可以在片段中传递它.

Since the onRefreshListener is bound to a fragment its OK to pass that inside your fragment.

您应该在ViewModel中创建一个LiveData或ObservableField来处理这种操作，因为如果您暂停并恢复片段，您将再次观察LiveData.这也意味着您将再次获得最后发送的数据.

You shoudnt create a LiveData or ObservableField inside your ViewModel to handle that kind of operations because if you pause and resume the fragment you'r going to observe the LiveData again. That also means that you will get the last data delivered again.

可以在ViewModel中使用的示例:

Example which can be used in the ViewModel:

<Textview ... name="@{viewModel.dataOfYourModel}" onClick="@{viewModel.doNetworkCall}" />

黄金法则:除了android.arch.*组件外，每个以android.*开头的包/导入都不应位于视图模型内.

Golden rule: Every package/import beginning with android.* should be NOT inside the viewmodel except the android.arch.* components.

这篇关于ViewModel +数据绑定中的最佳做法和模式. ViewModel中的ObservableField是否可以?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！