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)