Quando utilizzare un fornitore di contenuti

103

Comprendo che i fornitori di contenuti sono creati per consentire la condivisione pubblica dei dati tra le applicazioni. Tuttavia, mi chiedo se qualcuno abbia in mente di creare un fornitore di contenuti da utilizzare solo all'interno della tua app. Ci sarebbero dei vantaggi nel farlo? Qualche svantaggio?

In passato ho appena implementato SQliteOpenHelper per accedere ai dati dal mio database, ma sto pensando di creare un provider di contenuti. Mi sembra che l'approccio URI alla richiesta di dati sia chiaro e conciso. D'altra parte, l'utilizzo di un Content Provider solo per la mia applicazione sarà ridondante (poiché al suo interno avrò una classe SQliteOpenHelper) e più lavoro del necessario?

android android-contentprovider

— Pzanno
fonte

2

Ho creato una libreria per rendere il fornitore di contenuti facile da scrivere. Ancora più facile che scrivere semplice SQLiteOpenHelper. github.com/coocood/VContentProvider

— coocood

59

Se non hai intenzione di condividere i dati, non pensare ai fornitori di contenuti. Sono potenti ma difficili da scrivere e sarebbe sciocco implementarli se li utilizzerai internamente.

Tuttavia, mi chiedo se qualcuno abbia in mente di creare un fornitore di contenuti da utilizzare solo all'interno della tua app.

Ovviamente ... ad esempio, per una vecchia app di elenco TODO che ho scritto, ho dovuto scrivere un fornitore di contenuti per consentire ad altre app di recuperare e accedere agli stati delle attività. Faceva parte dei requisiti, ma soprattutto aveva senso e rendeva l'app più gradevole.

— Cristian
fonte

34

Sono d'accordo con la tua giustificazione, ma penso anche che sia importante (soprattutto per i principianti) che una volta implementato il fornitore di contenuti ottieni molti vantaggi. Ad esempio, puoi usare CursorLoaderper eseguire query asincrone ... hai accesso a un'istanza singleton (the ContentResolver) per eseguire query, ecc. Ovviamente potresti implementare il tuo Loader da utilizzare per il tuo database SQLite ... ovviamente tu potrebbe implementare l'accesso a una singola istanza di database attraverso l'intera applicazione ... e ovviamente non è richiesto un ContentProvider a meno che non si desideri condividere

— Alex Lockwood,

11

dati con altre app. Detto questo, ci sono molti vantaggi che derivano dall'implementazione del proprio fornitore di contenuti, quindi non dovresti lasciarlo perdere solo perché la tua app non condivide i suoi dati.

— Alex Lockwood,

8

Sì, hai completamente ragione, ma penso ancora che non valga la pena nella maggior parte dei casi. Ho fatto almeno 12 diverse app Android (pubblicate nel Play Store) e non ho mai avuto bisogno di un file ContentProvider. In effetti, l'ultima app su cui stavamo lavorando è stata inizialmente realizzata con una ContentProvidere l'abbiamo appena eliminata poiché in realtà è più una seccatura da usare di quanto dovrebbe (ho persino scritto una libreria per rendere più facile l'implementazione di ContentProviders di base : github.com/casidiablo/persistence ma non l'avevo mai usato da solo XD).

— Cristian

1

@Cristian fornisce i consigli più pratici. Anche il documento Android afferma che non dovremmo usare ContentProviderse non ne abbiamo bisogno: "Non è necessario un provider per utilizzare database o altri tipi di archiviazione persistente se l'uso è interamente all'interno della propria applicazione e non è necessario una delle funzionalità sopra elencate. Puoi invece utilizzare uno dei sistemi di archiviazione descritti nella pagina Salvataggio dati app. ". Altrimenti, siamo appena sopra l'ingegneria.

— Cheok Yan Cheng

Riepilogo: se non hai intenzione di condividere i tuoi dati, puoi evitare di Content Provider, ma d'altra parte Content Provider ti semplifica la vita se desideri modificare il database della tua app. ad esempio da SQLite a MangoDB.

— Prashant

116

Direi che è sicuramente una buona idea usare a ContentProvideranche se non intendi renderlo pubblico.

È buona norma fornire un ulteriore livello di astrazione sui dati per semplificare le modifiche interne. E se decidi di modificare la struttura del database sottostante in un secondo momento? Se usi un ContentProviderpuoi contenere tutte le modifiche strutturali al suo interno, dove come se non ne usassi uno, sei costretto a cambiare tutte le aree del codice che sono interessate dai cambiamenti strutturali. Inoltre, è bello poter riutilizzare la stessa API standard per accedere ai dati invece di sporcare il codice con un accesso di basso livello al database.

Inoltre, c'è sempre la possibilità che tu possa voler esporre i tuoi dati in futuro. Se non si utilizza un ContentProviderfrontale, sarà molto più difficile adattarlo in un secondo momento.

Quindi, ci sono le altre parti di Android in cui ContentProvidersono richieste / consigliate, ad esempio quando si utilizza SyncAdapterse si desidera un widget app che implichi l'accesso ai dati, ad esempio.

In sintesi, c'è un sovraccarico minimo nella scrittura di un ContentProvideranticipo (una volta appresa l'API che è comunque una buona idea) quindi ha senso farlo, anche per i dati privati.

— Paul Drummond
fonte

1

Non potrei essere più d'accordo. Ti costringe ad astrarre il tuo livello dati in un modo che praticamente garantisce che un nuovo sviluppatore non sarà in grado di accoppiare l'interfaccia utente con esso.

— Gabriel

3

Subito dopo aver appreso Android, ho iniziato a pensare allo stesso modo proprio per questo motivo. Anche se non pubblico, puoi sempre beneficiare della maggiore astrazione e del singolo punto di implementazione delle tue decisioni architettoniche. Adoro ContentProviders.

— davidcsb

1

Puoi rendere il fornitore di contenuti disponibile solo per la tua applicazione con questo attributo:android:exported="false"

— Toby 1 Kenobi

4

A mio modesto parere, puoi e dovresti gestire i tuoi dati in modo completamente astratto, senza alcuna necessità di implementare ContentProvider.

— hmartinezd

2

Mentre stavo implementando una soluzione di contentprovider per il mio db sqlite interno (nessuna interazione con altre app), ho visto il commento su developer.android.com/guide/topics/providers/… che afferma che non hai bisogno di un provider utilizzare un database SQLite se l'uso è interamente all'interno della propria applicazione.

— Selçuk Cihan

7

Dai un'occhiata a MOTODEV Studio per Eclipse. È un ambiente di sviluppo che estende Eclipse. Hanno uno strumento in cui è possibile generare automaticamente un fornitore di contenuti per un database. Se un fornitore di contenuti semplifica l'accesso ai tuoi dati e non ha un impatto significativo sulle prestazioni, vai avanti e usalo. Nella maggior parte degli scenari questo sarà il caso.

— zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
fonte

5

In breve, Content Providersaiuta a gestire i tuoi dati in modo efficace . Suggerirei di usarli per i seguenti motivi.

Funge da livello di astrazione tra l'interfaccia utente e il database . È possibile implementare la convalida dei dati in ContentProviders per convalidare i dati inseriti dall'utente. Consente inoltre di modificare la struttura del database senza toccare l'interfaccia utente e altre parti.
Giocano bene con altre classi di framework Android come SyncAdapter. Ad esempio, è possibile aggiornare automaticamente un elenco, quando un valore in un database cambia utilizzando ContentProviders insieme aCursorLoader . Senza ContentProvider devi implementare molte funzionalità come queste da solo.
Possiamo esporre in sicurezza i nostri dati privati ad altre app . L'utilizzo di ContentProviders ci consentirà di condividere i nostri dati in modo semplice e sicuro con altre app.

Quindi, anche se non hai bisogno di nessuna di queste funzionalità ora, potresti averne bisogno in futuro ed è bene fare il possibile e implementarle subito.

— Siva Prakash
fonte

Bella risposta. Descrizione di una singola frase ContentProviderse tre motivi separati per cui dovremmo usarli. A volte le semplici spiegazioni sono le migliori. +1

— AdamInTheOculus

4

Sono d'accordo che i ContentProvider siano un po 'difficili da capire ma sono decisamente utili, anche se vuoi usarli internamente per la tua app. La cosa migliore è che puoi personalizzare i provider di contenuti per gli URI adatti.

Ecco uno scenario in cui potresti avere 5 tabelle nel tuo database, ma devi unirti ad alcune di esse in determinati ordini prima di utilizzarle. E crea un URI di contenuto per ciascuno di questi join. Potresti quindi utilizzare questi URI come una tabella :)

Ti suggerisco di andare avanti con Content Provider, rimarrai stupito di vedere quanto sia potente.

— Shubhayu
fonte

2

Dal mio punto di vista, il fornitore di contenuti ha molti vantaggi, lascia da solo la condivisione dei dati con altre app. Se è necessario sincronizzarsi con il server utilizzando un adattatore di sincronizzazione, utilizzare la messaggistica cloud di Google, aggiornare automaticamente l'interfaccia utente quando i dati sottostanti nel database cambiano utilizzando i caricatori, implementare la ricerca, utilizzare i widget ... allora il fornitore di contenuti è per te.

Preferisco che tu segua le linee guida perché un giorno potresti dover implementare alcune delle funzionalità di cui sopra allegate al fornitore di contenuti

A proposito, puoi creare rapidamente il tuo database e CP in meno di 5 minuti utilizzando il generatore di provider di contenuti

— Phillip Kigenyi
fonte

1

Come detto nella documentazione: Creazione di un fornitore di contenuti

Non è necessario un provider per utilizzare un database SQLite se l'utilizzo è interamente all'interno della propria applicazione.

Allora perché preoccuparsi di sviluppare questo sovraccarico? Vuoi uno sviluppo più semplice e veloce, giusto? Quindi uno strato di astrazione (SQLiteOpenHelper discendente) è sufficiente.

Vedi il rasoio di Occam Non creare entità senza una buona ragione.

— stoarch
fonte

0

Non utilizzare il fornitore di contenuti se non desideri condividere i dati con altre app. Utilizzare semplice sqlitedatabase per eseguire operazioni di database. Fai attenzione quando utilizzi fornitori di contenuti per l'archiviazione di dati riservati perché le tue informazioni riservate potrebbero essere accessibili da altre app

— user3030895
fonte

Per impostazione predefinita, i fornitori di contenuti non sono esposti e la gestione delle restrizioni di accesso ad essi è facile. Downvote per la diffusione di disinformazione.

— TBridges42

2

@ TBridges42 Ti sei (eri) sbagliato. Infatti fino a quando i provider di contenuti di livello API 17 non sono stati esposti . E al momento della risposta il 25% dei dispositivi Android era interessato da questo comportamento e ancora il 10% al momento del tuo commento . Quindi, è più il contrario: il tuo commento è pericoloso, poiché dichiari qualcosa per essere sicuro che è / non era il fatto.

— Murmel

0

L'utilizzo di un fornitore di contenuti può aiutare a un ulteriore livello di astrazione: metterlo all'interno della propria applicazione aggiunge un tempo di sviluppo significativo al progetto. Tuttavia, se lo utilizzi per condividere dati, impostazioni dell'applicazione o configurazioni tra più applicazioni, il fornitore di contenuti è la tua scelta.

Controlla i tuoi livelli di sicurezza e ti consiglio di utilizzare SQLcipher per crittografare i dati al ripristino (DAR) se il tuo provider di contenuti scrive su SQLite. (Ho utilizzato un fornitore di contenuti in alcune soluzioni e ho fornito la possibilità di scattare una "istantanea" in tempo reale dei valori operativi per il debug e il test.)

— Jim Row
fonte