il pulsante Indietro torna a un UITableViewController diverso da cui proviene

Question

Supponiamo che io abbia UITableViewController A e UITableViewController B.Sia A che B caricano UIView C.Con il pulsante Indietro in C, come posso assicurarmi che torni sempre a B, anziché da dove proviene?

Ecco un esempio concreto:A=Finestra dei contatti in Skype per iPhone.B = finestra di chat, ogni riga è una cronologia della chat con una persona diversa c = finestra di chat mostra una conversazione con la stessa persona.

C può essere caricato da A o B, ma voglio che il pulsante Indietro nella finestra di chat (C) torni solo alla finestra di chat (B).

Saluti.

Answer 1

ho avuto la risposta da gruppo di google e seguito il suo suggerimento, funziona:

Da Sukima: Credo che (anche se non ho idea reale) che ciò che queste applicazioni come Skype e Beejive stanno facendo è quando vista A vuole vista C lo farà messaggio il vostro UITabBar per spostare le chat scheda quindi spingere dettaglio vista C. Questo in realtà è meglio perché allora l'utente vedrà che la vista è cambiato tramite il fatto che la barra delle linguette è cambiato salienti. da: Leggo ulteriormente il filo StackOverflow. Ora capisco che cosa il vostro richiesto.

Answer 2

Troverai difficile implementarlo in gran parte perché si tratta di una cattiva progettazione dell'interfaccia utente e l'API non lo supporta.

L'utente si aspetterà un pulsante Indietro per riportarlo "indietro" alla visualizzazione precedente proprio come in ogni altra app utilizzata.Passare a qualsiasi altra visualizzazione li confonderà ancora di più perché non è una gerarchia ma un ciclo.Gli utenti a volte andranno B-->C-->B ma altre volte A-->C-->B-->C.(Come tornano ad A?)

Invece di un pulsante Indietro in C, dovresti avere un pulsante sul lato destro che ti porta sempre a B indipendentemente da come sei arrivato a C.Lo stesso pulsante nello stesso contesto dovrebbe produrre sempre lo stesso risultato.Gli utenti non dovrebbero ricordare in quale modalità invisibile si trovano per prevedere quale azione avrà un pulsante.

---

Edit01:(Risposta ai commenti qui sotto)

(Questo è tutto fuori dalla mia testa, quindi prendilo con un granello di sale.) Dovrai abbandonare usando il controller di navigazione e invece gestire le viste da solo.Dovrai scambiare le visualizzazioni tramite la barra delle schede sostituendo la visualizzazione C con le visualizzazioni A e B nella proprietà di visualizzazione di ciascuna scheda.

Penso che dovrai iniziare con la vista principale che è invisibile e poi aggiungervi la barra delle schede.Nel controller della vista principale, crea attributi/outlet per ciascuna vista.In ogni vista, avere un attributo/outlet collegato al controller della vista principale.Quindi disponi del "pulsante Indietro" (che ti consiglio vivamente di etichettare "Chat") del metodo di chiamata della vista C in A e B che quindi chiama un metodo nel controller della vista principale che (1) rimuove la vista C dalla scheda A o la scheda B (2) cambia la scheda nella scheda B e quindi (3) carica la vista B nella scheda B.

Non posso sottolineare quanto penso che questo design sia sgraziato.Non importa se altre app lo utilizzano.Nella mia esperienza, le grandi aziende hanno maggiori probabilità di commettere errori di interfaccia perché i loro dipartimenti di marketing vogliono che l'interfaccia utente abbia un aspetto unico.

In confronto, guarda come l'app del telefono gestisce la stessa situazione.Non importa quale scheda utilizzi per effettuare una chiamata, preferiti, contatti, tastiera, ecc., tornerai comunque alla visualizzazione di quella scheda al termine della chiamata.Se vuoi effettuare una chiamata con un altro metodo, basta premere la scheda appropriata.

Ignora il cattivo esempio degli altri.Perché dedicare così tanto tempo e sforzi cercando di riprodurre l'errore di qualcun altro?

Answer 3

Sarai sempre vento per tornare alla vista che ha chiamato pushViewController

Potrebbe avere un invio B un messaggio che causa B a chiamare pushViewController?
Non posso capire la vostra architettura, ma credo che avrebbe funzionato.

Answer 4

Se si vuole veramente fare questo si potrebbe creare un metodo in B che spinge C quindi spingere B da A (senza animazione) e chiamare il metodo che spinge C. Naturalmente quando si pop C a B, A sarà ancora sotto di essa.