Massive View Controller - IOS - Soluzioni

Sono sicuro che ogni nuovo sviluppatore iOS ha il seguente problema: I View Controller sono molto affollati di codice per vari scopi, arrivando facilmente a oltre 500 righe di codice.

Ecco come appare per due schermate di base e comuni:

1) La schermata del modulo:

2) La schermata Controller vista tabella

Finora ho letto due diverse soluzioni:

1. Prima soluzione: https://bendyworks.com/single-responsibility-principle-ios/ . Questo si basa su Notifiche, separa completamente il View Controller dal modello di visualizzazione (Intenzioni) e quindi riduce il codice nel View Controller. Penso che abbia il rovescio della medaglia del codice di rottura, simile alle strutture Go-To. Sembra così:

2. La seconda soluzione mantiene gli stessi affollati View Controller (le azioni dei pulsanti vengono eseguite all'interno di VC e così via). ma utilizza librerie come TPKeyboardAvoiding , BlocksKit o altre soluzioni la maggior parte basate su categorie. Con questa seconda soluzione, il codice viene drasticamente ridotto, ma il controller di visualizzazione ha ancora molte responsabilità.

Cosa ne pensi di queste soluzioni? Che è migliore? Ce n'è uno migliore?

Possiamo usare MVVM per risolvere questo problema.

Il modello Model-View-ViewModel o MVVM come è comunemente noto è un modello di progettazione dell'interfaccia utente. VM prende tutta la logica sulla preparazione dei dati del modello per l'interfaccia utente da VC.

Esempio:
hai un oggetto modello con alcuni campi, vuoi formattare alcuni di essi, fare calcoli e combinarli.

Nel caso MVC tutta quella logica si trova in ViewController.
In MVVM si sposta tutto da VC a VM.

VM preparerà tutti i dati per UI e VC semplicemente li imposta in questo modo.

(in classe VC)

self.descriptionLabel = self.viewModel.textForDescriptionLabel;

Tutorial e argomenti:

• Introduzione a MVVM
• Tutorial MVVM con ReactiveCocoa
• Pattern di progettazione iOS: MVC e MVVM

In precedenza ho dovuto districare il codice in View Controller di grandi dimensioni e all'inizio mi ha impedito di navigare nei contenuti. Una cosa importante che ho capito è che la sola dimensione del View Controller non era una ragione sufficiente per separare le cose. C'è complessità nell'avere 1 file di grandi dimensioni e anche complessità nell'avere un mucchio di piccoli file. Ecco alcuni motivi validi per refactoring per suddividere un View Controller in parti più piccole:

MVC

View Controller non dovrebbe fare molto di più che essere la colla di collegamento tra View e Model. Se hai un sacco di codice di connessione di rete, codice di manipolazione delle immagini, ecc., Considera di suddividerli in classi di supporto.

Controlli multipli con View Controller come origine dati

Se hai un sacco di controlli sullo schermo che hanno il tuo View Controller come origine dati, prendi in considerazione l'idea di suddividerli in oggetti origine dati separati e farli diventare l'origine dati. Oppure puoi anche suddividerli in View Controller separati (come se View Controller ha una vista tabella oltre ad altri controller, puoi suddividerla nella propria classe Controller vista tabella).

Codice duplicato

Se hai lo stesso codice esatto in diversi controller di visualizzazione, inseriscilo in 1 posizione condivisa. Ciò renderà il tuo codice riutilizzabile e ti aiuterà a gestire la complessità.

Ecco alcuni consigli aggiuntivi per ridurre al minimo la complessità di View Controller:

Storyboard invece di Programmatic

La creazione di elementi View richiede molto codice e anche la geometria del frame richiede molto lavoro. Se non si considera già l'utilizzo di vincoli di layout automatico e l'inserimento di quanti più elementi View nello storyboard possibile.

Codice / commenti non necessari

Assicurati anche di rimuovere codice / commenti non necessari. Molte volte un nuovo file di View Controller verrà fornito con metodi che non si stanno utilizzando. Se non stai usando un metodo del genere didReceiveMemoryWarning, è sicuro eliminarlo. Inoltre, poiché il file View Controller è così grande a volte è spaventoso rimuovere il vecchio codice o commenti. Non rimandare! Aggiunge solo complessità.

notifiche

Per rispondere alla tua domanda sulle notifiche: le notifiche non sono un martello d'oro da utilizzare con tutto. Trovo che le notifiche siano utili quando più View Controller devono essere aggiornati contemporaneamente a causa di 1 azione particolare. Fai attenzione alle notifiche, l'uso eccessivo può causare molto dolore nel tentativo di rintracciarle.

C'è un'architettura speciale che chiamano VIPER (View, Interactor, Presenter, Entity e Routing). Proverò a riprendere qui quello che devi sapere:

Visualizza

• sono viste fittizie;
• contiene oggetti come UIView, UIViewController, UILabel, ecc;
• attende il contenuto dal Presentatore ;
• gestire l'interazione dell'utente e passarla al livello Presenter .

Presentatore

• non conosce gli oggetti dell'interfaccia utente;
• ottenere input dal livello Visualizza ;
• gestire la logica di visualizzazione (aggiungere metodo presenterà altra schermata);

Routing

• gestire la logica di navigazione e le animazioni di transizione;
• conosce oggetti come UINavigationController, UIWindow, ecc .;

Quindi, ciò che penso pulirai nel tuo codice:

• le convalide dei dati passeranno al livello Presenter ;

• la navigazione si sposterà sugli oggetti Wireframe ( livello Routing );

• dividere il controller della vista osservando il principio DRY ;

• Gli schermi complessi avranno due o più viste e presentatori.

Dovresti vedere il seguente link sull'architettura VIPER http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

Buona fortuna!