Uno dei miei fornitori di contenuti gestisce più database, stesso schema con set di dati diversi. Attraverso il Garbage Collection è stato scoperto che esisteva un database aperto nel mio provider di contenuti che non aveva più alcun riferimento a questo, anche se SQLiteCursor mi lasciava diverse scelte:
1) Lascia aperto l'oggetto SQLiteDatabase e metterlo in una collezione, per non essere mai più usato.
2) Lasciare aperto l'oggetto SQLiteDatabase e sviluppare una cache che consenta di riutilizzare l'oggetto del database quando si accede allo stesso database.
3) Chiudere il database quando il cursore è chiuso.
Soluzione 1 contrasta con il mio giudizio migliore. La soluzione 1 è solo un'altra forma di perdita di risorse; la sua unica speranza è che non sconvolge il sistema. Ho deciso questa scelta immediatamente.
Soluzione 2 era la mia idea della soluzione migliore. Ha conservato le risorse allo stesso tempo riducendo il tempo di esecuzione senza dover riaprire le connessioni al database. Il lato negativo di questa soluzione era che avrei dovuto scrivere la cache e avrebbe aumentato la dimensione dell'applicazione. La dimensione non era un problema, ma il tempo per scrivere era. Ho passato questa soluzione per il momento presente e potrei tornare più tardi.
Soluzione 3 è quello che ha deciso di andare con. In primo luogo, ho pensato che sarebbe stato semplice da fare; Nell'attività, tutto ciò che dovevo fare era riordinare il Cursore restituito dal mio Content Provider in un SQLiteCursor. Quindi potrei invocare il suo metodo getDatabase() e richiamare close() sul database.
Questo non è possibile. Risulta che il cursore restituito dal Content Provider si trova all'interno di una classe wrapper che impedisce l'accesso diretto all'oggetto Cursor effettivo. Il wrapper delega i metodi che chiama al Cursore. Nessuna possibilità di riportare il cursore sul suo tipo derivato.
Quindi, invece di affidare la responsabilità di chiudere il database sull'attività, ho seguito un percorso diverso e più semplice. Ho derivato la mia classe Cursor estendendo la classe SQLiteCursor. Ho aggiunto due membri di dati alla mia classe derivata; uno per fare riferimento al database e l'altro era un ID per l'uso nel debug. Il Ctor della classe ha avuto la stessa firma di SQLiteCursor Ctor con un parametro aggiuntivo aggiunto alla fine per l'impostazione del valore ID. Il ctor imposta il membro dei dati del database per assicurare che qualcosa stia facendo riferimento al database se si è verificato un Garbage Collection prima che il cursore fosse chiuso.
Sovrascrivo il metodo close() in modo che chiudesse il cursore [super.close()] e chiudesse il database se il riferimento non era nullo.
Ho anche eseguito l'override del metodo toString() in modo che il numero ID sia stato aggiunto alla stringa. Questo mi ha permesso di monitorare quali cursori erano ancora aperti e quali sono stati aperti e chiusi nel file di registro.
Ho anche aggiunto un metodo closeForReuse() in modo che il provider di contenuti possa riutilizzare un database per più query senza dover aprire ogni volta una nuova connessione al database.
Ho anche creato una classe che ha implementato l'interfaccia SQLiteDatabase.CursorFactory. Ha creato la mia nuova classe cursore derivata e gestito il valore ID passato a ciascuno.
Questa soluzione richiede comunque che ogni attività chiuda i cursori passati ad esso quando hanno finito di usare il cursore. Poiché questa è una buona pratica di programmazione, non è stata una preoccupazione.
Sembra che non sia necessario chiudere il database. La documentazione dice che il database è memorizzato nella cache in modo da avere un'istanza di database aperta per l'intera durata dell'applicazione. http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html#getWritableDatabase() –