UITabBarController UINavigationController Conseils de conception

Question

C'est plus une question philosophique que n'importe quoi, alors donnez-moi vos pensées.

La documentation de l'iPhone SDK spécifie qu'un contrôleur de barre d'onglets peut contenir un contrôleur de navigation, mais qu'un contrôleur de navigation ne peut pas contenir de contrôleur de barre d'onglets. Il semble que vous souhaitiez parfois organiser des vues dans une vue faisant partie d'une pile de contrôleurs de navigation sous forme de tableau. Est-ce déraisonnable? J'accepte ce qu'Apple dicte dans ces domaines comme évangile puisque le HIG fournit les meilleures pratiques qui semblent révéler le chemin de la moindre résistance (je suis sûr qu'il y a des exceptions à cela). Dans le cas de la barre d'onglets, cependant, je ne suis pas sûr du raisonnement derrière ce design. Peut-être que c'est évident pour les autres, mais je ne peux pas penser à une bonne raison pour laquelle vous n'autoriseriez pas les onglets comme autre chose qu'un contrôleur de niveau racine.

Que pensez-vous/savez-vous tous? Quel défaut de conception cela créerait-il? Comment résoudriez-vous ce problème de vouloir une présentation tabulaire des vues dans une vue? Ai-je besoin de repenser l'ensemble du design?

Merci.

Answer 1

Je peux voir d'où ils viennent, du point de vue de la conception. Les tabbars se sentent ancrés, constants, où les navbars se sentent dynamiques et mutables. Ainsi, un onglet contenant du contenu dynamique a du sens, alors qu'un seul point dans la hiérarchie dynamique d'une pile de navigation contenant une barre d'onglets ancrée au bas de l'écran ne semble pas correct. L'implémentation de Three20 gère cela d'une manière qui a plus de sens, en ancrant les onglets sous la barre de navigation, de sorte qu'ils se sentent plus comme s'ils faisaient partie de cet endroit dans la pile de navigation. Cela dit, Tweetie lance sa propre barre d'onglets, si je me souviens bien, sans UITabbarController pour contourner ce détail dans les directives de l'interface utilisateur, et cela fonctionne totalement du point de vue de l'interaction.

Answer 2

Je pense que le contrôleur de barre d'onglets est destiné à être le principal point de navigation autour d'une application si elle est utilisée. Si un contrôleur de navigation contient un contrôleur de tabulation, alors les onglets changeront chaque fois que vous naviguez ailleurs, ce qui peut être source de confusion pour les utilisateurs habitués à les utiliser de façon régulière dans d'autres applications. Je pense que c'est une bonne idée, mais Apple peut ne pas ressentir la même chose.

Answer 3

La réponse courte est qu'il serait déroutant pour l'utilisateur d'autoriser UITabBars à l'intérieur d'un contrôleur de navigation. L'application ne se comporterait certainement pas comme la plupart des utilisateurs s'y attendraient. Mais, c'est juste UITabBar, pas le concept de design des onglets en général. Les onglets à l'intérieur d'un contrôleur de navigation devraient, selon moi, aller en haut, pas en bas, comme le fait UITabBar.

Il y a plusieurs façons de procéder.

J'ai effectué des «onglets» dans un contrôleur de vue de navigation en faisant en sorte que la première ligne d'une vue de table comporte un sélecteur segmenté. (Voir l'application HangTime sur l'App Store). Je pense que ça marche plutôt bien, mais ce ne sont pas vraiment des "onglets". Joe Hewitt, le gars qui a écrit l'application Facebook, a résolu ce problème en créant sa propre vue et son propre contrôleur de «barre d'onglets», même si le rendu est très différent de celui d'un UITabBar. Cet élément est disponible via le framework Three20 et la bibliothèque open source. Check it out: http://github.com/joehewitt/three20/tree/master