Your SlideShare is downloading. ×
Effective Android UI - spanish
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Effective Android UI - spanish

4,931
views

Published on

Published in: Engineering

0 Comments
27 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,931
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
77
Comments
0
Likes
27
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Effective Android UI Pedro Vicente Gómez Sánchez - Mobile Software Engineer, Tuenti Technologies. @pedro_g_s , @TuentiEng pgomez@tuenti.com
  • 2. 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
  • 3. 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
  • 4. ¿Es el código de UI menos importante? Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com ¿Aprovechamos bien los recursos que Android nos ofrece?
  • 5. ● Introducción. ● Recursos y configuraciones. ● Custom Views. ● Model View Presenter. ● Model View ViewModel. ● MVP vs MVVM ● Consejos prácticos. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com
  • 6. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com https://github.com/pedrovgs/EffectiveAndroidUI
  • 7. Introducción Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 8. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com Introducción: S4 - Android 4.4.2
  • 9. Introducción: DraggablePanel Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com https://github.com/pedrovgs/DraggablePanel
  • 10. Introducción: MDPI device Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com
  • 11. Introducción: Nexus 7 y Nexus 10 - Android 4.4.4 Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com Portrait Landscape
  • 12. Recursos y configuraciones Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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)
  • 13. Recursos y configuraciones Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 14. Recursos y configuraciones Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com http://developer.android.com/guide/topics/resources/providing-resources.html
  • 15. Recursos y configuraciones Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com ¿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
  • 16. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com ¿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
  • 17. Custom Views Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com Las aplicaciones únicas utilizan componentes únicos
  • 18. Custom Views Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 19. Custom Views Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 20. Custom Views Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com En realidad existe una quinta forma, pero esta la veremos en la próxima librería open source de Tuenti.
  • 21. ¿Comenzamos a hablar de MVP y MVVM? Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com
  • 22. Model View Presenter Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 23. Model View Presenter Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 24. Model View Presenter Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 25. Model View Presenter Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 26. Model View Presenter Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s 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.
  • 27. Model View 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()”.
  • 28. Model View Presenter Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 29. Model View Presenter Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 30. Model View ViewModel Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 31. Model View ViewModel Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 32. Model View ViewModel Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 33. Model View ViewModel Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 34. Model View ViewModel Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s
  • 35. Model View ViewModel 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.
  • 36. Model View 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. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com
  • 37. Layout performance: Renderers Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com https://github.com/pedrovgs/Renderers
  • 38. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 39. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com ¿ MVP vs MVVM ?
  • 40. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s
  • 41. MVP vs MVVM Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com ● 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.
  • 42. MVP vs MVVM Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 43. MVP vs MVVM Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 44. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com 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.
  • 45. Effective Android UI - Pedro V. Gómez Sánchez - @pedro_g_s - pgomez@tuenti.com ¿Preguntas?
  • 46. 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 - pgomez@tuenti.com