Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Utilizando ContentProviderClient vs ContentResolver para acceder al proveedor de contenido

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

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

¿Cuándo debo usar un ContentProviderClient lugar de usar ContentResolver directamente? ¿Cuales son los beneficios?

  • Obtener cursor mediante la biblioteca Realm
  • Android: encuentra un contacto por nombre de visualización
  • Mostrar los contactos en orden de clasificación ContactsContract.Contacts de Content Resolver
  • ¿Puedo realizar esta consulta de Android con ContentResolver.query ()? (LEFT JOIN y CASE)
  • ¿Cómo hacer frente a múltiples proveedores de contenido?
  • Editar nombre / número de teléfono de contacto programáticamente
  • ¿Para qué se utiliza cursor.setNotificationUri ()?
  • Cómo agregar un enlace a mi aplicación desde el menú rápido de contactos
  • 5 Solutions collect form web for “Utilizando ContentProviderClient vs ContentResolver para acceder al proveedor de contenido”

    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.

    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 debe buscar ese mapa para una cadena que coincida y dirigir la consulta a la Proveedor correcto. Esta búsqueda cara ocurre durante cada llamada, ya que el URI puede ser diferente de llamada a llamada, con un contenido diferente de Autoridad también. Además, puede haber algunos costos involucrados en la creación y destrucción de una conexión a ese proveedor específico – No se puede reutilizar en todas las llamadas. No estoy seguro de la sobrecarga involucrada allí, que es un poco profundo código de nivel OS.

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

    NOTA: La documentación de la documentación de la adquisiciónContentProviderClient () : Si obtiene un ContentProviderClient, "la persona que llama debe indicar que se terminó con el proveedor llamando a ContentProviderClient.release () que permitirá al sistema liberar al proveedor, si determina que no hay otro Razón para mantenerla activa ". Así que esencialmente, dejando un cliente obsoleto abierto obligará al proveedor a seguir funcionando como un servicio en segundo plano. Por lo tanto, recuerde limpiar!

    Resumen:

    Muchas llamadas a contenido diferente Autoridades: Use ContentResolver .

    Llamadas repetidas a la misma Autoridad: Obtenga y use ContentProviderClient . Recuerde lanzarlo () cuando termine.

    Ok, pero tenga en cuenta que sólo funciona cuando ContentProvider se ejecuta en este mismo proceso como Actividad.

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

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

    Creo que la otra diferencia de importación es ContentProviderClient puede convertirse en su 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 

    Encontré la siguiente diferencia: escribí mi propio contenido personalizado en la aplicación A. Escribí un widget de pantalla de inicio en la aplicación B. Cuando intenté acceder al ContentProvider de la aplicación A a través de un ContentResolver de mi widget, obtuve un "proveedor no encontrado Info "error. Cuando, en cambio, adquiriría un ContentProviderClient a través de ContentResolver y consultaría a través de ContentProviderClient, funcionaría. Tuve que cambiar nada más, sólo uso ContentProviderClient en lugar de ContentResolver. No tengo ninguna explicación real para ese comportamiento y no he encontrado ninguna información en Internet, por lo que es así. No sé, si esto es una peculiaridad especial de los widgets, porque no lo probé desde una actividad en la aplicación B (la aplicación B es un mero widget, sin actividad).

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

    Implementar ContentProvider#shutdown() así:

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

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

     getContext() .getContentResolver() .acquireContentProviderClient(URI) .getLocalContentProvider() .shutdown(); 
    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.