DataBinding aún utilizan el procesamiento de datos dolores de cabeza? Este artículo a resolver el problema

prefacio

En años anteriores, el patrón de diseño MVVM arquitectura de subida, el más representativo de la trama es DataBinding, aunque este diseño de la arquitectura es muy innovador, pero todavía en uso, hay muchos puntos de dolor, así que pensé que este corto período de tiempo no puede ser demasiado diseño de la arquitectura popular.

Recientemente se hizo cargo del nuevo proyecto, está usando MVVM, sólo para encontrar sólo uno o dos años de desarrollo MVVM esfuerzo aún tan pronto, ya que es una de las habilidades necesarias para los desarrolladores de Android.

texto

Enlace de datos en las etapas iniciales, que era más problemático es el problema del tratamiento de los datos, a menudo con el fin de mostrar los datos, quiero unir una pluralidad de campo N en XML, si está por encima de la media de un proyecto, hay más dolor problema del huevo, Por ejemplo:

• El archivo XML, puede necesitar urgente o si dicho interruptor de una decisión;
• puntero nulo inesperada

En 2018, Google lanzó biblioteca JetPack, que MVVM modelo de vista + LiveData finalmente empujó a nuevas alturas.

ViewModel

Uso modelo de vista se basa biblioteca de ciclo de vida:

implementation "android.arch.lifecycle:viewmodel:x.x.x"
implementation "android.arch.lifecycle:extensions:x.x.x"

ViewModel creado son principalmente de dos maneras:

// 获取FragmentActivity共享的ViewModel
ViewModelProviders.of(FragmentActivity).get(ViewModel::class.java)

// 获取FragmentActivity共享的ViewModel
ViewModelProviders.of(Fragment).get(ViewModel::class.java)

Compartir gama modelo de vista son principalmente dos: uno es FragmentActivity, uno es Fragmento, se puede optar por compartir un rango de acuerdo a sus necesidades. Si desea un modelo de vista a nivel de aplicación, no se admite actualmente, puede personalizar la aplicación para sostener un modelo de vista, o utilizar un producto único.

problema ViewModel

1, la expansión de intercambio de datos de escenarios.

el intercambio de datos general y la transferencia de datos Fragmento de actividad, la práctica tradicional es utilizar setArguments (paquete), este método tiene los siguientes inconvenientes:

• SetArguments pueden no ser capaces de predecir que será completado en el período Fragmento, a la determinación de anormalidad conducta;
• Los datos pueden ser encontrados cambio setArguments, si los datos se proporcionan directamente Fragmento Actividad, el acoplamiento es muy alta;
• Cuando más datos, Fragmento hay muchas variables que afectan a la legibilidad y facilidad de mantenimiento.

uso modelo de vista, para evitar la situación más embarazosa, lo que los datos que se necesita para tomar desde el modelo de vista:

• Nueva transferencia de datos adicionales, sin modificar el código de los setArguments actividad, métodos Fragmento No escriba los datos recibidos;
• Reducir la transferencia de datos, independientemente de si desea eliminar el código temporalmente sin usar;
• Cuando ir a buscar los datos, tenga en cuenta la validez de los datos, que puede hacer el juicio;

Además, la vista personalizada también puede obtener modelo de vista, por lo que algunas de las características de la muy fuerte acoplamiento de vistas personalizadas para desarrollar más conveniente. Pero tenga en cuenta que el contexto es el contexto del tipo Ver actividad (no fragmento), sólo se puede utilizar el nivel de actividad de intercambio de datos.

2, para resolver el problema de visualización de vista DataBinding.

Si la vista requiere una gran cantidad de datos, el XML se hará más y más hinchado, y la urgente necesidad de añadir algunas sentencias simples, tales como:

Si A es descargada aparece B, si B está vacía en la primera C, si C está vacía ...

Aunque DataBinding apoyar el operador ternario para satisfacer las necesidades Si los juicios, es claro que el mantenimiento de la lógica XML de Java o Kotlin mucho más difícil (sin error de ortografía, etc.). Así que realmente necesitamos para separar algo de código a partir de XML, modelo de vista es muy cualificado para este papel.

Antes de la modificación:

<?xml version="1.0" encoding="utf-8"?>
<layout>

    <data>

        <variable
                name="A"
                type="String" />

        <variable
                name="B"
                type="String" />

        <variable
                name="C"
                type="String" />

    </data>

     <TextView
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:maxLines="4"
                android:ellipsize="middle"
                android:text="A != null ? A : B != null ? B : C" />
    ...

</layout>

modificado:

<?xml version="1.0" encoding="utf-8"?>
<layout>

    <data>

        <variable
                name="viewModel"
                type="ViewModel" />

    </data>

    <TextView
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:maxLines="4"
                android:ellipsize="middle"
                android:text="@{viewModel.getShowContent()}" />
...

</layout>

Datos en tiempo real

La mejor manera que acabamos de discutir el uso del modelo de vista, pero hay un problema no se resuelve, se actualiza los datos y resolver este problema es a modo de observador, pero si no se ocupó de la reconciliación de registro del observador atada propensos desbordamiento de la memoria. LiveData puede ser la solución perfecta a este problema.

Tenemos que añadir la dependencia LiveData:

implementation "androidx.lifecycle:lifecycle-livedata:2.1.0"

El siguiente es un ejemplo sencillo:

// 名为openDrawer的Boolean类型的LiveData
public final MutableLiveData<Boolean> openDrawer = new MutableLiveData<>();

// 更新openDrawer 
openDrawer.setValue(true)

// 观察openDrawer 的值的变化
openDrawer.observe(this, aBoolean -> {
             Toast.makeText(this, "${aBoolean}", Toast.LENGTH_SHORT).show();
        });

LiveData subclase es MutableLiveData, propiedad valor interno mantiene el último valor, la suscripción cambia LiveData llame directamente LiveData.observe ():

anulará la observan pública (propietario @NonNull LifecycleOwner, @NonNull el Observador Observador <Super T?>)
propietario: plazo de inscripción, será destruida cuando el propietario, la desagregación de observador.
observador: valor observado de la función de devolución de llamada se cambia

propietario puede utilizar directamente la actividad o fragmento. Si usted no sabe el uso del ciclo de vida, se puede ver en la información relevante.

resumen

Por último, dibujé una arquitectura diagrama, resumió lo que el uso de la última arquitectura MVVM:

Actividad: cuestiones mango de interfaz de usuario, pero para ello deben evitarse en la medida de lo posible DataBinding uso constante.
ViewModel: Guardar la página de datos requerido, funciones complejas se puede dividir en varias palabras.
Enlace de datos: Vista de procesamiento de interfaz de usuario, mantenga modelo de vista para la visualización de datos. Si la función de la página es más compleja, se puede dividir de nuevo modelo de vista y DataBinding.

Si usted tiene incluso mejor comprensión de MVVM, mensaje de bienvenida aprender juntos.
Lectura recomendada: 2017-2020 años byte superando entrevista Android Zhenti determinación (un total de 10,82 millones de tiempos de descarga para la actualización)

Autor: El Principito Everest
enlace: https: //www.jianshu.com/p/a2eb8e1807ef