Edgesforextendedlayout uiviewcontroller class

A partir do iOS7, os controladores de vista usam o layout de tela cheia por padrão. Ao mesmo tempo, você tem mais controle sobre como expõe suas visualizações, e isso é feito com essas propriedades: Basicamente, com essa propriedade você define quais lados de sua visão podem ser estendidos para cobrir toda a tela. Imagine que você empurre um UIViewController em um UINavigationController. Quando a exibição desse controlador de exibição é estabelecida, ele será iniciado onde a barra de navegação termina, mas essa propriedade irá definir quais lados da exibição (parte superior, esquerda, inferior, direita) podem ser estendidos para preencher a tela inteira. Vamos vê-lo com um exemplo: Aqui você não está definindo o valor de edgesForAxtendedLayout. Portanto, o valor padrão é tomado (UIRectEdgeAll), portanto, a exibição estende seu layout para preencher a tela inteira. Este é o resultado: Como você pode ver, o fundo vermelho se estende atrás da barra de navegação ea barra de status. Agora, você vai definir esse valor para UIRectEdgeNone. Então você está dizendo o controlador de exibição para não estender a exibição para cobrir a tela: Esta propriedade é usada quando sua exibição é um UIScrollView ou similar, como um UITableView. Você quer que sua tabela comece onde a barra de navegação termina, porque você não vai ver todo o conteúdo se não, mas ao mesmo tempo você quer que sua tabela para cobrir toda a tela ao percorrer. Nesse caso, a definição de edgesForFextendedLayout para Nenhum irá funcionar porque a sua tabela irá iniciar a rolagem onde a barra de navegação termina e ela não vai atrás dela. Aqui é onde esta propriedade vem a calhar, se você deixar o controlador de visualização ajustar automaticamente as inserções (configuração esta propriedade para YES, também o valor padrão) ele irá adicionar inserir para o topo da tabela, para que a tabela vai começar onde a navegação Barra termina, mas o pergaminho irá cobrir toda a tela. Isto é, quando é definido como NÃO: E SIM (por predefinição): Em ambos os casos, a tabela rola atrás da barra de navegação, mas no segundo caso (SIM), começará por debaixo da barra de navegação. Este valor é apenas uma adição aos anteriores. Se a barra de status for opaca, as exibições não serão estendidas para incluir a barra de status também, a menos que este parâmetro seja SIM. Portanto, se você estender sua exibição para cobrir a barra de navegação (edgesForExtendedLayout para UIRectEdgeAll) eo parâmetro é NO (padrão) ele não vai cobrir a barra de status se o seu opaco. Se algo não está claro, escrever um comentário e resposta mal a ele. Como o iOS sabe o que o UIScrollView usa para usar o iOS agarra a primeira subvisão na sua visualização de viewcontrollers, então a que está no índice 0, e se for uma subclasse do UIScrollView, aplica as propriedades explicadas a ela. Claro, isso significa que o UITableViewController funciona por padrão (uma vez que o UITableView é a primeira exibição). Eu tenho um projeto que foi construído no ano passado, e ele usa XIBs, sem storyboards. Os XIBs não usam Auto Layout, mas eles usam alguns Autosizing. Tenho um problema ao executar com o iOS7, no qual todas as visualizações estão escondidas sob a barra de status. Compreendo perfeitamente que este é um novo recurso com o iOS7, no qual isso pode ser esperado. No entanto, todas as soluções para corrigi-lo para não fazer isso não estão funcionando. Eu tenho uma imagem na parte superior da exibição que sempre aparece sob a barra de status, e eu não estou usando nav-bares ou algo assim. Eu tentei atualizar os Y-deltas no XIB (eles não têm nenhum efeito sobre a exibição), eu tentei definir o edgeForExtendedLayout para UIRectEdgeNone (não faz nada), e uma infinidade de outras coisas. Toda vez, a barra de status mostra com a visão dobrada sob ele, não importa o que eu faço. Que é a menos que eu manualmente mover para baixo a vista no XIB para permitir espaço para a barra de status (mas essa solução não funciona porque ele não olha direito no iOS6, é claro). O que é estranho é que mesmo quando eu tento uma linha de código para cortar em um turno de visão, ele não funciona (como o seguinte): Não que eu iria com esse tipo de solução, mas é apenas estranho que não funcionou Somente o tempo que normalmente vejo que não funciona é se Auto Layout está no lugar, que não é neste caso). É um requisito de design que a barra de status mostra, e eu apenas perguntei por que não consigo definir a exibição para estar sob a barra de status do iOS7. Eu li cada postagem de estouro de pilha sobre o assunto, bem como a transição de maçãs / guias. Mais uma vez, para reiterar, entendo perfeitamente como deve funcionar e qual deve ser a solução esperada para isso, mas nada disso parece estar funcionando para este projeto específico. Eu sou um experiente iOS dev, mas este projeto foi construído por outra equipe, então eu não sei se theres algo escondido em algum lugar nos arquivos XIB, plist, ou código que poderia ser trumping as configurações acima. Por favor, deixe-me saber se há algo mais que pode ser analisado sobre isso, ou mais informações que posso fornecer. Obrigado antecipadamente perguntou Sep 24 13 às 19:21 Apple estão empurrando você usar autolayout para realizar isso. Você precisa definir uma restrição para o Top Layout Guide da subview superior em sua visão. Veja este documento por exemplos: Para fazer isso sem XIBs, você precisará adicionar a restrição programaticamente. As maçãs docs dão um bom exemplo disto, que eu resumi abaixo. Dando que o topLayoutGuide é uma propriedade em um controlador de vista, você apenas usá-lo em seu dicionário de ligações variáveis. Então você configura sua restrição como normal: Ciclo de Vida de Objeto: UIViewController Ao programar em iOS, it8217s inevitável que you8217ll necessidade de subclasse UIViewController. Essas subclasses contêm toda a lógica que faz com que seus aplicativos pareçam e se comportem como deveriam. É difícil configurar uma subclasse sem saber quais métodos substituídos serão chamados e quando. Para remediar esta confusão potencial, este borne fará exame de um olhar no ciclo de vida de um UIViewController. A Simple Set Up Isto é o que o nosso conjunto parece no Interface Builder. Estaremos examinando a cena B. Este controlador é parte de uma pilha UINavigationController e contém outra cena através de uma exibição de contêiner. Como a maioria dos controladores, o controlador Scene B8217s tem referências a objetos criados no Interface Builder usando propriedades IBOutlet. Controlador A Pushes to Controller B Quando Scene A aciona 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 8216s A função loadView atribui todos os objetos com 8216Referencing Outlets8217 (também conhecido como IBOutlets) no Interface Builder às suas propriedades IBOutlet correspondentes. Se você precisar de acesso a esses objetos IBOutlet nesta função, chame primeiro super. PrepareForSegue: sender: Esta chamada permite-nos inspecionar o UIStoryboardEmbedSegue que incorpora a cena menor no modo de exibição de contêiner Scene B8217s. ViewDidLoad Este método é geralmente onde a maioria dos um controller8217s configurado acontece. Tenha em atenção que todos os nossos IBOutlets foram ligados, mas as nossas opiniões ainda não foram apresentadas. ExtendedLayoutIncludesOpaqueBars edgesForValenteAvançar viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForValenteAvançar updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Animação A animação que transita da Cena A para a Cena B é executada. Passo 18 não acontece até que a animação termine. ViewDidAppear: didMoveToParentViewController: Esta chamada conclui o processo iniciado na etapa 2. Aqui recebemos a mesma instância de UINavigationController. UpdateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Isso responde a algumas perguntas sobre quais chamadas vêm em primeiro lugar, além de expor algumas peculiaridades interessantes. Várias chamadas aparentemente estão acontecendo mais de uma vez. A cena scene8217s executa seu layout duas vezes, uma vez antes e uma após sua animação. A cena também consulta redundantemente o controlador sobre o layout estendido. Controlador B Empurra para o Controlador C Semelhante à nossa última transição, a Cena B dispara agora um 8216show8217 segue. Os métodos controlados do controller8217s são chamados na seguinte ordem: prepareForSegue: sender: Esta chamada permite-nos inspecionar o objeto UIStoryboardShowSegue que seguirá para a Cena C. viewWillDisappear: updateViewConstraints Animação A animação que transita da Cena B para a Cena C é executada. Etapa 5 não acontece até que a animação termine. ViewDidDisappear: Sem surpresas aqui. Só recebemos algumas chamadas e todas parecem fazer sentido neste contexto. Controlador C Pops para o Controlador B Agora que passamos da cena B, vamos voltar. Cena B está sendo carregado através de um pop UINavigationController (em oposição ao empurrar no primeiro exemplo). Recebemos as chamadas a seguir: prefersStatusBarHidden preferredStatusBarUpdateAnimation extendedLayoutIncludesOpaqueBars edgesForFundedLayout viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForExtendedLayout updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Animação A animação que transita da Cena C para a Cena B é executada. Etapa 12 não acontece até que a animação termine. ViewDidAppear: updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Essas chamadas e suas ordens 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 para que não haja chamadas relativas ao controlador pai. Controlador B Pops para o controlador A We8217re agora feito com o nosso controlador Scene B. Popping-lo fora da pilha UINavigationController nos dá as seguintes chamadas: willMoveToParentViewController: O argumento de controlador de vista nesta chamada é nil. Isso nos diz que a cena B está sendo removida da hierarquia. ViewWillDisappear: updateViewConstraints viewDidDisappear: Animation A animação que transita da cena B para a cena A é executada. Passo 6 não acontece até que a animação termine. DidMoveToParentViewController: Esta chamada conclui o processo iniciado na etapa 1. Aqui recebemos o mesmo argumento nil. Dealloc Similar à segunda transição, esta transição parece bastante direta. Depois que o controlador é removido da hierarquia seu método dealloc é chamado como qualquer outro NSObject. See For Yourself O código que eu usei para executar este teste está no meu github aqui. Sinta-se livre para experimentá-lo você mesmo, e insira quaisquer outras etapas que você usaria em seus próprios controladores. Post navigation Categorias Mensagens recentes