proveedor - que es uri en android studio

usar ContentProviderClient vs ContentResolver para acceder al proveedor de contenido

Question

La documentación sobre los proveedores de contenido de Android describe el uso de un ContentResolver , obtenido de getContentResolver() , para acceder al contenido.

Sin embargo, también hay un ContentProviderClient , que puede obtenerse de getContentResolver().acquireContentProviderClient(authority) . Parece que proporciona más o menos los mismos métodos disponibles en ContentResolver para acceder al contenido del proveedor.

¿Cuándo debería usar ContentProviderClient lugar de usar ContentResolver directamente? ¿Cuales son los beneficios?

Answer 1

Bien, pero tenga en cuenta que solo funciona cuando ContentProvider se ejecuta en este mismo proceso como Actividad.

Nota de la documentación para el método getLocalContentProvider() :

Si ContentProvider se ejecuta en un proceso diferente, se devolverá nulo. Esto se puede usar si sabe que se está ejecutando en el mismo proceso que un proveedor y desea obtener acceso directo a los detalles de su implementación.

Answer 2

Creo que la otra diferencia de importación es que ContentProviderClient se puede convertir en su objeto de proveedor personalizado y acceder a otro método además de CRUD.

ContentProvider cp = getContentResolver().acquireContentProviderClient(mCurUri).getLocalContentProvider();
yourProvider fld = (yourProvider)cp;
fld.query(...);           // you can query as ContentResolver
fld.addFolder(newFolder); // also can invoke the extend method of your custom ContentProvider

Answer 3

Encontré la siguiente diferencia: escribí mi propio proveedor de contenido personalizado en la aplicación A. Escribí un widget de pantalla de inicio en la aplicación B. Cuando traté de acceder al ContentProvider de la aplicación A a través de ContentResolver desde mi widget, recibí un "proveedor que no pude encontrar" info "error. Cuando, en cambio, adquiriera un ContentProviderClient a través de ContentResolver y realice una consulta a través de ContentProviderClient, funcionaría. No tuve que cambiar nada más, solo uso el ContentProviderClient en lugar del ContentResolver. No tengo una explicación real para ese comportamiento y no encontré información en Internet sobre por qué es así. No sé, si esto es una peculiaridad especial de los widgets, porque no lo intenté con una actividad en la aplicación B (la aplicación B es un simple widget, sin actividad).

Answer 4

Su dispositivo Android tiene muchas bases de datos, cada una de las cuales está identificada por una Autoridad de contenido única. Esta es la parte equivalente de "nombre de dominio" en el contenido: // uri - todo antes de la primera barra inclinada.

ContentResolver almacena datos que proporcionan una asignación de String contentAuthority a ContentProvider . Cuando llama a ContentResolver.query() o update() o lo que tiene, el URI se analiza en sus componentes, se identifica la cadena contentAuthority y contentResolver tiene que buscar esa cadena buscando el mapa y dirigir la consulta al proveedor correcto. Esta búsqueda costosa se produce durante cada llamada, ya que el URI puede ser diferente de llamada a llamada, con una ContentAuthority diferente también. Además, puede haber algunos costos relacionados con la configuración y el corte de una conexión a ese proveedor específico: no puede reutilizarse en llamadas. No estoy seguro de la sobrecarga involucrada allí, ese es un código bastante profundo del nivel del sistema operativo.

Por el contrario, cuando llamas a acquireContentProviderClient(authority) , ¿qué proveedor necesito? la búsqueda se realiza una vez, y se le otorga un ContentProviderClient que es esencialmente un enlace directo al ContentProvider . (Hay un poco de pegamento entre usted y el proveedor que implica comunicación entre hilos y bloqueo de simultaneidad). Sin embargo, cuando use ContentProviderClient , hablará directamente con el Proveedor para la autoridad que solicitó. Esto elimina el desperdicio de volver a computar constantemente "¿qué proveedor quiero?"

NOTA: según la documentación de acquireContentProviderClient () : si obtiene un ContentProviderClient, "la persona que llama debe indicar que ha terminado con el proveedor al llamar a ContentProviderClient.release() que permitirá que el sistema lo libere, ya que determina que no hay otro motivo para mantenerlo activo ". Así que, en esencia, dejar un Cliente obsoleto abierto obligará al Proveedor a seguir funcionando como un servicio en segundo plano. Entonces, ¡recuerda limpiar!

Resumen:

Muchas llamadas a diferentes contenidoAutoridades: use ContentResolver .

Llamadas repetidas a la misma Autoridad: Obtenga y use ContentProviderClient . Recuerde liberar () cuando haya terminado.

Answer 5

Uno de los usos de ContentProviderClient es útil para acceder a algunos de los métodos de ContentProvider en las pruebas. Por ejemplo, uso el método shutdown() en las pruebas unitarias para evitar múltiples pruebas que crean instancias de múltiples proveedores de contenido.

Implementar ContentProvider#shutdown() esta manera:

@Override
public void shutdown() {
    openHelper.close();
    super.shutdown();
}

Y al final del método de prueba, llame a shutdown() usando ContentProviderClient para limpiar la prueba para que otras pruebas puedan usar el proveedor de contenido:

getContext()
       .getContentResolver()
       .acquireContentProviderClient(URI)
       .getLocalContentProvider()
       .shutdown();