effective android ui - spanish

Effective Android UIPedro Vicente Gómez Sánchez - Mobile Software Engineer, Tuenti Technologies.

@pedro_g_s , @TuentiEng

[email protected]

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

Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s

http://corporate.tuenti.com/es/dev/blog


Esta charla es la continuación de Software Design Patterns on Android

Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - [email protected]

http://www.slideshare.net/PedroVicenteGmezSnch/software-design-patterns-on-android

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

http://www.youtube.com/watch?v=aAGke-ED-BA

Introducción: MDPI device


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

Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - [email protected] 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

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.

Model View PresenterAunque 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.

Model View ViewModelDe 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.

Model View ViewModelEn 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 - @TuentiEnghttp://corporate.tuenti.com/es/jobs




effective android ui - spanish

Engineering

comesjobs effective

versiones de android

cdigo de ui

principales tipos de

tuentieng http

uso de dagger

tuenti technologies

portrait landscape