Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

AIR Mobile – Le cycle de vie des View (destructionPolicy, viewActivate, …)

Comme on l'a vu dans le tutorial AIR Mobile précédent, on a un ViewNavigator qui gère l'instanciation et l'affichage des View:

AIR Mobile – Navigation entre les View : pushView, popView, …

Vous n'êtes donc plus maître des évènements en ce qui concerne les instanciations mais bien entendu, le SDK est accessible et extensible. Des évènements sont donc propagés pour vous permettre d'insérer votre logique métier au bon moment.

Les évènements propagés par View

Les objets de type View vont propagés 2 nouveaux types d'évènements:

• FlexEvent.VIEW_ACTIVATE ("viewActivate") : Envoyé quand la vue est devenue la vue courante ("activeView" sur ViewNavigator)
• FlexEvent.VIEW_DEACTIVATE ("viewDeactivate") : Envoyé quand on va remplacer cette vue par une autre.
• FlexEvent.REMOVING ("removing") : Envoyé lorsque la vue s'apprête à être supprimée car elle on a demandé l'activation d'une autre vue. Vous pouvez appeler la méthode preventDefault() sur cet évènement pour empêcher le changement d'écran.

Attention, l'évènement VIEW_ACTIVATE n'est envoyé qu'une fois la transition terminée. Il ne faut pas confondre VIEW_ACTIVATE et CREATION_COMPLETE qui aussi propagé par une View. FlexEvent.CREATION_COMPLETE indique que les composants de la vue ont été créés et qu'ils sont accessibles. FlexEvent.VIEW_ACTIVATE signifie que l'utilisateur peut agir sur la vue (il ne peut pas agir sur une View pendant une transition.

Voici le schéma complet expliquant cette mécanique récupéré depuis les specifications Hero 4.5 :

Politique de destruction des View

Comme on le voit dans l'enchaînement des évènements, à un moment donné, la vue A est supprimée de l'affichage. Le comportement par défaut est que lorsqu'une View est désactivée (remplacée par une autre), celle-ci est détruite automatiquement. Là encore, ce n'est pas pour le plaisir de la détruire, cela va surtout aider votre application à garder une consommation mémoire basse. En effet, avec ce système, vous n'aurez à un instant T, qu'une View en mémoire, la View courante.

Mais dans certains cas, vous ne voudrez pas que la vue soit détruite. Imaginez que dans votre application, vous ayez une vue qui ait un temps d'initialisation assez long ou que l'utilisateur puisse effectuer des actions qui ne soient pas seulement "cliquer sur un item de liste".

Voici deux exemples pour lesquels vous ne souhaitez pas détruire votre vue:

• Vous concevez une application de dessin et votre vue principale est un "tableau blanc" sur lequel l'utilisateur peut dessiner au doigt. L'utilisateur réalise plusieurs dessins puis va sur l'écran de paramétrage pour modifier une option (une autre View). Votre View principale serait alors détruite et au retour de votre vue de paramétrage, il faudrait dessiner à nouveau tout ce que l'utilisateur était en train de faire. Même si cela est possible, cela n'est pas très pratique et va ralentir l'utilisateur dans sa navigation.
• Un exemple auquel j'ai été confronté dans mon application, celui d'une vue longue à initialiser. Dans mon cas, c'est ma carte qui comprend de nombreux objets graphiques (tuiles images, des Shape) créés à l'avance dans un Object Pool. La navigation courante de l'utilisateur est aussi importante. Si l'utilisateur s'est déplacé sur un point précis, il voudra revenir à ce point. Même si cette position est sauvegardée, il serait trop long de recréer mon composant carte, de l'initialiser et de le replacer à chaque fois que l'utilisateur revient sur la vue de la carte.

Il y a sûrement d'autres exemples mais ceux-ci sont ceux qui me viennent directement en tête.

Si votre vue n'est pas complexe, il est conseillé de laisser AIR la détruire / créer pour éviter que l'application gonfle en mémoire. Sinon, vous pouvez utiliser le paramètre "destructionPolicy" qui est présent sur View. Si vous donnez la valeur "never"  à "destructionPolicy", votre vue ne sera pas détruite et pourra être réutiliser en cas de retour du cette vue.

"Never Say Never"

Pour reprendre l'expression de notre ami chevelu, il ne faut jamais dire jamais. En effet, même si votre vue a une "destructionPolicy" fixée à "never", dans certains cas, la vue va être recrée.

Dans mon application, par exemple, j'ai les vues suivantes:

• Map
• Recherche
• Resultats
• Fiche Info

Si l'utilisateur fait le cheminement suivant:

Map > Search > BACK (popView) > Map

Parfait, notre vue Map n'a pas été détruite et on a bien pu la récupérer. Prenons maintenant le cheminement suivant, en réalisant un "pushView" à chaque étape:

Map > Search > Result > Info Sheet > Map

Et bien dans ce cas, le ViewNavigator va créer une nouvelle vue Map. Pour résumer, lorsque vous faîtes appel à pushView, même si vous lui donnez une Class qui a déjà été instanciée auparavant, ViewNavigator va créer une nouvelle vue et peu importe la destructionPolicy de celle-ci.

Il faut noter que le cheminement suivant ne détruit pas la vue:

Map > Search > Result > Info Sheet > popView();popView();popView(); > Map

Mais ce n'est pas une vraie solution. Etant confronté directement à ce problème, j'ai du trouver une solution (merci au forum de la prerelease pour le coup de main) que je partagerai sur flex-tutorial.