- J'ai pris toutes les libs des projets ou j'ai pris un peu de code (sans faire de tri)
- Il y a une variable COLUM_NUMBER dans build.gradle (app) pour choisir le nombre de colones (grid)
- Un build Mock avec un petit jeu de fake data (toute avec title = nekfeu)
- Injection de dépendance au travers des build PROD // MOCK
+ PROD: utilise le serveur
+ MOCK: utilise des fake data pour lancer l'app sans internet
- Un presenter pour choisir quel sub-view doit être appelé
- Un ViewState (en guise de ViewModel)
- Des ViewEvent, pour fire des UseCase (à la manière des Intent avec
les Action).
- Des test Unitaire
- Des test de repository (avec et sans internet)
+ sans internet: test vraiment le repo
+ avec internet: test en plus les lib et le serveur
- Multiplier les ViewState avec presenter et usecase associer.
- Permet de recoder plusieurs fois de petit bout de code.
- DUPLIQUER? JAMAIS ! Sauf qu'en se faisant, on rend le dev plus
intéressant et on évite d'avoir une équipe qui disparait tous les
6 mois. Car le projet n'est pas agréable à coder.
- En plus ! Permet d'avoir un mode ESSAYER facilement.
- Permet une meilleure agilité entre les divers composant, afin de build
des version très différente :
+ (Asi / Europe).
+ Les pub interstitiel en Angletterre sont proscrite, alors qu'elles
fonctionnent bien en France.
- Ce que j'appelle une pane est une View Custom qui regroupe l'ensemble des composant:
- Event, UseCase, Presenter, viewController (dont les states, key_frame)
- Un ViewController:
- Composoant qui regroupe les 3 layout : enter, inside, exit
- pour gérer les switch entre les view, grace au constraintSet
- Chaque Etat doit avoir :
- 3 layout : enter, inside, exit (pour assurer les transition de manière autonome)
| layout_enter | layout_inside | resultat |
|---|---|---|
 |
 |
 |
