Views: ViewControllers, molti a uno o uno a uno?

Prima di tutto Android e iOS sono piattaforme diverse, ciò che è molto efficiente in uno, potrebbe non essere così buono nell'altro. Ma sinceramente, non ne ho idea, perché non li ho letti. Io uso l'approccio 1: 1 perché è facile e non ho mai avuto problemi di prestazioni che mi hanno portato in quell'area.

Per quanto riguarda la qualità del codice, hai ragione. La leggibilità e "quanto sia facile tirare un pezzo di codice" è una misura provocatoria. A volte lascio un codice inefficiente con un commento solo per poter poi capire cosa diavolo ho fatto lì.

Per il tuo problema, sta a te decidere se vuoi essere un bravo ragazzo e renderlo facile al programmatore successivo o semplicemente portare a termine il lavoro. (considera: il prossimo programmatore sarai tu?)

There appears to be one ViewController that handles the display logic for many different types of views. In the ViewController are an assortment of boolean flags and arrays of data (to be displayed) that are used to determine what view to load and how to display it.

È tipico nelle app iOS avere un'istanza del controller di visualizzazione per ogni "screenful" di contenuto, ad esempio una vista e le sue sottoview, simile a ciò che si otterrebbe da un layout in Android. Se l'app su cui stai lavorando utilizza un singolo oggetto controller di visualizzazione o anche istanze separate della stessa classe di controller di visualizzazione, per gestire un numero di schermate diverse probabilmente hai ragione che il codice debba essere refactored. Prima di entrare in questo progetto, leggi la Guida alla programmazione dei controller di Apple in modo da avere una solida comprensione di come i controller di visualizzazione interagiscono in iOS.

Non preferirei neanche io, preferirei quello che ha meno if, switch, variabili di stato ausiliarie e duplicazione del codice.

Di solito è 1: 1 con classi ausiliarie che si occupano di visualizzare le informazioni che appaiono in più punti, ma questa non è la regola. La regola è quella che ha meno rami senza causare la duplicazione del codice in quella particolare situazione.

Divulgazione - il mio approccio può o meno allinearsi con interpretazioni severe di MVC, MVP o MVVM. Ma si basa sulla mia esperienza nel lavorare con questi approcci.

In generale, un VC dovrebbe avere solo un View , ma ciò dipende principalmente dal fatto che non avrai molte sovrapposizioni tra Views . Penso che l'aspetto più importante sia l'indifferenza sulla parte di VC su cosa sia effettivamente View . Quindi, se hai bisogno di if e switch istruzioni per accoppiare il tuo VC al tuo View , allora penso che qualcosa non va.

Il VC è lì per indirizzare i dati a View , ma non gli interessa sapere come View presenta i dati poiché questo è il lavoro di View . Allo stesso modo, View non si preoccupa di come VC ottiene i dati, ma sa solo che lo farà. È davvero la separazione delle responsabilità che è importante.

"Bene, è grandioso" (~ Denis Leary) ma non risolve i problemi in cui si verificano duplicazioni su View s. Questo è il punto in cui prenderei un approccio leggermente bastardizzato e consentire a VC di essere composto da altri VC s ma mantenere una relazione dell'1% diView a 1% diVC. Il "contenere" VC s si legherà a un View ma al "contenuto" (figlio, i membri del contenitore VC, qualunque cosa tu voglia chiamare) non avranno necessariamente un View al quale sono vincolati. Ciò fornisce un grado di riutilizzo all'interno del codice senza cose eccessivamente confuse. Vola di fronte ad alcuni dei paradigmi, quindi vorrei commentare quello che stai facendo.

In definitiva, avrai un VC che gestisce il recupero | manipolando i dati che vengono visualizzati su più View s. Ma avrai bisogno di un "layer" aggiuntivo di VC s per mantenere pulita la struttura del codice.

In alternativa, basta duplicare il codice al livello VC e riutilizzare le chiamate su Model . Non sono un grande fan di questo perché mi piace pensare in termini di widget riutilizzabili quando metto insieme il mio View se ViewController s.