iPhone Dev - Application multi-affichage paresseux

Question

(Juste pour que vous sachiez que je suis en train d'apprendre à développer pour iPhone, sans constructeur d'interface)

Je suis en train de coder ma première application multi-vues, qui comporte un contrôleur de vue racine et deux autres contrôleurs de vue, et le contrôleur de vue racine utilise un chargement différé. Ainsi, lorsque viewDidLoad crée le premier contrôleur de vue et ajoute sa vue au sous-affichage, ne crée pas l’autre tant que ce n’est pas nécessaire. Mais, une fois le second chargé, ils y restent tous les deux jusqu'à la fin de l'application (sauf si un avertissement concernant la mémoire lui est attribué).

Je me pose donc la question suivante: lorsque l'utilisateur bascule l'autre vue, dois-je décharger l'autre vue en cours de suppression (en lui attribuant la valeur nil, c'est une propriété de rétention)? Ainsi, chaque fois que l'utilisateur clique sur le bouton, le contrôleur de vue actuel est déchargé (après avoir été supprimé de la vue d'ensemble) et le suivant est chargé et ajouté en tant que sous-vue?

Donc, est-ce la bonne chose à faire, ou est-ce juste, mais seulement lorsque l'application a de nombreux points de vue et que le mien n'est pas assez compliqué pour justifier cela, ou est-il mauvais de le faire du tout et je devrais simplement laissez didReceiveMemoryWarning s'en charger (dans didReceiveMemoryWarning, je règle le contrôleur de vue qui n'est pas affiché actuellement sur nil)?

Answer 1

La réponse dépend vraiment. En règle générale, vous devez libérer et paramétrer sur nil la vue qui ne s'affiche pas. Toutefois, si l'utilisateur doit basculer fréquemment entre elles, vous pouvez conserver la vue masquée conservée (mise en cache).

Vous ne voulez pas vraiment que votre application pousse le téléphone de l'utilisateur vers didReceiveMemoryWarning. Lorsque vous recevez cet avertissement, le téléphone subit d'autres événements qui peuvent provoquer le gel de votre application pendant que l'iPhone vide les pages Safari en mémoire cache, les objets UIImageView en mémoire cache, etc. l'application risque de ne pas sembler aussi lisse qu'elle le devrait.

Il est également important de noter que certains utilisateurs peuvent utiliser des iPhones, iPod Touch et 3Gs de première génération, de sorte qu'ils ne disposent pas de la mémoire supplémentaire du 3GS.

Cela étant dit, je suis plutôt conservateur en mémoire, donc je libère et j'annule la vue, puis je l'instancie de nouveau lorsque l'utilisateur souhaite la voir. L'impact de l'affichage de votre vue sur le nettoyage du système dû à didReceiveMemoryWarning aura généralement beaucoup moins d'impact sur l'utilisateur de votre application.