Broadcast和ContentProvider

廣播機制是一個典型的發佈-訂閱模式，也就是我們所說的觀察者模式。廣播機制的最大的特點就是接收雙方的完全耦合。廣播機制包含三個基本要素，分別是用於發送廣播的Broadcast、接收廣播的BroadcastReceiver以及用於傳遞信息的 Intent。廣播可分爲普通廣播、有序廣播、本地廣播和Sticky廣播。
有序廣播通過sendOrderedBroadcast()來發送，所有的廣播接收器按照優先級依次執行，廣播接收器的優先級通過receiver的intent-filter中的android:priority屬性來設置，數值越大優先級越高。當廣播接收器接收到廣播後，可以使用setResult函數來傳給下一個廣播接收器，然後通過getResult函數來取得上個廣播接收器返回的結果，並可以用abortBroadcast函數來讓系統丟棄該廣播，使該廣播不再傳送到別的廣播接收器。
本地廣播是在21版的Support v4中，也就是LocalBroadcastManager。使用該廣播能夠實現該廣播只在該應用內廣播，替換爲本地廣播的成本相對較低，爲了程序的安全性，建議在不需要其他進程接收廣播的情況下使用本地廣播。
粘性廣播通過sendStickyBroadcast函數來發送，用此函數發送的廣播會一直滯留，當有匹配此廣播接收器註冊後，該廣播接收器就會收到此條廣播。發送粘性廣播只保留最後一條廣播，並且一直保留下去，這樣即使已經有廣播接收器處理了該廣播，當再有匹配的廣播接收器被註冊時，此廣播仍會被接收。如果你只想處理一遍該廣播，可以通過removeStickyBroadcast函數來實現。
ContentProvider在android中的作用是對外共享數據，使用ContentProvider的好處是，統一了數據的訪問方式，它實際上是對SQliteOpenHelper的進一步封裝，通過Uri映射來判斷選擇需要操作數據庫中的哪個表，並進行增刪改查。
Uri主要包含了兩個部分信息，一是需要操作的ContentProvider，二是對ContentProvider中的哪個表進行操作。ContentProvider的scheme由android固定設置爲content://，Authority用於唯一標識這個ContentProvider，path就是要操作的數據庫表。如果要把字符串轉換成URI，可以使用Uri的parse函數。我們需要在ContentProvider中根據Uri建立關係映射，通過UriMatcher管理不同的Uri對應的Type類型，這個類型會在getType中被返回，當在ContentProvider中進行增刪改查時，就會根據這個類型選擇對應的數據表。
Uri的格式主要有兩種，以表名結尾就表示期望訪問該表的所有數據，以id結尾就表示期望訪問該表中擁有相應id的數據。我們可以使用通配符的方式來分別匹配這兩種格式的內容Uri，*表示匹配任意長度的任意字符，#表示匹配任意長度的數字。
創建表的sql語句舉例：create table table_name (id text primary key , business text , addr text)