2010-09-02 7 views
2

Plus précisément, j'ai quelque chose comme un jeu, avec un écran de menu fait de composants standard. Je veux un bouton pour passer à un autre contrôleur de vue avec lequel l'utilisateur va interagir pendant un moment, puis revenir à l'écran de menu. Il semble que le contrôleur de menu présente le mode «jeu» car un contrôleur de vue modale est la solution la plus simple, mais est-ce la meilleure façon de remplacer l'ensemble de la vue? Est-ce que tout le menu (qui peut devenir un contrôleur de nav ou de split) sera gardé en mémoire tant que le contrôleur modal sera en face, et est-ce que c'est quelque chose dont je devrais m'inquiéter?Les contrôleurs de vue modale sont-ils le moyen préféré de remplacer l'ensemble de l'interface sur un iPad?

+0

pas vraiment pourquoi cela a été downvoted – zem

Répondre

3

Il y a vraiment deux parties à cette question:

Quelle méthode de la transition d'une vue à l'autre dans une application iPad offre la meilleure expérience à l'utilisateur?

Quelle méthode de transition d'une vue à l'autre est la plus facile à implémenter et gère le mieux la gestion de la mémoire?

Je ne vais pas essayer de répondre à la première partie de cette question autre que de vous pointez sur « Human Interface Guidelines iPad » d'Apple qui dit (entre autres):

Réduire Full- Transitions d'écran

Associez étroitement les transitions visuelles au contenu en cours de modification. Au lieu d'échanger un tout nouvel écran lorsque des informations intégrées sont modifiées, essayez de mettre à jour uniquement les zones de l'interface utilisateur qui en ont besoin. En règle générale, préférez la transition des vues individuelles et des objets, pas l'écran. Dans la plupart des cas, il n'est pas recommandé de retourner l'intégralité de l'écran. Lorsque vous effectuez moins de transitions en plein écran, votre application bénéficie d'une plus grande stabilité visuelle, ce qui permet aux utilisateurs de savoir où ils se trouvent dans leur tâche. Vous pouvez utiliser des éléments d'interface utilisateur tels que la vue éclatée et le survol pour réduire le besoin de transitions en plein écran.

http://developer.apple.com/library/ios/prerelease/#documentation/General/Conceptual/iPadHIG/DesignGuidelines/DesignGuidelines.html

Cependant, dans votre cas, je l'aurais pensé une transition plein écran est tout à fait approprié (mais je ne suis pas un expert de l'expérience utilisateur).

En réponse à la deuxième partie, oui afficher un nouveau contrôleur de vue modalement semble être une bonne approche à prendre. Par défaut, les objets utilisés par la vue de menu et ceux utilisés par la vue modale seront conservés en mémoire - mais l'avantage d'utiliser les sous-classes UIViewController est qu'ils disposent d'une gestion de mémoire par défaut intégrée. . Si votre application reçoit un avertissement de mémoire alors que la vue modale est présentée en mode plein écran, les vues du contrôleur de vue de menu seront supprimées et la méthode "viewDidUnload" sera appelée. Donc, dans votre implémentation de cette méthode, vous devez libérer tous les objets dont vous n'avez pas besoin et ensuite les recréer comme nécessaire dans la méthode viewDidLoad du contrôleur de vue de menu (qui sera appelée à nouveau avant l'affichage du menu).

Ceci est expliqué plus en détail dans la référence de classe UIViewController:

Lorsqu'un avertissement à faible mémoire se produit, la classe UIViewController purges ses vues si elle sait qu'elle peut recharger ou les recréer à nouveau plus tard.Si cela se produit, il appelle également la méthode viewDidUnload pour donner à votre code une chance de renoncer à la propriété de tous les objets associés à la hiérarchie, y compris les objets chargés avec le fichier nib, les objets créés dans votre méthode viewDidLoad et les objets créés paresseusement. runtime et ajouté à la hiérarchie de vue. En règle générale, si votre contrôleur de vue contient des prises (propriétés ou variables brutes contenant le mot clé IBOutlet), vous devez utiliser la méthode viewDidUnload pour renoncer à la propriété de ces prises ou de toute autre donnée liée à la vue dont vous n'avez plus besoin.

http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html

+0

Wow, excellente réponse. J'apprécie particulièrement la séparation en parties. Re le premier, je suis d'accord que pour la partie de jeu une transition en plein écran est nécessaire. Cependant, j'avais déjà prévu une transition en plein écran entre deux zones de navigation, que je vais reconsidérer à la lumière de cet extrait du HIG. En ce qui concerne la seconde, depuis l'écriture de la question, j'ai appris à comprendre ces mécanismes de façon informelle, par la présence et la description de viewDidUnload et des méthodes associées. Encore une fois, il est utile d'isoler cette partie de la documentation. – zem

Questions connexes