Componente riutilizzabile con servizio Web

Poiché il tuo obiettivo è avere un componente riutilizzabile , sosterrei l'uso del secondo approccio.

Inoltre, seguendo il secondo approccio: dovresti pensare alla tua vista da sola e ai dati di cui ha bisogno (e alla struttura in cui dovresti fornire quei dati al tuo componente). Non dovrebbe dipendere dalla struttura in cui l'API fornisce i dati, ma dovrebbe avere più senso per la tua vista.

Questo è principalmente dovuto al fatto che il recupero dei dati è logico di business e non UI Logic. Qui è una bella domanda su dove dovrebbe andare la logica di business nel pattern MVC.

In generale, vuoi mettere solo la logica che si occupa della presentazione insieme alla tua interfaccia utente (la logica per gestire gli eventi, ecc.)

Alcuni vantaggi del secondo approccio rispetto al primo

1. La tua fonte di dati potrebbe cambiare o potresti dover utilizzare più fonti di dati e aggregare le loro informazioni.
2. Il resto del tuo codice potrebbe richiedere anche l'accesso all'API. O il tuo componente finirebbe a dipendere dal codice nel resto della tua applicazione per fare le sue chiamate API, o finiresti per duplicare la logica che tornerebbe a morderti quando l'API cambia in un modo non retrocompatibile.
3. Il tuo codice al di fuori del componente potrebbe richiedere i dati
4. Tu o un designer sarebbe in grado di lavorare sull'interfaccia utente usando solo dati fittizi, senza doversi preoccupare di altro che dell'interfaccia utente.

L'unico vantaggio che vedo al primo approccio è che è veloce e non richiede di aggiungere un altro livello di astrazione (l'interfaccia tra interfaccia utente e origine dati), ma questa non è la strada da percorrere poiché vogliamo riusabilità.

^{Nota: non ho particolarmente lavorato con il framework cocoa touch, ma ho cercato di rispondere in un modo agnostico al framework, in base alla mia esperienza con il lavoro con altri framework di MVC UI}

Basati sui principi di progettazione MVC, che sono generalmente incoraggiati in Cocoa Touch sviluppo, dovresti probabilmente andare con il secondo approccio.

Fondamentalmente, in MVC, l'app (o qualche sottocomponente dell'app) è suddivisa in tre parti: la vista contiene informazioni visive, il modello contiene informazioni sui dati e il controller gestisce le comunicazioni tra il modello e la vista .

Questo si adatta alla tua situazione in questo modo: la tua UIView personalizzata è la vista e visualizza solo le informazioni meteo. Non sa nulla sul download o sull'elaborazione di questi dati. Il controller, probabilmente una sottoclasse UIViewController, scarica i dati e li fornisce alla vista, eventualmente elaborando i dati o rimuovendo parti non necessarie. Non sa nulla di pixel, o colori, o qualsiasi informazione visiva.

In questo modo, una volta terminata la tua app, sarà modulare. Supponi di voler aggiornare i tuoi colori per renderli più belli. Quindi cambia la sottoclasse UIView e ignora il controller. O se vuoi cambiare l'API. Cambia il controller, non preoccuparti per la vista. Se hai seguito il primo approccio, entrambe le modifiche ti portano allo stesso file, che a sua volta sarebbe probabilmente più grande e più confuso, richiedendoti più tempo per aggiornare il codice.

Questo è il vero vantaggio di MVC: quando torni indietro per cambiare il codice in futuro, è molto più semplice e chiaro.