安卓基本开发 （二）broadcast -contentProvider Service

广播

1. 系统级的消息通知机制
2. 广播可以在APP之间，APP内部，APP与系统之间传递
3. 分成广播发送者，和广播接收者
   • 发送者可以是APP，其它APP，或者系统
   • 接收者接收广播，不能进行耗时操作，否则引起ARN
4. 广播分为
   • 标准广播：多个接收方同时收到
   • 有序广播：多个接收方按优先级以此收到，且优先级高的可以截断广播
5. 为了安全性考虑，可以使用本地广播，只在APP内部传递

接收系统广播

1. 派生BroadcastReceiver
   • 重写 onReceive() 注意，不可进行耗时操作
   • 在AndroidManifest.xml种静态注册，由intent-filter指定接收的广播action
   • 或者在代码种动态注册registerReceiver，由IntentFilter指定接收的广播action
2. 接收系统网络状态变化的广播(可以动态注册，也可以静态注册)
   • android.net.conn.CONNECTIVITY_CHANGE
3. 接收系统启动的广播(只能静态注册)
   • android.intent.cation.BOOT_COMPLETED
   • 注意权限 android.permission.RECEIVE_BOOT_COMPLETED

发送和接收标准广播

1. 在APP1中发送广播
   • sendBroadcast
   • 借助Intent, 指定广播的action
2. 在APP2中接收广播
   • BroadcastReceiver->onReceive()
   • 动态或者静态注册，并设定广播action

发送和接收有序广播

1. 在APP1中发送广播
   • sendOrderedBroadcast
   • 借助Intent, 指定广播的action
2. 在APP1中接收广播
   • BroadcastReceiver->onReceive()
   • 动态或者静态注册，并设定广播action，设定优先级
   • 进行广播截断 abortBroadcast
3. 在APP2中接收广播
   • BroadcastReceiver->onReceive()
   • 动态或者静态注册，并设定广播action，设定优先级

发送和接收本地广播

1. LocalBroadcastManager
2. 在APP1中发送广播
   • sendBroadcast
   • 借助Intent, 指定广播的action
3. 在APP1中接收广播
   • BroadcastReceiver->onReceive()
   • 动态注册，并设定广播action

   • review

4. Broadcast 系统级的消息通知机制
5. 广播可以在APP之间，APP内部，APP与系统之间传递
6. 分成广播发送者，和广播接收者
   • 发送者可以是APP，其它APP，或者系统
   • 接收者接收广播，不能进行耗时操作，否则引起ARN
7. 广播分为
   • 标准广播：多个接收方同时收到
   • 有序广播：多个接收方按优先级以此收到，且优先级高的可以截断广播
8. 为了安全性考虑，可以使用本地广播，只在APP内部传递

ContentResolver

1. 使用其它APP提供的数据
2. getContentResolver
3. 类似对数据库进行CRUD的操作
   • 表名 换成 Uri

运行时权限 Android 6.0 之后

1. 普通权限 在AndroidManifest声明即可
2. 危险权限
   • 先在 AndroidManifest声明
   • 运行时请求用户授权ActivityCompat.requestPermissions
3. 检查权限 ContextCompat.checkSelfPermission
4. 授权结果回调 onRequestPermissionsResult
   • grantResults

ContentProvider

1. 向其它APP提供数据
2. 实际上后台还是在操作数据库
3. ContentProvider仅仅是提供一个隔离层
   • 所有的CRUD操作最终还是转给SQLiteDatabase

ContentResolver读取通讯录

1. 在通讯录中添加几条联系人的信息
2. 利用ContentResolver.query，查询通讯录的数据
3. 注意：运行时检查危险权限 ContextCompat.checkSelfPermission
   • 请求权限 ActivityCompat.requestPermissions
4. 把数据Log出来
5. 把数据显示到ListView (选做)

自定义ContentProvider

1. 在APP1中
   • 结合数据库操作，增加数据
   • 自定义ContentProvider
   • 在query中匹配uri，查询数据库，返回cursor
2. 在APP2中
   • 利用ContentResolver.query，查询APP1提供的数据
3. • 完善APP1中 CRUD的操作
   • 在APP2中测试 CRUD的操作

review

1. ContentResolver 使用其它APP提供的数据
   • 类似对数据库进行CRUD的操作 表名 换成 Uri
2. 运行时权限
   • 危险权限
   • 先在 AndroidManifest声明
   • 运行时请求用户授权ActivityCompat.requestPermissions
3. ContentProvider 向其它APP提供数据
   • ContentProvider仅仅是提供一个隔离层
   • 所有的CRUD操作最终还是转给SQLiteDatabase

Service

1. 可以把它简单的认为是没有界面的Activity
   • 没有UI
   • 没有用户交互
2. Service可由Activity启动 startService
   • 类似于启动Activity
   • 5.0之后只能显式启动
   • 停止服务 stopService
3. Service可以被启动多次
   • 但是只创建一次
   • 只要stopService一次，它就destory
4. Service有自己的生命周期
5. Service虽然没有UI界面
   • 实际上在UI主线程中运行
   • 耗时的操作仍然需要开启子线程

多线程 异步消息机制

1. 开启子线程比较简单
   • Thread
   • Runnable
2. 关键是子线程怎么和主线程通讯
   • 消息机制
   • Looper 维持一个死循环，分发消息
   • Message
   • MessageQueue
   • Handler 发送消息Message，处理消息

Service 与 Activity的通讯

1. Activity启动Service后，二者就失联了
2. 需要bindService，来将二者捆绑在一起
   • Activity ServiceConnection
   • Service Binder
   • 二者之间使用Binder来通讯
   • 解除绑定unBindService
3. Service可以被绑定多次
   • 只有都unBindService后，它才destory
4. 注意绑定的生命周期和启动的生命周期稍有不同

Service 的启动

1. 自定义Service, 在生命周期函数中打印日志
2. 在Activity中启动，停止
3. Activity传递数据给Service

多线程-异步消息处理机制

1. 消息发送与传递
2. 在主线程中开启子线程 Thread.start
3. 子线程完成一些耗时任务，可以用休眠来模拟
4. 主线程中显示数字 runOnUiThread
5. 子线程中发送消息 Handler.sendMessage
6. 主线程中处理消息 Handler.handlMessage

Service与Activity的通讯

1. 绑定二者
   • bindService
   • Binder
2. 在Service中
   • 开启线程，改变数据
   • 回调Activity
3. 在Activity中取得数据，并显示
4. 在Activity中再次启动Service的doBack (选做)