Clean Architecture on Android - a modern approach to medium to large-sized apps. The talk was done by: Manuel Sala de Borja Robles - https://www.linkedin.com/in/manuel-sala-de-borja-robles-50295130/ Lennart Bartelt - https://www.linkedin.com/in/lennart-bartelt/ Grigori Hlopkov - https://www.linkedin.com/in/grigorihlopkov/ Clean architecture has increased its popularity for Android in the last years. Three developers from Netlight built a sample app using Kotlin, Coroutines, Koin, Architecture Components, and Retrofit to showcase how a project is structured and how different parts of the codebase interact with each other. These are some of the insights they want to share: - What is it about? - Why is it worth a look? - How can we use it on an Android project? - What benefits does it bring? Link to sample app: https://github.com/netlight/android_cleanarchitecturesample

2. Architecting modern
Android apps
From our perspective

3. Grigori Hlopkov
Android Developer
Manu Sala de Borja
Android Developer
Lennart Bartelt
Android Developer

4. Finding a perfect recipe

5. Loop clicking

6. There must be a better way

7. Clean Architecture

8. What is it about?

9. A simple way to build
software systems

10. Robert C. Martin (Uncle Bob)

11. Robert C. Martin (Uncle Bob)

12. Why is it worth a look?

13. Which benefits does it bring?

14. Which benefits does it bring?
• Clean separation of concerns
• Highly decoupled
• Testable
• Not complex
• Easy to maintain

15. No drawbacks?

16. Pitfalls
• Learning curve (but not complex)
• Adds some bloat
• Many separate classes
• Increase of project size

17. Can we use it on an
Android project?

18. Definitely!

19. Overview

20. Clean Architecture
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

21. Clean Architecture on Android
Domain
React
Act

22. Domain layer calling
data layer?

23. Dependency Inversion Principle
Uncle Bob’s definition:
1. High-level modules should not depend on
low-level modules. Both should depend
on abstractions.
2.Abstractions should not depend on
details. Details should depend on
abstractions.

24. Dependency Inversion Principle
In the end:
1. the high-level module depends on the
abstraction
2.the low-level depends on the same
abstraction

25. Keys for application of Dependency Inversion Principle?
• Inner layers define interfaces
• Outer layers implement interfaces
• Direction of coupling is towards the center

26. We built a sample app

27. Some info about the sample app
• Clean architecture
• MVVM (Model-View-ViewModel)
• 💯 Kotlin
• Coroutines (Flow 🌊)
• Retrofit
• Room
• Koin
• Coil
• MockK

28. What does our awesome
app do?

33. Code structure

34. Code Structure

35. Folder Structure

36. Layers - Domain

37. Layer - Domain
• Holds our business logic
• Pure Kotlin or Java
• Independent of frameworks (UI, DB, …)
• Unit testable

38. Layer - Domain

39. Layer - Domain

40. Layer - Domain

41. Robert C. Martin (Uncle Bob)
In fact your business rules
simply don’t know anything
at all about the outside
world.

42. Layers - Data

43. Layer - Data
• Gets data
• Stores data
• Implements repositories
• Contains frameworks (i.e. Retrofit, Room, etc.)
• Unit testable

44. Repository pattern
● Abstraction of data layer
● Loose coupling
● Testable

45. Layer - Data
Implementing repositories

46. Layer - Data
Remote data source

47. Layers - Presentation

48. Layer - Presentation
• Displays data
• Bridges user interaction with business logic
• Contains frameworks (i.e. AndroidX, Coil, etc.)
• Unit testable

49. Layer - Data
View model

50. Layer - Presentation
Up to you to choose a pattern for presentation layer:
• MVVM (Model-View-ViewModel)
• MVP (Model-View-Presenter)
• MVC (Model-View-Controller)
• MVI (Model-View-Intent)
• etc.

51. Layers - Data flow overview

52. Flow Overview

54. Summary - Clean Architecture in a nutshell
• Separation
• Highly decoupled
• Testable
• Not complex
• Easy to maintain

55. How to start
• Read about the subject
• Build a sample project
• Try to think of use cases and how you can
isolate parts of your code
• Ask

56. Try it out
• List your use cases
• Start with domain layer (write use cases)
• Define interfaces between layers
• Use TDD (Test-Driven Development)

57. Here is the repo
https://github.com/netlight/android_cleanarchitecturesample

58. References
• https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
• https://stackify.com/dependency-inversion-principle/
• https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
• https://fullstackmark.com/post/11/better-software-design-with-clean-architecture
• http://www.plainionist.net/Implementing-Clean-Architecture/
• https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/
• https://pusher.com/tutorials/clean-architecture-introduction
• https://proandroiddev.com/clean-architecture-data-flow-dependency-rule-615ffdd79e29
• https://phauer.com/2017/clean-code-kotlin/
• https://proandroiddev.com/multiple-ways-of-defining-clean-architecture-layers-bbb70afa5d4a
• https://proandroiddev.com/the-real-repository-pattern-in-android-efba8662b754
• https://medium.com/androiddevelopers/unit-testing-livedata-and-other-common-observability-problems-
bb477262eb04

59. Thank you!
Questions?

60. Manu
Sala de Borja
manuel.robles@netlight.com
@mansaldebor
Grigori
Hlopkov
grigori.hlopkov@netlight.com
Lennart
Bartelt
lennart.bartelt@netlight.com