Controlador de exibição maciça - IOS - Soluções

Tenho certeza de que todo novo desenvolvedor de iOS tem o seguinte problema: Os Controladores de exibição ficam muito cheios de código para várias finalidades, chegando facilmente a mais de 500 linhas de código.

É assim que parece para duas telas básicas e comuns:

1) A tela do formulário:

2) A tela do controlador de exibição de tabela

Até agora eu li sobre duas soluções diferentes:

1. Primeira solução: https://bendyworks.com/single-responsibility-principle-ios/ . Isso é baseado em Notificações, separa completamente o View Controller do Modelo de Visão (Intenções) e, portanto, reduz o código no View Controller. Eu acho que ele tem a desvantagem de quebrar o código, semelhante às estruturas Go-To. Se parece com isso:

2. A segunda solução mantém os mesmos Controladores de exibição lotados (as ações dos botões são executadas no VC e assim por diante). mas usa bibliotecas como TPKeyboardAvoiding , BlocksKit ou outras soluções, a maioria delas com base em categorias. Com esta segunda solução, o código é drasticamente reduzido, mas o controlador de exibição ainda tem muita responsabilidade.

O que você acha dessas soluções? Qual é melhor? Existe um melhor?

Podemos usar o MVVM para resolver esse problema.

O padrão Model-View-ViewModel, ou MVVM, como é comumente conhecido, é um padrão de design da UI. A VM utiliza toda a lógica sobre a preparação de dados de modelo para a interface do usuário do VC.

Exemplo:
você tem um objeto de modelo com alguns campos, deseja formatar alguns deles, fazer cálculos e combiná-los.

No caso do MVC, toda essa lógica localizada no ViewController.
No MVVM, você move tudo isso do VC para a VM.

A VM preparará todos os dados para a interface do usuário e o VC apenas os definirá assim.

(na classe VC)

self.descriptionLabel = self.viewModel.textForDescriptionLabel;

Tutoriais e tópicos:

• Introdução ao MVVM
• Tutorial do MVVM com ReactiveCocoa
• Padrões de design para iOS: MVC e MVVM

Eu tive que desembaraçar código em controladores de tamanho grande antes e isso realmente impediu minha capacidade de navegar no conteúdo primeiro. Uma coisa importante que percebi é que apenas o tamanho do View Controller não era motivo suficiente para separar as coisas. Existe complexidade em ter 1 arquivo grande e também complexidade em ter um monte de arquivos pequenos. Aqui estão alguns motivos válidos para refatorar a quebra de um View Controller em partes menores:

MVC

O View Controller não deve fazer muito mais do que ser a cola de conexão entre o View e o Model. Se você tiver muitos códigos de conexão de rede, códigos de manipulação de imagens, etc., considere dividi-los em classes auxiliares.

Vários controles com o View Controller como fonte de dados

Se houver vários controles na tela que tenham o seu View Controller como fonte de dados, considere dividi-los em objetos de fonte de dados separados e faça com que eles sejam a fonte de dados. Ou você também pode dividi-los em View Controllers separados (como se o View Controller tivesse uma exibição de tabela além de outro controlador, você pode quebrá-lo em sua própria classe Table View Controller).

Código duplicado

Se você tiver exatamente o mesmo código em diferentes Controladores de exibição, coloque-o em um local compartilhado. Isso tornará seu código reutilizável e ajudará a gerenciar a complexidade.

Aqui estão alguns conselhos adicionais para minimizar a complexidade do View Controller:

Storyboard em vez de programático

Criar elementos de exibição é muito código e o código da geometria do quadro também é muito trabalhoso. Caso ainda não considere usar restrições de layout automático e colocar o máximo possível dos elementos Exibir no storyboard.

Código / comentários desnecessários

Certifique-se também de remover códigos / comentários desnecessários. Muitas vezes, um novo arquivo do View Controller vem com métodos que você não está usando. Se você não estiver usando um método como didReceiveMemoryWarningesse, é seguro removê-lo. Além disso, como o arquivo do View Controller é muito grande, às vezes é assustador remover o código ou os comentários antigos. Não adie isso! Isso apenas aumenta a complexidade.

Notificações

Para responder à sua pergunta sobre notificações: As notificações não são um Martelo de Ouro para usar com tudo. Considero as notificações úteis quando vários controladores de exibição precisam atualizar ao mesmo tempo devido a uma ação específica. Tenha cuidado com as notificações, porém, o uso excessivo delas pode causar muita dor ao tentar localizá-las.

Há uma arquitetura especial que eles chamam de VIPER (View, Interactor, Presenter, Entity and Routing). Vou tentar resumir aqui o que você precisa saber:

Visão

• eles são vistas fictícias;
• conter objetos como UIView, UIViewController, UILabel, etc;
• aguarda o conteúdo do apresentador ;
• manipule a interação do usuário e passe-a para a camada do Presenter .

Apresentador

• não conhece objetos da interface do usuário;
• obter entradas da camada View ;
• manipular a lógica da visualização (o método add apresentará outra tela);

Encaminhamento

• lidar com a lógica de navegação e animações de transição;
• conhece objetos como UINavigationController, UIWindow, etc;

Então, o que eu acho que você limpará no seu código:

• as validações de dados serão movidas para a camada Presenter ;

• a navegação será movida para objetos Wireframe ( camada de roteamento );

• divida o seu controlador de exibição, observando o princípio DRY ;

• Telas complexas terão duas ou mais visualizações e apresentadores.

Você deve ver o link a seguir sobre a arquitetura VIPER http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

Boa sorte!