Who needs an architecture for android applications development?

Clean Architecture

Transcript

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? http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf #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 https://github.com/erikcaffrey/DesignLibraryFirebase
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) http://erikcaffrey.github.io/2015/11/03/mvp/ https://github.com/erikcaffrey/Android-Spotify-MVP
22. Android + Dagger 2 + MVP Sample https://github.com/erikcaffrey/Dagger2-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 http://erikcaffrey.github.io/2015/12/16/databinding- android/ https://github.com/erikcaffrey/People-MVVM
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 https://github.com/erikcaffrey/Clean-Architecture-Android
36. https://github.com/erikcaffrey/Clean-Architecture-Android
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 https://erikcaffrey.github.io • Android Clean Architecture by Fernando Cejas https://github.com/android10/Android-CleanArchitecture • Clean Architecture by Uncle Bob https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html • Rosie Android Framework for Clean Architecture by Karumi https://github.com/Karumi/Rosie
42. Erik Jhordan González Reyes Android Developer +Erik Jhordan Rey Caffrey @ErikJhordan_Rey erikcaffrey erikcaffrey.github.io