Eu costumo ouvir desenvolvedores iOS faça alguma variante da mesma pergunta-chave:

Qual é a melhor maneira de desenvolver uma IU no iOS: por meio de Storyboards, NIBs ou código?

As respostas a esta pergunta, explícita ou implicitamente, tendem a supor que há uma escolha mutuamente exclusiva a ser feita, que muitas vezes é abordada antecipadamente, antes do desenvolvimento.

Sou de opinião que a resposta, em vez disso, deve assumir a forma de um ou mais contador questões.

Qual é o “melhor” carro?

Deixe-me explicar com um exemplo fora do tópico. Digamos que eu queira comprar um carro e faça uma pergunta simples: “Qual é a melhor escolha?”

Você pode realmente responder sugerindo um modelo, ou mesmo um marca ? Provavelmente não, a menos que você sugira uma Ferrari. Em vez disso, você provavelmente responderia com algumas outras perguntas, como:

• Qual é o seu orçamento?
• Quantos assentos você precisa?
• Você se preocupa com o consumo de combustível?
• Como você se sente em relação aos carros esportivos?

É óbvio que não existe tal coisa como Boa ou ruim carro, a menos que seja colocado em um contexto adequado - há apenas um carro bom ou ruim com base em necessidades específicas.

Voltar ao design da IU do iOS

Assim como com nossa pesquisa de carro, o “Qual é a melhor maneira de desenvolver uma IU iOS” questão carece de contexto. E, surpreendentemente, a resposta não precisa ser um caso geral.

Em termos gerais, existem três tipos de abordagens de design de interface do usuário que você pode adotar, cada uma com seus prós e contras, seus fãs e inimigos:

• Storyboards iOS : Uma ferramenta visual para o layout de múltiplas visualizações de aplicativos e as transições entre elas.
• NIBs (ou XIBs) : Cada arquivo NIB corresponde a um único elemento de visualização e pode ser disposto no Interface Builder, tornando-o também uma ferramenta visual. Observe que o nome “NIB” é derivado da extensão do arquivo (anteriormente .nib e agora .xib, embora a pronúncia antiga tenha persistido).
• Código personalizado : ou seja, não GUI ferramentas, mas em vez disso, lidar com todo o posicionamento personalizado, animação, etc. de forma programática.

Nenhuma dessas opções é universalmente Melhor do que qualquer outro (apesar do que você possa ouvir).

o que é powerpivot no excel

Storyboards , por exemplo, são a adição mais recente ao kit de ferramentas de IU do iOS. Disseram-me que eles são o futuro, que substituirão os NIBs e as interfaces de usuário de código personalizado. Eu vejo Storyboards como uma ferramenta útil, mas não tanto um substituição tenha um complemento para NIBs e código personalizado. Os storyboards são a escolha certa em algumas situações, mas não em todas.

Além disso, por que você deveria se limitar estaticamente a uma única opção quando pode usar todas elas (no mesmo projeto), escolhendo o mecanismo que melhor se adapta ao problema específico em questão?

Esta é uma pergunta que pode ser, na minha opinião, generalizada em um nível mais alto, e cuja resposta é altamente classificada em minha lista de princípios de desenvolvimento de software: Não existe uma linguagem, estrutura ou tecnologia universal que seja a melhor escolha universal para todos os problemas de desenvolvimento de software. O mesmo se aplica ao design da IU do iOS.

Neste tutorial de desenvolvimento iOS, vamos explorar cada um desses métodos e apresentar casos de uso em que eles devem e devem não ser empregados, bem como as maneiras pelas quais eles podem ser combinados.

Storyboards iOS

Um erro clássico do iniciante é criar um grande storyboard do iOS para todo o projeto. Eu também cometi esse erro quando comecei a trabalhar com Storyboards (provavelmente porque é um caminho tentador).

Um erro clássico do iniciante é criar um grande storyboard para todo o projeto. Um Storyboard é um quadro com uma história para contar. Não deve ser usado para misturar histórias não relacionadas em um grande volume.

Como o próprio nome indica, um Storyboard é um placa com uma história para contar . Não deve ser usado para misturar histórias não relacionadas em um grande volume. Um storyboard deve conter controladores de visualização logicamente relacionados entre si, o que não significa cada ver controlador.

Por exemplo, faz sentido usar Storyboards ao lidar com:

• Um conjunto de visualizações para autenticação e registro.
• Um fluxo de entrada de pedido em várias etapas.
• Um fluxo tipo assistente (ou seja, tutorial).
• Um conjunto de visualizações de detalhes mestres (por exemplo, listas de perfis, detalhes de perfil).

Enquanto isso, storyboards grandes devem ser evitados, incluindo storyboards em todo o aplicativo (a menos que o aplicativo seja relativamente simples). Antes de irmos mais fundo, vamos ver o porquê.

A loucura de grandes storyboards iOS

Grandes storyboards, além de serem difíceis de navegar e manter, adicionam uma camada de complexidade a um ambiente de equipe: quando vários desenvolvedores trabalham no mesmo arquivo de storyboard ao mesmo tempo, conflitos de controle de origem são inevitáveis . E embora um storyboard seja internamente representado como um arquivo de texto (um arquivo XML, na verdade), a fusão geralmente não é trivial.

o que é um CFO responsável por

Quando os desenvolvedores visualizam o código-fonte, eles atribuem a ele um significado semântico. Assim, ao mesclar manualmente, eles são capazes de ler e entender os dois lados de um conflito e agir de acordo. Em vez disso, um storyboard é um arquivo XML gerenciado pelo Xcode, e o significado de cada linha de código nem sempre é fácil de entender.

Vejamos um exemplo muito simples: digamos que dois desenvolvedores diferentes mudem a posição de um UILabel (usando autolayout), e o último empurra sua mudança, produzindo um conflito como este (observe os atributos id conflitantes):

id

O alloc em si não fornece qualquer indicação quanto ao seu verdadeiro significado, então você não tem nada com o que trabalhar. A única solução significativa é escolher um dos dois lados do conflito e descartar o outro. Haverá efeitos colaterais? Quem sabe? Você não.

Para facilitar esses problemas de design de interface do iOS, o uso de vários storyboards no mesmo projeto é a abordagem recomendada.

Quando usar storyboards

Os storyboards são mais bem usados ​​com vários controladores de exibição interconectados, pois sua maior simplificação está na transição entre os controladores de exibição. Até certo ponto, eles podem ser considerados como uma composição de NIBs com fluxos visuais e funcionais entre controladores de visualização.

Os storyboards são mais bem usados ​​com vários controladores de exibição interconectados, pois sua maior simplificação está na transição entre os controladores de exibição.

Além de facilitar o fluxo de navegação, outra vantagem distinta é que eles eliminam o código clichê necessário para pop, push, apresentar e dispensar controladores de visualização. Além disso, os controladores de visualização são alocados automaticamente, portanto, não há necessidade de manualmente init e prepareForSegue:sender.

Finalmente, embora os Storyboards sejam mais usados ​​para cenários que envolvem vários controladores de visualização, também é defensável usar um Storyboard ao trabalhar com um solteiro controlador de visualização de tabela por três razões:

• A capacidade de projetar protótipos de células de mesa no local ajuda a manter as peças juntas.
• Vários modelos de células podem ser projetados dentro do controlador de visualização da tabela pai.
• É possível criar visualizações de tabela estáticas (uma adição muito esperada que infelizmente só está disponível em Storyboards).

Alguém poderia argumentar que vários modelos de células também podem ser projetados usando NIBs. Na verdade, isso é apenas uma questão de preferência: alguns desenvolvedores preferem ter tudo em um só lugar, enquanto outros não se importam.

Quando Não usar storyboards iOS

Alguns casos:

• A visualização tem um layout complicado ou dinâmico, melhor implementado com código.
• A visualização já está implementada com NIBs ou código.

Nesses casos, podemos deixar a visualização fora do Storyboard ou incorporá-la em um controlador de visualização. O primeiro quebra o fluxo visual do Storyboard, mas não tem quaisquer implicações funcionais ou de desenvolvimento negativas. Este último retém esse fluxo visual, mas requer esforços de desenvolvimento adicionais, uma vez que a visualização não está integrada ao controlador de visualização: é apenas incorporado como um componente, portanto, o controlador de visualização deve interagir com a visualização em vez de implementá-lo.

Prós e contras gerais

Agora que sabemos quando os Storyboards são úteis no iOS Design de interface do usuário , e antes de passarmos para os NIBs neste tutorial, vamos ver suas vantagens e desvantagens gerais.

Pro: Desempenho

Intuitivamente, você pode assumir que, quando um Storyboard é carregado, todos os seus controladores de visualização são instanciados imediatamente. Felizmente, isso é apenas uma abstração e não verdadeiro para a implementação real: em vez disso, apenas o controlador de visualização inicial, se houver, é criado. Os outros controladores de visualização são instanciados dinamicamente, quando uma segue é realizada ou manualmente a partir do código.

Pro: protótipos

Storyboards simplificam a prototipagem e simulação de interfaces de usuário e fluxo. Na verdade, um aplicativo protótipo de trabalho completo com visualizações e navegação pode ser facilmente implementado usando Storyboards e apenas algumas linhas de código.

Com: Reutilização

Quando se trata de mover ou copiar, os storyboards do iOS estão mal posicionados. Um Storyboard deve ser movido junto com todos os seus controladores de visualização dependentes. Em outras palavras, um único controlador de visualização não pode ser extraído e reutilizado individualmente em outro lugar como uma única entidade independente; depende do resto do Storyboard para funcionar.

Com: Fluxo de dados

Os dados geralmente precisam ser transmitidos entre controladores de visualização quando um aplicativo faz a transição. No entanto, o fluxo visual do Storyboard é interrompido neste caso, já que não há vestígios disso acontecendo no Interface Builder. Os storyboards cuidam do fluxo entre os controladores de visualização, mas não do fluxo de dados. Portanto, o controlador de destino deve ser configurado com código, substituindo a experiência visual.

Os storyboards cuidam do fluxo entre os controladores de visualização, mas não do fluxo de dados.

Nesses casos, temos que confiar em um - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier [email protected] 'segue_name_1']) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier [email protected] 'segue_name_2']) { ... } else if ... } , com um esqueleto if / else-if como este:

TTLoginView

Acho que essa abordagem é propensa a erros e desnecessariamente prolixa.

NIBs

Os NIBs são a forma mais antiga de realizar o design da interface do iOS.

Nesse caso, 'antigo' não significa 'ruim', 'desatualizado' ou 'obsoleto'. Na verdade, é importante entender que os Storyboards do iOS não são uma substituição universal para os NIBs; eles apenas simplificam a implementação da IU em alguns casos.

Com os NIBs, qualquer visualização arbitrária pode ser projetada, que o desenvolvedor pode então anexar a um controlador de visualização conforme necessário.

Se aplicarmos um design orientado a objetos às nossas IUs, faz sentido dividir a visão de um controlador de visualização em módulos separados , cada um implementado como uma visualização com seu próprio arquivo NIB (ou com vários módulos agrupados no mesmo arquivo). A vantagem clara dessa abordagem é que cada componente é mais fácil de desenvolver, testar e depurar.

NIBs compartilham os problemas de conflito de mesclagem que vimos com Storyboards, mas em menor grau, pois os arquivos NIB operam em uma escala menor.

Quando usar NIBs para iOS UI Design

Um subconjunto de todos os casos de uso seria:

• Vistas modais
• Visualizações simples de login e registro
• Definições
• Janelas pop-up
• Modelos de visualização reutilizáveis
• Modelos de célula de tabela reutilizáveis

Entretanto…

Quando Não usar NIBs

Você deve evitar o uso de NIBs para:

que tipo de llc eu tenho

• Exibições com conteúdo dinâmico, onde o layout muda significativamente dependendo do conteúdo.
• Visualizações que, por natureza, não são facilmente projetáveis ​​no Interface Builder.
• Visualize controladores com transições complicadas que podem ser simplificadas com o Storyboarding.

Prós e contras gerais

De forma mais geral, vamos examinar os prós e contras do uso de NIBs.

Pro: Reutilização

Os NIBs são úteis quando o mesmo layout é compartilhado por várias classes.

Como um caso de uso simples, um modelo de visão contendo um nome de usuário e um campo de texto de senha poderia ser implementado com o hipotético TTSignupView e TTLoginView visualizações, ambas podendo originar-se do mesmo NIB. O

teria que ocultar o campo de senha, e ambos teriam que especificar rótulos estáticos correspondentes (como ‘Digite seu nome de usuário’ vs ‘Digite sua senha’), mas os marcadores teriam a mesma funcionalidade básica e layouts semelhantes.

Pro e Con: Desempenho

NIBs são carregado preguiçosamente , para que não usem memória até que seja necessário. Embora isso possa ser uma vantagem, há latência para o processo de carregamento lento, o que também o torna uma desvantagem.

Código personalizado iOS (IUs programáticas)

Qualquer design de interface iOS isso pode ser feito com Storyboards e NIBs também pode ser implementado com código bruto (houve um tempo, é claro, em que os desenvolvedores não podiam se dar ao luxo de um conjunto tão rico de ferramentas).

como escrever documentação de software

O que não pode ser feito com NIBs e Storyboards sempre pode ser implementado com código.

Talvez mais importante, o que não pode ser feito com NIBs e Storyboards sempre pode ser implementado com código - desde, é claro, que seja tecnicamente viável. Outra maneira de ver isso é que NIBs e Storyboards são implementados com código, portanto, sua funcionalidade será naturalmente um subconjunto. Vamos pular direto para os prós e contras.

Pro: Under the Hood

A maior vantagem de criar uma IU iOS programaticamente: se você sabe como codificar uma interface de usuário, então sabe o que acontece nos bastidores , enquanto o mesmo não é necessariamente verdadeiro para NIBs e Storyboards.

Para fazer uma comparação: uma calculadora é uma ferramenta útil. Mas não é uma coisa ruim saber fazer cálculos manualmente.

Isso não se limita ao iOS, mas a qualquer ferramenta visual RAD (por exemplo, Visual Studio e Delphi, apenas para citar alguns). Os ambientes RAD em HTML visual representam um caso limítrofe típico: eles são usados ​​para gerar código (muitas vezes mal escrito), alegando que nenhum conhecimento de HTML é necessário e que tudo pode ser feito visualmente. Mas nenhum desenvolvedor da web implementaria uma página da web sem sujar as mãos: eles sabem que manusear manualmente o HTML e CSS brutos levará a um código mais modular e mais eficiente.

Portanto, dominar a codificação das interfaces de usuário do iOS dá a você mais controle e maior consciência de como essas peças se encaixam, o que aumenta seu limite superior como desenvolvedor.

Pro: quando o código é a única opção

Também há casos em que o código iOS personalizado é a única opção para design de IU. Layouts dinâmicos, onde os elementos da vista são movidos e o fluxo ou layout se ajusta significativamente com base no conteúdo, são exemplos típicos.

Pro: mesclar conflitos

Enquanto NIBs e Storyboards sofreram significativamente com conflitos de mesclagem, o código não tem a mesma falha. Todo código tem significado semântico, portanto, resolver conflitos não é mais difícil do que o normal.

Com: Prototipagem

É difícil descobrir como um layout ficará até que você o veja em ação. Além disso, você não pode posicionar visualmente visualizações e controles, portanto, traduzir as especificações de layout em uma visualização tangível pode demorar muito mais, em comparação com NIBs e Storyboards, que fornecem uma visualização imediata de como as coisas serão renderizadas.

Com: Refatoração

Refatorar código que foi escrito há muito tempo ou por outra pessoa também se torna muito mais complicado: quando os elementos estão sendo posicionados e animados com métodos personalizados e números mágicos, as sessões de depuração podem se tornar árduas.

Pro: Desempenho

Em termos de desempenho, Storyboards e NIBs estão sujeitos à sobrecarga de carregamento e análise; e no final, eles são traduzidos indiretamente em código. Nem é preciso dizer que isso não acontece com interfaces de usuário criadas por código.

Pro: Reutilização

Qualquer visualização implementada programaticamente pode ser projetada de forma reutilizável. Vejamos alguns casos de uso:

• Duas ou mais visualizações compartilham um comportamento comum, mas são ligeiramente diferentes. Uma classe base e duas subclasses resolvem o problema elegantemente.
• Um projeto deve ser bifurcado, com o objetivo de criar uma única base de código, mas gerando duas (ou mais) aplicações diferentes, cada uma com customizações específicas.

O mesmo processo de design de IU seria muito mais complicado com NIBs e Storyboards. Arquivos de modelo não permitem herança, e as soluções possíveis são limitadas ao seguinte:

• Duplique os arquivos NIB e Storyboard. Depois disso, eles têm vidas separadas e nenhuma relação com o arquivo original.
• Substitua a aparência e o comportamento por código, o que pode funcionar em casos simples, mas pode levar a complicações significativas em outros. Substituições pesadas com o código também podem tornar o design visual inútil e evoluir para uma fonte constante de dores de cabeça, por exemplo, quando um certo controle é exibido de uma maneira no Interface Builder, mas parece completamente diferente quando o aplicativo está em execução.

Quando usar o código

Muitas vezes é uma boa opção usar o código personalizado para o design da interface do usuário iOS quando você tem:

• Layouts dinâmicos.
• Vistas com efeitos, como cantos arredondados, sombras, etc.
• Qualquer caso em que usar NIBs e Storyboards seja complicado ou inviável.

Quando Não usar código

Em geral, interfaces de usuário feitas em código podem sempre ser usado. Eles raramente são uma má ideia, então eu coloquei um aqui.

Embora NIBs e Storyboards tragam algumas vantagens para a mesa, eu sinto que não há nenhuma desvantagem razoável que eu colocaria em uma lista para desencorajar o uso de código (exceto, talvez, preguiça).

Um projeto, várias ferramentas

Storyboards, NIBs e código são três ferramentas diferentes para construir a interface do usuário iOS. Temos sorte de tê-los. Os fanáticos por interfaces de usuário programáticas provavelmente não levarão as outras duas opções em consideração: o código permite que você faça tudo o que é tecnicamente possível, enquanto as alternativas têm suas limitações. Para o restante dos desenvolvedores, o canivete Xcode fornece três ferramentas que podem ser usadas todas de uma vez, no mesmo projeto, de forma eficaz.

Como, você pergunta? Como queiras. Aqui estão algumas abordagens possíveis:

• Agrupe todas as telas relacionadas em grupos separados e implemente cada grupo com seu próprio Storyboard distinto.
• Projete células de tabela não reutilizáveis ​​no local com um Storyboard, dentro do controlador de visualização de tabela.
• Projete células de tabela reutilizáveis ​​em NIBs para incentivar a reutilização e evitar a repetição, mas carregue esses NIBs por meio de código personalizado.
• Projete visualizações personalizadas, controles e objetos intermediários usando NIBs.
• Use o código para visualizações altamente dinâmicas e, de forma mais geral, para visualizações que não são facilmente implementáveis ​​por meio de Storyboards e NIBs, enquanto hospeda as transições de visualização em um Storyboard.

Para fechar, vejamos um último exemplo que liga tudo isso.

como iniciar o projeto angularjs

Um caso de uso simples

Digamos que queiramos desenvolver um aplicativo de mensagens básico com várias visões diferentes:

• Uma lista de amigos seguidos (com um modelo de célula reutilizável para manter a IU consistente em listas futuras).
• Uma visualização de detalhes do perfil, composta em seções separadas (incluindo informações do perfil, estatísticas e uma barra de ferramentas).
• Uma lista de mensagens enviadas e recebidas de um amigo.
• Um novo formulário de mensagem.
• Uma visualização da nuvem de tags que exibe as diferentes tags usadas nas mensagens do usuário, com cada tag proporcional em tamanho ao número de vezes que foi usada.

Além disso, queremos que as visualizações fluam da seguinte forma:

• Clicar em um item na lista de amigos seguidos exibe os detalhes relevantes do perfil do amigo.
• Os detalhes do perfil mostram o nome do perfil, endereço, estatísticas, uma pequena lista das mensagens mais recentes e uma barra de ferramentas.

Para implementar este aplicativo iOS, todas as três ferramentas de interface do usuário serão úteis, pois podemos usar:

• Um Storyboard com quatro controladores de visualização (a lista, detalhes, lista de mensagens e novo formulário de mensagem).
• Um arquivo NIB separado para o modelo de célula de lista de perfis reutilizável.
• Três arquivos NIB separados para a visualização de detalhes do perfil, um para cada uma das seções separadas que o compõem (detalhes do perfil, estatísticas, últimas três mensagens), para permitir uma melhor manutenção. Esses NIBs serão instanciados como visualizações e, em seguida, adicionados ao controlador de visualização.
• Código personalizado para a visualização da nuvem de tags. Esta visualização é um exemplo típico de uma que não pode ser projetada no Interface Builder, nem por meio de StoryBoards nem de NIBs. Em vez disso, é totalmente implementado por meio de código. A fim de manter o fluxo visual do Storyboard, optamos por adicionar um controlador de visualização vazio ao Storyboard, implementar a visualização da nuvem de tag como uma visualização independente e adicionar programaticamente a visualização ao controlador de visualização. Claramente, a visão também pode ser implementada dentro do controlador de visão ao invés de uma visão independente, mas nós os mantemos separados para melhor reutilização.

Um mock-up realmente básico pode ser parecido com:

Com isso, descrevemos a construção básica de um razoavelmente aplicativo iOS sofisticado cujas visões principais unem nossas três abordagens principais para Design de interface do usuário . Lembre-se: não há decisão binária a ser feita, pois cada ferramenta tem seus pontos fortes e fracos.

Empacotando

Conforme examinado neste turtorial, Storyboards adicionam uma simplificação perceptível para iOS Design da interface do usuário e fluxo visual. Eles também eliminam o código clichê; mas tudo isso tem um preço pago em flexibilidade. Os NIBs, por sua vez, oferecem mais flexibilidade concentrando-se em uma única visualização, mas sem fluxo visual. A solução mais flexível, é claro, é o código, que tende a ser bastante hostil e inerentemente não visual.

Se este artigo intrigou você, eu recomendo assistir o grande debate de Ray Wenderlich, 55 minutos bem gastos em uma discussão sobre NIBs, Storyboards e UIS criados por código.

Para encerrar, quero enfatizar uma coisa: Evite usar a todo custo a ferramenta imprópria de design da IU do iOS . Se uma visualização não for projetável com um Storyboard, ou se puder ser implementada com NIBs ou código de uma forma mais simples, não use um Storyboard. Da mesma forma, se uma visualização não for projetável usando NIBs, não use NIBs. Essas regras, embora simples, irão percorrer um longo caminho em sua educação como desenvolvedor.