Edgesforextendedlayout Uiviewcontroller Class

Começando no iOS7, os controladores de exibição usam o layout de tela inteira por padrão. Ao mesmo tempo, você tem mais controle sobre como ele expõe seus pontos de vista, e isso é feito com essas propriedades: basicamente, com essa propriedade, você define quais lados de sua exibição podem ser estendidos para cobrir toda a tela. Imagine que você empurre um UIViewController para um UINavigationController. Quando a visão desse controlador de visualização é estabelecida, ele começará onde a barra de navegação termina, mas essa propriedade irá definir quais lados da vista (superior, esquerda, inferior, direita) podem ser estendidos para preencher a tela inteira. Deixe-o com um exemplo: Aqui você não está definindo o valor de edgesForExtendedLayout. Portanto, o valor padrão é tomado (UIRectEdgeAll), então a vista amplia seu layout para preencher a tela inteira. Este é o resultado: como você pode ver, o fundo vermelho se estende por trás da barra de navegação e da barra de status. Agora, você vai definir esse valor para UIRectEdgeNone. Então você está dizendo ao controlador de exibição para não estender a exibição para cobrir a tela: Esta propriedade é usada quando sua exibição é UIScrollView ou similar, como um UITableView. Você quer que sua mesa comece onde a barra de navegação termina, porque você não verá todo o conteúdo se não, mas ao mesmo tempo você deseja que sua tabela cubra toda a tela ao deslocar-se. Nesse caso, definir bordasForExtendedLayout para None não funcionará porque sua tabela começará a deslizar para onde a barra de navegação termina e não vai atrasar. Aqui é onde esta propriedade é útil, se você deixar o controlador de exibição ajustar automaticamente as inserções (configurando esta propriedade para SIM, também o valor padrão), ela adicionará inserção no topo da tabela, então a tabela começará onde a navegação O bar termina, mas o pergaminho cobrirá toda a tela. Isto é quando é definido como NÃO: E SIM (por padrão): Em ambos os casos, a tabela se desliza para trás da barra de navegação, mas no segundo caso (SIM), ele irá começar por baixo da barra de navegação. Esse valor é apenas uma adição aos anteriores. Se a barra de status for opaca, as vistas não serão estendidas para incluir a barra de status também, a menos que este parâmetro seja SIM. Então, se você estender sua visão para cobrir a barra de navegação (edgeForExtendedLayout para UIRectEdgeAll) e o parâmetro é NO (padrão), ele não cobrirá a barra de status se for opaco. Se algo não estiver claro, escreva um comentário e eu responda. Como o iOS sabe o que o UIScrollView usa para usar o iOS, aceita a primeira sub-visualização na visualização do seu viewcontrollers, de modo que o do índice 0 e, se for uma subclasse do UIScrollView, aplica as propriedades explicadas a ele. Claro, isso significa que o UITableViewController funciona por padrão (uma vez que o UITableView é a primeira visualização). Ciclo de vida do objeto: UIViewController Ao programar no iOS, it8217s é inevitável que you8217ll precise subclasse UIViewController. Essas subclasses contêm toda a lógica que faz com que seus aplicativos se vejam e se comportem como deveriam. It8217s é difícil de configurar uma subclasse sem saber quais métodos substituídos serão chamados e quando. Para remediar esta confusão potencial, esta publicação examinará o ciclo de vida de um UIViewController. Uma configuração simples É o que a nossa configuração parece no Interface Builder. Vamos examinar a Cena B. Este controlador faz parte de uma pilha UINavigationController e contém outra cena através de uma visão de recipiente. Como a maioria dos controladores, o controlador Scene B8217s possui referências a objetos criados no Interface Builder usando propriedades IBOutlet. O Controlador A Pusha para o Controlador B Quando a Cena A desencadeia um 8216show8217 segue, esses métodos substituídos são chamados no controlador Scene B8217s na seguinte ordem: initWithCoder: Ao usar storyboards, o controlador é inicializado com este método, não com o init ou initWithNibName: bundle : métodos. AwakeFromNib willMoveToParentViewController: O controlador que é passado com esta chamada é o UINavigationController. PrefereStatusBarHidden preferredStatusBarUpdateAnimation loadView UIViewController A função loadView de 8216s atribui todos os objetos com 8216Referencing Outlets8217 (também conhecido como IBOutlets) no Interface Builder para suas propriedades IBOutlet correspondentes. Se você precisa acessar esses objetos IBOutlet nesta função, ligue para o primeiro. PrepareForSegue: remetente: esta chamada nos permite inspecionar o UIStoryboardEmbedSegue que incorpora a cena menor na visão de recipiente Scene B8217s. ViewDidLoad Este método geralmente é onde a maioria de uma configuração do controller8217s acontece. Observe que todos os nossos IBOutlets foram conectados, mas nossos pontos de vista ainda não foram definidos. ExtendedLayoutIncludesOpaqueBars edgesForExtendedLayout viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForExtendedLayout updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Animação A animação que transita da Cena A para a Cena B é executada. O Passo 18 não acontece até a animação terminar. ViewDidAppear: didMoveToParentViewController: esta chamada conclui o processo iniciado no passo 2. Aqui recebemos a mesma instância do UINavigationController. UpdateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Isso responde algumas perguntas sobre quais chamadas são feitas primeiro, além de expor algumas peculiaridades interessantes. Várias chamadas aparentemente estão acontecendo mais de uma vez. A exibição scene8217s executa seu layout duas vezes, uma vez antes e uma vez após sua animação. A cena também consulta redundantemente o controlador sobre o layout estendido. O Controlador B empurra para o Controlador C Semelhante à nossa última transição, a Cena B agora desencadeia um 8216show8217 segue. Os métodos substituídos do controller8217s são chamados na seguinte ordem: prepareForSegue: remetente: esta chamada nos permite inspecionar o objeto UIStoryboardShowSegue que seguirá a cena C. viewWillDisappear: updateViewConstraints Animação A animação que transita da Cena B para a Cena C é executada. O Passo 5 não acontece até a animação terminar. ViewDidDisappear: sem surpresas aqui. Nós só conseguimos algumas chamadas e todos parecem fazer sentido neste contexto. Controlador C Pops para Controlador B Agora que passamos atrás da Cena B, vamos voltar. A Cena B está sendo carregada através de um pop-up UINavigationController (em oposição ao push no primeiro exemplo). Recebemos as seguintes chamadas: prefersStatusBarHidden preferredStatusBarUpdateAnimation extendedLayoutIncludesOpaqueBars edgesForExtendedLayout viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForExtendedLayout updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Animação A animação que transita da Cena C para a Cena B é executada. O passo 12 não acontece até a animação terminar. ViewDidAppear: updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Estas chamadas e seu pedido devem ser bastante familiares a partir da primeira transição. Notavelmente ausente são algumas das etapas de configuração únicas. O controlador ainda está dentro do UINavigationController, portanto, não há chamadas relativas ao controlador pai. Controlador B Pops para o controlador A We8217re agora feito com o nosso controlador Scene B. Estar fora da pilha UINavigationController nos dá as seguintes chamadas: willMoveToParentViewController: O argumento do controlador de exibição nesta chamada é nulo. Isso nos diz que a Cena B está sendo removida da hierarquia. ViewWillDisappear: updateViewConstraints viewDidDisappear: Animação A animação que transita da Cena B para Scene A é executada. O Passo 6 não acontece até a animação terminar. DidMoveToParentViewController: esta chamada conclui o processo iniciado no passo 1. Aqui, recebemos o mesmo argumento nil. Dealloc Semelhante à segunda transição, esta transição parece bastante direta. Depois que o controlador é removido da hierarquia, o método dealloc é chamado como qualquer outro NSObject. Veja para si mesmo O código que eu usei para executar este teste está no meu github aqui. Sinta-se à vontade para tentar você mesmo, e insira todas as outras etapas que você usaria em seus próprios controladores. Publicar navegação Categorias Mensagens recentes