Real-World Designing Maintainable Architecture for Android

Real-World Designing Maintainable Architecture for Android

My talk on Droidcon Santo Domingo 2017. After many years of failures, the Android development industry is slowly coming to understand what makes projects successful. Best practices have begun to appear, sometimes mixed with misinformation and simple technical culture, but through testing and errors, teams around the world have begun to worry about getting better architecture in their Android applications. This talk is about how to write software that can be maintained, verifiable and flexible enough to adapt to growth and change following a series of the patterns and guidelines that I and my team believe that can be applied to the daily work of a software developer..

9f523401a845a29c93ff73cde4c3db2b?s=128

Erik Jhordan Rey

March 06, 2017
Tweet

Transcript

  1. Real-World Designing Maintainable Architecture for Android Erik Jhordan González Reyes

    Mobile Engineer at Segundamano erik.gonzalez@schibsted.com.mx @ErikJhordan_Rey github.com/erikcaffrey
  2. / SCHIBSTED MEDIA GROUP Erik Jhordan Rey “Mobile Engineer believer

    on software architecture, design patterns, clean code, solid and testing.” Mobile Engineer at Segundamano
  3. / SCHIBSTED MEDIA GROUP Presence in 30 Countries Y seguimos

    creciendo MÉXICO Colombia Chile Brasil República Dominicana LATINOAMÉRICA Noruega Suecia Finlandia Bélgica Francia ESCANDINAVIA / EUROPA Portugal Alemania Polonia España Italia Irlanda Suiza Austria Hungría Rumania Bielorrusia Reino Unido Marruecos ÁFRÍCA Túnez Malasia Indonesia Singapur Vietnam Tailandia Bangladés ASIA / OCEANÍA
  4. “Segundamano is the quickest and easiest way for people like

    you to sell and buy used things”
  5. Mobile Team ➔ Carmen Salvador ➔ Diego Ramirez ➔ Ivan

    Alvarez Frias ➔ Juan Pablo Villa ➔ Quentin Désert ➔ Arturo Gutierrez ➔ Jose Luis Cadena ➔ Ranferi Dominguez
  6. “This talk begins with a common software development story on

    android”
  7. Android Smells

  8. / SCHIBSTED MEDIA GROUP https://github.com/android/platform_frameworks_base/blob/donut-release/core/java/android/app/Activity.java Android Donut - 3628 lines

    of code Activity.java https://github.com/android/platform_frameworks_base/blob/jb-release/core/java/android/app/Activity.java Android Jelly Bean - 5200 lines of code https://github.com/android/platform_frameworks_base/blob/nougat-release/core/java/android/app/Activity.java Android Nougat - 7177 lines of code https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/java/android/app/Activity.java Android Lollipop - 6209 lines of code Android O - WTF ???????
  9. / SCHIBSTED MEDIA GROUP https://github.com/android/platform_frameworks_base/blob/ics-mr1-release/core/java/android/app/Fragment.java Android ICS-MR1-Release - 1563 lines

    of code Fragment.java https://github.com/android/platform_frameworks_base/blob/jb-release/core/java/android/app/Fragment.java Android Jelly Bean - 1601 lines of code https://github.com/android/platform_frameworks_base/blob/nougat-release/core/java/android/app/Fragment.java Android Nougat - 2633 lines of code https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/java/android/app/Fragment.java Android Lollipop - 2291 lines of code Android O - WTF ???????
  10. / SCHIBSTED MEDIA GROUP https://github.com/android/platform_frameworks_base/blob/donut-release/core/java/android/widget/TextView.java Android Donut - 7317 lines

    of code TextView.java https://github.com/android/platform_frameworks_base/blob/jb-release/core/java/android/widget/TextView.java Android Jelly Bean - 8768 lines of code https://github.com/android/platform_frameworks_base/blob/nougat-release/core/java/android/widget/TextView.java Android Nougat - 10402 lines of code https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/java/android/widget/TextView.java Android Lollipop - 9476 lines of code Android O - WTF ???????
  11. / SCHIBSTED MEDIA GROUP https://github.com/android/platform_frameworks_base Android Platform Frameworks Base

  12. ➔ UI ➔ Performance ➔ Arquitectura ➔ Tools Android Smells

  13. Product Stories

  14. “I need an application for ...”

  15. “I only need a minimum viable product (MVP) but ...”

  16. “Change button please, it’s just a button …”

  17. Fast Development vs Maintainable

  18. Smells

  19. ➔ Project Started to grow ➔ More features were required

    ➔ Product People was happy it success Smell #1
  20. ➔ More users using the application ➔ More features ➔

    Large Roadmap ➔ Deadlines ➔ More Contributors Smell #2
  21. Smell #3 ➔ Code started to grow ➔ Complexity to

    add new feature ➔ New Bugs ➔ Inconsistency code base ➔ Coupled code Started to grow ➔ Anti-patterns ➔ No tests
  22. Technical Debt

  23. How to detect if our software is maintainable?

  24. Technical Debt ➔ Does team have the same level? ➔

    Is it easy to onboard new people? ➔ Is the code consistent? ➔ Is hard to maintain? ➔ Can we add a new functionality fast? ➔ Can we get kpi’s on easy way? ➔ Can measure and monitoring the app? ➔ Is our code base preparate to scale? ➔ Is our code preparate to write test?
  25. / SCHIBSTED MEDIA GROUP No Silver Bullet ¬ Essence and

    Accidents of software Engineering
  26. Silver Bullets do not exist¬

  27. Software Development Guidelines

  28. / SCHIBSTED MEDIA GROUP ➔ People ➔ Architecture ➔ Testing

    Software Development Guidelines
  29. / SCHIBSTED MEDIA GROUP ➔ Only are guidelines to try

    work on easy way ➔ Are easy to understand but not necessarily easy to apply ➔ Require that a level of technical expertise be applied ➔ A lot Refactoring is needed to keep applying the guidelines overtime Do not Silver bullets
  30. People guidelines

  31. “Sometimes from management, who may not understand the value ”

  32. “Teams face resistance on several fronts”

  33. “Developers may take badly the fact that they are being

    told how to work best”
  34. “Different skills or level into the team”

  35. Types of developers

  36. “Nobody likes working with you”

  37. / SCHIBSTED MEDIA GROUP

  38. / SCHIBSTED MEDIA GROUP

  39. / SCHIBSTED MEDIA GROUP

  40. Architectural guidelines

  41. / SCHIBSTED MEDIA GROUP Inheritance Smells A lot Coupled Code

    Infinite levels of Inheritance Common Mistakes Extends non abstract class Base classes with hundreds of lines code. (code not maintainable) Architecture based on Inheritance Difficult to add new functionality
  42. STUPID

  43. / SCHIBSTED MEDIA GROUP STUPID Singleton Invasion Tight Coupling Untestability

    Premature Optimization Indescriptive Naming Duplication
  44. / SCHIBSTED MEDIA GROUP From STUPID to SOLID code These

    are principles, not laws!
  45. / SCHIBSTED MEDIA GROUP

  46. / SCHIBSTED MEDIA GROUP ➔ Passes all tests ➔ Reveal

    al idea ➔ No Duplication ➔ Minimized classes and methods 4 rules of Simple design
  47. Clean Code

  48. SOLID

  49. / SCHIBSTED MEDIA GROUP Write SOLID code Single Responsibility Principle

    Open / Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
  50. “Depend upon abstractions. Do not depend upon concrete classes”

  51. Apply DIP and DI! The usage of IoC, Dependency Inversion

    and Dependency Injection provides give us the following benefits: • Testability • Decoupling • Modularity (Flexible) • Maintainability
  52. public class TeamsActivity extends BaseActivity implements TeamsPresenter.View { private TeamsPresenter

    presenter; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); TeamsRepository teamsRepository = new TeamsRepository( new TeamDataSourceFactory(this), new TeamToTeamEntityMapper()); GetEuroTeams getEuroTeams = new GetEuroTeams(teamsRepository); presenter = new TeamsPresenter(getEuroTeams, new TeamViewModelToTeamMapper()); presenter.setView(this); presenter.initialize(); }
  53. public class TeamsActivity extends BaseActivity implements TeamsPresenter.View { @Inject TeamsPresenter

    presenter; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); presenter.setView(this); presenter.initialize(); }
  54. / SCHIBSTED MEDIA GROUP Dependency Injection https://github.com/erikcaffrey/Dependency-Injection-Android

  55. / SCHIBSTED MEDIA GROUP Architecture #By Martin Fowler “Architecture as

    a word we use when we want to talk about design but want to puff it up to make it sound important.”
  56. / SCHIBSTED MEDIA GROUP

  57. / SCHIBSTED MEDIA GROUP ➔ Onion Layer ➔ Clean Architecture

    ➔ MVP ➔ Riblets ➔ Your Custom Architecture Architectures & Patterns
  58. / SCHIBSTED MEDIA GROUP • MVC • MVP • MVVM

    UI Design Patterns UI code doesn't matter, the user can’t see it!
  59. / SCHIBSTED MEDIA GROUP • MVC • MVP • MVVM

    UI Design Patterns UI code doesn't matter, the user can’t see it!
  60. / SCHIBSTED MEDIA GROUP • MVC • MVP • MVVM

    UI Design Patterns
  61. / SCHIBSTED MEDIA GROUP What Do They have in common?

  62. / SCHIBSTED MEDIA GROUP Allows separate the view from the

    business logic and data logic.
  63. / SCHIBSTED MEDIA GROUP What pattern Should I use?

  64. / SCHIBSTED MEDIA GROUP • These patterns try to solve

    the same problems • Both patterns are going to improve code quality and testability. • Think about these patterns and use the one you understand better. UI Patterns
  65. Clean Architecture

  66. / SCHIBSTED MEDIA GROUP Entities Use Cases Controllers Gateways Presenters

    Devices W eb UI DB External Interfaces Frameworks and drivers Interface Adapters Business Rules Domain Logic
  67. / SCHIBSTED MEDIA GROUP View Presenter ViewController Use Case Use

    Case Use Case Domain Model Data Source Implementation Repository Repository Data Source Data Source Data Source Implementation Presentation Layer Domain Layer Data Layer Navigator
  68. / SCHIBSTED MEDIA GROUP Euro Clean Architecture https://github.com/erikcaffrey/Clean-Architecture-Android

  69. Our job is to solve problems, do not program android

  70. “Put attention in your DOMAIN”

  71. Good Architecture ➔ Fast Development ➔ Easy maintain ➔ Good

    Scalability ➔ Consistency code base ➔ Tests
  72. Testing guidelines

  73. / SCHIBSTED MEDIA GROUP Why we need write test?

  74. It is your responsibility

  75. The only way to make refactor

  76. It’s a tool for design

  77. It’s Money

  78. “Bad code affect your customers, Martin Fowler”

  79. / SCHIBSTED MEDIA GROUP FIRST Fast Independent Repeatable Self-validating Timely

  80. / SCHIBSTED MEDIA GROUP Building Testing Pipeline Domain Layer -

    test my code implements the business Data Layer - test my http client requests and responses Presentation - test user is watching UI expected
  81. / SCHIBSTED MEDIA GROUP O’Reilly Free Programming The main goal

    is to practice good practices, architecture and testing. https://github.com/erikcaffrey/oreilly-books-android
  82. • Depend on abstractions do not depend on concrete class

    • Use design patterns on smart way • Avoid coupled code and strive for loosely coupled design between objects that interact • Avoid expensive tasks executed on main thread • Maintain a clean code style • Write Clean and Solid Code • Favor composition over inheritance • If your code is coupled the Refactor is your friend • Write test is your responsibility • Understand the tools before used it • Automatize Advices
  83. Questions? Find me Erik Jhordan González Reyes Mobile Engineer github.com/erikcaffrey

    erik.gonzalez@schibsted.com.mx erikcaffrey.github.io @ErikJhordan_Rey +Erik Jhordan Rey
  84. 01 02 https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html Uncle Bob - Clean Architecture http://www.oreilly.com/programming/free/real-world-maintainable-software.csp Real-World

    Maintainable Software 03 Further Reading 04 https://goo.gl/sduh0M Clean Code https://erikcaffrey.github.io/ANDROID-clean-architecture/ Erik Jhordan Rey - Clean Architecture
  85. Thank You! Droidicon Santo Domingo