Implementazione di un metodo che non restituisce mai gli stessi dati due volte

Ho un'applicazione mobile che recupera il x numero di ContentItems da un'API Web, tuttavia ho bisogno di un modo per visualizzare solo il contenuto che l'utente non ha mai visto sullo schermo. (Per essere chiari, l'utente vedrà sempre un singolo elemento di contenuto una sola volta.)

Immagina che la classe di contenuti sia così:

public class ContentItem 
{
    public int ID {get; set; }
    public string Foo {get; set; }
}

Posso pensare a due modi per implementarlo, entrambi con gravi inconvenienti a lungo termine:

1. Restituendo x numero di contentItems , quindi confrontandolo con un elenco di ID contenuto memorizzato internamente che l'utente ha già visto.

Restituisci il x ContentItems più recente dall'API, quindi confronta questi elementi con un elenco (Mobile side SQLite DB) di ID's memorizzato internamente che rappresenta gli elementi di contenuto che l'utente ha già visto. Se l'ID di uno degli articoli restituiti corrisponde a un ID memorizzato nel database, rimuoverlo dall'elenco ContentItem .

Nota: se l'API restituisce 100 elementi di contenuto e l'utente ne ha visti 3, visualizzerò solo i 97 nuovi elementi. Questo vale anche per l'inverso, (97 visto, 3 nuovi) poiché ho un meccanismo che rileva quando l'utente sta esaurendo il contenuto, quindi esegue il metodo 'getContent' in modo asincrono.

Svantaggi:

• Che cosa succede se l'utente ha visto tutto il contenuto restituito dall'API? La risposta ovvia qui è di rieseguire il metodo che raccoglie i dati, ma questo ha implicazioni sulle prestazioni. (Se è un utente molto pesante, potremmo finire per eseguire il metodo più volte per ottenere nuovi contenuti.) Anche questo sembra un po 'ridondante poiché non abbiamo idea di quale contenuto stiamo per tornare.

2. Invio di un elenco di ID di contenuti visualizzati al server per garantire che vengano restituiti solo nuovi contenuti

In questo metodo, utilizzerei l'elenco memorizzato internamente di Content ID che l'utente ha visto e lo invieremo all'API Web prima di inviare la richiesta di getData . L'API assicurerebbe quindi che i dati restituiti non corrispondano a un ID presente nell'elenco dei contenuti visti in precedenza.

Inconvenienti

• Invio di due richieste: ciò significa che inizialmente devo pubblicare l'ID di ogni contentItem che l'utente abbia mai visto all'API, quindi creare una richiesta GET per restituire effettivamente nuovi dati. (Non sono sicuro di quanto sia effettivamente un inconveniente, ma un problema con questo metodo significherebbe che l'id non è in grado di inviare in modo asincrono le richieste - Come faccio a sapere quando il server ha finito di analizzare l'elenco di id per inviare la richiesta di ottenere per esempio?)

• Per utenti molto pesanti, potrei pubblicare un elenco enorme di ID (specialmente dopo 3 anni di utilizzo dell'App, ad esempio), questo potrebbe portare a problemi di prestazioni.

Vale la pena notare che ho il controllo totale sull'API e sull'app e che l'API serve solo l'app - Non ci sono altre dipendenze.

Se qualcuno ha qualche feedback sul metodo con cui andrebbero (o con qualsiasi metodo alternativo) lo apprezzerei molto!