En 2018, realicé un período de investigación sobre Android DataBinding (digamos que fue una investigación, y probablemente duró menos de dos semanas), pisé algunos pozos y puse el resumen en Evernote en ese momento. Hoy, por casualidad , Volví a las cosas que resumí antes, y siento que debería compartirlas. Espero poder ser útil para amigos que se encuentran con problemas similares.
El conjunto se divide en tres partes:
Escenarios de aplicación, desventajas, ventajas.
1. Escenarios de aplicación
1. Los campos de la pantalla son muchos y complejos, y están básicamente orientados a la visualización, con menos interacción.
2. Desventajas
1. El mensaje de aviso es doloroso cuando la compilación falla y se informa de un error.
tal como:
En realidad, este error se debe a un problema con la escritura del método de llamada en la pantalla y no se ha compilado.
el código se muestra a continuación:
<TextView
android:id="@+id/tv_order_state"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentRight="true"
android:textSize="@dimen/common_font_size_level_3"
android:textColor="@{orderDetailActivity.showOrderStateTextColor()}”/>Sin embargo, el informe de errores es básicamente información que no tiene nada que ver con este problema, lo más valioso es que se puede ubicar directamente en la información de error.
android:textColor="@{orderDetailActivity.showOrderStateTextColor()}”/>En esta línea, el resto de la información es básicamente inútil.
2. La página de aviso de error estático del editor xml es muy dolorosa. Los códigos que se ejecutan sin problemas también darán una tilde roja (este es el compilador usado en 18 años, y es mucho más inteligente que antes. Es posible que ya no vea la tilde roja en la captura de pantalla en la última versión 3.3 de AS).
tal como:
Aparece la línea roja y el mensaje de aviso es:
Pero el código real se puede ejecutar y se ejecuta sin problemas.
3. Cuando el método de escritura no es estándar, el mensaje de error que aparece no puede proporcionar referencia.
Por ejemplo, de acuerdo con el código escrito en la documentación oficial de enlace de datos:
Finalmente, habrá una advertencia después de que la compilación sea exitosa:
La solución en línea es eliminar el prefijo del atributo "binding:" en @BindingAdapter.
Personalmente me siento muy casita. Sin embargo, todavía no se han encontrado otras soluciones.
4. En la expresión y gramática de @DataBinding, los recursos mipmap no se admiten temporalmente.
En otras palabras, puede escribir esto en el archivo de diseño:
bind:error="@{@drawable/list_default}"Pero no puedes escribir así:
bind:error="@{@mipmap/list_default}"Se informará de un error al escribir mipmap. como sigue:
Muy sin palabras.
5. Las sugerencias de código en xml no son tan poderosas como las de los archivos java.
6. Si la clase de herramienta importada en xml necesita usar otros objetos de tipo no pojo, ¿cómo inyectarlo?
Respuesta: Inyecte según el método normal, no hay diferencia con pojo, pero a veces está limitado por algunos bugs del IDE, lo que provocará muchos problemas, como por ejemplo: el método que se ha generado claramente, el IDE genera un error cuando se llama. En este momento, debe reiniciar el IDE para volver a la normalidad.
7. En el archivo de plantilla de pantalla, el método correspondiente a la pantalla no se puede usar directamente y se requiere inyección, que es ligeramente diferente de AngularJS.
8. Para aquellos que no están familiarizados con el marco, muchos problemas son difíciles de localizar.
Por ejemplo, en la pantalla de detalles del producto, se usa el control de banner, pero la imagen no se muestra en vida o muerte. Si está escrita normalmente, debería mostrarse. Pero después de usar el marco de enlace de datos, no se puede mostrar este tipo de problema.
Más tarde, se descubrió que no era el problema del control de banner, sino el problema de olvidar llamar al método de inicio del control de banner. Sin embargo, debido al uso de un marco de enlace de datos, habrá alguna interferencia con la resolución de problemas.
9. El mensaje de error de compilación no es amigable:
Por ejemplo, me he encontrado con un problema:
提示 ： Error: (42, 34) No se puede encontrar el definidor para el atributo 'bind: imageUrl' con el tipo de parámetro java.lang.String en com.makeramen.undedimageview.RoundedImageView.
Sin embargo, bind: imageUrl y bind: error se declaran claramente en BindingAdapter, pero se informa de un error cuando se especifica bind: imageUrl.
La sugerencia es: no se puede encontrar el definidor de bind: imageUrl, pero esta propiedad se ha declarado con BindingAdapter.
De hecho, la verdadera razón es:
参见 url: http://blog.csdn.net/gdut_lemon/article/details/53330631
El mensaje incorrecto es realmente antipático. Puede considerarse básicamente inútil para los huevos.
10. La inyección del objeto debe realizarse manualmente y, a veces, se olvida el paso de inyección manual.
Por ejemplo: cuando se inyecta el evento onClick, aunque está escrito así:
android:onClick="@{fragment::onAllCommentsClick}"Sin embargo, si olvida llamar al método correspondiente para inyectar el objeto de fragmento en el código Java, este oyente no funcionará.
binding.setFragment(this);Y la inyección de este objeto de escucha es fácil de olvidar,
Porque en el desarrollo tradicional, podríamos escribir directamente en el control así:
android:onClick=“onBtnClick"En este momento, simplemente escriba un método en la Actividad correspondiente:
public void onBtnClick(View v){
// Do something
}Eso es. Esto ahorra un paso en comparación con DataBinding.
11. El marco de enlace de datos no admite el uso de las características proporcionadas por el marco en la etiqueta del fragmento. En otras palabras, no podemos vincular variables a la etiqueta de fragmento.
Si hacemos esto, se informará un error al compilar primero. El mensaje de error es: el enlace de datos no se puede utilizar en el fragmento (el significado de la indicación incorrecta en inglés traducida)
El segundo problema es
Cuando intente definir un @BindingAdapter para manejar Fragmento, se informará el siguiente error:
Error: (36, 24) 错误: @BindingAdapter bindFragmentParams (android.support.v4.app.Fragment, java.lang.String, java.lang.String) se aplica a un método que no toma una subclase de View como el primer o segundo parámetro. Cuando un BindingAdapter usa un DataBindingComponent, el parámetro del componente es el primero y el parámetro View es el segundo; de lo contrario, el parámetro View es el primero.
La traducción de las palabras anteriores es: si usa BindingAdapter para definir nuevas propiedades, el primer parámetro es un DataBindingComponent o una Vista; de lo contrario, no funcionará. El código de error es el siguiente:
@BindingAdapter({"bind:fragmentParamKey", "bind:fragmentParam"})
public static void bindFragmentParams(Fragment fragment, String paramKey,String param) {
Bundle bundle = new Bundle();
bundle.putString(paramKey,param);
fragment.setArguments(bundle);
}
12. Cuando se utiliza incluir para anidar en el diseño, el objeto de enlace no puede obtener los controles en el diseño de inclusión por id.
13. Al reconstruir recursos como cadenas de caracteres con parámetros, los nombres de las variables correspondientes en el archivo de diseño de enlace de datos no se pueden reconstruir directamente a través de la reconstrucción. tal como:
<TextView
android:id="@+id/tv_order_total_fee"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_centerVertical="true"
android:layout_toRightOf="@+id/tv_sum_title"
android:textColor="@color/common_warn_font_color"
android:textSize="@dimen/common_font_size_level_2"
android:text="@{@string/common_item_price(orderDetailModel.totalAmount)}"/>Aquí, si la variable de cadena se reconstruye en strings.xml y common_item_price se reconstruye a common_item_price_with_symbol, la parte roja del código aquí no se puede reconstruir directamente a través de la reconstrucción de AS. Debe modificarlo manualmente usted mismo.
14. CustomListView (utilizado para el control de lista anidado en ScrollView) tiene problemas cuando se usa el modo de desarrollo de enlace de datos para desarrollar Adapter. Principalmente reflejado en: Cuando el texto del control TextView en el elemento de la lista tiene más de una línea, hay un problema con el cálculo de la altura de la lista, lo que hace que la lista se muestre de forma incompleta (la altura de visualización real de la lista es menor que la altura real de la lista, lo que hace que parte del contenido se trunque).
Cuando se utiliza el modo de soporte tradicional para escribir el adaptador, no existe tal problema.
3. Ventajas:
1. El código se simplifica
Después de reescribir la pantalla de detalles del pedido con el marco de DataBinding, el código de Java 354-> 264 archivo de diseño: 537-> 510 (La reducción del código se debe a la optimización del diseño, por lo que esta parte en realidad no se reduce en circunstancias normales, pero en su lugar, habrá un aumento. Antes de que se optimice el diseño, es aproximadamente 537-> 550+, es decir, aproximadamente 20 líneas más)
Por lo tanto, la cantidad de código después de usar el enlace de datos se reduce en aproximadamente 70 líneas, y la cantidad total de código es 891-> 814, lo que reduce la cantidad de código en un 10%.
2. La lógica de la página se vuelve simple y clara.
Es como si la sensación de JQuery cambiara a Angular. Con el enlace de datos, no es necesario escribir una gran sección de código para el procesamiento de enlace de datos del control.
3. Elimina findViewById (en realidad, hace lo que ButterKnife hace por nosotros, pero el enlace de datos es más conveniente en el uso real, porque nos permite ni siquiera escribir anotaciones)
En un archivo de diseño que usa enlace de datos, siempre que especifiquemos un id para un control, se generará un control correspondiente al id correspondiente en el objeto de enlace correspondiente. Podemos referirnos directamente a este objeto a través del objeto vinculante.