Jetpack Compose para usuarios tardíos | de Jimly Asshiddiqy | mayo 2022

Foto de Edho Pratama en Unsplash

Para los que no estáis seguros de si aprender o no a componer mochilas propulsoras

Existe esta nueva biblioteca de tendencias en el desarrollo de aplicaciones de Android llamada componer, se anunció hace unos tres años en Google I/O 2019. Desde entonces, solo se ha vuelto más grande y mejor. Mucha gente dice que este es el final del uso de XML para diseñar aplicaciones en aplicaciones de Android. Y se han creado muchos tutoriales, se han publicado muchos cursos, se han desarrollado muchas bibliotecas para respaldar el ecosistema desde que Google lanzó la primera versión estable de Compose.Jetpack Compose en acción Cuando se lanzó por primera vez, pensé que probablemente pasaría mucho tiempo antes de que comenzara a usarlo en mi propio proyecto. Porque a primera vista parece mucho trabajo migrar nuestros proyectos actuales para comenzar a usar compose. Además, no tengo experiencia con IU declarativas, y solo leyendo la documentación parece estar aprendiendo muchos conceptos nuevos. Así que dudo en aprender composición en sus primeros días. Mirando hacia atrás, hubo un momento en que comencé a aprender a componer, pero la vista previa no funcionaba como cuando usaba XML. Cuando diseña una aplicación de Android con diseño XML, la vista previa se actualiza automáticamente y sin problemas con cada cambio que realiza en el archivo. Por otro lado, usar componer cuando se usa la vista previa requiere que construyas tu módulo y vuelvas a renderizar tus vistas previas cada vez que hagas cambios. Dejo de aprender de inmediato porque tiendo a hacer muchas revisiones y una vista previa me mantiene cuerdo mientras diseño la aplicación. Este año pensé que debería empezar a aprender a componer de nuevo. Y puedo decir que soy adicto a él, incluso el problema de la vista previa que mencioné antes ya no parece molestarme tanto. Si sus cambios son pequeños, como B. actualizando el relleno o el tamaño del ancho, la vista previa lo resolverá automáticamente, pero agregando un nuevo componente… no tanto el juego.

Este no es un tutorial sobre cómo usar la composición, solo algunas cosas peculiares que aprendí mientras aprendía a componer.

Interfaz de usuario imperativa frente a declarativa

En el desarrollo de aplicaciones móviles, existe una transición hacia una interfaz de usuario declarativa. No hace mucho tiempo, los desarrolladores de Android usaban XML para diseñar el diseño de su aplicación. Pero este archivo xml solo puede contener qué componente dentro del diseño y la configuración, como el color, el fondo o el contenido. Si luego necesita cambiar el contenido dinámicamente, como mostrar datos obtenidos de API/servicio web, debe hacerlo en su archivo Kotlin. Sin embargo, dado que su diseño está en un archivo XML y su código está en Kotlin, necesita una forma de hacer referencia a su componente XML en su código Kotlin. Hay muchas maneras de hacer esto, tales como:

• consulte manualmente findViewById para su ID
• ButterKnife, crear variable con anotación con ID de recurso como parámetro (obsoleto)
• Kotlin sintético, genere código adicional para acceder a su vista como si fueran propiedades con el nombre de su ID de recurso (obsoleto)
• ViewBinding/DataBinding, genere clases de enlace para cada diseño XML en su módulo con referencia directa a su componente

Esto se denomina interfaz de usuario imperativa porque primero se enfoca en cómo se muestran los datos. Y hay problemas con eso, p. B. cuando su aplicación puede volverse más compleja y es posible que necesite actualizar o configurar su aplicación en varios lugares. La interfaz de usuario declarativa resuelve este problema con un enfoque diferente. Se centra más en los datos que se muestran. Básicamente significa que está bien construir partes de su interfaz de usuario desde cero en lugar de modificarla, una CPU moderna lo suficientemente rápida como para hacerlo.

repensar

Mi opinión sobre esto es que el código está en Kotlin, no necesita una identificación de recurso como cuando usa XML, no necesita consultarlo después de crearlo. Pero entonces podrías asustarte y preguntar:

«¿Cómo los actualizamos más tarde?».

En lugar de cambiar o actualizar la interfaz de usuario cuando cambia el estado de la aplicación, describimos cómo se comporta la interfaz de usuario en condiciones de estado específicas. Eche un vistazo a este ejemplo de código: Estados de ejemplo en redacción

Si está familiarizado con Kotlin, el código como el siguiente probablemente debería ser intuitivo para usted

Tenemos un texto que muestra cuántos vasos de agua hemos bebido cada vez que pulsamos el botón. Entonces, en lugar de actualizar el contenido del texto cada vez que se hace clic en el botón, creamos una variable que contiene el número de agua como Condición y actualice la variable cada vez que se haga clic en el botón.Core UI Update LoopUsando la imagen a continuación como referencia:

• El evento es cuando se hace clic en el botón.
• Actualizar estado, el valor actual actualizado es contar +1
• Indica el estado, el contenido del texto cambia

Estado federal determina lo que se muestra en la interfaz de usuario en un momento dado. Puede crear casi cualquier cosa como estado, p. B. tipos básicos (String, Boolean, Int) e incluso recursos (String, Color, Drawable y Dimension). Y cuando se actualice su estadística, todos los componentes que la usaron se actualizarán en consecuencia. Y ese es el corazón de la interfaz de usuario declarativa en Jetpack Compose. No llevará mucho tiempo acostumbrarse a usar estados en su código. Más tarde, todo su código de actividad podría estar en la función de redacción.

Implementalo en tu proyecto

Probablemente te estés preguntando cuántos cambios se realizarán en la implementación/migración del proyecto actual para usar Jetpack Compose. Si su proyecto ya ha implementado una arquitectura de código limpio, no se realizarán muchos cambios.Arquitectura de código limpioPorque Jetpack Compose es solo una biblioteca que describe cómo funciona y se muestra su interfaz de usuario, solo suya diapositiva tendrá que cambiar. El resto de su código, como obtener datos de la API, almacenar y manipular datos en la base de datos local, funcionará según lo diseñado con Jetpack Compose. Incluso puede migrar gradualmente su código para adoptar Compose, ya que Compose y Android View funcionan bien juntos. Más sobre esto aquí.

Ver datos de la lista

Para comprender lo fácil que es usar componer, tomemos un ejemplo cuando queremos mostrar una lista de datos. En la era XML, probablemente usaremos RecyclerView. Y los pasos podrían verse así:

• Crear Adaptador y ViewHolder con Array/List para almacenar datos en RecyclerView
• Agregue RecyclerView al diseño XML
• Configure RecyclerView con Layout Manager y agregue el adaptador
• (opcional) Si sus datos no están listos cuando se inicializa RecyclerView, debe agregar los datos a la lista en el adaptador para actualizarlos

Hay muchos pasos que se deben realizar solo para ver la lista de datos. Sin embargo, use componer porque todo el diseño, la configuración y el estado se almacenan en la función componible. Para que ya no tenga que hacer tanto, veamos este ejemplo: Función Compose para mostrar la lista de objetos Con Compose puede hacer lo siguiente:

• El administrador de diseño no es necesario, puede definir cómo se muestra la lista en el diseño integrado. Por ejemplo, use LazyColumn para visualización vertical y LazyRow para visualización horizontal
• Cree una nueva función de composición y agregue el objeto de datos como parámetro. Cualquier acción como hacer clic se puede configurar en él.

Y eso es todo, no se necesita adaptador ni ViewHolder. Como puede ver, el uso de componer lo ayuda a escribir menos código y puede trabajar con menos archivos. Solo por esta razón, algunos desarrolladores están ansiosos por aprender más sobre Compose.

RestricciónLayout

Creo firmemente que creará un mejor diseño con ConstraintLayout. Porque si está pensando en una interfaz de usuario receptiva, usar ConstraintLayout realmente tiene sentido. Al principio pensé que sería difícil implementar ConstraintLayout con Compose ya que no usamos una identificación de recurso para agregar restricciones. Hay una implementación de ConstraintLayout que puede usar agregando esto a su configuración de Gradle: dependencia para ConstraintLayoutFirst, en lugar de usar una identificación de recurso como cuando se diseña en XML ConstraintLayout en redacción con referencia, usa createRefs() o createRefFor(). Echemos un vistazo al ejemplo: la muestra de ConstraintLayout en Compose dará como resultado una interfaz de usuario como esta:Ejemplo de ConstaintLayout Cuando comienza un nuevo proyecto de Android, debe responder a la pregunta de qué arquitectura usaremos para desarrollarlo.

• ¿El uso de múltiples actividades sigue siendo relevante?
• ¿Utilizamos Fragment Back Stack manualmente?
• ¿O implementamos una arquitectura de actividad única con navegación jetpack?

Hoy en día, las personas usan componentes de navegación y usan una sola actividad como contenedor y una lista de fragmentos como página de la aplicación. Hay algunos problemas a los que me enfrento cuando uso el componente de navegación, como: B. Sincronizar el ciclo de vida de la Actividad y el Fragmento porque tienen su propio ciclo de vida. Antes de usar Lifecycle Observer, es bastante difícil definir qué función se ejecuta en qué ciclo de vida cuando se usa Fragment.Por Süleyman BaşaranoğluUsar la navegación para componer no es lo mismo que usar el componente de navegación. La diferencia que noto es esta:

• Al navegar para redactar, no se llega a una sola actividad usando una lista de fragmentos, sino que usa las funciones de redacción como objetivo
• El gráfico de navegación no se crea con XML sino en Kotlin dentro de la función de redacción.

Por ejemplo, veamos: Navegación en Compose SampleTwitter desarrollará funciones adicionales en Jetpack ComposeTwitter anuncia que desarrollará funciones adicionales en Jetpack Compose. Entonces, ¿qué hay de nosotros? ¿Deberíamos? Mi experiencia con Compose hasta ahora es buena y creo que es una tecnología revolucionaria. Usarlo cambia tu mentalidad al desarrollar aplicaciones y también reduce tu código, lo cual es bueno. Desarrollar más código en un lenguaje también es algo bueno. Dije que puede crear NavGraph usando Navigation for Compose, pero en realidad ya puede hacerlo con el componente Navigation. El lado positivo es usar Compose, no solo puedes diseñar tu aplicación con Kotlin, sino que tus recursos como el estilo, los colores, la tipografía e incluso los elementos de diseño (llamados ImageVector en Compose) también se pueden escribir en Kotlin.