Effective Android UI - spanish

Effective Android UI
Pedro Vicente Gómez Sánchez - Mobile Software Engineer, Tuenti Technologies.
@pedro_g_s , @TuentiEng
pgomez@tuenti.com

http://corporate.tuenti.com/es/dev/blog - @TuentiEng
http://corporate.tuenti.com/es/jobs
Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s

Esta charla es la continuación de Software Design Patterns on Android
Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com
http://www.slideshare.net/PedroVicenteGmezSnch/software-design-patterns-on-android

¿Es el código de UI menos
importante?
¿Aprovechamos bien los recursos
que Android nos ofrece?

● Introducción.
● Recursos y configuraciones.
● Custom Views.
● Model View Presenter.
● Model View ViewModel.
● MVP vs MVVM
● Consejos prácticos.

https://github.com/pedrovgs/EffectiveAndroidUI

Introducción
https://github.com/pedrovgs/EffectiveAndroidUI
● Ejemplos de MVP y MVVP.
● Como trabajar con fragments.
● Comunicación entre fragments y activities.
● Como implementar inyección de dependencias con
Dagger.
● Como utilizar recursos para soportar diferentes tamaños
de pantalla, landscape-portrait y diferentes versiones de
Android.
● Cómo utilizar estilos y temas.
● Como utilizar Navigator o ActionCommand para
implementar la navegación.
● Como utilizar custom qualifiers con recursos.
● Uso de diferentes layouts: RelativeLayout, LinearLayout,
FrameLayout.
● Uso de merge, inflate y view stub.
● Implementación de ListView con reciclado basada en
Renderers.
● Implementación de interactors descrita en la charla
"Software Design Patterns on Android".
● Uso de Dagger con diferentes ámbitos: ámbito de
aplicación y ámbito de Activity.

Introducción: S4 - Android 4.4.2

Introducción: DraggablePanel
https://github.com/pedrovgs/DraggablePanel

Introducción: MDPI device

Introducción: Nexus 7 y Nexus 10 - Android 4.4.4
Portrait Landscape

Recursos y configuraciones
Los recursos son una de las herramientas más potentes que
tiene Android para trabajar con UI. Los principales tipos de recursos son:
● Color: Colores disponibles en la aplicación. En el fichero colors.xml se define
la paleta de colores de la app.
● Drawable: Permite definir los drawables de la aplicación (normalmente
shapes y assets).
● Layout: Directorio donde debemos situar todos los layouts de la
aplicación.
● Menu: Directorio donde deberemos situar los menús que utilicemos en la
aplicación.
● Integer: Fichero integers.xml en el que deberemos guardar valores de tipo
entero.
● XML: Directorio en el que podemos guardar ficheros de configuración en
formato xml (no muy usado)

Para proyectos complejos en los que tenemos que soportar miles de dispositivos diferentes con
versiones de Android ejecutando nuestra aplicación necesitamos exprimir la potencia de los recursos
al máximo.
Para sacar todo el jugo de los recursos de Android deberemos utilizar qualifiers. Los qualifiers nos
permitirán aplicar configuraciones diferentes de recursos en función de diferentes elementos:
● Densidad de pantalla : ldpi, mdpi, hdpi, xhdpi, etc
● Idioma: es, en, fr, en-rUS, etc
● Ancho mínimo: sw600dp, sw720dip la menor dimensión soportada. Usado para configuraciones de tablets.
● Ancho o alto disponible: w720dp, h1024dp. Deben coincidir los valores exactos.
● Orientación de pantalla: landscape, portrait.
● Versión de Android: v7, v8, v9, etc. Usado para crear diferentes configuraciones para versiones de Android
concretas.

http://developer.android.com/guide/topics/resources/providing-resources.html

¿Cómo lo hemos usado en el ejemplo?
● Layouts:
○ layout-v10: Android 2.X utilizará un layout con un solo fragment.
○ layout-v11: Android 3.X y 4.X que no coincida con layout-sw600dp-land.
○ layout-sw600dp-land: Activity con dos fragments para la versión landscape de tablets.
● Values:
○ values-mdpi: Dispositivos mdpi y ldpi utilizarán una configuración de una columna para el
GridView e imágenes con alturas reducidas.
○ values-hdpi: Dispositivos hdpi, xhdpi y xxhdpi con ancho de pantalla inferior a 820 dip (en
cualquiera de las orientaciones) utilizarán una configuración con 2 columnas para el GridView
y un tamaño de imágenes normal.
○ values-w820: Dispositivos con ancho de pantalla (en portrait o landscape) superior o igual a
820 dip utilizarán 3 columnas para el GridView

¿Cómo funciona esto si no hemos declarado
todas las configuraciones?
Revisa las reglas de aplicación de qualifiers:
http://developer.android.
com/guide/topics/resources/providing-resources.
html#QualifierRules

Custom Views
Las aplicaciones únicas utilizan
componentes únicos

Custom Views
Los principales motivos por los que hacer una custom view son:
● Crear un widget que no existe en el SDK.
● Agrupar lógica de presentación de una vista. Muy cómodo con MVVM.
● Añadir semántica a componentes de la capa de UI.
● Evitar duplicidad de código.

Custom Views
Existen 4 formas de crear una custom view:
● Extender de un widget ya existente como TextView o ImageView.
● Extender de view y dibujar en el método onDraw utilizando canvas.
● Extender de un layout/ViewGroup e inflar un layout.
● Extender de un layout/ViewGroup y añadir hijos en cada layout.

Custom Views
En realidad existe una quinta forma, pero esta la veremos en la próxima
librería open source de Tuenti.

¿Comenzamos a hablar de MVP y
MVVM?

Model View Presenter
Model View Presenter es un patrón
derivado de MVC muy usado en la construcción
de interfaces gráficas. En este patrón el
“presenter” asume la funcionalidad de mediador
entre la implementación de la vista y el modelo e
implementa la lógica de presentación.
La “view” en MVP se asocia a una
interface que representa la funcionalidad de
una vista.

Los principales problemas que MVP pretende
resolver son mejorar la testabilidad del código
(podemos testar de forma independiente a la
plataforma) y mover lógica de implementación de la
vista al presenter haciendo que la vista sea lo más
“tonta” posible.
Cuanto más “tonta” sea la vista, más
reutilizable será el presenter. Queda en manos del
desarrollador cuánta responsabilidad tiene la
implementación de la vista.

Uno de los puntos clave para la
correcta implementación de MVP es dejar
entidades del SDK de Android fuera del
presenter. De este modo podremos
escribir unit tests de una forma mucho
más sencilla.
El método setView() será común a
todos vuestros presenters, al igual que la
dependencia de la implementación de
la “vista” con el “presenter” que
utilice.

Con una implementación basada en
MVP nuestros Fragments, Activities o Custom
Views implementarán la interfaz que
representa la vista del presenter.
Su única responsabilidad será
implementar la interface View y conectar
las acciones del usuario con el presenter.

Con una implementación basada en
MVP nuestros Fragments, Activities o Custom
Views implementarán la interfáz que
representa la vista del presenter.
Su única responsabilidad será
implementar la interface View y conectar
las acciones del usuario con el presenter.

Aunque utilicemos MVP el ciclo de vida del componente sobre el que utilicemos el
“presenter” seguirá estando muy presente en la implementación.
Tanto si tenemos implementaciones de “onSavedInstanceState” como si
queremos reaccionar a eventos “onResume()” o “onPause()”.

Para implementar los eventos de usuarios (como clicks
sobre una vista) la implementación de la “vista” (en este caso
el Fragment) deberá delegar al “presenter” para que este a
su vez tome la decisión oportuna ante este evento de usuario.

Si se quiere extraer la implementación de
la navegación de Activities y Fragments podréis
utilizar una implementación similar a la clase
“Navigator”.
Así se puede evitar algunos ciclos en el
diagrama de colaboración por el cual cuando
una implementación de view recibe un evento
éste lo delega al presenter que a su vez acaba
devolviendo el evento a la vista.
Para este ejemplo concreto se necesita ser
capaz de inyectar el contexto asociado al activity
actual o pasarlo como parámetro.

Model View ViewModel
Model View ViewModel es un patrón
derivado de Presentation Model (by Martin
Fowler) muy usado en la construcción de
interfaces gráficas. Muy usado por Microsoft en
el desarrollo de aplicaciones para Windows.
La potencia de este patrón radica en el uso
de un engine de binding aunque también
podemos utilizarlo sin él.
El engine de binding nos permitirá
ahorrar muchísimo código de inicialización o
actualización de la vista.

El ViewModel debe mantener todo el
estado lógico de la vista, desde su visibilidad,
hasta si es clickable o los datos que está
representando en un momento dado.
Si queremos que nuestra vista sea
reactiva debemos conectarla con el
ViewModel utilizando un mecanismo de
notificación que puede ser desde un engine de
binding hasta un sistema de listeners clásicos.
Si igual que con MVP, el ciclo de vida de
Activities, Fragments y Custom Views se verá
reflejado en el ViewModel.

En MVVM la implementación del ViewModel
no mantendrá diréctamente una instancia de la
vista como tal, sino que utilizará un mecanismo
de notificaciones para indicar que algo ha
cambiado.
La vista, en este caso no es una interfaz
que la representa sino una implementación
concreta (un Activity, Fragment o CustomView),
mantendrá una instancia del ViewModel y se
registrará en él para ser notificada de eventos.
Eventos que serán declarados mediante el
mecanismo de notificación que elijamos.

En la vista que estemos utilizando (Activities, Fragments o Custom Views) deberemos ejecutar
comandos ofrecidos por el ViewModel ante la acción concreta de un usuario.

De este modo, cuando el usuario haga click
en un widget la vista obtendrá el comando que
ofrece el ViewModel y lo ejecutará para llevar a
cabo la acción pertinente.
Esta implementación encaja bien cuando los
comandos representan acciones de UI como abrir
un Activity o mostrar un Toast.
Si nos interesa podemos prescindir de la
parte de los comandos y conectar nuestra vista
con los métodos que queramos del ViewModel.

En el caso en el que nuestro ViewModel
tenga que trabajar con una vista que requiera una
lista este tendrá que devolver ViewModel que
representen los elementos de cada row dentro del
ListView.

Layout performance: Renderers
https://github.com/pedrovgs/Renderers

github.com/RoboBinding github.com/gueei/AndroidBinding github.com/kejunxia/Android-Mvvm
Utilizar una librería para implementar MVVM nos ayudará a implementar el
engine de binding. Aunque debéis tener en mente que no es necesario
recurrir a estas librerías si no necesitáis que vuestras vistas sean
reactivas.

¿ MVP vs MVVM ?

MVP vs MVVM
● El engine de binding de MVVM es muy poderoso, aunque no todas las
librerías soportan ofuscación o parecen no ser demasiado completas.
● MVP suele encajar semánticamente y es más sencillo de aplicar con
vistas grandes. La mayoría de desarrolladores lo entienden mejor.
● En MVP si no queremos devolver objetos tenemos que estar creando
presenters más pequeños que no siempre encajan (comienza a parecer
MVVM)
● MVP puede ser más sencillo de testar que MVVM (depende del engine de
binding que se utilice).
● MVVM favorece los tiempos de desarrollo (si no hacemos el binding a
mano constantemente)
● Ambos mejoran la mantenibilidad, testabilidad y reusabilidad de código.

MVP vs MVVM
Ambos patrones nos aíslan de la implementación
concreta de modelo y la vista, esto supone que tras
presenters y view models podemos utilizar lo que queramos:
interactors, hexagonal, controllers, etc en la
implementación de vuestro modelo.

MVP vs MVVM
Ninguno de los dos gana la batalla claramente
(sin un engine de binding), yo recomiendo
utilizar el que mejor entendáis y os permita
testar mejor vuestro código.

Consejos prácticos
● Hacer lo menos posible el el hilo de UI.
● Evitar la duplicidad de código.
● Medir empíricamente el performance de vuestra UI.
● Dedicar tiempo y cariño a estilos, temas, dimensiones y colores.
● Pensar en el desarrollo de UI como un dominio independiente.
● Crear código testable.
● Medir el rendimiento de vuestra UI de forma empírica.
● Evitar consultas constantes a vuestro dominio. Usar objetos
completos.
● Pensar en el reciclado de las listas.
● Escribir código para los compañeros no para la máquina.

¿Preguntas?

http://corporate.tuenti.com/es/dev/blog - @TuentiEng
http://corporate.tuenti.com/es/jobs

Effective Android UI - spanish

Effective Android UI - spanish

Recommended

More Related Content

Viewers also liked

Viewers also liked(20)

Similar to Effective Android UI - spanish

Similar to Effective Android UI - spanish(20)

Recently uploaded

Recently uploaded(20)

Effective Android UI - spanish