Android Apps in modular structure paradigms

Slide 1

Slide 1 text

Erik Jhordan Rey GDE Android @ErikJhordan_Rey Android Apps in modular structure paradigms

Slide 2

Slide 2 text

Scalable and Maintainable Software

Slide 3

Slide 3 text

Android App Architecture Challenges

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Technical Decisions Making

Slide 6

Slide 6 text

Kotlin or Java?

Slide 7

Slide 7 text

RX or Coroutines?

Slide 8

Slide 8 text

Dagger or Koin?

Slide 9

Slide 9 text

MVP or MVVM or MVI or MV?

Slide 10

Slide 10 text

Should I use Android Jetpack Libraries?

Slide 11

Slide 11 text

Single Module or Multi Module

Slide 12

Slide 12 text

Manifesto for Agile Software Development https://agilemanifesto.org/

Slide 13

Slide 13 text

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Slide 14

Slide 14 text

Modern Android Development

Slide 15

Slide 15 text

A Good Architecture is important

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Architecture

Slide 18

Slide 18 text

Architecture is something that supports its own evolution, and is deeply intertwined with programming.

Slide 19

Slide 19 text

What good architecture looks like?

Slide 20

Slide 20 text

How teams can create it?

Slide 21

Slide 21 text

How best to cultivate architectural thinking in our development organizations?

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

DDD + Architecture Principles

Slide 24

Slide 24 text

Domain Driven Design

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Architecture Principles

Slide 27

Slide 27 text

Architecture Principles ● Separation of Concerns ● Composability ● Testability ● Modularity https://speakerdeck.com/erikjhordan_rey

Slide 28

Slide 28 text

Modularization in Android Apps

Slide 29

Slide 29 text

Modularization Smells

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Modular Thinking

Slide 32

Slide 32 text

Modular Thinking ● Clear separation of concerns ● Reusability ● Evolutionary design ● Refactoring ● Improve build times ● Adopt new technologies ● External code integration abstraction

Slide 33

Slide 33 text

Modules

Slide 34

Slide 34 text

App Module

Slide 35

Slide 35 text

app App Module apply plugin: 'com.android.application' In single module projects, this base module will contain all of your applications responsibilities.

Slide 36

Slide 36 text

Shared Module

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Dynamic Feature Module

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Modular Structure Paradigms

Slide 41

Slide 41 text

Modularization by Feature

Slide 42

Slide 42 text

App Modularization by Feature Checkout User Data Domain UI Data Domain UI android library android library application cyclic dependencies

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Modularization by Layer

Slide 45

Slide 45 text

App Modularization by Layer Domain Data User Checkout User Checkout User Checkout android library kotlin library application

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Modularization by Feature / Layer

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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)

Slide 50

Slide 50 text

Modularization by Library

Slide 51

Slide 51 text

App Modularization by Library application User Checkout Core Styling android libraries (aar) UI Data Domain UI resources Extensions Common

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Modularization by Dynamic Features

Slide 54

Slide 54 text

App Modularization by Dynamic Features application User About Core Styling Shopping dynamic feature Storage Data Domain UI UI resources

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Do we need into modular architecture?

Slide 57

Slide 57 text

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.

Slide 58

Slide 58 text

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Erik Jhordan Rey GDE Android @ErikJhordan_Rey Thank You!