bouton retour remonte à un autre UITableViewController d'où il vient

Question

Dire que j'ai UITableViewController A et B. UITableViewController A et B charges UIView C. Au bouton de retour en C, comment puis-je me assure qu'il va toujours à B, plutôt que d'où il vient?

Voici un exemple concret: A = contacts fenêtre iphone skype. B = fenêtre Causeries, chaque ligne est une histoire de chat avec une autre personne C = Fenêtre de chat affiche une conversation avec la même personne.

C peut être chargé de A ou B, mais je veux la backbutton sur la fenêtre de chat (C) remonte à la fenêtre Causeries (B) uniquement.

Vive.

Answer 1

Je suis la réponse de groupe google et a suivi sa suggestion, cela fonctionne:

De Sukima: Je crois (bien que je ne sais pas vrai) que ce que ces applications comme skype et Beejive font est lorsque la vue A veut vue C, il sera un message de votre UITabBar pour passer à l'onglet chats puis pousser dans la vue détaillée C. Ceci est en fait mieux car alors l'utilisateur verra que la vue a changé par le fait que la barre d'onglets a changé les faits saillants. de: Je lis encore le fil stackoverflow. Je comprends maintenant ce que votre demande.

Answer 2

Votre va trouver cela difficile à mettre en œuvre en grande partie parce que c'est une mauvaise conception de l'interface utilisateur et l'API ne supporte pas.

utilisateur attend un bouton de retour pour les prendre « retour » à la vue précédente comme dans toutes les autres applications qu'ils utilisent. Aller à toute autre vue les confondent d'autant plus parce qu'il n'est pas une hiérarchie, mais une boucle. Les utilisateurs vont parfois B -> C -> B, mais d'autres fois, A -> C -> B -> C. (Comment ils reviennent à A?)

Au lieu d'un bouton de retour en C, vous devriez avoir un bouton sur le côté droit qui vous emmène toujours à B quelle que soit la façon dont vous avez à C. Le même bouton dans le même contexte devrait toujours produire le même résultat. Les utilisateurs ne devraient pas avoir à se souvenir de ce mode invisible, ils sont pour prédire quelle action un bouton aura.

---

Edit01: (Réponse aux commentaires ci-dessous)

(Tout cela est du haut de ma tête pour le prendre avec un grain de sel.) Vous devrez abandonner l'utilisation du contrôleur de navigation et de gérer plutôt les vues vous-même. Vous aurez besoin d'échanger les vues via la barre d'onglets en substituant la vue C pour les vues A et B dans la propriété vue de chaque onglet.

Je pense que vous devez commencer avec vue maître qui est invisible, puis ajoutez la barre d'onglets à cela. Dans le contrôleur de vue principale, créer des attributs / sorties pour chaque vue. Dans chaque vue, un attribut / sortie reliée au dispositif de commande d'affichage maître. Alors le bouton « retour » (que je vous conseille vivement LABEL « Causeries ») de la méthode d'appel de vue C en A et B, qui appelle ensuite une méthode dans le contrôleur de vue maître que (1) supprime la vue C soit de l'onglet A ou onglet B (2) commute l'onglet à l'onglet B et ensuite (3) les charges en vue B onglet B.

Je ne peux pas l'accent comment disgracieuse Je pense que cette conception est. Peu importe si d'autres applications utilisent. Dans mon expérience de grandes entreprises sont plus susceptibles de faire des erreurs d'interface parce que leurs services de marketing veulent l'interface utilisateur pour un look unique.

Par comparaison, regardez comment l'application téléphone gère la même situation. Quelle que soit l'onglet que vous utilisez pour faire un appel, favoris, contacts, clavier etc, viennent encore en arrière que le point de vue de l'onglet lorsque l'appel est fait. Si vous voulez faire un appel avec une autre méthode, vous appuyez simplement sur l'onglet correspondant.

Ignorer le mauvais exemple des autres. Pourquoi passer tant de temps et d'efforts à essayer de reproduire l'erreur de quelqu'un d'autre?

Answer 3

Vous liquidez toujours revenir à la vue qui a appelé pushViewController

: Pouvez-vous envoyer un message B qui provoque B appeler pushViewController?
Je ne peux pas comprendre votre architecture, mais je crois que cela fonctionnerait.

Answer 4

Si vous voulez vraiment faire cela, vous pouvez créer une méthode B qui pousse C puis appuyez sur B de A (sans animation) et appeler la méthode qui pousse C. Bien sûr, quand vous pop C à B, A sera encore dessous.