ho eseguito la programmazione di database SQLite per Android, ma non so nulla di Content-Provider tranne questo: "Come ho fatto riferimento alla pagina degli sviluppatori Android, Android SDK ha spiegato di" Content-provider "poiché viene utilizzato per archiviare e recuperare i dati."
Ma allora,
Qualsiasi esempio o aiuta !!
Risposte:
Ho trovato una grande differenza, come segue:
La memorizzazione dei dati in un database è un buon modo per persistere i dati , ma c'è un avvertimento nei database Android creati in Android sono visiblesolo per l'applicazione che li ha creati. Vale a dire, un database SQLite creato su Android da un'applicazione è utilizzabile solo da quell'applicazione, non da altre applicazioni.
Quindi, se need to share data between applications, you need to use the content provider model as recommended in Android.questo articolo presenta le basi dei fornitori di contenuti e come puoi implementarne uno.
Ho trovato questo articolo a questo link
Informazioni davvero carine fornite.
Qual è la differenza esatta tra "Content-Provider" e "Database SQLite"?
ContentProviderè una facciata: un'API che puoi implementare che espone i database ad altri processi. Si può essere implementato in modo in cui i dati vengono memorizzati in un database SQLite, ma non dovrebbe essere così.
Qual è il modo migliore per memorizzare i dati, quando?
È impossibile rispondere in astratto. In generale, a meno che qualcosa non richieda di utilizzare a ContentProvider, usa semplicemente un database.
Ho creato molte buone app con migliaia di utenti che le utilizzavano che utilizzavano semplicemente i metodi SQLite. Ma è stato tempo fa e ho dovuto scrivere manualmente un sacco di codice che ora può essere facilmente gestito da ContentProvider. Allora non ero favorevole all'utilizzo di Content Provider perché sembrava aggiungere solo complessità al codice.
Tuttavia negli ultimi due anni, con l'evoluzione di Android, sono passato a ContentProvider in quanto consente di risparmiare tempo e ti consente di fare di più. Ora lo uso ampiamente. Una volta che hai scritto un corso per provider di contenuti, la tua vita diventa molto più facile. Con ContentProvider posso gestire molto facilmente Cursor Loader, Loader Callback e Bulk Insert per i quali ho dovuto scrivere tutto manualmente in passato e tuttavia non ha funzionato in modo altrettanto efficiente. Soprattutto durante l'aggiornamento della visualizzazione elenco, che ora viene aggiornata automaticamente grazie a un solo metodo notifychange (). Ciò significa che ora non devo digitare i miei listener e aggiornare manualmente il contenuto nelle visualizzazioni elenco e negli adattatori. Inoltre, non devo preoccuparmi dell'apertura e della chiusura dei database o delle perdite di memoria. È tutto gestito dal fornitore di contenuti. L'unico problema che ogni tanto devo affrontare è che non puoi fare alcune query complesse in ContentProviders. In questo caso è ancora possibile utilizzare query non elaborate e utilizzare l'interazione manuale vecchio stile con sqlite.
Se in precedenza hai scritto il tuo DbAdapter, Helper e Observer, puoi trasferirli in sicurezza sulle tue nuove app senza perdere tempo a convertire tutto in ContentProvider. Ma in base alla mia esperienza, consiglio vivamente di passare a ContentProvider. Ci vorrà del tempo per abituarsi, ma una volta che avrai acquisito esperienza, rimarrai con esso.
AGGIORNAMENTO 2017 Ora sono passato a Realm , un modo molto migliore per utilizzare i database su qualsiasi piattaforma. Trascorri qualche ora ad apprenderlo e risparmia innumerevoli ore nella tua carriera nello sviluppo di app.
Per impostazione predefinita, i fornitori di contenuti non sono thread-safe. Se hai più thread che utilizzano un provider di contenuti, puoi vedere molte eccezioni diverse generate e altre incongruenze nei dati. Il modo più semplice per risolvere questo problema è utilizzare la parola chiave sincronizzata su ciascuno dei metodi pubblici esposti dal provider di contenuti.
In questo modo solo un thread alla volta può accedere a questi metodi.
Ho la necessità nella nuova applicazione Serval Maps di importare dati da file binari nel database utilizzato internamente dall'applicazione. Per fare questo e giocare bene con il resto dell'applicazione è meglio:
Genera un nuovo thread per eseguire l'importazione in modo che gli altri thread non vengano influenzati negativamente, in particolare il thread responsabile dell'aggiornamento dell'interfaccia utente; e Pausa brevemente alla fine di ogni importazione per dare più possibilità agli altri thread che necessitano di utilizzare i metodi sincronizzati.
Il modo in cui funzionano i provider di contenuti in Android è fornire un livello di astrazione tra il resto del codice e il database sottostante. Ciò è dovuto principalmente al fatto, per quanto ne so, che i fornitori di contenuti possono accedere ai dati da luoghi diversi dai database.
Ciò significa che non è possibile eseguire query SQL non elaborate sul database sottostante ed è necessario specificare i vari componenti di una query SQL utilizzando variabili passate ai vari metodi come il metodo query. Se hai un'attività che non si adatta al modo in cui SQL viene gestito da un fornitore di contenuti, hai due opzioni:
Pensa lateralmente alla query, forse puoi ottenere i dati di cui hai bisogno con query alternative e accedendo ai risultati dal cursore; e Usa un URI per accedere normalmente ai dati e un URI speciale che viene abbinato a una query specifica per quelle attività che non hanno alternative.
I fornitori di contenuti vengono utilizzati quando desideri condividere i tuoi dati tra le applicazioni.
Se si dispone di un database collegato a un'applicazione e si desidera che un'altra applicazione utilizzi alcuni dati, è possibile implementare un fornitore di contenuti che esponga i dati
La differenza principale è: quando la tua app deve condividere informazioni con un'altra app, usa Content-Provider. SQLite archivia solo i dati per l'app che li crea
Ho letto questa risposta mentre cercavo lo stesso dubbio, quindi ho pensato di condividerlo. afferma -
È 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 utilizzi un ContentProvider puoi contenere tutte le modifiche strutturali al suo interno, dove come se non ne usassi uno, sei costretto a modificare tutte le aree del codice che sono interessate dalle modifiche 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.
Quindi, utilizzare un fornitore di contenuti sarebbe una buona idea.
Pensa a sistemi avanzati di gestione dei contenuti. Ogni oggetto (pagina, immagine, articolo di notizie, elemento di un evento, ecc.) Ha un contenuto, un indirizzo, autorizzazioni utente e modi per interagire con esso da diverse parti del sistema. I fornitori di contenuti lo fanno per Android. Ora puoi condividere file o immagini che potresti aver memorizzato nella tua applicazione. Puoi anche creare oggetti condivisibili personalizzati, come contatti di lavoro, note modificabili, ecc. E specificare la sicurezza e l'applicazione predefinita per gestire tali oggetti quando li apri da qualsiasi altra applicazione.
Una differenza è che i fornitori di contenuti hanno il supporto della piattaforma per gli osservatori di contenuti. Dovrai implementare il tuo pattern Observable per un database SQLite.