Android Apps in modular structure paradigms

Approaches to create modular architectures in Android Apps

Transcript

1. Erik Jhordan Rey GDE Android @ErikJhordan_Rey Android Apps in modular structure paradigms
2. Scalable and Maintainable Software
3. Android App Architecture Challenges
4. Android App Architecture Smells • Over abstraction • No Boundary Classes • Different code styles at the same base code • Base Classes (BaseActivity, BaseUseCase, BasePresenter, BaseViewModel, etc.) • LiveData or Android classes in all Layers • Expose MutableLiveData • ViewModels without CoroutineDispatcher or Scheduler as argument • Handle Errors (try / catch everywhere) • Wrong dependency injection implementations • Unreliable test or not tests • Technical Decisions Making
5. Technical Decisions Making
6. Kotlin or Java?
7. RX or Coroutines?
8. Dagger or Koin?
9. MVP or MVVM or MVI or MV?
10. Should I use Android Jetpack Libraries?
11. Single Module or Multi Module
12. Manifesto for Agile Software Development https://agilemanifesto.org/
13. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
14. Modern Android Development
15. A Good Architecture is important
16. Modern Android Architecture Stack • Android Jetpack Libraries • Popular Library (RX, OkHttp, Retrofit, Glide, etc.) • SOLID • Clean Code • MVVM / MVP / MV? • Clean Architecture Note: The majority of current android projects use any of those principles
17. Architecture
18. Architecture is something that supports its own evolution, and is deeply intertwined with programming.
19. What good architecture looks like?
20. How teams can create it?
21. How best to cultivate architectural thinking in our development organizations?
22. Architecture is a tricky subject for the customers and users of software products - as it isn't something they immediately perceive. But a poor architecture is a major contributor to the growth of cruft
23. DDD + Architecture Principles
24. Domain Driven Design
25. Domain Driven Design Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. • Bounded Context • Ubiquitous Language
26. Architecture Principles
27. Architecture Principles • Separation of Concerns • Composability • Testability • Modularity https://speakerdeck.com/erikjhordan_rey
28. Modularization in Android Apps
29. Modularization Smells
30. Modularization Smells • Premature modularization • Excessive modularization • Wrong modules distribution • No definition of responsibilities and limits on modules • Not reusable setup configuration • Flaky communication between modules
31. Modular Thinking
32. Modular Thinking • Clear separation of concerns • Reusability • Evolutionary design • Refactoring • Improve build times • Adopt new technologies • External code integration abstraction
33. Modules
34. App Module
35. app App Module apply plugin: 'com.android.application' In single module projects, this base module will contain all of your applications responsibilities.
36. Shared Module
37. core Shared Module apply plugin: 'com.android.library' apply plugin: 'kotlin' These modules to separate out related areas and promote isolate code re-use of your project. Feature Analytics Abstract Module Core Module Feature Module
38. Dynamic Feature Module
39. Feature Dynamic Feature Module apply plugin: 'com.android.dynamic-feature' In single module projects, this base module will contain all of your applications responsibilities. app
40. Modular Structure Paradigms
41. Modularization by Feature
42. App Modularization by Feature Checkout User Data Domain UI Data Domain UI android library android library application cyclic dependencies
43. Modularization by Feature • Single repository VCS with multi-module android project • Modules organized around business functionality (checkout, users) • Cyclic feature modules • Hard to communication between feature modules • Hard to share resources or reuse code if shared modules approach is not used
44. Modularization by Layer
45. App Modularization by Layer Domain Data User Checkout User Checkout User Checkout android library kotlin library application
46. Modularization by Layer • Single repository VCS with multi-module android project • Modules organized around layer functionality (data/domain/UI) • Possibility to keep purely kotlin module without android framework classes • Coupling Modules (strong dependencies) • Excessive abstraction usages, add complexity code navigation. • Exposed to create a bunch of git conflicts - Complicates collaboration • Build time performance can be affected • Hard to share resources or reuse code if shared modules approach is not used
47. Modularization by Feature / Layer
48. App Modularization by Feature / Layer User Checkout Core Data Domain Data Domain Extensions Common UI Android SDK DI application android library kotlin library android library
49. Modularization by Feature / Layer • Single repository VCS with multi-module android project • Modules organized around layer and feature functionality (mix) • Reuse code using shared modules as Core Module • Possibility to keep purely kotlin module without android framework classes • Centralized UI logic in app module • Slow compile time switching between variants • Reduce decoupling from libraries (not dagger in all modules)
50. Modularization by Library
51. App Modularization by Library application User Checkout Core Styling android libraries (aar) UI Data Domain UI resources Extensions Common
52. Modularization by Library • Multiple repository VCS with single-module android project • Useful to reuse code on different projects at same company • Useful for large and distributed teams (10 devs or more) • Complicated navigation between libraries and projects on AS • Hard to upgrade, implies a new library release (automate) • Development time can be affected adding new functionality to the library • Hard to maintain multiple libraries / projects at the same time • Hard to maintain consistency in version across all modules
53. Modularization by Dynamic Features
54. App Modularization by Dynamic Features application User About Core Styling Shopping dynamic feature Storage Data Domain UI UI resources
55. Dynamic Features • Single repository VCS with multi-module android project • Modules organized around features functionality (about, users, shopping) • Complicated to decide if use on demand module true/false • Limited compatibility with aab • Slow compile time switching between variants • Navigation • Premature Optimization
56. Do we need into modular architecture?
57. Recommendations • Focused on Domain Business logic • Use the tools, libraries, programming languages with your team knows and feel comfortable, even better if your project get benefited • Prevent over-engineering, "Done is better than perfect" • Despite your values and disciplines and practices, the health of the organization will be an upper bound on the health of your code. • Communication patterns, weak concepts, ambiguity, conflicts, conflict avoidance, all that is going to affect your code.
58. Further reading
59. Further Reading • https://martinfowler.com/articles/microservices.html • https://martinfowler.com/bliki/DomainDrivenDesign.html • http://files.catwell.info/misc/mirror/2003-martin-fowler-who-needs-an-architect.pdf • https://agilemanifesto.org/ • https://martinfowler.com/architecture/ • https://www.youtube.com/watch?v=PZBg5DIzNww • https://speakerdeck.com/erikjhordan_rey/building-scalable-applications-inspired-into- micro-service-architecture-5b484b6b-2a9d-4031-a6d9-fccb913cf334 • https://open.spotify.com/episode/4jKZY82UScy6w1V6ZA8mOS • https://anchor.fm/erik-jhordan-rey
60. Erik Jhordan Rey GDE Android @ErikJhordan_Rey Thank You!