DataBinding es un marco lanzado oficialmente por Google. El marco mvvm que está directamente vinculado en función de los datos de la página fue inicialmente sorprendente cuando se contactó. Puede enlazar datos directamente en archivos xml y obtener controles de identificación directamente a través de la clase Binding. El monitoreo de datos puede modificar directamente los datos para cambiar los datos de la página, incluso si la página se usa en varios lugares. Pero ahora decidí abandonarlo. Los motivos se enumeran a continuación.
1. Retraso de compilación
La compilación de DataBinging no es oportuna. Después de haber escrito el diseño del archivo xml, no podemos encontrar directamente la clase Binding correspondiente al archivo xml, pero solo podemos encontrar la clase Binding después del Proyecto de reconstrucción. Después de agregar la identificación de un control en el archivo xml, No puede hacer referencia directa a este control, sino también a Rebuild Project . De hecho, cualquier modificación al archivo xml debe ser Rebuild Project , el enlace de datos tendrá efecto, a diferencia del archivo R, no necesitamos realizar operaciones adicionales después de la modificación, el archivo R Va a cambiar Y esto afectará la velocidad de codificación.
2. Muchas funciones inútiles
DataBinding puede enlazar directamente el evento click en el archivo xml, y el evento de enlace puede activarse cuando se cambia la propiedad (el método de DataBinding cambia). Sin embargo, estas funciones aparentemente hermosas nunca han sido utilizadas por mí en esencia.
3. Archivo de diseño complejo
Podemos escribir el siguiente código:
<data>
<variable
name="bean"
type="***.ConsignmentDetailBean"/>
</data>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#f4f4f4"
android:orientation="vertical">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_marginRight="15dp"
android:text="@{bean.createTime}"
android:textColor="@color/colorTextWhite"
android:textSize="15sp"
tools:text="2018/08/12 12:20:20" />
</LinearLayout>Después de obtener la clase de entidad de datos a través de la solicitud de red, úsela mBinding.setBean(bean);para establecer los datos. Sin embargo, cuando deseamos realizar algunas configuraciones de formato para el tiempo obtenido, primero debemos escribir una clase de conversión de tiempo y luego llamarla de la siguiente manera:
<import type="com.saiot.steward.baseLib.util.TimeUtil"/>
android:text="@{TimeUtil.formatTime(bean.createTime)}"Por supuesto, también puede hacerlo en el método get de la clase de entidad, pero el manejo de DataBinding es realmente más problemático. Porque las funciones directamente compatibles con DataBinding son limitadas.
Si no usa DataBinding, solo tenemos que hacer el procesamiento de formato en el tiempo establecido.
Existe otra situación, por ejemplo, la interfaz debe mostrarse de la siguiente manera: "Hoy debe hacerse (10)", y luego la interfaz devuelve 10 a nuestra interfaz, luego tenemos que hacer esto en DataBinding:
android:test="{@string/a+bean.value+@string/b}"Entre ellos, ayb se definen en el archivo de recursos "to-do today (" y ")", y no se pueden empalmar directamente en el archivo XML.
4. Desarrollo de módulos múltiples
Si los problemas anteriores son problemas pequeños que no son lo suficientemente convenientes para mí, entonces el problema con el desarrollo de múltiples módulos es la razón principal por la que me di por vencido.
Cuando DataBinding se desarrolla en múltiples módulos, existe un mecanismo de este tipo:
-Si el submódulo usa DataBinding, entonces el módulo principal también debe agregarse a la configuración de Gradle, de lo contrario se informará un error; -Si el
módulo principal y el submódulo se agregan a la configuración de DataBinding Luego, en el momento de la compilación, la clase Binding generada por el archivo XML del submódulo tendrá una copia debajo del módulo principal además de su propia compilación.
Luego, si el módulo principal y el submódulo tienen un activity_main.xml en el directorio raíz del diseño, el ActivityMainBinding generado por el módulo principal se generará en función del archivo del submódulo. En este caso, también podemos usar diferentes nombres para el módulo principal y los submódulos, entonces el siguiente problema será mortal:
Si algún archivo xml del submódulo usa algunos controles de terceros, el módulo principal también generará la clase Binding de este archivo y tendrá referencias a controles de terceros. En este momento, debido a que el módulo principal no introduce estos controles, entonces Se informará un error, y la solución es usar el método API cuando el control de terceros se aplica al submódulo, de modo que el módulo principal se refiera firmemente a estos controles de terceros, lo que viola el principio de desacoplamiento.
