Best Practices und Muster in ViewModel + Data Binding. Ist ObservableField in ViewModel in Ordnung?

Question

Durch die Beispiele sah ich 2 Ansätze zu MVVM mit Android Architecture Components.

Erster Ansatz:

1. ViewModel bietet LiveData
2. Activity abonniert LiveData
3. Wenn Beobachter genannt Activity Daten an ViewModelObservableField Einstellung.
4. Ganze ViewModel wird an die Bindung übergeben.

5. In xml Sie setzen nur ObservableField als Wert

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

Vorteile: Ich brauche keinen Zustand zu übergeben (zum Beispiel "Laden"), wie ich listLoadingObservableField in ViewModel aktualisieren, diese:

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

Nachteile: Gibt es Nachteile bei diesem Ansatz?

Zweiter Ansatz:

1. ViewModel bietet LiveData
2. Activity abonniert LiveData
3. Wenn Beobachter genannt Activity Bindung
4. nur benötigt Objekt (pojo) geleitet wird, übergeben

Bindung

Pros: Alle Vorteile dieses Ansatzes?

Nachteile: Status sollte von ViewModel zurückgegeben werden. In diesem sample from Google Daten sind in Resource Objekt verpackt.

erster Ansatz ist in another sample app from Google

verwendet würde ich gerne wissen, was Vor- und Nachteile beider Muster von den Entwicklern mit mehr Erfahrung arbeitet mit Android Data Binding und Android Arch Komponenten.

Answer 1

Sie sollten in Erwägung ziehen, View-Logik mit Business-Logik zu teilen.

Da Sie ein ViewModel mit Datenbindung und AAC verwenden, sollten Sie auch die Logik in Ihrer Ansicht (Layout) trennen.

Übergeben Sie einfach zwei Variablen an Ihr Layout. Eines ist das VievModel, das Geschäftslogik wie das Drücken eines Knopfes und die Verarbeitung der Logik behandelt, das zweite ist das View (Fragment).

Danach können Sie

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

und vermeiden „Kontext Lecks“ oder eine nicht funktionierende Lösung zu haben, wenn es zur Zeit keine Aussicht abonniert.

Da der onRefreshListener an ein Fragment gebunden ist, ist es OK, das in Ihrem Fragment zu übergeben.

Sie sollten kein LiveData oder ObservableField in Ihrem ViewModel erstellen, um diese Art von Operationen zu bearbeiten. Wenn Sie das Fragment anhalten und fortsetzen, werden Sie die LiveData erneut beobachten. Das bedeutet auch, dass Sie die letzten Daten erneut erhalten.

Beispiel der in dem Ansichtsmodell verwendet werden kann:

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

Goldene Regel:. Jedes Paket/Import mit Android Anfang * sollte in dem Viewmodel mit Ausnahme der android.arch sein NICHT * Komponenten..