Developing for Android (The movie)

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.

Transcript

1. Developing FOR Android (The Movie) Una película de José Manuel Pereira v3.0
2. ¿QuiÉn SOY? José Manuel Pereira jmpergar.com @JMPergar
3. ¿QuÉ hago? Homo Curiositus ? Android Software Engineer at Organizer of GDG Barcelona
4. jobs@redbooth.com https://redbooth.com/jobs Redbooth platform https://redbooth.com/api/
5. EL Porqué DE ESTA PONENCIA 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) ¡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.
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. ¡AVISO! ¡NO RULES! Conjunto de consejos, ejemplos y principios.
8. 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) ¿CÓmo LO HAGO?
9. Yo he visto cosas que vosotros no creeríais ¿Básico?
10. Show me the “movida”
11. Naming Mi nombre es Íñigo Montoya 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. ¡El que sea, pero aplica uno!
12. Naming Antes Después
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. Packaging What’s in the box?? Básico para ser organizado. Es la base de nuestras arquitecturas. ¡El que sea, pero aplica uno!
15. ¿Model VIEW PRESENTER? Packaging
16. Architecture 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] MVC, MVP, Clean Architecture, Ports and Adapters... Usa la arquitectura que quieras, pero aplica S.O.L.I.D. (Barroso dixit)
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. Principio de Responsabilidad Única Contraejemplo: The God Activity “Una clase debería tener una y sólo una razón para cambiar” (Robert C. Martin) Un objeto debe tener una única responsabilidad. S.O.L.I.D.
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. 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.” Contraejemplo: Context Los objetos de un programa deben poder reemplazarse por instancias de sus subtipos sin alterar la correctitud del programa.
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” (Robert C. Martin) Contraejemplo: ViewPager.OnPageChangeListener Es preferible muchas interfaces específicas de cliente que una interfaz de uso general.
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. Es la única manera de disminuir el número de programadores que cometen suicidio. (BECARIOTON 470 a.c.) S.O.L.I.D.
24. Desacoplar del framework es parte de la solución Fragmentation and the framework Hardware Versiones Pantallas Fabricantes Forks
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. Context Sí, pero NO
27. Context MAL
28. Context MEJOR
29. Más información en Context, What Context? http://www.doubleencore.com/2013/06/context/ Context
30. Memory Leaks Cada vez que guardamos una referencia al Context de una Activity el Garbage Collector llora. Llora muuuucho. Se considera una fuga de memoria a cualquier objeto que perdura tras no utilizarlo o necesitarlo más.
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. Memory Leaks Muerte por OutOfMemoryError ¡OJO!
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. FRONT-END Layouts Styles Themes Dimens Colors Animations Los Resources son tus amigos. No los abandones, úsalos. Campaña apadrina un Resource.
35. FRONT-END include
36. FRONT-END merge
37. FRONT-END ViewStub
38. FRONT-END tools attributes http://tools.android.com/tech-docs/tools-attributes
39. Graddle is coming Build Types Flavors Flavors Groups Gestión de dependencias
40. Google+ http://goo.gl/2zgvlp
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. Referencias
43. PREGUNTAS
44. ¡Gracias! jmpegar.com