interfaces de usuário iOS: Storyboards vs. NIBs vs. código personalizado

muitas vezes ouço Desenvolvedores iOS fazer 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 assumir que há uma escolha mutuamente exclusiva a ser feita, que muitas vezes é abordada antecipadamente, antes do desenvolvimento.

sou da opinião de que a resposta deve assumir a forma de uma ou mais perguntas contrárias.

Qual é o “melhor” carro?

deixe-me explicar com um exemplo fora do tópico. Diga que quero comprar um carro e faço uma pergunta simples: “Qual é a melhor escolha?”

você pode realmente responder sugerindo um modelo, ou mesmo uma marca? Não é provável, 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 sobre carros esportivos?

é óbvio que não existe um carro bom ou ruim, a menos que seja colocado em um contexto adequado—há apenas um carro bom ou ruim com base em necessidades específicas.

de volta ao design da interface do usuário do iOS

assim como com nossa consulta do carro, a pergunta “Qual é a melhor maneira de desenvolver uma interface do usuário do iOS” carece de contexto. E, surpreendentemente, a resposta não precisa ser um caso catch-all.

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

• Storyboards do iOS: uma ferramenta visual para estabelecer várias 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 apresentado no Construtor de Interface, tornando-o uma ferramenta visual também. 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, sem ferramentas GUI, mas sim, lidando com todo o posicionamento personalizado, animação, etc. programaticamente.

nenhuma dessas opções é universalmente melhor do que qualquer outra (apesar do que você possa ouvir).

Storyboards, por exemplo, são a adição mais recente ao iOS UI toolkit. Disseram-me que eles são o futuro, que eles substituirão NIBs e UIs de código personalizado. Vejo Storyboards como uma ferramenta útil, mas não tanto um substituto como um complemento para NIBs e código personalizado. Storyboards são a escolha certa em algumas, mas não em todas as situações.

além disso, por que você deve se ater estaticamente a uma única opção quando você pode usá-los todos (no mesmo projeto), escolhendo o mecanismo que melhor se adapta ao problema específico em mãos?

Esta é uma pergunta que pode ser, na minha opinião, generalizada em um nível superior, e cuja resposta é altamente classificado na minha lista de software princípios de desenvolvimento: não Há linguagem universal, estrutura ou a tecnologia que a universal é a melhor escolha para cada problema de desenvolvimento. O mesmo vale para o design da interface do usuário do iOS.

neste tutorial de desenvolvimento do iOS, vamos explorar cada um desses métodos e introduzir casos de uso nos quais eles devem e não devem ser empregados, bem como maneiras pelas quais eles podem ser misturados.

Storyboards iOS

o erro de um iniciante clássico é criar um Storyboard iOS em todo o projeto. Eu também cometi esse erro quando comecei a trabalhar com Storyboards (provavelmente porque é uma rota tentadora a seguir).

como o próprio nome indica, 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. Um storyboard deve conter controladores de visualização que estão logicamente relacionados entre si-o que não significa que todos os controladores de visualização.

por exemplo, faz sentido usar Storyboards ao manusear:

• um conjunto de visualizações para autenticação e registro.
• um fluxo de entrada de pedidos em várias etapas.
• um fluxo semelhante a um assistente (ou seja, tutorial).
• um conjunto de visualizações de detalhes mestre (por exemplo, listas de perfis, detalhes do perfil).Enquanto isso, Storyboards grandes devem ser evitados, incluindo Storyboards únicos em todo o aplicativo (a menos que o aplicativo seja relativamente simples). Antes de irmos mais fundo, vamos ver o porquê.
  

  A Insensatez de Grande iOS Storyboards

  Grande Storyboards, além de ser difícil de navegar e manter, adicione uma camada de complexidade para um ambiente de equipe: quando vários desenvolvedores trabalhem no mesmo arquivo de storyboard, ao mesmo tempo, fonte de controlar os conflitos são inevitáveis. E enquanto um storyboard é representado internamente como um arquivo de texto (um arquivo XML, na verdade), a fusão geralmente não é trivial.

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

  vamos dar um exemplo muito simples: dizem que dois desenvolvedores diferentes alterar a posição de um UILabel (usando o esquema automático), e o último empurra sua mudança, produzindo um conflito como este (observe a conflitantes id atributos):

  <layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides><layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides>

  O id por si só não fornece nenhuma indicação de qualquer natureza quanto ao seu verdadeiro significado, assim você não tem nada para trabalhar. A única solução significativa é escolher um dos dois lados do conflito e descartar o outro. Haverá efeitos colaterais? Quem sabe? Tu não.

  para aliviar esses problemas de design de interface do iOS, usar vários storyboards no mesmo projeto é a abordagem recomendada.

  quando usar Storyboards

  Storyboards são melhor usados com vários controladores de visualização interconectados, pois sua principal simplificação está na transição entre os controladores de visualização. Até certo ponto, eles podem ser pensados como uma composição de pontas com fluxos visuais e funcionais entre os controladores de visualização.

  Storyboards são melhor usados com vários controladores de visualização interconectados, pois sua principal simplificação é a transição entre os controladores de visualizaçã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, present e dismiss view controllers. Além disso, os controladores de visualização são alocados automaticamente, portanto, não há necessidade de manualmente alloc e init.

  finalmente, embora os Storyboards sejam melhor usados para cenários envolvendo vários controladores de visualização, também é defensável usar um Storyboard ao trabalhar com um único 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 de tabela pai.
  • é possível criar visualizações de tabela estáticas (uma adição tão esperada que infelizmente só está disponível em Storyboards).

  pode-se 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 implicações funcionais ou de desenvolvimento negativas. Este último retém esse fluxo visual, mas requer esforços de desenvolvimento adicionais, pois a visualização não está integrada ao controlador de visualização: ela é apenas incorporada como um componente, portanto, o controlador de visualização deve interagir com a visualização em vez de implementá-la.

  prós e contras Gerais

  agora que temos um senso de quando os Storyboards são úteis no design da interface do usuário do iOS e, antes de passarmos para NIBs neste tutorial, vamos passar por suas vantagens e desvantagens gerais.

  Pro: Performance

  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 é verdade 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, seja quando um segue é executado ou manualmente a partir do Código.

  Pro: protótipos

  Storyboards simplificam a prototipagem e zombam das interfaces de usuário e do 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.

  Con: 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.

  Con: fluxo de dados

  os dados geralmente precisam ser passados entre os controladores de visualização quando um aplicativo faz a transição. No entanto, o fluxo visual do Storyboard está quebrado neste caso, pois não há vestígios disso acontecendo no Construtor de Interface. Os Storyboards cuidam de lidar com o fluxo entre os controladores de visualização, mas não com o fluxo de dados. Portanto, o controlador de destino deve ser configurado com código, substituindo a experiência visual.Os Storyboards cuidam de lidar com o fluxo entre os controladores de visualização, mas não com o fluxo de dados.

  nesses casos, temos que confiar em um prepareForSegue:sender, com um if/else-if esqueleto como este:

  - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = ; if ("segue_name_1"]) { MyViewController *vc = (MyViewController *) ; ; } else if ("segue_name_2"]) { ... } else if ...}

  acho que essa abordagem é propensa a erros e desnecessariamente detalhada.

  NIBs

  NIBs são a maneira antiga (er) de executar o design da interface do iOS.

  neste caso,” antigo “não significa” ruim”,” desatualizado “ou”obsoleto”. Na verdade, é importante entender que os Storyboards do iOS não são um substituto universal para NIBs; eles apenas simplificam a implementação da interface do usuário em alguns casos.

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

  se aplicarmos o design orientado a objetos às nossas UIs, faz sentido dividir a visualizaçã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 clara vantagem dessa abordagem é que cada componente é mais fácil de desenvolver, mais fácil de testar e mais fácil de depurar.

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

  quando usar NIBs para iOS UI Design

  um subconjunto de todos os casos de uso seria:

  • Modal vistas
  • Simples de login e cadastro de pontos de vista
  • Configurações
  • janelas de pop-up
  • Reutilizáveis modelos de modo de exibição
  • Reutilizáveis célula da tabela de modelos de

  Enquanto isso…

  Quando Não Utilizar Bicos

  Você deve evitar o uso de Bicos para:

  • Vistas com conteúdo dinâmico, onde o layout é alterado significativamente dependendo do conteúdo.
  • visualizações que, por natureza, não são facilmente projetáveis no Construtor de Interface.
  • ver controladores com transições complicadas que poderiam ser simplificadas com Storyboarding.

  prós e contras Gerais

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

  Pro: reutilização

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

  como um caso de uso simples, um modelo de visualização contendo um nome de usuário e um campo de texto de senha pode ser implementado com as visualizações hipotéticas TTLoginView e TTSignupView, ambas originadas da mesma ponta. O TTLoginView 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 rótulos teriam a mesma funcionalidade básica e layouts semelhantes.

  Pro & Con: Performance

  NIBs são preguiçosamente carregados, então eles não usam memória até que tenham que. Embora isso possa ser uma vantagem, há latência para o processo de carregamento lento, tornando-o uma desvantagem também.

  iOS Custom Code (Programmatic UIs)

  qualquer design de interface iOS que pode ser feito com Storyboards e NIBs também pode ser implementado com código bruto (houve um tempo, é claro, quando os desenvolvedores não tinham o luxo de um conjunto tão rico de ferramentas).

  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 que, é claro, que é tecnicamente viável. Outra maneira de olhar para isso é que NIBs e Storyboards são implementados com código, então sua funcionalidade será naturalmente um subconjunto. Vamos pular direto para os prós e contras.

  Pro: sob o capô

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

  para fazer uma comparação: uma calculadora é uma ferramenta útil. Mas não é uma coisa ruim saber como realizar 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 visual HTML rad representam um caso típico de fronteira: eles são usados para gerar código (geralmente 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 lidar manualmente com html e CSS brutos levará a um código mais modular e eficiente.

  portanto, dominar a codificação das interfaces de usuário do iOS oferece mais controle e maior conscientização sobre 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 o design da interface do Usuário. Layouts dinâmicos, onde os elementos de visualização são movidos e o fluxo ou layout se ajusta significativamente com base no conteúdo, são exemplos típicos.

  Pro: Conflitos de mesclagem

  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.

  Con: 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 levar muito mais tempo, em comparação com NIBs e Storyboards que fornecem uma visualização imediata de como as coisas serão renderizadas.

  Con: Refatoração o código de refatoração 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 indiretamente traduzidos em código. Escusado será dizer que isso não acontece com UIs de código.

  Pro: Reutilização

  qualquer visualização implementada programaticamente pode ser projetada de forma reutilizável. Vamos ver 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 com elegância.
  • um projeto deve ser bifurcado, com o objetivo de criar uma única base de código, mas gerando dois (ou mais) aplicativos diferentes, cada um com personalizações específicas.

  o mesmo processo de design da interface do usuário seria muito mais complicado com NIBs e Storyboards. Os 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 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 determinado controle exibe uma maneira no Construtor de Interface, mas parece completamente diferente quando o aplicativo está em execução.

  quando usar o código

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

  • layouts dinâmicos.
  • Visualizações com efeitos, como cantos arredondados, sombras, etc.
  • qualquer caso em que o uso de NIBs e Storyboards seja complicado ou inviável.

  quando não usar o código

  em geral, as UIs de código sempre podem ser usadas. Eles raramente são uma má ideia, então eu colocaria um aqui.

  embora NIBs e Storyboards tragam algumas vantagens para a mesa, 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 criar a interface do usuário do iOS. Temos sorte em tê-los. Fanáticos de UIs programáticas provavelmente não levarão em conta as outras duas opções: o código permite que você faça tudo o que é tecnicamente possível, enquanto as alternativas têm suas limitações. Para o resto dos desenvolvedores por aí, o Xcode army knife fornece três ferramentas que podem ser usadas de uma só vez, no mesmo projeto, de forma eficaz.

  como, você pergunta? Como quiser. 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 mesa não reutilizáveis no local com um Storyboard, dentro do controlador de visualização de mesa.
  • Projete células de tabela reutilizáveis em pontas para incentivar a reutilização e evitar a repetição, mas carregue essas pontas 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 as transições de visualização de habitação em um Storyboard.

  Para fechar, vejamos um último exemplo que une tudo.

  um caso de uso simples

  digamos que queremos desenvolver um aplicativo de mensagens básico com várias visualizaçõ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 de 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 de 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 maneira:

  • clicar em um item na lista de amigos seguidos exibe os detalhes do perfil do amigo relevante.
  • 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, todos os três de nossas ferramentas de INTERFACE do usuário vai vir a calhar, como podemos usar:

  • Um Storyboard com quatro vista (controladores de lista, detalhes, lista de mensagens, e de novo formulário de mensagem).
  • um arquivo de ponta separado para o modelo de célula de Lista de perfil reutilizável.
  • três arquivos NIB separados para a visualização 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. Essa visualização é um exemplo típico de um que não pode ser projetado no Construtor de Interface, nem por meio de StoryBoards nem NIBs. Em vez disso, é completamente implementado por meio de código. Para manter o fluxo visual do Storyboard, optamos por adicionar um controlador de visualização vazio ao Storyboard, implementar a exibição de nuvem de tags como uma exibição autônoma e adicionar programaticamente a exibição ao controlador de visualização. Claramente, a visualização também pode ser implementada dentro do controlador de visualização, em vez de como uma visualização autônoma, mas os mantemos separados para melhor reutilização.

  uma maquete realmente básica pode parecer:

  com isso, delineamos a construção básica de um aplicativo iOS razoavelmente sofisticado, cujas visualizações principais unem nossas três abordagens principais ao design da interface do Usuário. Lembre – se: não há decisão binária a ser tomada, pois cada ferramenta tem seus pontos fortes e fracos.

  encerrando

  conforme examinado neste turtorial, os Storyboards adicionam uma simplificação notável ao design da interface do usuário do iOS e ao fluxo visual. Eles também eliminam o código clichê; mas tudo isso tem um preço, pago em flexibilidade. NIBs, por sua vez, oferecem mais flexibilidade, concentrando-se em uma única visã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 o intrigou, recomendo assistir ao grande debate de Ray Wenderlich, 55 minutos bem gasto em uma discussão de NIBs, Storyboards e UIS de código.

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