Pro e contro dell'approccio Listener/Observer per notificare Modifiche al modello

Question

In qualsiasi applicazione iPhone tipica, ci saranno classi modello responsabili del caricamento/analisi dei dati. Al completamento delle attività di caricamento/analisi dei dati, i controllori interessati dovevano essere informati della modifica nel modello e aggiornare di conseguenza la vista.

Ci sono diversi approcci all'ascoltatore/osservatore per questo nello sviluppo di applicazioni per iPhone. Quali sono i pro/contro e i motivi per utilizzare ciascuno dei seguenti approcci?

1. KVO
2. NSNotification
3. Delegato
4. Qualsiasi altro approccio noto

Answer 1

Nella mia esperienza:

delegazione:

• PRO: utilizzare solo quando si dispone di un singolo oggetto da notificare;
• PRO: utilizzando un protocollo esplicito è possibile documentare chiaramente le proprie intenzioni;
• CON: può essere fonte di incidenti e perdite di memoria se usato erroneamente (consiglio: non conservano i delegati, assegnarli, e ricordarsi di deassign delegati quando/se vengono rilasciate)

ho scritto a proposito di problemi di gestione della memoria generati da delegazione in questo articolo sul mio blog:

http://akosma.com/2009/01/28/10-iphone-memory-management-tips/

NSNotification:

• PRO: migliore quando si hanno diversi oggetti da notificare;
• PRO: molto flessibile, porta a classi vagamente accoppiate;
• CON: le notifiche vengono inviate in modo sincrono (quindi assicuratevi che i vostri singoli gestori di notifiche facciano davvero poco)
• CON: a volte difficile da documentare e mantenere. Assicurati di spiegare chiaramente nei documenti di intestazione cosa significa ogni notifica e quando viene inviata.

KVO:

• preoccupazioni simili riguardo NSNotifications;
• CON: ancora più oscuro da documentare. Assicurati di aggiungere ulteriori documenti di intestazione o suggerimenti di architettura sui tuoi commenti per spiegare chi sta ascoltando cosa. Personalmente non userei KVO per il caricamento dei dati o le attività di analisi.

Personalmente, quando si tratta di applicazioni di rete abilitate a parlare con un servizio Web remoto, io uso una classe di dati caricatore di Singleton (confezionamento ASIHTTPRequest e gestione di tutte la serializzazione e deserializzazione), che si apre notifiche quando si verifica qualcosa.In questo modo posso avere il delegato della app che gestisce gli errori di connessione da solo (spuntando gli avvisi e così via), e ad ogni controller interessano solo le risposte che desidera.

Naturalmente, questo approccio dipende dall'applicazione, ma questa architettura generale potrebbe essere un punto di partenza per il proprio codice.