学习是最好的投资!
不好意思,又自問自答了。這個問題我已經在程式碼層面解決,解決方案是:
如果ContentProvider的update、insert、delete會影響到UI的顯示,那程式碼中就不能直接操作DB了,而應該統一使用ContentProvider,同時需要註冊ContentObserver進行Uri的監聽,以便切換UI。
如果ContentProvider的操作不會影響UI,那就無所謂了。內部直接操作DB也是可以的。
根據ContentProvider定義,它是在不同應用中進行資料交換的標準API,當一個應用需要把資料暴露給其他應用時可以使用它,而其他應用可以透過ContentResolver去操作暴露的數據,透過ContentProvider暴露自己的資料操作接口,其他應用就可以透過此接口進行對應的增刪改查操作。但透過ContentResolver操作本質就是呼叫了ContentProvider的操作,而其中的操作使用的還是SQLiteOpenHelper的db。所以個人認為不需要重寫,不過這也是個人觀點,還是要自己去試試看就知道結果了。
應該是的,直接透過資料寫的資料是應用私有數據,其他應用程式無法訪問,不過如果DB檔案在SD卡裡面進行操作就好像可以存取。
不好意思,又自問自答了。這個問題我已經在程式碼層面解決,解決方案是:
如果ContentProvider的update、insert、delete會影響到UI的顯示,那程式碼中就不能直接操作DB了,而應該統一使用ContentProvider,同時需要註冊ContentObserver進行Uri的監聽,以便切換UI。
如果ContentProvider的操作不會影響UI,那就無所謂了。內部直接操作DB也是可以的。
根據ContentProvider定義,它是在不同應用中進行資料交換的標準API,當一個應用需要把資料暴露給其他應用時可以使用它,而其他應用可以透過ContentResolver去操作暴露的數據,透過ContentProvider暴露自己的資料操作接口,其他應用就可以透過此接口進行對應的增刪改查操作。但透過ContentResolver操作本質就是呼叫了ContentProvider的操作,而其中的操作使用的還是SQLiteOpenHelper的db。所以個人認為不需要重寫,不過這也是個人觀點,還是要自己去試試看就知道結果了。
應該是的,直接透過資料寫的資料是應用私有數據,其他應用程式無法訪問,不過如果DB檔案在SD卡裡面進行操作就好像可以存取。