2010-07-28 120 views
76

我已經完成了針對Android的SQLite數據庫編程,但是我不知道 Content-Provider除此之外的任何內容:「正如我所提到的Android Developer page,Android SDK解釋」內容提供者「,因爲它用於存儲和檢索數據。」「內容提供者」和「SQLite數據庫」之間的確切區別

但隨後,

  1. 是什麼「內容提供者」和「SQLite數據庫」之間的確切區別?
  2. 哪個最好存儲數據?

任何示例或幫助!

回答

122

我發現一個重大差異的數據內容提供商,內容如下:

將數據存儲在數據庫中是保存數據的一種好方法,但Android中創建的Android數據庫只有創建它們的應用程序需要visible。也就是說,一個應用程序在Android上創建的SQLite數據庫只能由該應用程序使用,而不能由其他應用程序使用。

所以,如果你need to share data between applications, you need to use the content provider model as recommended in Android.本文介紹了內容提供者的基本知識以及如何實現它。

我發現這篇文章在提供了這個link

非常好的信息。

+2

似乎現在鏈接已經死了......再也看不到這篇文章了。希望看到您正在參考的文章,如果再次找到它。 – prolink007 2012-01-23 02:32:49

+0

於2012年2月11日鏈接[http://www.devx.com/wireless/Article/41133](http://www.devx.com/wireless/Article/41133)作品, – k3b 2012-02-11 05:25:31

+0

如果我們提供機制以線程安全的方式跨多個應用程序共享數據的過程? – Manohar 2012-07-13 11:46:14

50

「Content-Provider」和「SQLite Database」之間的確切區別是什麼?

ContentProvider是一個外觀 - 一個API,您可以實現將數據庫公開給其他進程的API。它可以以數據存儲在SQLite數據庫的方式實現,但它不一定是。

哪個最好存儲數據?

這是不可能在摘要中回答的。一般來說,除非需要您使用ContentProvider,否則只需使用數據庫即可。

+25

我更喜歡使用ContentProvider,因爲它是一個非常好的SQL抽象。您還可以玩CursorAdapter和自動重新查詢。 – alexanderblom 2010-07-28 07:03:12

5

當您希望跨應用程序共享您的數據時使用內容提供程序。

如果連接與應用程序數據庫,並且希望其他應用程序中使用的一些數據,可以實現暴露

3

主要區別在於:當您的應用程序需要將信息共享到其他應用程序時,請使用Content-Provider。 SQLite只爲創建它的應用程序存儲數據

21

我已經制作了許多優秀的應用程序,使用它們的成千上萬的用戶只使用SQLite方法。但是那是前一陣子,我不得不手動編寫很多代碼,現在很容易被ContentProvider處理。當時我並不贊成使用Content Providers,因爲它似乎只會增加代碼的複雜性。

但是在過去的幾年裏,隨着Android的發展,我已經轉向ContentProvider,因爲它節省了時間,並且可以讓您做更多。我現在廣泛使用它。一旦你寫了一個Content Provider類,你的生活就變得容易了。使用ContentProvider,我可以輕鬆處理光標加載器,加載器回調和批量插入,我不得不在過去手動編寫所有內容,但仍然無法高效工作。特別是在更新列表視圖時,由於只有一個notifychange()方法,現在自動更新列表視圖。這意味着現在我不必鍵入我自己的偵聽器並手動更新列表視圖和適配器中的內容。另外,我不需要擔心數據庫的打開和關閉,或者擔心內存泄漏。這一切都由內容提供商處理。我偶爾遇到的唯一問題是您無法在ContentProviders中執行一些複雜的查詢。在這種情況下,您仍然可以使用原始查詢並使用與sqlite的舊式手動交互。

如果您以前編寫過自己的DbAdapter,Helper和Observer,那麼您可以安全地將它們帶到新的應用程序,而無需花費時間將所有內容轉換爲ContentProvider。但基於我的經驗,我強烈建議轉移到ContentProvider。需要一段時間才能習慣它,但一旦你有了它的經驗,你會保持它。

UPDATE 2017年 我現在已經切換到境界,一個更好的方法在任何平臺上使用的數據庫。花幾個小時學習它,並在您的應用程序開發生涯中節省數不清的時間。

+0

我正在考慮將我的代碼轉換爲內容提供者,但現在我想保留它。 – 2014-03-16 14:11:33

+0

現在你也可以添加Android的'房間'庫 – 2018-02-07 06:23:31

8

1.內容提供商不是線程安全

默認情況下,內容提供商不是線程安全的。如果你有多個使用內容提供者的線程,你可以看到拋出了許多不同的異常和其他數據不一致。解決這個問題的最簡單方法是在內容提供者公開的每個公共方法上使用synchronized關鍵字。

這樣一次只有一個線程可以訪問這些方法。做大量的寫

我在新的藪貓地圖應用程序需要進口從二進制文件數據到應用程序內部使用的數據庫的時候

2.發揮好。爲了做到這一點,並與其他應用程序一起玩,最好是:

產生一個新線程來進行導入,以便其他線程不會受到負面影響,特別是負責更新UI的線程;和 在每次導入結束時暫停一下,以使其他線程需要使用同步方法的機會更多。

3。內容提供者強制你有時側重思考

Android內容提供者的工作方式是在代碼的其餘部分和底層數據庫之間提供一個抽象層。這主要是因爲,據我所知,內容提供者可以從數據庫以外的地方訪問數據。

這意味着您無法在底層數據庫上執行原始SQL查詢,並且需要使用傳遞給各種方法(如查詢方法)的變量來指定SQL查詢的各個組件。如果您的任務不符合內容提供商處理SQL的任務,您有兩種選擇:

側重考慮查詢,也許您可​​以通過備選查詢獲取所需的數據並訪問遊標的結果;和 使用URI來正常訪問數據,並使用與特定查詢相匹配的特殊URI來查找那些沒有替代方法的任務。

2

我讀this answer同時尋找同樣的疑問,所以想到分享它。 它聲明 -

對您的數據提供額外的抽象級別以便更易於在內部進行更改是一種好的做法。如果您決定稍後更改底層數據庫結構會怎麼樣?如果您使用ContentProvider,則可以包含其中的所有結構更改,就像不使用它一樣,您將被迫更改受結構更改影響的代碼的所有區域。此外,能夠重複使用相同的標準API來訪問數據,而不是通過對數據庫的低級訪問來亂拋垃圾的代碼是很好的。

因此,使用內容提供商將是一個好主意。

3

想想高級內容管理系統。每個對象(頁面,圖像,新聞文章,事件項目等)都有一個內容,一個地址,用戶權限以及與系統不同部分進行交互的方式。內容提供商爲Android做到這一點。您現在可以共享您可能已存儲在應用程序中的文件或圖像。您還可以創建自定義可共享對象,如業務聯繫人,可編輯筆記等。並指定安全性和默認應用程序來處理此類對象時,從任何其他應用程序中打開它們。

+0

這是一個好點! – 2015-06-29 05:02:11

相關問題