Looking for android Keywords? Try Ask4Keywords

AndroidMVVM (Architektur)


Bemerkungen

Syntax-Macken mit DataBinding

Beim Binden einer viewModel-Funktion an eine Eigenschaft in xml werden bestimmte Funktionspräfixe wie get oder is gelöscht. Z.B. ViewModel::getFormattedText auf dem ViewModel wird zu @{viewModel.formattedText} wenn es an eine Eigenschaft in XML gebunden wird. Ähnlich bei ViewModel::isContentVisible -> @{viewModel.contentVisible} (Java Bean-Notation)

Die generierten Bindungsklassen wie ActivityMainBinding sind nach der XML-Datei benannt, für die sie Bindungen erstellen, nicht nach der Java-Klasse.

Kundenspezifische Bindungen

In der activity_main.xml habe ich das textColor-Attribut für die app und nicht den android Namespace festgelegt. Warum das? Weil für das Attribut textColor ein benutzerdefinierter Setter definiert ist, der eine vom ViewModel textColor ColorRes-Ressourcen-ID in eine tatsächliche Farbe auflöst.

public class CustomBindings {

    @TargetApi(23)
    @BindingAdapter({"bind:textColor"})
    public static void setTextColor(TextView textView, int colorResId) {
        final Context context = textView.getContext();
        final Resources resources = context.getResources();
        final int apiVersion = Build.VERSION.SDK_INT;
        int color;

        if (apiVersion >= Build.VERSION_CODES.M) {
           color = resources.getColor(colorResId, context.getTheme());
        } else {
            color = resources.getColor(colorResId);
        }

        textView.setTextColor(color);
    }

}

Einzelheiten zur Funktionsweise von DataBinding Library: Custom Setters finden Sie hier

Warten Sie ... es gibt Logik in Ihrer XML !!!?

Sie könnten argumentieren, dass die Dinge, die ich in XML für android:visibility und app:textColor falsche / Anti-Muster im MVVM-Kontext sind, da in meiner Ansicht Ansichtslogik app:textColor . Ich würde jedoch argumentieren, dass es für mich wichtiger ist, Android-Abhängigkeiten zu Testzwecken aus meinem ViewModel herauszuhalten.

Was macht app:textColor wirklich? Es löst nur einen Ressourcenzeiger auf die tatsächlich zugeordnete Farbe auf. Das ViewModel entscheidet also immer noch, welche Farbe aufgrund bestimmter Bedingungen angezeigt wird.

Bei android:visibility empfinde ich aufgrund der Benennung der Methode als richtig, den ternären Operator hier zu verwenden. Aufgrund der Namen isLoadingVisible und isContentVisible besteht kein Zweifel daran, in was jedes Ergebnis in der Ansicht aufgelöst werden soll. Ich habe also das Gefühl, dass es eher einen Befehl ausführt, der vom ViewModel gegeben wird, als die View-Logik.

Andererseits stimme ich zu, dass viewModel.isLoading ? View.VISIBLE : View.GONE wäre eine schlechte Sache, weil Sie Annahmen in der Ansicht machen, was dieser Zustand für die Ansicht bedeutet.

Nützliches Material

Die folgenden Ressourcen haben mir sehr geholfen, dieses Konzept zu verstehen:

MVVM (Architektur) Verwandte Beispiele