ANDROID

ARCHITECTURE
I o n u t Va l e n t i n
Negru

at Endava

ionut_negru87

https://stackoverflow.com/user
s/3596576/ionut-negru

ionut.negru87@gmail.com
Architecture of an
Android app?
Android framework, bad

• Context, the GOD object needed to be used everywhere

• All kind of singleton managers
• Fragments with their lifecycles (and other components that have lifecycle)
• AsyncTasks usually implemented incorrectly (sucking memory and resources of the
application)
App purpose

What is the actual purpose of the application?

News Reader Music Player Weather To-do list

“Your architecture should scream the purpose of the app”

(Uncle Bob)
App purpose

Business logic should be clearly separated and independent of the framework.

Good architecture

What should a good architecture do?

• Satisfy a multitude of stakeholders

• Encourage separation of concerns
• Run away from the real world
• Enable components to be testable
Satisfy a multitude of
stakeholders
• Stakeholder == any person interested in the development of the app
• Is it really doable?
• Organize the code based on what it does
• Interactions separated in classes/modules/components/whatever
• A developer that works on a component should work only on that component only
Encourage separation of concerns

• Maps nicely to the organization of teams and project phases,

• Architecture should also encourage the separation of concerns generally.
• Separation of concerns (single responsibility) - every component should have only one reason
to change.
Run away from real world

• Scream out what the app really does

• Emphasize the business logic
• Leave framework details under the hood
• Hide all the details related to the outside world.
• Nitty gritty dirty Android stuff: sensors, notifications, screen details, database access, internet
access, services, etc.
Enable your components to be
testable
• Unit test the app as much as possible
• The architecture should allow to easily test the app
• At least business logic should be testable
• Goes hand in hand with the separation from the real world
• Easier to test if everything is clearly separated
Clean architecture
Clean architecture

Systems should be:

– Independent of Frameworks
– Testable
– Independent of UI
– Independent of Database
– Independent of any external agency (3rd party libraries)
Master of your domain

• Know the purpose

• Delay decisions as much as possible
• Don’t focus on implementation details until business logic is done

Features of clean architecture:

I. Dependency rule
II. Abstraction
III. Communication between layers
I. Dependency rule
I. Dependency rule

• The implementation of the dependency rule can vary

• Package structure?
• Modules structure?
• Why not both?

• What about skipping layers?

II. Abstraction

• More abstract towards the

middle of the diagram

• Can be defined between

multiple layers
II. Abstraction (Example)

• Abstract interface in the inner layer

(to be used by the business logic)
• Move the implementation in the
outer layer.

• Business logic can use the

notification feature without
knowing the implementation details.

• Business logic isn’t aware of the implementation details.

II. Abstraction

• Abstraction is the theory

• Dependencies are the practice
• Abstraction is the logical layout of the app
• Dependencies are how it is actually composed together

• In clean architecture these two match app

• When these two don’t match up => logical inconsistencies & mess
III. Communication between
layers
• How can we pass data between layers?
• How is the communication and data flow happening?
• Inner layer communication with the outer layer?

• How?

• Well lets see …

III. Communication between
layers
III. Communication between
layers
III. Communication between
layers
Labels/components
Entities

• Domain objects or business objects

• The core of the app
• Don’t interact with the outside world
Use cases

• Interactors or business services are an extension of the entities

• Contain logic that isn’t constrained only to one entity but handle more of them
• Can be described with a simple sentence
• Can be used for naming classes: TransferMoneyUseCase
Repositories

• Serve to persist entities

• Defined as interfaces and serve as output ports for the use cases that want to perform CRUD
operations on entities
• Can expose more complex operations
• Concrete persistency strategies are implemented in outer layers
Presenters

• From MVP pattern

• They handle user interactions, invoke appropriate business logic, and send the data to the UI
• Multiple presenters for one screen
• The presenter lifecycle should be tied to the view lifecycle it resides in
• Methods name should be technology agnostic
Device

• Contains the implementation of Android specific components

• Two-part component: interfaces and implementations
• Business logic doesn’t care how the data is shown and where it comes from
• Useful for debugging and creating a deterministic environment
• Create wrappers around Android’s manager classes if the implementation cannot be
completely decoupled
Db & API

• Implementation of the repositories

• Under the hood persistence stuff should be in this component
• Caching strategy should be implemented in this component
• Business logic does not care where the data comes from
• Could be an exception for the above rule?
UI

• Everything related to UI
• Activities
• Fragments
• Views
• Adapters
• Etc.
Modules
How it measures?
How it measures?
How it measures?
How it measures?
How it measures?
Conclusion

• Is this overly complicated? Overly obscured? Over-engineered?

• Simple when you get used to it!
• It is necessary! If you care about your architecture, that is…
• Allows to make that nice abstraction/dependency match actually communicate and work
Bonus: reactive approach

• RxJava – reactive pattern

• Convert the Interactors to support Observables
• Decoupling between Observables and Subscribers
• Simplified asynchronous tasks: java threads and futures are complex -> we can avoid the
“callback hell”
• Data transformation/composition
• UseCase reactive implementation -> the Observable elephant in the room
• Subscriber – the presenter comes in action
Bonus: reactive approach
Bonus: reactive approach

• RxJava 2 & RxAndroid

• Dependency Injection: Dagger2
• Lambda expressions: Retrolambda
• Testing approach
• Package organization: by feature
• Build logic organization
In the end

• Respect SOLID principles

• Do not overthink (KISS)
• Be as pragmatic as possible

• Minimize framework dependencies and run away from the real world
• Test, test and test
References & Inspiration

• Tomislav Homan
• Uncle Bob – Robert C. Martin
• Fernando Cejas – android10(github), http://fernandocejas.com/