O botão traseiro remonta a um UitableViewController diferente de onde veio de

Question

Digamos que eu tenha o UAableViewController A, e o UitableViewController B. Ambos A e B carregam UIView C. No botão de volta em C, como me certifico de que ele sempre volta para B, e não de onde veio?

Aqui está um exemplo concreto: A = Janela de contatos no iPhone Skype. B = Janela de bate -papos, cada linha é um histórico de bate -papo com uma pessoa diferente C = Janela de bate -papo exibe uma conversa com a mesma pessoa.

C pode ser carregado de A ou B, mas eu quero que o backbutton na janela de bate -papo (C) volte para os bate -papos (b) apenas a janela.

Felicidades.

Answer 1

Eu recebi a resposta de Grupo do Google e seguiu sua sugestão, funciona:

De Sukima: Eu acredito (embora eu não tenha uma idéia real) que o que esses aplicativos como Skype e Beejive estão fazendo é quando a visualização A deseja visualizar C, enviará uma mensagem para o seu uitabbar para se mover para a guia Bats e depois empurre a visualização detalhada C. Isso é realmente melhor, porque o usuário verá que a visualização mudou pelo fato de o TabBar ter alterado os destaques. De: Eu li ainda mais o thread StackOverflow. Eu entendo agora o que você está perguntando.

Answer 2

Você vai achar isso difícil de implementar em grande parte porque este é um design de interface do usuário ruim e a API não a suporta.

Seu usuário espera que um botão de volta para levá -los "de volta" para a visualização anterior, como em todos os outros aplicativos que eles usam. Ir a qualquer outra visão os confundirá ainda mais porque não é uma hierarquia, mas um loop. Às vezes, os usuários vão B-> C-> B, mas outras vezes, A-> C-> B-> C. (Como eles voltam para um?)

Em vez de um botão traseiro em C, você deve ter um botão no lado direito que sempre o leva a B, independentemente de como você chegou a C. O mesmo botão no mesmo contexto deve sempre produzir o mesmo resultado. Os usuários não devem ter que se lembrar de que modo invisível eles estão para prever em que ação um botão terá.

---

Edit01: (Resposta aos comentários abaixo)

(Tudo isso é do topo da minha cabeça, então leve -o com um grão de sal.) Você precisará abandonar o uso do controlador de navegação e, em vez disso, gerenciar as visualizações. Você precisará trocar as visualizações através do TabBar, substituindo a visualização C pelas visualizações A e B na propriedade View de cada guia.

Eu acho que você terá que começar com a Visualização Master que é invisível e, em seguida, adicione o Tabbar a isso. No controlador de visualização Master, crie atributos/pontos de venda para cada visualização. Em cada visualização, tenha um atributo/saída vinculado ao controlador de visualização principal. Em seguida, tenha o "botão traseiro" (que eu sugiro fortemente que você rotule "bate -papos") do método de chamada de visualização C em A e B que então chama um método no controlador de visualização mestre que (1) remove a exibição C da guia a ou Guia B (2) alterna a guia para a guia B e, em seguida, (3) carrega a exibição b na guia B.

Não posso enfatizar o quão desajeitadamente acho que esse design é. Não importa se outros aplicativos o usam. Na minha experiência, as grandes empresas têm maior probabilidade de cometer erros de interface, porque seus departamentos de marketing querem que a interface do usuário pareça única.

Em comparação, veja como o aplicativo de telefone lida com a mesma situação. Não importa qual guia você use para fazer uma chamada, favoritos, contatos, teclado etc., você ainda volta a visualização dessa guia quando a chamada é concluída. Se você deseja fazer uma chamada com outro método, basta pressionar a guia apropriada.

Ignore o mau exemplo dos outros. Por que gastar tanto tempo e esforço tentando reproduzir o erro de outra pessoa?

Answer 3

Você sempre acaba voltando à vista que chamava pushViewController

Você poderia ter um envio b uma mensagem que faz B ligar pushViewController?
Posso não entender sua arquitetura, mas acredito que isso funcionaria.

Answer 4

Se você realmente deseja fazer isso, pode criar um método em B que empurre C, empurre B de A (sem animação) e chamar o método que empurra C. É claro que quando você aparecer C para B, A ainda estará sob ele.