Onglets Web pour l'iPhone

Question

Quelle est la meilleure approche pour implémenter des onglets qui ressemblent à des applications web sur l'iPhone, comme la capture d'écran ci-dessous (notez les onglets "Checkin-Info-Friends")? Ceux-ci ne font pas partie de la bibliothèque standard UIKit, mais ils semblent être très courants ces derniers temps.

J'ai passé beaucoup de temps à développer des applications pour l'iPhone, mais je n'ai pas développé de commandes comme celle-là. Quelle serait la meilleure approche ici:

• créer un nouveau UIView pour chaque contenu de l'onglet, et d'ajouter les trois sous-vues à la vue principale tout de suite?
• créer de nouveaux UIViews uniquement lorsque l'utilisateur clique sur chacun des onglets?
• Mettez tout le contenu dans un UIScrollView, et changez juste la page que l'utilisateur clique sur chaque onglet?

Peut-être y a-t-il des contrôles open source pour cela? Je n'ai rien trouvé.

alt text http://www.foursquaregame.com/foursquare-game-images/foursquare-game-mobile-app.jpg

Answer 1

Mon approche à un problème similaire était de faire tous les 4 onglets (dans mon cas) vues, mais répondre à didReceiveMemoryWarning en libérant tous, mais la vue de l'onglet en cours. (Ensuite, bien sûr, vous devez vous assurer que vous créez la nouvelle vue, si elle n'existe pas, lorsque l'utilisateur choisit un nouvel onglet.)

Je pensais que c'était un bon compromis - une réaction rapide à la utilisateur au premier abord (et dans mon cas l'empreinte mémoire est à son plus bas à ce stade de mon application), puis une réponse à la mémoire faible pour éviter d'être abattu.

Answer 2

Je pense qu'il est préférable d'avoir trois références UIView * aux sous-vues de la vue parent ou du contrôleur de vue, toutes initialement nulles, puis d'avoir un sous-programme pour masquer les deux autres vues si elles sont construites et affichées ou montrez simplement la nouvelle vue. En supposant pas d'exigences de mémoire extraordinaire. Je pense qu'avec une si petite zone d'écran, les problèmes de chargement/déchargement au niveau de la sous-vue ne sont pas préoccupants, mais si les vues parentes doivent être chargées/déchargées, les sous-vues doivent toutes être masquées et déchargées), et sur recharger, loadView devrait appeler la routine décrite dans le dernier paragraphe au démarrage. S'il y a en fait beaucoup de mémoire ou d'utilisation de ressources par l'une des trois sous-vues, alors mon conseil est inversé et chacune des sous-vues et/ou tous les objets de mémoire derrière eux doivent être non seulement cachés mais déchargé autant que possible. Je pense qu'avec votre utilisation de Google Maps, un besoin de déchargement caché pourrait s'appliquer à cela.

Est-ce le bon point à faire? Y a-t-il des détails supplémentaires qui me manquent?

Answer 3

Vous pouvez avoir chaque onglet être un contrôleur de vue réel avec nib et tout. Le seul problème est que vous devez transférer les appels du contrôleur de vue standard que vous voulez recevoir (viewWillAppear, etc) mais cela rend le codage beaucoup plus propre puisque vous codez comme pour n'importe quelle autre vue (bien que pour un espace plus petit).

Vous appelez la propriété "view" de chaque contrôleur pour sortir la vue, que vous ajoutez en tant que sous-vue d'une vue de conteneur que vous avez sous les onglets.

Answer 4

Si tous les trois sont des vues de table, vous pouvez utiliser un seul UITableViewController qui modifie le contenu en fonction de l'onglet sélectionné. Dans le cas contraire, j'appuie le commentaire de KHG sur l'utilisation de contrôleurs de vue réels pour sauvegarder chacune des sous-vues.Pour les onglets eux-mêmes, considérer UISegmentedControl.