Uno de mis proveedores de contenido administra varias bases de datos, el mismo esquema con diferentes conjuntos de datos. Para evitar que el IllegalStateException ser a través de cuando la recolección de basura descubrió que había una base de datos abierta en mi proveedor de contenido que ya no tenía nada referencia a ella, a pesar de que la SQLiteCursor me dejó con varias opciones:
1) Deja las SQLiteDatabase objeto abierto y colóquelo en una colección, para nunca volver a utilizarlo.
2) Deje el objeto SQLiteDatabase abierto y desarrolle un caché que me permita reutilizar el objeto de la base de datos al acceder a la misma base de datos.
3) Cierre la base de datos cuando el cursor esté cerrado.
Solución 1 va en contra de mi mejor juicio. La solución uno es solo otra forma de fuga de recursos; su única gracia salvadora es que no altera el sistema. Decidí esta opción de inmediato.
Solución 2 fue mi idea de la mejor solución. Conservó recursos al mismo tiempo, reduciendo el tiempo de ejecución al no tener que volver a abrir las conexiones de la base de datos. El inconveniente de esta solución era que tendría que escribir el caché y habría aumentado el tamaño de la aplicación. El tamaño realmente no era un problema, pero era el momento de escribirlo. Pasé esta solución por el momento y puedo volver sobre ella más adelante.
Solución 3 es el que decidió ir con. Primero, pensé que sería simple de hacer; en la actividad, todo lo que tenía que hacer era volver a convertir el Cursor devuelto por mi proveedor de contenido en un SQLiteCursor. Entonces podría invocar su método getDatabase() e invocar close() en la base de datos.
Esto no es posible. Resulta que el cursor devuelto por el proveedor de contenido está dentro de una clase contenedora que impide el acceso directo al objeto real del cursor. El contenedor delega llamadas de método que recibe al Cursor. No hay posibilidad de devolver el cursor a su tipo derivado.
Por lo tanto, en lugar de colocar la responsabilidad de cerrar la base de datos sobre la actividad, tomé una ruta diferente y más fácil. Obtuve mi propia clase de Cursor extendiendo la clase SQLiteCursor. Agregué dos miembros de datos a mi clase derivada; uno para referenciar la base de datos y el otro era una ID para usar en la depuración. El ctor de la clase tiene la misma firma que el cursor SQLiteCursor con un parámetro adicional agregado al final para establecer el valor de ID. El administrador estableció el miembro de datos de la base de datos para asegurarse de que algo hacía referencia a la base de datos si se producía una recolección de elementos no utilizados antes de que se cerrara el cursor.
Anula el método close() para que cierre el cursor [super.close()] y cierre la base de datos si la referencia no fue nula.
También anulé el método toString() para que el número de ID se anexara a la cadena. Esto me permitió rastrear qué cursores seguían abiertos y cuáles se han abierto y cerrado en el archivo de registro.
También agregué un método closeForReuse() para que el proveedor de contenido pudiera reutilizar una base de datos para múltiples consultas sin tener que abrir una nueva conexión de base de datos cada vez.
También creé una clase que implementó la interfaz SQLiteDatabase.CursorFactory. Creó mi nueva clase de cursor derivado y administré el valor de ID pasado a cada uno.
Esta solución aún requiere que cada actividad cierre los cursores que se le pasen cuando hayan terminado con el cursor. Como esta es una buena práctica de programación, no fue una preocupación.
Parece que no hay necesidad de cerrar la base de datos. La documentación dice que la base de datos está en caché, por lo que solo tendrá una instancia de base de datos abierta para toda la vida útil de la aplicación. http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html#getWritableDatabase() –