Who needs an architecture for android applications development? activity 13 · Androidinights · June 2016 ¬ #android 

Erik Jhordan González Reyes #Android Developer Strong believer in software craftsmanship, solid, clean code and testing. 

Talk Schedule ● Who needs an Architect? ● Clean Architecture 

Who needs an architect? http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf #By Martin Fowler 

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 

Clean Architecture 

Entities Use Cases Controllers Gateways Presenters Devices W eb UI DB External Interfaces Frameworks and drivers Interface Adapters Business Rules Domain Logic 

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. 

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. 

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. 

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. 

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. 

Presentation Layer 

UI design patterns ● MVC ● MVP ● MVVM 

What do they have in common? 

Allows separate the view the business logic and data logic. 

Trygve Reenskaug 

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 

Design Library + Firebase + Twitter API https://github.com/erikcaffrey/DesignLibraryFirebase 

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. 

Android-Spotify Model View Presenter(MVP) http://erikcaffrey.github.io/2015/11/03/mvp/ https://github.com/erikcaffrey/Android-Spotify-MVP 

Android + Dagger 2 + MVP Sample https://github.com/erikcaffrey/Dagger2-MVP-Sample 

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 

People-MVVM http://erikcaffrey.github.io/2015/12/16/databinding- android/ https://github.com/erikcaffrey/People-MVVM 

What pattern should I use? 

● 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. 

Data Layer 

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 

Data Mapper Repository Client Business Logic Business Entity Business Entity Persist Query Query Object Data Source 

Clean Architecture on Android 

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 

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 

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 

Show me code 

Clean Architecture - Eurocup 2016 https://github.com/erikcaffrey/Clean-Architecture-Android 

https://github.com/erikcaffrey/Clean-Architecture-Android 

Answers & Questions 

Developer Successful Rules 

#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 

#SOLID Single responsibility principle Open / Closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle 

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 

Erik Jhordan González Reyes Android Developer +Erik Jhordan Rey Caffrey @ErikJhordan_Rey erikcaffrey erikcaffrey.github.io