Save 37% off PRO during our Black Friday Sale! »

Who needs an architecture for android applications development?

9f523401a845a29c93ff73cde4c3db2b?s=47 Erik Jhordan Rey
June 15, 2016

Who needs an architecture for android applications development?

Clean Architecture


Erik Jhordan Rey

June 15, 2016


  1. Who needs an architecture for android applications development? activity 13

    · Androidinights · June 2016 ¬ #android
  2. Erik Jhordan González Reyes #Android Developer Strong believer in software

    craftsmanship, solid, clean code and testing.
  3. Talk Schedule • Who needs an Architect? • Clean Architecture

  4. Who needs an architect? #By Martin Fowler

  5. 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.” “In most successful software projects, the expert developers working on that project have a shared understanding of the design system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers.” #By Ralph Johnson
  6. Clean Architecture

  7. Entities Use Cases Controllers Gateways Presenters Devices W eb UI

    DB External Interfaces Frameworks and drivers Interface Adapters Business Rules Domain Logic
  8. Dependency Rule Entities encapsulate Enterprise wide business rules. An entity

    can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.
  9. Entities Entities encapsulate Enterprise wide business rules. An entity can

    be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.
  10. Uses Cases The software in this layer contains application specific

    business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
  11. Interface Adapters The software in this layer is a set

    of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web.
  12. Frameworks and Drivers The outermost layer is generally composed of

    frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards. This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.
  13. Presentation Layer

  14. UI design patterns • MVC • MVP • MVVM

  15. What do they have in common?

  16. Allows separate the view the business logic and data logic.

  17. Trygve Reenskaug

  18. Model View Controller Model What to display? View How it’s

    displayed? Controller Formatting the model for display and handling events like user input. #MVC
  19. Design Library + Firebase + Twitter API

  20. Model View Presenter #MVP The MVP pattern allows separate the

    presentation layer from the logic, so that everything about how the interface works is separated from how we represent it on screen. Ideally the MVP pattern would achieve that same logic might have completely different and interchangeable views.
  21. Android-Spotify Model View Presenter(MVP)

  22. Android + Dagger 2 + MVP Sample

  23. Model View ViewModel Is an architectural approach used to abstract

    the state and behaviour of a view, which allows us to separate the development of the UI from the business logic. #MVVM
  24. People-MVVM android/

  25. What pattern should I use?

  26. • 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.
  27. Data Layer

  28. Repository Pattern Use a repository to separate the logic that

    retrieves the data and maps it to the entity model from the business logic that acts on the model. The business logic should be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database, a SharePoint list, or a Web service. #msdn
  29. Data Mapper Repository Client Business Logic Business Entity Business Entity

    Persist Query Query Object Data Source
  30. Clean Architecture on Android

  31. Clean Architecture Principles • The Dependency Rule • Presentation is

    decoupled from domain • Domain module can be a layer module. • Data layer decouples the rest of the app • Independent of Frameworks. • Independent of UI • Independent of Database • Entities Representing Enterprise Rules
  32. View Presenter Activity Fragment 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
  33. Clean Architecture Conclusion Conforming to these simple rules is not

    hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss. #Uncle Bob
  34. Show me code

  35. Clean Architecture - Eurocup 2016


  37. Answers & Questions

  38. Developer Successful Rules

  39. #OO Principles Favor composition over inheritance Program to interfaces, not

    implementations Classes should be open for extension but closed for modifications Strive for loosely coupled design between objects that interact Depend on abstractions do not depend on concrete class
  40. #SOLID Single responsibility principle Open / Closed principle Liskov substitution

    principle Interface segregation principle Dependency inversion principle
  41. Further Reading • My Personal Blog • Android Clean

    Architecture by Fernando Cejas • Clean Architecture by Uncle Bob • Rosie Android Framework for Clean Architecture by Karumi
  42. Erik Jhordan González Reyes Android Developer +Erik Jhordan Rey Caffrey

    @ErikJhordan_Rey erikcaffrey