iPhone - UINavigationController, réutiliser les vues?

Question

La question fondamentale est "Combien de UIViewControllers pouvez-vous pousser sur la pile de navigation?" sans provoquer des avertissements de mémoire ni gagner une fin de surveillance.

Supposons que j'ai une application qui est essentiellement une base de données pour trois entités, chacune pouvant avoir une relation avec une autre entité, et que la relation est affichée sur un UIViewController. Les utilisateurs peuvent suivre ces relations et chaque personne crée un nouveau contrôleur - Si les entités sont A, B et C et A-> B-> C-> B-> C-> A, alors chaque type de vue est sur la pile deux fois. Je comprends comment pousser et faire apparaître, comment repousser un contrôleur particulier, et je pense que plutôt que de simplement étendre la pile de navigation indéfiniment, il serait peut-être préférable de réutiliser un contrôleur de vue dans la pile de navigation.

Pour ce faire, chaque fois que je voulais un FirstEntityViewController, je pouvais scanner la pile de navigation pour trouver un objet où [self isKindOfClass: [FirstEntityViewController class]]; , puis appeler des méthodes conçues pour modifier cette vue. Pour ce que je veux voir actuellement, il suffit d’actualiser les données de la même manière que lors de la réutilisation d’un UITableViewCell.

Cela convient, sauf pour l'effet que cela pourrait avoir sur le NavigationController. Si j'utilise UINavigationController: popToViewController: animated: , je pense qu'il va supprimer tout ce qui se trouve au-dessus de la vue sur laquelle je passe, y compris la vue que l'utilisateur s'attend à trouver en tapant sur "Retour "". dans la barre de navigation. Donc, l'utilisateur tape une relation, tape en arrière et va "hein?"

Si je supprime le contrôleur correspondant de la pile de navigation, puis le dépose en haut de la pile, le comportement de retour reste correct tant que l'utilisateur ne retourne pas jusqu'à l'instance de FirstEntityViewController déplacée ou sinon, la navigation semblera incohérente.

La bonne solution consiste-t-elle à retirer le contrôleur de la pile et à conserver une place dans la pile de manière à ce que le contrôleur réutilisé puisse être remplacé d'où il venait? Devrais-je conserver ma propre liste de types de vues et d’affichages de données afin de pouvoir remplacer la vue située au-dessous de la vue sur laquelle vous souhaitez passer, tout en gardant une longueur d’avance sur la navigation arrière?

Ou est-ce simplement que cela devient trop compliqué? Ne vous inquiétez-vous même pas de cette situation, car le système d'exploitation réutilise une grande partie des contrôleurs de vue de la même manière que les UITableViewCells sont réutilisés et qu'il n'y a pas de réel impact en termes de mémoire ou de performances pour une pile de navigation de 50 profondeurs?

Answer 1

Les instances de ViewController restent dans la pile de UINavigationController, mais toute vue, à l'exception de la vue de dessus, peut être déchargée à tout moment (le contrôleur de vue est averti par le message viewDidUnload ).

En d'autres termes, les vues situées sous la vue de dessus ne traînent pas et sont éventuellement déchargées dans des conditions de mémoire insuffisante. Vous n'avez donc pas besoin de tenter de réutiliser vos contrôleurs de vue.

Answer 2

La dernière fois que j'ai vérifié, vous ne pouvez pas y insérer à nouveau un contrôleur de vue qui se trouve déjà sur une pile de contrôleur de navigation. Vous devrez créer un nouveau contrôleur de vue et le placer dans la pile. Chaque bouton précédent le retirera de la pile. Le mieux que vous puissiez faire est de créer un cache de contrôleurs de vue et de le distribuer en fonction des besoins, à condition qu'ils soient sortis de la pile de navcontroller. Mais il ne vous achètera probablement pas beaucoup en économies de mémoire.

UITableViews est un peu différent dans la mesure où il n’ya qu’un nombre relativement petit de cellules en vue à un moment donné et dès que la cellule disparaît de l’écran, elle est supprimée et renvoyée dans le pool. Si vous pouvez garantir que la profondeur maximale de votre chaîne est fixe, vous pouvez utiliser un schéma de fenêtrage similaire. Sinon, vous devrez peut-être rester en profondeur et être vigilant pour libérer la mémoire dès que vous le pourrez.