Come gestite i thread separati durante il recupero dei dati in iOS?

Question

Ciao Attualmente sto costruendo un app che ha le seguenti proprietà:

1. utilizza Core Data per la memorizzazione
2. ha un feed che visualizza un elemento alla volta
3. se fuori oggetti, applicazione chiamerà Recupero dal server in modo asincrono

La gestione delle ricerche asincrone si è dimostrata piuttosto complicata.

Attualmente, stiamo memorizzando gli elementi recuperati dal server direttamente in Core Data.

Ogni volta che l'app ha bisogno di un nuovo articolo, stiamo interrogando i dati di base per un oggetto invisibile.

Stiamo vedendo alcuni impatti significativi riguardo alle prestazioni dell'app a causa di questa costante interrogazione di Core Data.

Abbiamo pensato di utilizzare una matrice in memoria e di mantenere un indice ma l'aspetto asincrono del recupero una volta che siamo fuori dall'elemento si dimostra troppo complesso in quanto dobbiamo utilizzare i blocchi e altre misure di concorrenza per mantenere il thread dell'array sicuro.

Avete qualche suggerimento su come posso ridurre le chiamate totali ai dati principali?

Answer 1

È necessario mantenere al minimo i viaggi nel negozio permanente, in modo da recuperare un numero ragionevole di elementi che si prevede di visualizzare. Core Data è molto efficiente nell'errore degli oggetti gestiti, quindi l'impronta della memoria non dovrebbe essere un problema.

Quando si esauriscono gli elementi da visualizzare ma ne rimangono ancora alcuni nell'array, provare a recuperarne altri.

A questo punto, se non si ottengono risultati, inviare una coda asincrona con il proprio contesto oggetto gestito, creare i nuovi oggetti gestiti, salvare e notificare il contesto principale in modo che possa unire le modifiche.

Una volta fatto, si torna a recuperare i nuovi elementi.