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

AndroidMVVM (Arquitectura)


Observaciones

Sintaxis con el enlace de datos

Cuando se vincula una función viewModel a una propiedad en xml, se eliminan ciertos prefijos de función como get o is . P.ej. ViewModel::getFormattedText en el ViewModel se convertirá en @{viewModel.formattedText} al enlazarlo a una propiedad en xml. De forma similar con ViewModel::isContentVisible -> @{viewModel.contentVisible} (notación Java Bean)

Las clases de enlace generadas como ActivityMainBinding se nombran después del xml para el que están creando enlaces, no la clase java.

Encuadernaciones personalizadas

En el activity_main.xml establecí el atributo textColor en la app y no el espacio de nombres de android . ¿Porqué es eso? Debido a que hay un textColor personalizado definido para el atributo textColor que resuelve un ID de recurso ColorRes enviado por ViewModel a un color real.

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

}

Para obtener detalles sobre cómo funciona esto, consulte la Biblioteca de DataBinding: Configuradores personalizados

Espera ... ¿hay lógica en tu xml?

Podría argumentar que las cosas que hago en xml para android:visibility y app:textColor son incorrectas / anti-patrones en el contexto MVVM porque hay una lógica de vista en mi opinión. Sin embargo, diría que es más importante para mí mantener las dependencias de Android fuera de mi ViewModel por razones de prueba.

Además, ¿qué hace realmente la app:textColor ? Solo resuelve un puntero de recurso al color real asociado con él. Así que el ViewModel aún decide qué color se muestra en función de alguna condición.

En cuanto a android:visibility que siento por el nombre del método, en realidad está bien usar el operador ternario aquí. Debido al nombre isLoadingVisible y isContentVisible realmente no hay duda acerca de a qué se debe resolver cada resultado en la vista. Así que siento que es más bien ejecutar un comando dado por ViewModel en lugar de hacer realmente la lógica de visualización.

Por otro lado, estoy de acuerdo en que usar viewModel.isLoading ? View.VISIBLE : View.GONE sería algo malo porque está haciendo suposiciones en la vista qué significa ese estado para la vista.

Material util

Los siguientes recursos me han ayudado mucho para tratar de entender este concepto:

MVVM (Arquitectura) Ejemplos relacionados