Developing for Android (The movie)

33,241 views

Published on

Tras tres años programando en la plataforma Android esta es la película de mi vida como Android Developer, un conjunto de buenas practicas y conceptos necesarios que aún a día de hoy sigo viendo que no se cumplen en la mayoría de proyectos con los que me cruzo. Son la conclusiones sacadas de mi experiencia y de multitud de debates con compañeros. Se abordan temas como: fragmentación, uso de la clase Context, naming, maquetación en Android, memory leaks y S.O.L.I.D.

Published in: Software

Developing for Android (The movie)

  1. 1. Developing FOR Android (The Movie) Una película de José Manuel Pereira v3.0
  2. 2. ¿QuiÉn SOY? José Manuel Pereira @JMPergar jmpergar.com
  3. 3. ¿QuÉ hago? Android Software ? Engineer at Homo Curiositus Organizer of GDG Barcelona
  4. 4. Redbooth platform https://redbooth.com/api/ jobs@redbooth.com https://redbooth.com/jobs
  5. 5. EL Porqué DE ESTA PONENCIA ¡Sube, Marty! ¡El cliente quiere un proyecto para ayer! Equipos con poca experiencia. Problemas para optimizar y corregir. Repetimos los mismos errores. No aplicamos Unit Testing. No hay excusas. YOU ARE YOUR CODE but... It's easy to hate code you didn't write, without an understanding of the context in which it was written. (Martin Fowler)
  6. 6. La REALIDAD Un proyecto no dura mucho… Un proyecto no dura poco… Dura exactamente lo que se necesita. COMO MíNIMO (Gandalf en una stand up de SCRUM)
  7. 7. ¡AVISO! ¡NO RULES! Conjunto de consejos, ejemplos y principios.
  8. 8. ¿CÓmo LO HAGO? Kaizen 改善 (Mejora continua) Done is better than perfect. Si tras 6 meses tu código no te da vergüenza, no lo estás haciendo bien. (PROGRASTOTOLES 499 a.c)
  9. 9. ¿Básico? Yo he visto cosas que vosotros no creeríais
  10. 10. Show me the “movida”
  11. 11. Naming Mi nombre es Íñigo Montoya ¡El que sea, pero aplica uno! Identifica actores del framework. Identifica patrones. Respeta los nombres comunes y crea los tuyos. Aplícalo en todos los niveles. Muy importante en los recursos.
  12. 12. Naming Antes Después
  13. 13. Naming Drawables group_type_name_state_suffix → actionbar_icon_create_disabled, common_background_app Layouts type_name_suffix → activity_login, fragment_profile, adapter_user, include_header_premium Dimens property_default_group_type_name → fontsize_default, height_common_button Id’s type_name → cv_footer, tv_name, iv_avatar Classes NameBaseType → BaseActivity, ProfileFragment, ScreenUtils, RenderFactory, UserMVO, PostDAO Common names colors.xml, config.xml, dimens.xml, strings.xml, plurals.xml, arrays.xml, styles.xml, themes. xml...
  14. 14. Packaging What’s in the box?? ¡El que sea, pero aplica uno! Básico para ser organizado. Es la base de nuestras arquitecturas.
  15. 15. Packaging ¿Model VIEW PRESENTER?
  16. 16. Architecture MVC, MVP, Clean Architecture, Ports and Adapters... Usa la arquitectura que quieras, pero aplica S.O.L.I.D. (Barroso dixit) Te permitirá aplicar TESTING unitario. https://www.youtube.com/watch?v=I0qDmbwGz3o [Fernando Cejas] https://www.youtube.com/watch?v=EwcrTVmu7f4 [Jorge Barroso] Te conducirá a aplicar PATRONES. https://www.youtube.com/watch?v=tt3zI9cKiWU [Pedro Vicente] Hará tu app más sólida y ESCALABLE. https://www.youtube.com/watch?v=ROdIvrLL1ao [Jorge Barroso] https://www.youtube.com/watch?v=N6yqe88ysNw [Pedro Vicente]
  17. 17. S.O.L.I.D. The Single responsibility principle The Open closed principle The Liskov substitution principle The Interface segregation principle The Dependency inversion principle
  18. 18. S.O.L.I.D. Principio de Responsabilidad Única “Una clase debería tener una y sólo una razón para cambiar” (Robert C. Martin) Un objeto debe tener una única responsabilidad. Contraejemplo: The God Activity
  19. 19. S.O.L.I.D. Principio Abierto / Cerrado Todo módulo debe estar abierto para la extensión, pero cerrado para la modificación. Contraejemplo: El Adapter pintalotodo
  20. 20. S.O.L.I.D. Principio de Sustitución de Liskov “Si parece un pato y grazna como un pato, pero necesita pilas, probablemente no sea un pato.” Los objetos de un programa deben poder reemplazarse por instancias de sus subtipos sin alterar la correctitud del programa. Contraejemplo: Context
  21. 21. S.O.L.I.D. Principio de Segregación de Interfaces “Los clientes no deben ser forzados a depender de interfaces que no necesitan” Es preferible muchas interfaces específicas de cliente que una interfaz de uso general. (Robert C. Martin) Contraejemplo: ViewPager.OnPageChangeListener
  22. 22. S.O.L.I.D. Principio de Inversión de Dependencias Debemos depender de las abstracciones y no de las concreciones. Ejemplos: Capas, base de datos, servicios, librerias...
  23. 23. S.O.L.I.D. Es la única manera de disminuir el número de programadores que cometen suicidio. (BECARIOTON 470 a.c.)
  24. 24. Fragmentation and the framework Desacoplar del framework es parte de la solución Hardware Versiones Pantallas Forks Fabricantes
  25. 25. Context Context es probablemente el elemento más usado en el desarrollo de aplicaciones Android… y quizás también el peor usado. Application Activity Service BroadcastReceiver ContentProvider
  26. 26. Context Sí, pero NO
  27. 27. Context MAL
  28. 28. Context MEJOR
  29. 29. Context Más información en Context, What Context? http://www.doubleencore.com/2013/06/context/
  30. 30. Memory Leaks Se considera una fuga de memoria a cualquier objeto que perdura tras no utilizarlo o necesitarlo más. Cada vez que guardamos una referencia al Context de una Activity el Garbage Collector llora. Llora muuuucho.
  31. 31. Memory Leaks No guardar referencias al context-activity Trata de usar context-application en lugar de context-activity Usa WeakReference cuando no tengas más remedio que guardar las referencias. Evitar Inner Class no estáticas. Cuidado con las Static References.
  32. 32. Memory Leaks Muerte por OutOfMemoryError ¡OJO!
  33. 33. Memory Leaks Más información en Google I/O 2011: Memory management for Android Apps https://www.youtube.com/watch?v=_CruQY55HOk
  34. 34. FRONT-END Layouts Styles Themes Dimens Colors Animations Los Resources son tus amigos. No los abandones, úsalos. Campaña apadrina un Resource.
  35. 35. FRONT-END include
  36. 36. FRONT-END merge
  37. 37. FRONT-END ViewStub
  38. 38. FRONT-END tools attributes http://tools.android.com/tech-docs/tools-attributes
  39. 39. Graddle is coming Build Types Flavors Flavors Groups Gestión de dependencias
  40. 40. Google+ http://goo.gl/2zgvlp
  41. 41. Referencias The CommonsBlog http://commonsware.com/blog/ sgoliver.net blog http://www.sgoliver.net/blog/?page_id=3011 Cyril Mottier http://cyrilmottier.com/ Dan Lew Codes http://blog.danlew.net/ Antonio Leiva http://antonioleiva.com/ ANDROID TALES http://android.amberfog.com/ Android Coding http://android-coding.blogspot.com.es/ Styling Android http://blog.stylingandroid.com/ Android Weekly http://androidweekly.net/ vogella.com http://www.vogella.com/tutorials/android.html double encore http://www.doubleencore.com/tag/android/ Android-er http://android-er.blogspot.com.es/ Youtube: Android Developers https://www.youtube.com/user/androiddevelopers AndroCode http://androcode.es/ Android Developers Blog http://android-developers.blogspot.com.es/ Grokking Android http://www.grokkingandroid.com/ ANDROID DESIGN PATTERNS http://www.androiddesignpatterns.com/ Twitter List https://twitter.com/JMPergar/android-dev-must/members Android Arsenal http://android-arsenal.com/ AndroidViews http://www.androidviews.net/ Square Code Styles http://goo.gl/yZqppi
  42. 42. Referencias
  43. 43. PREGUNTAS
  44. 44. ¡Gracias! jmpegar.com

×