#Un peu d’histoire

#Google et l’obsolecence

Killed By Google

Google a une longue histoire de produits abandonnés. Android n’échappe pas à la règle, avec de nombreux frameworks et librairies tombés en désuétude, un développement mobile contrairement au web, n’a pas vraiment d’autre choix que de suivre les guidelines de Google (ou d’Apple). Chaque année Google propose de nouvelles guidelines, de nouveaux patterns, de nouvelles librairies. Parce que l’innovation est constante et vient du mobile depuis l’avènement de l’iPhone en 2007.

#Du chaos à la Clean Architecture moderne

#Les débuts chaotiques (2008-2014)

• À ses débuts, Android ne proposait pas de guidelines architecturales claires.
• Les développeurs devaient souvent tout gérer dans leurs Activities, créant ce qu’on appelle aujourd’hui des “God Activities” - des classes massives mélangeant UI, logique métier et accès aux données.
• Il ne faut pas oublier qu’Android est un système d’exploitation à la base fait pour les appareils photo.
  • Le développement d’applications mobiles n’était pas la priorité de Google.
  • C’est pourquoi le développement d’applications Android était souvent chaotique, avec des applications lentes, instables et difficiles à maintenir.

graph TD A[Activity] --> B[UI Logic] A --> C[Business Logic] A --> D[Data Access] A --> E[Network Calls] style A fill:#f44336 style B fill:#ffcdd2 style C fill:#ffcdd2 style D fill:#ffcdd2 style E fill:#ffcdd2

#L’émergence des patterns (2014-2016)

Face à ces problèmes, la communauté a commencé à adopter différents patterns :

1. MVC (Model-View-Controller)

   • Premier pattern largement adopté
   • Problème : Controller trop lié à la View dans Android

2. MVP (Model-View-Presenter)

   • Plus adapté à Android
   • Meilleure séparation des responsabilités
   • Tests plus faciles

graph LR V[View/Activity] <--> P[Presenter] P <--> M[Model] style V fill:#4CAF50 style P fill:#2196F3 style M fill:#FFC107

#La révolution MVVM (2016-2018)

Google introduit l’Architecture Components et le pattern MVVM :

• ViewModel: Gestion du cycle de vie
• LiveData: Data binding réactif
• Room: ORM pour SQLite

graph TD subgraph "MVVM Pattern" V[View] --> VM[ViewModel] VM --> M[Model/Repository] M --> DB[(Room DB)] M --> API[API Service] end style V fill:#4CAF50 style VM fill:#2196F3 style M fill:#FFC107 style DB fill:#9C27B0 style API fill:#9C27B0

#Clean Architecture & Single Activity (2018-2020)

Influence de Robert C. Martin et adoption massive de la Clean Architecture :

1. Principes clés:

   • Separation of Concerns
   • Dependency Rule
   • SOLID Principles

2. Couches:

   • Presentation (UI)
   • Domain (Use Cases)
   • Data (Repositories)

graph TB subgraph "Clean Architecture Android" UI[UI Layer<br/>Activities/Fragments] --> VM[ViewModel Layer] VM --> UC[Domain Layer<br/>Use Cases] UC --> REPO[Data Layer<br/>Repositories] REPO --> SRC1[(Local Source<br/>Room)] REPO --> SRC2[Remote Source<br/>API] end style UI fill:#4CAF50 style VM fill:#2196F3 style UC fill:#FFC107 style REPO fill:#9C27B0 style SRC1 fill:#795548 style SRC2 fill:#795548

#Modern Android Development avec Jetpack (2020+)

L’introduction de Jetpack Compose révolutionne l’architecture UI :

#Data Layer

Au niveau du data layer, Google à choisi de conserver les mêmes principes que ceux de la Clean Architecture.

La nouveauté se situe surtout au niveau de la couche UI avec Compose.

#Ui Layer

1. Composable Architecture:

   • UI déclarative
   • État unidirectionnel
   • Composition over inheritance

2. Jetpack Compose + Clean Architecture:

   • Séparation claire des responsabilités
   • State hoisting
   • Composition locale vs globale

#Bonnes pratiques actuelles avec Jetpack Compose

1. Single Source of Truth (SSOT)

   • État UI centralisé dans le ViewModel
   • Flow/StateFlow pour la réactivité
   • State hoisting pour la composition

2. Unidirectional Data Flow (UDF)

   • État descendant (top-down)
   • Événements remontants (bottom-up)
   • Predictable state management

3. Design Patterns courants

   • Repository Pattern pour l’accès aux données
   • Factory Pattern pour la création d’objets complexes
   • Strategy Pattern pour les différentes implémentations
   • Observer Pattern via Flow/StateFlow

graph TD subgraph "Flux de données moderne" UI[Composables] --> |Observe| State[UI State] UI --> |Dispatch| Event[UI Events] Event --> VM[ViewModel] VM --> |Update| State VM --> |Call| UC[Use Cases] UC --> |Execute| REPO[Repository] REPO --> |Fetch| DS[DataSources] end style UI fill:#4CAF50 style State fill:#2196F3 style Event fill:#2196F3 style VM fill:#FFC107 style UC fill:#9C27B0 style REPO fill:#795548 style DS fill:#795548

#Et alors ?

L’architecture Android a considérablement évolué, passant d’un système sans structure claire à un écosystème mature avec Jetpack Compose. Les principes de Clean Architecture, combinés aux outils modernes de Jetpack, permettent aujourd’hui de créer des applications maintenables, testables et évolutives.