Exibir a arquitetura do controlador/NIB para aplicação não de navegação com transições?

Question

Estou mexendo com um aplicativo para iPad que (como muitos aplicativos para iPad) não usa o sistema de controle da Uinavigation Root View, para que não tenha propriedade natural para cada aplicativo "Visualização". Eu tenho essencialmente duas visualizações básicas: uma visualização da lista de documentos e uma visualização de edição de documentos.

Estou tocando com o UIView Animation para obter de um documento selecionado para a visualização Editar.

Eu também tenho uma barra de ferramentas no topo que existe (com botões diferentes) em ambas as "visualizações".

Como não tenho uinavigação executando o programa para mim, tenho uma tendência a jogar mais e mais coisas em uma ponta e uma visualização que possui o contêiner inteiro. Mas agora estou tentando descobrir como seguir a visualização da lista de documentos para a visualização Editar se a exibição Edit vive dentro de uma ponta diferente, preservando a barra de ferramentas também.

Alguém tem pensamentos ou experiência em estruturas de aplicativos como essa? Acho que os documentos que faltam nas melhores práticas em torno da estrutura de código/UI para qualquer coisa, exceto aplicativos triviais de uma tela ou aplicativos de navegação completa.

Você não "deveria" ter controladores de exibição de pais/filhos que possuem subcomponentes da mesma tela "" de acordo com os documentos, mas isso implica um enorme controlador de visão de buzina que basicamente contém o aplicativo inteiro, e isso não pode estar certo.

Não tenho certeza se há uma "resposta certa" para isso; Estou procurando alguns exemplos ou sugestões inteligentes. Ninguém tocou essa pergunta em meses, então estou adicionando uma recompensa para gerar boas conversas. :)

Obrigado!

ATUALIZAR: Não estou falando de uma visão dividida, que é claramente bem tratada por um controlador de exibição dividida. Em vez disso, dê uma olhada nos aplicativos iwork da Apple (por exemplo, páginas) que têm uma visualização de lista de documentos e uma visualização de edição independente, mas estes estão relacionados pela animação.

Talvez a verdadeira pergunta aqui seja: como você (ou você poderia até?) Construir um controlador de exibição de "contêiner", como a Visualização Split ou o Controlador de Navegação, você mesmo? Você é obrigado a construir a coisa toda do zero? Sinto que você é, porque parece estar oculto na interação entre os controladores de exibição. Se sim, pensa sobre isso?

Answer 1

Eu acho que a única fiação oculta nos controladores de exibição está definindo o ParentViewController, o que é necessário para apoiar as categorias declaradas para dividir e navegar.

Os controladores de exibição são projetados para serem aninhados, com cada controlador possuindo uma parte da hierarquia de visualizações. O único objetivo de design é que nenhum controlador de exibição alcance a hierarquia de visualização de outro controlador. Um controlador de visualização pai geralmente terá alguma chamada para adicionar controladores filhos para que possa definir o quadro da visualização na hierarquia de visualizações que possui. Um controlador de visualização infantil não deve fazer nada com a supervisão da visualização que controla, pois é de propriedade de outro controlador. Não deve definir o centro ou o quadro da visualização que ele controla.

Por exemplo, um controlador de navegação possui um método de push, no qual remove a exibição anterior do controlador, adiciona a nova visualização do controlador e define o quadro da visualização recém -adicionada. Em geral, um controlador de visualização pai é livre para definir a estrutura da visão de um controlador filho, mas não os limites.

Se você deseja alterar a animação de um controlador de navegação, acho que você começaria implementando todos os métodos com um argumento animado:. Configure sua animação e ligue para a bandeira animada antes de cometer a animação.

Answer 2

Eu não experimentei a coisa de controladores de visualização múltipla fora dos uikit fornecidos (navegação/tabar/modal/etc), mas não vejo por que não deveria funcionar. Sob o capô, tudo é uma visão, embora eu observe que o UIKIT tem visualizações especiais para os controladores de exibição que, sem dúvida, têm algum tipo de manuseio especial pelo sistema (o UIViewController tem uma visualização de wrapper, o UinAvigationController tem um UinavigationTransitionView ou algo assim. .).

Aconselho não se preocupar muito com a "prática recomendada" - basta codificar algo que faz o que você deseja. Algumas opções:

• Faça a lógica nas classes de exibição (ewwww!). Um de nossos aplicativos faz isso para que possa lidar com a rotação de maneira personalizada (as visualizações deslizam para dentro/fora em vez de girar). Provavelmente deveríamos ter implementado nossa própria lógica do View Controller.
• Quebre o modelo em componentes que correspondem às visualizações. Faça com que cada visualização saiba como carregar seu componente e carregar recursivamente subcomponentes. Em seguida, o controlador de exibição só precisa se preocupar com coisas de "cenário geral".

Observe também que você pode carregar várias pontas no mesmo controlador de exibição, por exemplo, conectando -a a uma saída chamada EditView.

-(EditView*)editView {
  if (!editView) {
    // Loads EditView into the outlet editView
    [NSBundle loadNibNamed:@"EditView" owner:self];
  }
  return editView;
}

Você também precisará se preocupar em adicioná -lo à sua hierarquia de visualizações, descarregá -lo -(void) ViewDidunLoad (iPhone OS 3.0+), configurando -o em -(void) ViewDidload, caso houvesse um aviso de memória durante o modo de edição, etc ...

Não é fácil, mas a interface do usuário nunca é.

Answer 3

Você precisa de uma visualização mestre-Detail implementada com uma visão dividida/POPOVER-View e controlada com um UISPLITVIELCONTROLLER.

A visualização principal é a lista de documentos e a visualização detalhada é a visualização de edição. Cada um tem seu próprio controlador. Os dois controladores são gerenciados pelo UISplitViewController.

Se você não usar o SplitView Controller, acabará com a codificação manual de algo que funciona muito parecido. Esta é realmente a única maneira de fazer o que você deseja facilmente na API e é o layout que os usuários do iPad esperam.

Ver Criando uma interface de visão dividida No guia de programação do iPad para obter detalhes.