Quando usar o Storyboard e quando usar XIBs

Existem diretrizes sobre quando usar storyboards em um projeto iOS e quando usar XIBs? Quais são os prós e os contras de cada um e em que situações eles se adequam?

Pelo que sei, não é tão fácil usar os seguimentos do storyboard quando você vê controladores sendo pressionados por elementos dinâmicos da interface do usuário (como pinos do mapa).

Eu usei XIBs extensivamente e concluí dois projetos usando Storyboards. Meus aprendizados são:

• Os storyboards são ótimos para aplicativos com um número pequeno a médio de telas e navegação relativamente direta entre visualizações.
• Se você tiver muitas visualizações e muita navegação cruzada entre elas, a exibição do Storyboard fica confusa e com muito trabalho para se manter limpa.
• Para um projeto grande com vários desenvolvedores, eu não usaria o Storyboards porque você tem um único arquivo para sua interface do usuário e não pode trabalhar facilmente em paralelo.
• Pode valer a pena que aplicativos grandes se dividam em vários arquivos de storyboard, mas eu não tentei isso. Esta resposta mostra como fazer segues entre storyboards.
• Você ainda precisa de XIBs: nos dois projetos do Storyboard, eu tive que usar XIBs para células de tabela personalizadas.

Acho que os Storyboards são um passo na direção certa para a implementação da interface do usuário e espero que a Apple os estenda nas futuras versões do iOS. Eles precisam resolver o problema de "arquivo único", caso contrário, não serão atraentes para projetos maiores.

Se eu iniciar um aplicativo de tamanho pequeno e puder oferecer compatibilidade apenas com iOS5, eu usaria Storyboards. Para todos os outros casos, atendo aos XIBs.

Atualização 1/12/2016 : é 2016 e ainda prefiro definir minhas interfaces de usuário no código e não no Storyboards. Dito isto, os Storyboards percorreram um longo caminho. Eu removi todos os pontos deste post que simplesmente não se aplicam mais em 2016.

Atualização 24/04/2015 : Curiosamente, a Apple nem usa Storyboards em seu ResearchKit de código aberto recentemente, como Peter Steinberger notou (no subtítulo "Interface Builder").

Atualização 6/10/2014 : Como esperado, a Apple continua aprimorando o Storyboards e o Xcode. Alguns dos pontos aplicados ao iOS 7 e abaixo não se aplicam mais ao iOS 8 (e agora estão marcados como tal). Portanto, embora os Storyboards ainda tenham falhas, eu reviso meus conselhos de não usar para usar seletivamente onde faz sentido .

Mesmo agora que o iOS 9 está pronto, eu recomendaria contratenha cuidado ao decidir usar Storyboards. Aqui estão as minhas razões:

• Os storyboards falham no tempo de execução, não no tempo de compilação : você possui um erro de digitação no nome de um segue ou o conectou errado no seu storyboard? Ele explodirá em tempo de execução. Você usa uma subclasse UIViewController personalizada que não existe mais no seu storyboard? Ele explodirá em tempo de execução. Se você fizer essas coisas no código, as capturará desde o início, durante o tempo de compilação. Atualização : Minha nova ferramenta StoryboardLint resolve principalmente esse problema.

• Os storyboards ficam confusos rapidamente : à medida que seu projeto cresce, seu storyboard se torna cada vez mais difícil de navegar. Além disso, se vários controladores de visualização tiverem várias sequências para vários outros controladores de visualização, seu storyboard rapidamente começará a parecer uma tigela de espaguete e você se aproximará e afastará o zoom e rolar por todo o local para encontrar o controlador de visualização que está procurando para e descobrir o que segue aponta onde. Atualização : Esse problema pode ser resolvido principalmente dividindo seu Storyboard em vários Storyboards, conforme descrito neste artigo por Pilky e neste artigo por Robert Brown .

• Os storyboards tornam o trabalho em equipe mais difícil : como você geralmente possui apenas um arquivo de storyboard enorme para o seu projeto, ter vários desenvolvedores regularmente fazendo alterações nesse arquivo pode ser uma dor de cabeça: as alterações precisam ser mescladas e os conflitos resolvidos. Quando ocorre um conflito, é difícil saber como resolvê-lo: o Xcode gera o arquivo XML do storyboard e ele não foi realmente projetado com o objetivo de que um ser humano precisaria ler e muito menos editá-lo.

• Os storyboards tornam as revisões de código difíceis ou quase impossíveis : as revisões de código por pares são uma ótima coisa para fazer em sua equipe. No entanto, quando você faz alterações em um storyboard, é quase impossível revisar essas alterações com um desenvolvedor diferente. Tudo o que você pode obter é uma comparação de um enorme arquivo XML. Decifrar o que realmente mudou e se essas mudanças estão corretas ou se quebraram algo é realmente difícil.

• Os storyboards dificultam a reutilização do código : nos meus projetos para iOS, geralmente crio uma classe que contém todas as cores, fontes, margens e inserções que uso em todo o aplicativo para proporcionar uma aparência e sensação consistentes: é necessário alterar uma linha se necessário. ajuste qualquer um desses valores para todo o aplicativo. Se você definir esses valores no storyboard, você os duplicará e precisará encontrar todas as ocorrências quando quiser alterá-los. Há grandes chances de você perder uma, porque não há pesquisa e substituição nos storyboards.

• Os storyboards exigem alternância constante de contexto : eu me pego trabalhando e navegando muito mais rápido no código do que nos storyboards. Quando seu aplicativo usa storyboards, você muda constantemente de contexto: "Oh, eu quero que uma torneira nesta célula de exibição de tabela carregue um controlador de exibição diferente. Agora, tenho que abrir o storyboard, encontrar o controlador de exibição correto, criar um novo segue para o outro controlador de exibição (que eu também tenho que encontrar), dê um nome às segue, lembre-se desse nome (não posso usar constantes ou variáveis ​​nos storyboards), volte ao código e espero não digitar o nome de isso segue para o meu método prepareForSegue. Como eu gostaria de poder digitar essas 3 linhas de código aqui onde estou! " Não, não é divertido. A alternância entre código e storyboard (e entre teclado e mouse) envelhece rapidamente e o torna mais lento.

• Os storyboards são difíceis de refatorar : quando você refatorar seu código, verifique se ele ainda corresponde ao que o storyboard espera. Quando você move as coisas no seu storyboard, você só descobrirá em tempo de execução se ele ainda funcionar com o seu código. Parece-me que tenho que manter dois mundos sincronizados. Parece frágil e desencoraja mudanças na minha humilde opinião.

• Os storyboards são menos flexíveis : no código, você pode basicamente fazer o que quiser! Com os storyboards, você está limitado a um subconjunto do que você pode fazer no código. Especialmente quando você quer fazer coisas avançadas com animações e transições, você se encontrará "lutando contra o storyboard" para fazê-lo funcionar.

• Os storyboards não permitem alterar o tipo de controladores de exibição especiais : você deseja alterar um UITableViewControllerpara um UICollectionViewController? Ou em uma planície UIViewController? Não é possível em um storyboard. Você precisa excluir o antigo controlador de exibição, criar um novo e reconectar todos os seguintes. É muito mais fácil fazer essa alteração no código.

• Os storyboards adicionam dois passivos extras ao seu projeto : (1) A ferramenta Editor de storyboard que gera o XML do storyboard e (2) o componente de tempo de execução que analisa o XML e cria objetos de interface do usuário e controlador a partir dele. Ambas as partes podem ter bugs que você não pode consertar.

• Os storyboards não permitem adicionar uma subvisão aUIImageView : Quem sabe o porquê.

• Os storyboards não permitem ativar o Layout automático para exibições individuais (controladores) : Ao marcar / desmarcar a opção Layout automático em um Storyboard, a alteração é aplicada a TODOS os controladores no Storyboard. (Obrigado a Sava Mazăre por este ponto!)

• Os storyboards têm um risco maior de quebrar a compatibilidade com as versões anteriores : o Xcode às vezes altera o formato do arquivo do Storyboard e não garante de forma alguma que você possa abrir os arquivos do Storyboard criados hoje em alguns anos ou meses. (Agradecemos aos pensamentos avançados sobre este ponto. Veja o comentário original )

• Os storyboards podem tornar seu código mais complexo : quando você cria seus controladores de exibição no código, pode criar initmétodos personalizados , por exemplo initWithCustomer:. Dessa forma, você pode tornar customerimutável a parte interna do seu controlador de exibição e garantir que ele não possa ser criado sem um customerobjeto. Isso não é possível ao usar Storyboards. Você terá que aguardar a prepareForSegue:sender:chamada do método e, em seguida, definir a customerpropriedade no seu controlador de exibição, o que significa que você deve tornar essa propriedade mutável e permitir que o controlador de exibição seja criado sem um customerobjeto . Na minha experiência, isso pode complicar bastante o seu código e dificulta o raciocínio sobre o fluxo do seu aplicativo. Atualização 9/9/16: Chris Dzombak escreveu um ótimo artigo sobre esse problema .

• É o McDonald's : Para dizer isso nas palavras de Steve Jobs sobre a Microsoft: É o McDonald's (vídeo) !

Essas são as minhas razões pelas quais eu realmente não gosto de trabalhar com storyboards. Alguns desses motivos também se aplicam aos XIBs. Nos projetos baseados em storyboard nos quais trabalhei, eles me custaram muito mais tempo do que economizaram e tornaram as coisas mais complicadas, em vez de mais fáceis.

Quando crio minha interface do usuário e o fluxo do aplicativo no código, tenho muito mais controle sobre o que está acontecendo, é mais fácil depurar, é mais fácil detectar erros desde o início, é mais fácil explicar minhas alterações para outros desenvolvedores e é mais fácil oferecer suporte ao iPhone e iPad.

No entanto, concordo que o layout de toda a interface do usuário no código pode não ser uma solução única para todos os projetos. Se a interface do usuário do iPad diferir muito da interface do iPhone em determinados lugares, pode fazer sentido criar um XIB apenas para essas áreas.

Muitos dos problemas descritos acima podem ser corrigidos pela Apple e espero que seja isso que eles farão.

Apenas meus dois centavos.

Atualização : No Xcode 5, a Apple retirou a opção de criar um projeto sem um Storyboard. Eu escrevi um pequeno script que porta os modelos do Xcode 4 (com a opção Storyboard-opt-out) para o Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

Os storyboards foram criados para ajudar os desenvolvedores a visualizar seu aplicativo e o fluxo do aplicativo. É como ter um monte de xib, mas em um único arquivo.

Existe uma pergunta semelhante a esta localizada Qual é a diferença entre um arquivo .xib e um .storyboard? .

Você também pode criar transições personalizadas via código que mudará dinamicamente, se necessário, da mesma forma que você pode com .xibs.

PROS:

• Você pode simular o fluxo de um aplicativo sem escrever muito, se houver algum código.
• Muito mais fácil ver suas transições entre telas e o fluxo do aplicativo.
• Também pode usar .xibs, se necessário, com storyboards.

CONTRAS:

• Funciona apenas com iOS 5 ou superior. Não funciona com iOS4.
• Pode ficar desordenado facilmente se você tiver um aplicativo muito intenso.

Realmente não há certo / errado quando usar um ou outro, é apenas uma questão de preferência e quais versões do iOS você deseja usar.

Explicarei apenas 4 razões simples pelas quais você deve usar storyboards, especialmente em um ambiente produtivo, no qual você deve trabalhar em uma equipe de proprietários de produtos, gerentes de produto, designers de UX, etc.

1. A Apple melhorou bastante o trabalho com Storyboards. E eles incentivam você a trabalhar com eles. O que significa que eles não quebrarão seus projetos existentes com atualizações, garantirão que os storyboards sejam uma prova futura de versões mais recentes do XCode / iOS.
2. Resultados mais visíveis em menos tempo para os proprietários e gerentes de produtos, mesmo durante a fase de criação. Você pode até usar o próprio storyboard como um diagrama de fluxo de tela e discuti-lo em reuniões.
3. Mesmo após a conclusão de um aplicativo (e é geralmente aí que o seu ciclo de vida começa) - no futuro, será mais rápido e fácil aplicar pequenos ajustes . E isso pode muito bem alterar vários aspectos do seu layout ao mesmo tempo, o que você provavelmente deseja ver de maneira WYSIWYG. A alternativa seria alterar manualmente a interface do usuário no código e alternar entre o IDE e o simulador para testá-lo, sempre aguardando a compilação e a compilação.
4. Os não desenvolvedores podem ser ensinados a configurar layouts em storyboards e criar os ganchos necessários para os desenvolvedores (IBOutlets e IBActions). Essa é uma vantagem muito grande, pois permite que os desenvolvedores se concentrem na lógica e os designers de UX aplicam suas alterações de maneira visual, sem precisar escrever nenhum código.

Não escreverei nenhum CONS, pois Johannes já listou provavelmente todos os viáveis ​​em sua resposta. E a maioria deles definitivamente não é viável, especialmente as principais melhorias do XCode6.

Não acho que exista uma resposta certa para sua pergunta, é apenas uma questão de experiência pessoal e com o que você se sente mais confortável.

Na minha opinião, os Storyboards são ótimos. É verdade, é realmente difícil descobrir por que seu aplicativo está travando misteriosamente em tempo de execução, mas depois de algum tempo e experiência, você perceberá que está sempre relacionado a algum IBOutlet ausente em algum lugar e poderá corrigi-lo facilmente.

O único problema real é trabalhar em equipe sob controle de versão com storyboards; nos estágios iniciais de desenvolvimento, pode ser uma verdadeira bagunça. Porém, após esse primeiro estágio, as atualizações da interface do usuário que alteram completamente o storyboard são muito raras e, na maioria dos casos, você acaba com conflitos nas últimas partes do xml, que são referências a seguir que geralmente se corrigem automaticamente quando você reabre o storyboard. . Em nosso trabalho de equipe, preferimos lidar com isso em vez de controladores de exibição pesados ​​com toneladas de código de exibição.

Eu li muitos comentários contra o layout automático. Com o XCode5, ele realmente melhorou, é muito bom mesmo para autorotating layouts. Em alguns casos, você terá que fazer algo no código, mas pode simplesmente eliminar a restrição que precisa editar e, nesse ponto, fazer o que precisa no seu código. Até animá-los.

Eu também acho que a maioria das pessoas que não gostam de storyboards não tentaram entender completamente o poder de um manual personalizado segue, onde você pode personalizar totalmente (em um único arquivo) a maneira como faz a transição de uma maneira para outra e também (com alguns truques) até reutilizam um controlador de visualização carregado anteriormente, apenas atualizando seu conteúdo de visualização em vez de recarregar completamente a coisa toda. No final, você pode realmente fazer as mesmas coisas que no código, mas acho que você tem uma melhor separação de preocupações com os storyboards, mas eu concordo que em muitas coisas elas não possuem recursos (fontes, imagem como plano de fundo colorido, etc.) )

Não estou usando o StoryBoard ou XIBs em nenhum aplicativo, mas criando tudo programaticamente.

∆ Benefícios:

√ Você pode criar qualquer tipo complexo de interface do usuário ou animações de transição para UIView.

√ Suporte todas as versões do iOS. Não precisa se preocupar com <iOS 5.

√ * Seu aplicativo suporta todos os dispositivos iPhone / iPod / iPad dentro do seu código.

√ Você está sempre atualizado, pois conhece o código que sempre funcionará.

√ * Funciona em qualquer dispositivo (novo) iniciado - Não há necessidade de alterar o código.

√ Tudo depende de você. Em determinado lugar, você deseja alterar alguma coisa - Não há necessidade de procurar no storyboard ou no xib. Basta procurá-lo em uma classe específica.

√ Por último, mas não a lista - você nunca esquecerá isso, como gerenciar tudo programaticamente. Essa é a melhor coisa, pois você conhece um controle muito profundo do que qualquer um.

_{Nunca encontrei um problema ao não usar SB ou XIBs, pois sou bom nisso.}

_{* se você definiu os quadros de objeto do UIKit de acordo com o tamanho da tela.}

_{PS Se você ainda não fez isso - pode ter dificuldade (ou pode se sentir entediado), mas depois de se familiarizar com isso - é realmente um doce para você.}

Se você está prestes a se importar com o desempenho do Storyboard, assista à Sessão 407 da WWDC 2015

Tempo de construção

Quando o criador de interfaces está compilando um storyboard, ele faz duas coisas primeiro, tenta maximizar o desempenho do seu aplicativo e, em segundo lugar, também minimiza o número de arquivos de ponta criados.

Se eu tiver um controlador de exibição com uma exibição e várias sub-exibições, construtor de interfaces, o tempo de criação criará um arquivo de ponta para o controlador de exibição e criará um arquivo de ponta para a exibição.

Por ter arquivos de ponta separados para o controlador de exibição e a exibição, isso significa que a hierarquia da exibição pode ser carregada sob demanda.

Tempo de execução

Quando você aloca uma instância de storyboard usando o storyboard da interface do usuário, API, inicialmente tudo o que você está alocando memória é a própria instância do storyboard da interface do usuário.

Ainda não há controladores de exibição.

Quando você instancia seu controlador de exibição inicial, ele carrega a ponta desse controlador de exibição inicial, mas, novamente, nenhuma hierarquia de exibição foi carregada até que alguém realmente o solicite.

Eu tenho trabalhado em um projeto de tamanho razoável (> 20 cenas no jargão do storyboard), e deparei com muitas limitações e tenho que ir repetidamente à documentação e às pesquisas no Google para fazer as coisas.

1. A interface do usuário está tudo em um arquivo. Mesmo se você criar vários storyboards, ainda terá muitas cenas / telas em cada storyboard. Esse é um problema em equipes de médio e grande porte.

2. Em segundo lugar, eles não funcionam bem com controladores de contêiner personalizados que incorporam outros controladores de contêineres etc. Estamos usando o MFSlideMenu em um aplicativo com guias e a cena possui uma tabela. Isso é quase impossível de se fazer com um storyboard. Depois de passar dias, recorri à maneira XIB, onde há controle completo.

3. O IDE não permite selecionar controles no estado de redução de zoom. Portanto, em um projeto grande, a redução é principalmente para obter uma visualização de alto nível e nada mais.

Eu usaria storyboards para aplicativos menores com equipes pequenas e usaria a abordagem XIB para equipes / projetos de médio a grande porte.

Se você deseja reutilizar alguma interface do usuário em vários controladores de exibição, use XIBs