Best practice per l'utilizzo di CoreLocation nei modelli vs controller

Question

Sto cercando di capire il modo migliore per progettare la mia app. Attualmente ho una classe wrapper attorno a CLLocationManager che si imposta come delegato e gestisce tutte le impostazioni e le logiche di business extra di cui abbiamo bisogno. È anche un singleton (sharedManager).

Mi piacerebbe essere il più fedele possibile a MVC e spingere la maggior parte della logica nei miei modelli, ma non sono sicuro dei modi migliori per farlo. Attualmente sia i controller che i modelli stanno ottenendo il SharedManager e i metodi di chiamata su di esso come il controllo della posizione è disponibile prima di presentare un modale (controller) o ottenere la posizione corrente prima di effettuare una chiamata REST (modello), ma ciò sembra molto accoppiato e difficile da testare.

Mi piacerebbe utilizzare il più possibile l'integrazione delle dipendenze per evitare di interrogare costantemente il metodo Singleton in tutte le parti del mio codice, ma non riesco a capire il modo migliore per farlo.

Alcune idee che ho avuto:

• convertire il mio CLLocationManager wrapper per utilizzare la notifica di parlare con tutte le parti della app per migliorare il disaccoppiamento. Potrei quindi effettuare chiamate di avvio/arresto utilizzando il singleton, ma i miei controller/modelli reagiranno ai cambiamenti ascoltando le notifiche. Questo ancora non evita di dover usare il singleton dappertutto.

• Utilizzare solo il singleton nel controller e trasferire i dati di posizione necessari al modello impostando le proprietà. Questo sembra che renderebbe più facile testare i miei modelli, ma non il mio controller e mettere il codice di posizione di Core nei controller è anche icky.

• È possibile passare un'istanza del mio wrapper di location manager personalizzato impostando le proprietà su entrambi i modelli e controller, ma ciò sembra un po 'noioso e le immagini ferme lasciano la domanda su dove creare il gestore iniziale?

mi piacerebbe qualche consiglio da parte di persone che hanno pensato su questo problema più in profondità. Tutte le idee sono benvenute e apprezzate!

Answer 1

Mi piacerebbe utilizzare il più possibile l'iniezione di dipendenze per evitare di interrogare costantemente il metodo Singleton in tutte le parti del mio codice, ma non riesco a capire il modo migliore per farlo.

Si risponde alla tua domanda:

ho potuto passare un'istanza del mio percorso personalizzato responsabile wrapper impostando le proprietà su entrambi i modelli e controller, ma che si sente un po 'noioso e alambicchi lascia la questione da dove posso creare il manager iniziale?

Non c'è niente di male nel fare il vostro involucro di un Singleton, e passando intorno un riferimento ad esso per gli oggetti che ne hanno bisogno - questo è un modo di gestire l'iniezione di dipendenza. Puoi avere un sacco di oggetti che dipendono dalla sua interfaccia, ma se vuoi evitare di essere un singleton, puoi farlo anche tu.

I tuoi modelli non devono sapere che il tuo gestore di posizione è un singleton. Forse solo i tuoi controllori lo fanno. Oppure puoi scegliere uno o pochi punti radice nella tua applicazione che conosce la natura singleton del gestore di posizione e lo inietta a componenti dipendenti. Il modo in cui vuoi farlo dipende molto dall'architettura dell'applicazione esistente.Si potrebbe fare un "finder" per questo (lo rende molto simile a un singleton di nuovo) o passarlo come parametro nei costruttori - un metodo di iniezione della dipendenza che a volte viene trascurato.

Auspico inoltre che si affacciano Key Value Observing e magari avere i vostri modelli o controller osservare una proprietà posizione sul location manager. Personalmente mi piace anche usare Reactive Cocoa come una libreria "KVO con blocchi", senza necessariamente tuffarsi a capofitto in Programmazione reattiva funzionale. ReactiveCocoa può risparmiare un sacco di headaches associato al sistema KVO altrimenti molto potente in Objective-C.

Non vorrei sostenere l'uso delle notifiche per comunicare una modifica di base come una singola posizione. Ho avuto le cose in modo abbastanza complicato in questo modo. Uno schema comune nei programmi Objective-C è "messages-leafward/notifications-appward".

Quello che hai nel tuo gestore di location manager è essenzialmente un servizio di localizzazione. Non è una cattiva idea mettere molta logica aziendale in quei servizi invece che nei modelli (dove ha senso). Ad esempio, se si dispone della logica aziendale attorno alla frequenza delle modifiche alla posizione che si propagano alle modifiche dell'interfaccia utente o alle soglie di movimento, queste possono essere applicate a vari modelli diversi. Avere quella logica di business correlata alla posizione in un servizio di localizzazione può davvero ASCIUGARE i tuoi modelli.