proyectos - ¿Cuáles son los pros y los contras de la vinculación de datos de Android?

importar base de datos sqlite android

Question

Tanto mi colega como yo tenemos experiencia en MVVM de la aplicación web, mientras que somos nuevos en el desarrollo nativo de Android. Ahora tenemos opiniones contrarias sobre el enlace de datos de Android: soy un fanático de él mientras que él no lo es.

Mis Argumentos:

• Reduce el código repetitivo que a su vez trae
  • Menos acoplamiento
  • Mayor legibilidad
• Potente, fácil de implementar atributo personalizado y vista personalizada
• Incluso más rápido que findViewById ( details )

Sus Argumentos:

• El .class generado automáticamente aumenta el tamaño de la aplicación.
• Más difícil de depurar

He hecho algunas investigaciones pero no hay muchas discusiones al respecto. Ahora quiero recopilar los pros y los contras de la vinculación de datos de Android.

Los aspectos de discusión incluyen pero no se limitan a:

• prueba de unidad
• tamaño de la aplicación
• actuación
• curva de aprendizaje
• legibilidad
• acoplamiento

Answer 1

Incluso si me gusta la respuesta de Danypata, me gustaría agregar / editar algunas de sus declaraciones al enlace de datos de Android.

1.Elimine el código repetitivo : tal como está escrito en la respuesta de los danypatas, elimina algunos códigos y agrega otros códigos en otro lugar, como en los diseños. Eso no significa que el boilercode no se reduzca porque generalmente se reduce.

Por ejemplo, es posible que desee crear un adaptador de enlace, que maneja varios adaptadores de matriz personalizados para su spinner / recyclerview / listview / .. pero solo requiere un adaptador simple. Es posible que desee utilizar el adaptador en su diseño mediante, por ejemplo,

app:myCoolAdaptersData="@{model.mydata}"

Ahora puede crear su adaptador genérico y (re) usar su adaptador de enlace en todos sus diseños en lugar de usar, por ejemplo:

ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);

Este es solo un ejemplo simple que recurre el código mucho en proyectos más grandes. Otro ejemplo para recudir el código es que vincula su modelo a su diseño. La actualización de los valores de campo de su modelo generalmente actualiza también su modelo (si es al menos un BaseObservable / ObservableField).

Eso significa que no necesita encontrar todas sus vistas, actualizar sus vistas, actualizar sus modelos, ...

2. Mayor legibilidad : el tiempo extra dedicado a aprender el enlace de datos no es realmente importante. Dado que los diseños no son realmente diferentes, excepto que los envuelve en una etiqueta de diseño y coloca sus espacios de nombres allí, realmente no difiere de los diseños "normales". El uso de los adaptadores de enlace y el acceso al modelo en el diseño puede demorar un poco, pero por lo general puede comenzar con los conceptos básicos que también son fáciles y hermosos de usar. Aprender cosas nuevas siempre lleva tiempo, pero después de un tiempo se revisará fácilmente el tiempo de uso del enlace de datos.

3.Powerful - Sí, es muy poderoso. Es más fácil reutilizar el código existente, reutilizar los adaptadores de enlace existentes y puede llevar a un código más generado, pero eso no siempre es cierto. Por ejemplo, puede crear múltiples adaptadores dentro de varias clases en lugar de crear un adaptador de enlace, puede ser difícil "optimizarlo" más tarde. La optimización de Bindingadapter significa que se actualiza en todas partes. La optimización puede disminuir las "líneas de código" ya que el lugar de la caldera se reduce de todos modos.

Estoy de acuerdo con 4. y 5.

6. Difícil de depurar Dado que AS 3.0+ genera sugerencias útiles como problemas de sintaxis en su diseño (número de línea y archivo) es fácil de depurar el código generado por el enlace de datos. Si tiene problemas para encontrar el problema, es posible que también desee buscar errores en el código generado. Algunas bibliotecas como dagger 2 o android architecture library pueden confundirlo porque las líneas de error no coinciden con el "error" real. Este es debido código generado por otros procesadores de anotación. Si sabe que esos procesadores de anotación pueden tener problemas con las salidas de error de enlaces de datos, puede solucionarlo fácilmente.

7. Pruebas de unidad Es posible si no usa el enlace de datos usando executePendingBindings.

8. Legibilidad La legibilidad puede ser mejor sin el enlace de datos. Ya que coloca cierta lógica de negocios en su diseño, otra en su código real, puede llevar a un código de espagueti. Otro problema es que el uso de lambdas en su diseño puede ser muy confuso si el "diseñador de diseño" no sabe qué parámetro se puede usar.

Otro gran problema es que bindingapapter puede estar en todas partes. El uso de la anotación BindingAdapter genera el código. Eso significa que usar esto en su diseño puede llevar a problemas para encontrar el código adecuado. Si desea actualizar un enlace de enlace debe "buscarlo".

¿Cuándo deberías usar qué? Para proyectos más grandes, es una muy buena idea usar el enlace de datos junto con el patrón mvvm o mvp. Esta es una solución realmente limpia y muy fácil de extender. Si solo desea crear una aplicación pequeña y sencilla, puede utilizar MVC Pattern sin enlace de datos. Si tiene adaptadores de enlace genéricos existentes que se pueden usar de otros proyectos, es posible que desee utilizar el enlace de datos, porque es fácil reutilizar este código.

Answer 2

Primero comentaré sus argumentos y luego expresaré mi opinión:

1.Elimine el código de repetición: eliminará algunos, solo moverá algunos en el xml o requerirá clases adicionales. Por lo tanto, debe tener cuidado y equilibrar el uso del enlace de datos.

2. Facilidad de lectura: depende si usted es un desarrollador nuevo, entonces puede que le resulte fácil aprenderlo, pero si trabajó anteriormente en Android, necesitará tiempo adicional para aprenderlo.

3. Potente: el código tiene más poder, puedes implementar lo que quieras en el código. Piénselo así, todo lo que implementa utilizando enlace de datos tiene un código equivalente (puede ser más largo y más código para escribir), pero la reversa no es válida.

4. Incluso más rápido que findViewById : comparar la velocidad entre estos dos, en mi opinión es inútil, nunca notará la diferencia, si ve alguna diferencia, entonces una de las implementaciones es incorrecta.

5. Clase generada automáticamente: es cierto que aumentará el tamaño de la aplicación, pero de nuevo solo si tiene toneladas de ella, será importante. Es cierto que en el sitio web de desarrolladores de Android afirman que es un poco mal usar bibliotecas que crean código generado automáticamente o annotations que generarán código adicional.

6. La dificultad de depurar: depende, al igual que la legibilidad, de lo que está acostumbrado, ya que la depuración es difícil para algunos problemas, y mejorará al depurar, no utilizando una biblioteca diferente.

Así que esto es solo mi opinión, he desarrollado muchas aplicaciones que utilizan diferentes bibliotecas y diferentes enfoques, y todas tienen ventajas y desventajas, pero lo que he aprendido: equilibrar todo, no usar toneladas de bibliotecas, no desperdiciar tiempo implementando cosas que ya están implementadas y funcionan bien, no "desacoplar todo", no "acoplar" todo, no usar solo el código, no intentar "generar" todo.

Creo que está muy mal, y puedes tener una idea equivocada, si pides ''pros y contras'' sobre alguna biblioteca / implementación, porque generalmente no será imparcial, obtendrás muchos pros de alguien que usó el La biblioteca de una manera específica y funcionó y otras le darán contras porque usaron diferentes y no funcionó.

Entonces, en conclusión, creo que debería comprobar qué puede hacer la biblioteca por usted y qué no puede hacer por usted y decidir si es bueno para su configuración. En otras palabras, debe decidir si una biblioteca es buena para usted, no para otras personas;).

Actualización - 8 de agosto de 2018

En primer lugar, sigo con mi conclusión inicial, el equilibrio es la clave en este tipo de situaciones, pero en mi caso, el enlace de datos acelera un poco el proceso de desarrollo y también lo mejora. Aquí hay algunos puntos nuevos en los que todos deberían pensar.

1. Probar la interfaz de usuario: con el enlace de datos es mucho más fácil probar la interfaz de usuario, pero el enlace de datos no es suficiente para eso, también se necesita una buena arquitectura y utilizar la arquitectura sugerida por Google mostrará el poder real del enlace de datos.

2. Los cambios más visibles se proporcionaron para los puntos 2 y 5 de mi respuesta original. De alguna manera, fue más fácil leer el código después de que decidimos usar el enlace de datos, y lo más importante aquí es que, como equipo, decidimos que usaremos el enlace de datos y después de eso, esperamos que tengamos la mayor parte de La configuración trivial y básica de la interfaz de usuario en el archivo XML.

Para la parte de depuración, aquí es un poco complicado, Android Studio tiene mucho que mejorar en los errores y el autocompletar para el enlace de datos, pero los errores más comunes los obtendrás después de las primeras 2 o 3 apariciones. También he aprendido que un "proyecto limpio" se forma de vez en cuando, ayuda MUCHO.

3. Otro punto que deberá tener en cuenta es la configuración del proyecto para usar el enlace de datos, en este momento AS (3.1) admite el enlace de datos predeterminado (solo establezca una marca en graddle) para Java, pero tuve algunos problemas con Kotlin, después de un poco de búsqueda aquí en SO, me las arreglé para arreglarlo todo.

Como segunda conclusión (de mi publicación original), si puede y el plazo / los requisitos / etc del proyecto le permite probar el enlace de datos, valdrá la pena (a menos que haga algo realmente estúpido :)).