TableViewManager: Abstraindo o uso do UITableview convencional

As visualizações de tabela no iOS exibem linhas de conteúdo de rolagem vertical em uma única coluna. Cada linha na tabela contém um pedaço do conteúdo do seu aplicativo. Você pode configurar uma tabela para exibir uma única longa lista de linhas, ou pode agrupar linhas relacionadas em seções para facilitar a navegação no conteúdo. Seu framework foi disponibilizado pela Apple ainda no iOS 2 e com o passar dos anos, foram sendo introduzidos novos métodos, tornando assim a UITableView ainda mais completa e com uma série de benefícios para nossos códigos.

Porém, vamos recapitular um pouco da quantidade de código necessário para dar vida, por exemplo, a está ilustração abaixo.

DataSource e Delegate

Os dados exibidos são gerenciados pelo objeto DataSource da tableview acessível através da propriedade dataSource. A primeira informação que a tableview precisa do seu data source é o número de sessões que ela exibirá, chamando o método:

numberOfSectionsInTableView(_:)

Como esse método é opcional no seu protocolo, caso ele não seja implementado, a tableview assume que precisa exibir apenas uma única sessão.

Você deve estar se perguntando: “O que é uma seção da table view?”. Uma seção da table view é um grupo de linhas. O aplicativo de Contatos do iOS, por exemplo, agrupa contatos com base na primeira letra do primeiro ou último nome. Cada grupo de contatos forma uma seção, que é composta por um section header na parte superior da seção e/ou um section footer na parte inferior da seção.

Agora que a tableview sabe quantas seções precisa exibir, ela pede ao seu data source quantas linhas há em cada seção. Para cada seção na tableview ela chama o método:

tableView(_:numberOfRowsInSection:)

A implementação desse método é muito simples, passando o valor total de itens do nosso array de objetos (em nosso exemplo passamos um total de 10), precisamos implementar agora o método:

tableView(_:cellForRowAtIndexPath:)

Outro método do protocolo UITableViewDataSource. O nome do método é muito descritivo. Chamando este método do data source, a table view pede a seu data source pela table view cell da linha específica pelo indexPath, o segundo argumento do método.

Agora imagine um projeto grande, onde você e seu time precisam fazer isso dezenas de vezes!? 😅

Foi aí, que em 2011 quando trabalhava no UOL, meu time e eu, criamos uma biblioteca ainda em Objective-C, que podia abstrair toda essa complexidade, traz o princípio de responsabilidade única (aqui estou falando do SOLID) e de quebra traz um maior reaproveitamento de código. Eis que lhe apresento a SelfTableViewManager 😃

GitHub - jjfernandes87/SelfTableViewManager

Para começar a mostrar os benefícios de usar o SelfTableViewManager, imagine você trocar toda a complexidade mostrada acima implementando apenas poucas linhas código em sua ViewController.

var rows = [AnyObject]()        
for value in 1...50 {            
   rows.append(CustomCell(value: value))        
}         
tableView.setRows(rows)

Isso mesmo! Usando o método setRows(…)

A solução

O principal objetivo da SelfTableViewManager é remover a complexidade criada dentro da sua ViewController, e dividir isso em camadas, dessa forma podemos seguir a risca o conceito de responsabilidade única.

Outro ponto interessante fica por conta das classes CellController e CellView, a CellController tem como objetivo reter toda sua regra de negócio, muito parecido com a arquitetura MVVM onde o ViewModel é encarregado por isso. Já a CellView como o nome já diz é responsável por criar a interface visual, aqui você pode usar Xib, Storyboard, ViewCode, não existe limitação.

No exemplo abaixo vou mostrar uma implementação super simples. Por favor, vamos abstrair boa parte desse código, nele estou usando 100% viewCode OK?

Como mencionei acima, temos 3 classes cada uma delas tem sua responsabilidade bem definida, com isso nosso código ganha:

1. Facilidade de leitura e manutenção bem maior.
2. Separação de responsabilidade.
3. Testabilidade.
4. Reutilização de código.
5. Conceitos de Server Driven UI
6. Conceitos de BFF (Backend for frontend).

Conclusão

Os benefícios que a SelfTableViewManager pode trazer para o seu projeto, são enormes, imagine você conseguir padronizar o desenvolvimento de telas, usar conceitos de Server Driven UI junto ao seu time backend, vocês ganham uma produtividade enorme e velocidade de entrega de valor para o cliente final bem alta, alem disso conceitos de Server Driven favorecem pequenos ajustes de texto ou diagramação de conteúdo na tela sem a necessidade de uma nova versão do app sendo disponibilizada.

Na XPInc. usamos esse conceito atrelado ao nosso Design System, em nossa versão mais recente criamos o que chamamos de WLego nosso conceito de Whitelabel + Lego que é um brinquedo cujo conceito baseia em partes que se encaixam permitindo muitas combinações.

Ficou curioso e quer se juntar ao nosso time? Estamos contratando