Concrete Logo
Hamburger button

Como migrar um app da Marvel para View Code

  • Blog
  • 17 de Fevereiro de 2017
Share

*Este post foi originalmente publicado no Cocoa Academy (em inglês). Veja aqui.

Atualmente, View Code é a nova “hype” da comunidade iOS. Não é nada novo, podemos dizer que essa abordagem é, de diversas formas, uma volta às origens do iOS, nas quais as views eram criadas em código. Se você voltar alguns anos no tempo nas primeiras versões do XCode, nosso famoso Interface Builder não estava presente. O Storyboard, por exemplo, nasceu muito tempo depois.

Depois de falar com vários desenvolvedores que estão adotando View Code nas suas aplicações e afirmando vários benefícios, eu comecei a me interessar bastante pelo assunto.

Benefícios. Quais são eles?

– Melhora o trabalho em equipe, evita conflitos do tipo storyboards/xibs;
– Código tende a se tornar modular, reusável e com um propósito claro;
– É mais fácil testar;
– É mais fácil manter e evoluir o code base.

Hoje eu vou migrar um app da Marvel que eu criei em uma série de posts (cujo início você pode ver aqui), para View Code. A ideia é compartilhar com vocês minha experiência, opiniões e lições que aprendi no processo. Você pode clonar o repositório com View Code aqui.

A abordagem

Migrar para view code não é algo que precisa ser feito de uma vez, você pode começar migrando algumas partes pequenas do seu código até eventualmente ter migrado o projeto por inteiro.  Comecei esse processo migrando as células. Elas já estavam fora do Storyboard, em uma xib separada, então “let’s make the diff”.

Usando xib

Usando View Code

Tem um monte de coisa acontecendo aqui. A segunda versão, usando view code, é muito maior. Vamos analisar a diferença antes de prejulgar, ok?

– Primeiro: removemos os IBOutlets, portanto esqueça os force unwraps!! =)
– A célula implementa agora o protocolo Reusable ao invés do NibReusable, ambos do excelente pod  Reusable.
– A célula deve implementar agora alguns initializers esperados, que não precisávamos antes quando isso era criado na xib ou Storyboard. Isso deve parecer algo ruim a princípio, mas agora nós temos controle do processo de inicialização, o que é ótimo! Isso deixa o teste bem simples.
– A célula também implementa um protocolo ViewConfiguration, que eu defini para criar um padrão.

– Estes métodos serão responsáveis por construir a hierarquia da view, configurar as constraints do autolayout e permitir que configurações extras sejam facilmente adicionadas;
– Você pode notar que estou usando o SnapKit, uma biblioteca que tem uma DSL que permite trabalhar com autolayout no código de uma forma realmente fácil. Existem diversas outras bibliotecas similares como Cartography PureLayout, dentre outras, que fazem a mesma coisa. Aqui, o gosto pessoal é seu aliado, escolha a melhor pra você.

Não precisamos mudar mais nada nesse projeto, e tudo está funcionando como deveria. A grande diferença é que agora, se você quiser mudar a célula, adicionar outro label ou botão, por exemplo, está muito mais fácil. Você só precisa mudar em um lugar e esquecer os problemas de merge. Além de rápida, essa abordagem permite acabar com o “dragging and dropping” programming, para aqueles já estão cansados disso.

Repetindo o padrão

De agora em diante seu trabalho é migrar o restante do projeto: as outras células, view controllers e etc. É quase a mesma coisa, então vou só mencionar as partes importantes, ok? Você pode ver o código no repositório sempre que precisar =)

LoadView, the new kid on the block

Agora que não estamos carregando view Controllers dos storyboards, devemos nos preocupar com outro método do life cycle, chamado de loadView, que é chamado antes do viewDidLoad. Até agora, isso era feito automaticamente pelo storyboard, não mais. Neste método nós precisamos setar a self.view da view controller com alguma coisa que faça sentido.

A última parte do quebra-cabeças, depois de abandonar o Storyboard, é dizer para seu app que não precisamos dele. Graças a Deus! (brincadeira). Isso pode ser feito em dois passos: primeiro nós dizemos ao app que não precisamos de uma main Interface, depois configuramos o AppDelegate.

Passo 1

lioy1

Passo 2

Depois deste último passo, tudo deve funcionar como esperado. Vamos analisar mais uma controller para ver o antes e depois.

Sem usar o View Code

Usando View Code

Vocês podem notar que o tamanho da controller é quase o mesmo, mas a segunda versão tem muito menos responsabilidade que a primeira. Muita coisa foi movida para lugares mais adequados, sem contar que não temos mais IBoutlet ou IBActions, force unwrap, etc. Também é muito mais fácil testar essa nova ViewController, já que agora controlamos o processo de inicialização e não precisamos trazê-la do storyboard.

Então…

Eu tenho gostado muito dessa experiência. View Code é algo que definitivamente vou explorar e usar nos meus novos projetos. Em breve, pretendo escrever outro post sobre testes e view code, e como nós podemos refatorar os testes no nosso antigo app da Marvel  para trabalhar no nosso novo design. Dito isso, é bom lembrar que esse foi só o meu primeiro contato com o View Code. Ainda tem muita coisa pra fazer.

Se você tiver alguma experiência sobre o assunto, alguma dúvida, outros padrões e etc, deixe seu comentário abaixo. Até a próxima!

 É desenvolvedor iOS e quer fazer parte de times multidisciplinares, trabalhando em produtos incríveis? Clique aqui.