Bienvenido a nuestro sitio web, en este lugar vas a hallar la solucíon que estás buscando.
Solución:
Al diseñar la aplicación móvil, me gustaría abordar las siguientes preguntas:
¿Es un buen caso de uso usar Litho? ¿O usar un RecyclerView es suficiente?
-
¿Las vistas se están reciclando correctamente?
Lo que significa para nosotros es considerar, crear 40-50 vistas por pantalla y, a medida que el usuario sale de la vista, el sistema no debe marcar todas las vistas para GC, sino que debe estar dentro de algún tipo de lista archivada y, como lo requerimos nuevamente, deberíamos ser capaz de obtener de él.
¿Por qué necesitamos eso? GC es la operación más costosa que causaría fluctuaciones en la representación de la aplicación, tratamos de minimizar el GC para llamar en este punto al no borrar las vistas
Para esto, me gustaría ir con litho, la justificación está aquí ya que su requisito parece tener más recuento variable de
viewtypesreferenciaConclusión: Litho +1, RecyclerView +0
¿Qué pasa con el estado de mis vistas? Si uso un patrón de reciclaje, ¿podría mantener el estado de cada uno de mis campos (incluso los que están fuera de la pantalla) y así poder guardar el formulario sin perder datos?
-
Guardar contenido de EditText en RecyclerView Este es uno de los componentes, pero también se debe aplicar la misma lógica a la casilla de verificación o al botón de opción. o como en mantenimiento del estado para litho está aquí
Conclusión: Litho +1, RecyclerView +1 tienen API específicas para lograr el mantenimiento del estado
Si uso un patrón de reciclaje para mostrar un formulario, ¿cómo manejaría varios formularios? ¿Podemos haber anidado RecyclerView? Los formularios deben mostrarse uno tras otro como dentro de un RV vertical, pero si los formularios en sí son RV, ¿cómo debo manejar esto?
- Esto debe abordarse con la experiencia del usuario más la capacidad técnica: Según el comportamiento del usuario en mi humilde opinión, desaconsejo el desplazamiento vertical anidado, sin embargo, otros pudieron lograrlo, puede encontrar fácilmente cómo hacerlo en SO. La solución óptima sería tener desplazamiento horizontal dentro de la vista del reciclador de Andriod o litho como aquí
NOTA: Si necesita conocer los detalles de implementación, plantéelo como una pregunta separadame encantaría ayudar allí
ACTUALIZACIÓN #1:
El problema con esto es que con formularios grandes (como> 20 campos), necesita inflar muchas vistas y el subproceso de la interfaz de usuario sufre mucho.
La creación/diseño de la interfaz de usuario se debe realizar en el backend, solo se debe agregar a la vista en el subproceso de la interfaz de usuario. Y litho lo hace incorporado. Sin embargo, también se puede lograr la vista del reciclador nativo, pero debe salir del subproceso de la interfaz de usuario y publicar periódicamente en la interfaz de usuario.
Ok, tienes dos problemas separados aquí. Uno es sobrecargar el subproceso de la interfaz de usuario y el otro es mantener el estado de sus vistas anónimas. Sobre la primera parte:
1.-Litho podría ayudarte con esto. Pero debe mover toda su lógica hacia los componentes litográficos en lugar de los widgets de Android. Como no conozco su base de código, no sé qué tan difícil puede ser. Una vista de reciclador ayudaría a ver el reciclaje, pero eso solo importa si está bien, usando una lista.
2.-Podría, siempre que tenga una forma de mantener una representación del estado del widget que pueda pasar al adaptador y luego volver a la vista (supongo que genera todas las ventanas por código y luego tiene cero referencia a ellos) y así. Suena desordenado, y es desordenado, así que no lo intentaré.
3.-Puedes, pero es desordenado. El mejor enfoque en este caso sería tener vistas de recicladores horizontales dentro de una vista de recicladores vertical. Anidar vistas de recicladores dentro de otra vista de recicladores con la misma dirección crea problemas divertidos, como “¿Por qué esta celda no se desplaza?”. Evitaría usar recyclerview como padre si la vista no lo necesita.
Ahora, a las soluciones:
A) Sobrecarga de la interfaz de usuario: de acuerdo con su pseudocódigo, no está inflando cosas. Está creando objetos Java que resultan ser subclases de View. Eso es bueno, porque crear objetos en un subproceso en segundo plano es mucho más fácil que inflar (analizar XML y usarlo como argumentos para generar copias idénticas de un recurso determinado invocando constructores) en un subproceso en segundo plano. Mientras que un constructor de contexto LinearLayout requiere que se ejecute un subproceso de interfaz de usuario, otras cosas, como las vistas de texto, no lo requieren. Por lo tanto, puede crear los últimos dentro de una tarea asincrónica y, una vez que haya terminado de generar toda su jerarquía, ejecute los métodos que necesitan el subproceso de la interfaz de usuario y agregue el diseño generado a la ventana. Para las clases de vista que no admiten la creación como objetos Java de forma asíncrona, puede tener un archivo XML solo con ese componente, como linearLayout, y crearlo de forma asíncrona con el paquete de soporte asyncLayoutInflater. esta solución se puede implementar en cualquier base de código y le permitiría generar una interfaz de usuario completamente asíncrona.
B) Hacer un seguimiento del estado de la vista: nuevamente, asumo que su jerarquía de vista es anónima. Si es así, lo que necesita es generar una interfaz que pueda usar como un contrato para invocar tanto el estado de guardado como el estado de carga desde un componente consciente del ciclo de vida, como la actividad. Después de crear dicha interfaz, subclasifique los widgets y cree un sistema de bus de suscripción/evento en cada widget que guarde/cargue el estado del widget cada vez que se active. De esa forma, cada uno de los componentes de la pantalla sería capaz de recordar su estado permaneciendo en el anonimato.
Simplemente use RecyclerView y cree vistas en tiempo de ejecución (no está inflando, está creando instancias). La creación y adición dinámica de vistas no debería ralentizar considerablemente el subproceso de la interfaz de usuario en dispositivos de rango medio. Si es así, investigue los cuellos de botella en otros lugares
Puede realizar un punto de referencia simple agregando/eliminando/estableciendo texto con muchas vistas dinámicamente dentro de un RecyclerView o incluso un LinearLayout alojado por un ScrollView, y verá que funciona sin problemas.
Agradecemos que desees añadir valor a nuestra información colaborando tu veteranía en las críticas.