Mortar (Square), défragmentez vos applications Android

La création de Mortar est venue d’un constat simple : La gestion des Fragments Android est bien trop complexe.

Les griefs sont les suivants :

• Ils ne proposent qu’un constructeur par défaut
• Gestion du cycle de vie lourde (Avec ces dizaines de callbacks…)
• Pas de contrôle direct sur les animations
• La gestion de la navigation entre Fragments peut très vite devenir complexe.

La solution de Square : Des vues et rien que des vues !

Avec cette bibliothèque, Square tente de coller au modèle MVP, difficilement réalisable avec le SDK Android de base. On a plutôt tendance à retrouver un modèle d’un côté et un énorme objet Vue-Présenteur de l’autre (Et hop, la “petite” activité d’un bon millier de lignes… ^^’ ) .

“Comment ?” me demanderez vous ? Simplement en injectant le Presenter dans les vues ! Et cela à l’aide de leur bibliothèque d’injection de dépendances : Dagger.

De cette manière, le Presenter made in Square, qui se charge de faire le lien entre le Modèle et la Vue, est décorrélé de la vue, du cycle de vie et de tout autre objet Android. Enfin, pas tout à fait, il possède tout le même de quoi sauvegarder son état lors de la destruction de l’appli au travers de seulement 4 callabacks : onLoad, onSave, onEnterScope et onExitScope.

L’intérêt ? En dehors de celui de ne plus avoir à nous soucier de la gestion d’un cycle de vie trop compliqué : Permettre de tester la logique métier sans avoir à utiliser un appareil Android ou un palliatif comme Robolectric. Et ça, c’est cool. ;)

Mais injecter un Presenter, ça coûte cher en temps d’exécution, non ? Pas tant que ça car Square encourage l’utilisation de Singletons de manière à ne faire N fois la création de l’objet et la résolution de dépendances qu’il peut entrainer.

“Un Singleton ? Mais c’est crado !” Eh bien non car, avec Dagger, le Singleton a un périmètre et donc une durée de vie bien défini. Les dépendances injectées sont en effet liées à un Scope !

La mission de Mortar est de faciliter la création, l’accès et la gestion des Scopes.

En effet, Mortar s’appuie sur un concept fort de Dagger : ObjectGraph, qui donne ici une gestion fine de la portée des objets injectés (dont font partie nos @Singleton Presenter) et par la même, de leur durée de vie. Le but étant de définir un scope pour chaque écran ou sous partie d’écran. Plus le Scope sera “précis” et plus le nombre d’objets qu’il injectera sera faible, minimisant ainsi l’impact de nos éventuels Singletons sur les performances de l’appareil. On se retrouve donc avec la facilité d’usage des Singletons sans peur des leaks et de faire exploser la mémoire vive de votre appareil !

Pour définir un Scope, on passe par un Blueprint qui va faciliter l’accès à celui-ci. Un Blueprint est défini par un nom et possède un Module contenant l’ensemble des objets à injecter dans ce Scope.

Les Scopes sont sauvegardés dans un Context Android. Ainsi, pour chaque Context défini dans votre application, on peut associer un Scope racine et ses éventuels sous-Scopes.

Conclusion sur cette présentation : Mortar répond à une vraie problématique : Avoir une application Android suivant le schéma MVP. Son utilisation demande un temps d’adaptation, mais reste simple et clairement définie. Reste le problème qu’il faut également maîtriser Dagger et potentiellement Flow pour pouvoir tirer réellement partie de sa force. Un investissement peu coûteux pour un nouveau projet perso, mais qui me semble difficile à faire passer auprès d’un directeur technique sur un projet mature et complexe.

Rx-fy all

Coming soon. ;)