Gestione di tabelle SQLite e cursori su Android

Question

Ho difficoltà a ottimizzare la retrocompatibilità, la complessità e le best practice per la gestione del database SQLite su Android. Ho trovato due modi non deprecato per gestire database SQLite e cursori:

• direttamente attraverso android.database.sqlite
• ContentProvider, CursorLoader e LoaderManager

Sto cercando di progettare il futuro implementazione del database prova. Ciò significa che vorrei implementare una best practice promossa da Google. I found a tutorial sull'implementazione di ContentProvider e LoaderManager.

Se seguo le proposte di Lars Vogels, il mio codice è saltato in aria con duplicazioni e complessità non necessarie. Ha senso per alcune tabelle nel mio database. Ma non avrebbe senso implementarlo per una tabella di mappatura con tre campi (per esempio). Inoltre ho problemi con ActionbarSherlock e l'interfaccia di callback di LoaderManager (c'è una soluzione ma raddoppierà le mie classi di gestione dei dati).

La gestione diretta del database e dei cursori tramite android.database.sqlite sta provocando problemi con la gestione delle risorse (chiudi i cursori!) E mi rende responsabile della gestione delle attività.

Le mie domande:
Come che state maneggiando database SQLite su Android?
Quando vai avanti e implementa ContentProvider e LoaderManager?
Come rimanere all'indietro?

mio approccio attuale:
ho creato una classe che separa base di dati di I/O (via android.database.sqlite) da attività. Tutti i metodi aprono e chiudono i cursori che usano durante la loro esecuzione (al di fuori delle mie attività) e restituiscono gli oggetti oi dati secondo necessità (invece di un cursore). Le operazioni di I/O vengono eseguite in AsyncTasks. Questo approccio sembra molto deprecato.

Answer 1

Recentemente ho avuto lo stesso semplice dilemma del provider di contenuto/contenuto, e sembra che il fornitore di contenuti sia l'approccio più comune per risolvere il problema.

Anche se il official doc afferma che

Non c'è bisogno di sviluppare il proprio provider se non si intende condividere i tuoi dati con altre applicazioni

hanno aggiunto la possibilità di avere fornitori di contenuti non esportate utilizzando

android:exported="false" 

Tutti i libri che ho letto, compreso di Reto Meier P rofessional Android Development 4, suggerisce di utilizzare i provider di contenuti.

Inoltre, al costo di molti codici di codice, è possibile dimenticare il multithreading e il problema del cursore aperto.

In ogni caso, devo dire che il vantaggio più grande che si ottiene dalla combinazione di content provider/loader loader è che il caricatore viene automaticamente informato ogni volta che i dati sottostanti cambiano.

Se si utilizza sqllite semplice è necessario implementare un modo per ottenere la notifica delle classi client ogni volta che i dati cambiano in background. Ad esempio, ho usato le trasmissioni per notificare qualsiasi attività che le tabelle sono state aggiornate all'interno di un intentservice.

Infine, sono rimasto un po 'deluso da tutta la duplicazione di codice su cui si sta sbagliando, e ho deciso di scrivere uno script python per generare il fornitore di contenuti al mio posto usando solo una descrizione del modello di dati. Probabilmente devi modificare la classe generata (o, meglio, estenderla), ma penso che risparmi un bel po 'di tempo. Lo si può trovare here

Conclusione:

• se si desidera esportare i dati in altre applicazioni (non così comune), è necessario andare per il fornitore di contenuti
• se si desidera osservare i dati/aggiorna l'interfaccia utente perché il tuo set di dati potrebbe essere cambiato in background, content provider + loader è estremamente potente
• se hai un set di dati precaricato, e forse lo aggiorni nella stessa attività che visualizza i dati, o hai bisogno per eseguire semplici operazioni con il tuo ta bles, forse una classe di helper sqllite è appena sufficiente