Architettura "di medio livello" per app iOS client-server?

5

Vedo due ovvi approcci all'architettura per un'app iOS che ha bisogno di parlare con un server per fare il suo lavoro.

Fai finta di essere un browser web

In base a questo approccio, l'app recupera una porzione di dati (in genere JSON) dal server in risposta a un'azione dell'utente (navigando verso un nuovo controller di visualizzazione, toccando un "Aggiornamento", qualunque cosa), attiva uno spinner o altro indicatore di avanzamento, quindi aggiorna la vista al completamento della richiesta. Le classi "modello" sono mappate direttamente dal JSON in arrivo e possibilmente anche immutabili, e gettate via quando l'utente si sposta dallo schermo che sono state recuperate per popolare.

Sotto la versione "pura" di questo approccio imposti le intestazioni appropriate sul server e lasci che NSURLSession e gli amici gestiscano il caching.

Funziona bene se si può presumere che l'utente abbia una connettività di rete veloce a bassa latenza e in genere legge i dati dal server e non scrive.

Sync

Con l'approccio "sincronizzazione", l'app mantiene un archivio di dati di base locale di oggetti modello da visualizzare all'utente. Si aggiorna in risposta all'azione dell'utente o periodicamente e aggiorna l'interfaccia utente (tramite KVO o simile) quando il modello cambia. Quando l'utente modifica il modello, queste modifiche vengono inviate al server in modo asincrono; ci deve essere un meccanismo per risolvere i conflitti.

Questo approccio è più adatto quando l'app ha bisogno di funzionare offline o in contesti di rete ad alta latenza / lenta, o dove l'utente sta scrivendo molti dati e devono vedere i cambiamenti del modello senza attendere un round-trip del server.

C'è una terza via di mezzo? Cosa succede se ho un'app che è principalmente ma non sempre legge, ma dove ci sono scritture l'utente dovrebbe vedere immediatamente quegli aggiornamenti riflessi nell'interfaccia utente. L'app dovrebbe essere utilizzabile in situazioni di rete scarsa o inesistente (mostrando i dati precedentemente memorizzati nella cache fino a quando una richiesta al server non ha il tempo di rispondere).

Posso ottenere il meglio da entrambi i mondi senza andare a pieno Core-Data-with-sync (che sembra pesante e difficile da correggere) ma senza implementare inavvertitamente un clone buggato e incompleto di Core Data?

    
posta Robert Atkins 14.08.2014 - 11:26
fonte

1 risposta

1

Non dal punto di vista dello sforzo. Se stai implementando qualcosa tramite un modello di sincronizzazione, devi costruire tutto ciò che comporta. Puoi opzionalmente scegliere di consentire - per alcuni feed - il caricamento lazy all'aggiornamento se ciò è auspicabile dal punto di vista delle prestazioni (questa è una pratica comune per i feed piccoli e oscuri a cui meno del 50% della base utente potrà mai accedere).

Ma ovviamente, mentre è ancora meglio che "uno o l'altro" come sopra, ha un problema che essenzialmente devi creare entrambi . È, a mio avviso, il modo più efficiente per gestire il caricamento dei dati in un'app mobile.

    
risposta data 30.09.2014 - 22:08
fonte

Leggi altre domande sui tag