Meilleures pratiques et modèles dans ViewModel + Data Binding. ObservableField dans ViewModel est-il correct?

Question

En regardant à travers les échantillons, j'ai vu 2 approches de MVVM utilisant Android Architecture Components.

Première approche:

1. ViewModel fournit LiveData
2. Activity est abonnée à LiveData
3. Lorsque observateur appelé Activity est la mise en données à ViewModelObservableField.
4. L'intégralité ViewModel est passée à la liaison.

5. En xml que vous venez de ObservableField en tant que valeur

   <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}"> 
   

Avantages: Je ne ai pas besoin de passer l'état (par exemple le "chargement"), comme je mets à jour listLoadingObservableField en ViewModel comme ceci:

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) 
     } 
    } 

Moins: Y a-t-il des inconvénients dans cette approche?

Deuxième approche:

1. ViewModel fournit LiveData
2. Activity est abonnée à LiveData
3. Quand observateur a appelé Activity est passé à la liaison
4. est passé à la liaison

objet uniquement nécessaire (POJO)

Pour: Des avantages de cette approche?

Contre: L'état doit être renvoyé à partir de ViewModel. Dans ce sample from Google les données sont enveloppées dans l'objet Resource.

Première approche est utilisée dans another sample app from Google

Je voudrais savoir quels sont les avantages et les inconvénients des deux modèles de développeurs plus expérimentés travaillant avec liaison de données Android et composants arqués Android.

Answer 1

Vous devriez envisager de diviser la logique de vue avec la logique métier.

Puisque vous avez un ViewModel utilisant la liaison de données et AAC pour gérer cela, vous devez également séparer la logique à l'intérieur de votre vue (mise en page).

Transmettez simplement deux variables à votre mise en page. L'un est le VievModel qui gère la logique métier comme appuyer sur un bouton et traiter la logique, le second est la vue (fragment).

Après cela, vous pouvez utiliser

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

et éviter d'avoir des « fuites de contexte » ou une solution de travail pas s'il n'y a actuellement pas de vue abonné.

Puisque l'onRefreshListener est lié à un fragment, il est OK de le transmettre à l'intérieur de votre fragment.

Vous devez créer un LiveData ou ObservableField à l'intérieur de votre ViewModel pour gérer ce type d'opérations, car si vous interrompez et reprenez le fragment, vous allez à nouveau observer le LiveData. Cela signifie également que vous recevrez à nouveau les dernières données.

exemple qui peut être utilisé dans le ViewModel:

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

Règle d'or. Chaque paquet/importation commençant par Android * ne devrait pas être à l'intérieur du viewmodel sauf les composants android.arch *..