Looking for android Answers? Try Ask4KnowledgeBase
Looking for android Keywords? Try Ask4Keywords

AndroidMVVM (Architecture)


Remarques

Syntaxe quirks avec DataBinding

Lors de la liaison d'une fonction viewModel à une propriété dans xml, certains préfixes de fonctions tels que get ou is sont supprimés. Par exemple. ViewModel::getFormattedText sur le ViewModel deviendra @{viewModel.formattedText} lors de la liaison à une propriété au format XML. De même avec ViewModel::isContentVisible -> @{viewModel.contentVisible} (notation Java Bean)

Les classes de liaison générées, telles que ActivityMainBinding portent le nom du fichier XML pour lequel elles créent des liaisons, et non la classe Java.

Fixations personnalisées

Dans le fichier activity_main.xml, je définis l'attribut textColor sur l' app et non l'espace de noms android . Pourquoi donc? Étant donné qu'un attribut personnalisé est défini pour l'attribut textColor qui résout un ID de ressource ColorRes envoyé par ViewModel à une couleur réelle.

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

}

Pour plus d'informations sur son fonctionnement, consultez DataBinding Library: Custom Setters

Attendez ... il y a de la logique dans votre xml !!!

Vous pourriez faire valoir que les choses que je fais dans XML pour android:visibility et app:textColor sont fausses / anti-patterns dans le contexte MVVM car il y a une logique de vue à mon avis. Cependant, je pense qu'il est plus important pour moi de garder les dépendances Android hors de mon ViewModel pour des raisons de test.

En outre, que fait vraiment app:textColor ? Il ne résout qu'un pointeur de ressource sur la couleur réelle qui lui est associée. Donc, le ViewModel décide toujours quelle couleur est affichée en fonction de certaines conditions.

En ce qui concerne l' android:visibility me semble liée à la manière dont la méthode est nommée. Il est donc normal d'utiliser l'opérateur ternaire ici. En raison du nom isLoadingVisible et isContentVisible il n'y a vraiment aucun doute sur la résolution de chaque résultat dans la vue. Je pense donc qu’il s’agit plutôt d’exécuter une commande donnée par ViewModel que de faire de la logique de vue.

D'un autre côté, je suis d'accord que l'utilisation de viewModel.isLoading ? View.VISIBLE : View.GONE serait une mauvaise chose à faire car vous faites des suppositions dans la vue de ce que cet état signifie pour la vue.

Matériel utile

Les ressources suivantes m'ont beaucoup aidé à comprendre ce concept:

MVVM (Architecture) Exemples Liés