Android应用程序的五大基本组件

 

2010-06-06 14:34 483人阅读 评论(0) 收藏 举报

5 Basic Components

1.          Activity

2.          Service

3.          Broadcast Receiver

4.          Content Provider

5.          Intent

 

Activity —— 应用表示层（ 基类 Activity ）

       应用程序中的每个屏幕都是通过继承和扩展基类 Activity 来实现的。

       同一应用中的每个 Activity 是相互独立的。程序启动后显示的第一幅画面是应用程序的第一个 Activity （默认窗口），而后可以根据需要从这个 Activity 启动另一个新的 Activity 。

       Activity 利用 View 来实现应用中的 GUI （用户直接通过 GUI 和应用程序做交互）。 Activity 窗口内的可见内容通过基类 View 提供。使用 Activity.setContentView() 方法设置当前 Activity 中的 View 对象。

l          每个 View 对象控制着窗口内的一个矩形空间；

l          View 是一种层次化结构， Parent View 中的布局属性会被子 View 继承；

l          位于 View 层次关系最底层的子 View 对象所代表的矩形空间就是跟用户进行交互的地方

 

Activity 状态回调：

l          onCreate

l          onStart

l          onRestart

l          onResume

l          onPause

l          onStop

l          onDestroy

 

Service —— 没有可见的用户界面，但能够长时间运行于后台（ 基类 Service ）

       运行于应用程序进程的主线程中，因此 Service 不会阻塞其他组件和用户界面。

       Service 是不能自己启动的，必须通过 Context 对象（如一个 Activity ）调用 startService 或 bindService 方法来启动（用这两种方法启动的 Service 的生命周期不同）。

1.          调用 startService 方法

a)          若 Service 没有启动，则首先会调用该 Service 的 onCreate 方法，然后再调用 onStart 方法。

b)         若 Service 已经启动，则会直接调用 onStart 方法

c)         该方法启动的 Service ，可以通过 Context 对象调用 stopService 来关闭，也可以通过 Service 自身调用 stopSelf() 或 stopSelfResult() 来关闭，关闭之前调用 onDestory 方法。

2.          调用 bindService 方法，使当前 Context 对象通过一个 ServiceConnection 的对象绑定到所指定的 Service

a)          若 Service 没有启动，则首先会调用该 Service 的 onCreate 方法初始化启动，然后调用 Service 的 onBind 方法初始化绑定。

b)         如果绑定 Service 的 Context 对象被销毁时，被绑定的 Service 也会调用 onUnbind 和 onDestroy 方法停止运行

c)         注意： BroadcastReceiver 是不能绑定服务的。

d)         一个绑定 Service 的 Context 对象还可以通过 unbindService() 来取消对服务的绑定。

e)          取消时， Service 会调用 unbind 方法，若 Service 是通过 bindService 来启动的，还会调用 onDestroy 方法来停止服务。

       Service 状态回调：

l          onCreate

l          onStart

l          onBind

l          onRebind

l          onUnbind

l          onDestroy

 

Broadcast Receiver —— 用户接收广播通知的组件（ 基类 BroadcastReceiver）

       Android 中的广播要么来自于系统，要么来自普通应用程序。

很多事件都可能导致系统广播，如手机所在时区发生变化，电池电量低，用户改变系统语言设置等。

来自普通应用程序，如一个应用程序通知其他应用程序某些数据已经下载完毕。

       为了响应不同的事件通知，应用程序可以注册不同的 Broadcast Receiver 。所有的 Broadcast Receiver 都继承自基类 BroadcastReceiver 。

       BroadcastReceiver 自身并不实现图形用户界面，但是当它收到某个通知后， BroadcastReceiver 可以启动 Activity 作为响应，或者通过 NotificationMananger 提醒用户。

       BroadcastReceiver 是对发送出来的 Broadcast 进行过滤接收并响应的一类组件。

 

       发送 Broadcast 信息

1.          把要发送的信息和用于过滤得信息 ( 如 Action 、 Category) 装入一个 Intent 对象

2.          调用 Context. sendBroadcast()、 sendOrderBroadcast() 、 sendStickyBroadcast() 方法，广播该 Intent 对象

3.          使用 sendBroadcast() 或 sendStickyBroadcast() 方法发出去的 Intent ，所有满足条件的 BroadcastReceiver 都会随机地执行其 onReceive() 方法；

4.          而 sendOrderBroadcast() 发出去的 Intent ，会根据 BroadcastReceiver 注册时 IntentFilter 设置的优先级的顺序来执行，相同优先级的 BroadcastReceiver 则是随机执行

5.          sendStickyBroadcast() 方法主要的不同是， Intent 在发送后一直存在，并且在以后调用 registerReceiver() 注册相匹配的 Intent 时会把这个 Intent 直接返回。

6.          若在使用 sendBroadcast() 方法时指定了接收的权限，这只有在 AndroidManifest.xml 中用 <uses-permission> 标签声明了拥有此权限的 BroadcastReceiver 才会有可能接收到发送来 Broadcast 。

7.          若在注册 BroadcastReciever 时，指定了可接收的 Broadcast 的权限，则只有在包内的 AndroidManifest.xml 中用 <uses-permission> 标签声明了，拥有此权限的 Context 对象所发送的 Broadcast 才有可能被这个 BroadcastReceiver 所接收。

接收 Broadcast 消息

1.          继承 BroadcastReceiver 类，并实现 onReceive 方法

2.          注册 Broadcast Receiver （有 2 种方法：一种方法是，静态地在 AndroidManifest.xml 中用 <receiver> 标签声明，并在标签内用 <intent-filter> 标签设置过滤器； 另一种方法，动态地在代码中先定义并设置好一个 IntentFilter 对象，然后再需要注册的地方调用 Context.registerReceiver() 方法） （取消注册时，调用 Context.unregisterReceiver() 方法）

 

Content Provider —— 为解决应用程序间数据通信、共享的问题（ 基类 ContentProvider）

       在 Android 中，每个应用程序都是用自己的用户 ID 并在自己的进程中运行。这样的好处是，可以有效地保护系统及应用程序，避免被其他不正常德应用程序所影响，每个进程都拥有独立的进程地址空间和虚拟空间。

       Content Provider 可以将应用程序特定的数据提供给另一个应用程序使用。其数据存储方式可以是 Android 文件系统、 SQLite 数据库或者其他合理的方式。

       当数据需要在应用程序间共享时，我们就可以利用 ContentProvider 为数据定义一个 URI 。之后，其他应用程序对数据进行查询或者修改时，只需要从当前上下文对象获得一个 ContentResolver, 然后传入响应的 URI 就可以了。

       Content Provider 继承自基类 ContentProvider ，并且实现了一组标准接口。通过这组接口，其他应用程序能对数据进行读写和存储。然而，需要使用数据的应用程序并不是直接调用这组方法，而是通过调用ContentResolver 对象的方法来完成。 ContentResolver 对象可以与任意 ContentProvider 通信。

       要为当前应用程序的私有数据定义 URI ，就需要专门定义一个继承自 ContentProvider 的类，然后根据不同的操作调用的方法去实现这些方法的功能。

       ContentResolver 类为应用程序提供了接入 Content 机制的方法。要构造一个 ContentResolver 对象可以为构造方法 ContentResolver(Context context) 传入一个 Context 对象，也可以直接通过 Context 对象调用 getContentResolver() 方法获得 —— 有的 ContentResolver 对象后，就可以通过调用其 query() 、 insert() 、 update() 等方法来对数据进行操作了。

 

一旦需要以上 4 种 Android 应用程序基本组件完成请求， Android 会首先确认该组件所在进程是否运行，如果没有运行， Android 将先启动进程，同时确认被请求组件的实例是否存在，否则将创建一个新的组件实例。

 

Intent —— 连接组件的纽带

       以上 4 种基本组件中，除了 Content Provider 是通过 Content Resolver 激活外，其他 3 种组件 Activity 、 Service 和 Broadcast Receiver 都是由 Intent 异步消息激活的。

       Intent 在不同的组件之间传递消息，将一个组件的请求意图传给另一个组件。因此， Intent 是包含具体请求信息的对象。

针对不同的组件， Intent 所包含的消息内容有所不同，且不同组件的激活方式也不同， 且不同类型组件有传递 Intent 的不同方式。

       Intent 是一种运行时绑定（ runtime binding ）机制，它能够在程序运行的过程中连接两个不同的组件。通过 Intent ，你的程序可以向 Android 表到某种请求或者意愿， Android 会根据意愿的内容选择适当的组件来处理请求。

l          激活一个新的 Activity ，或者让一个现有的 Activity 执行一个新的操作，可以通过调用如下两种方法 ( 这两汇总方法需要传入的 Intent 参数称为 Activity Action Intent) ：

1.          Context.startActivity()

2.          Activity.startActivityForResult()

l          启动一个新的服务，或者向一个已有的服务传递新的指令，可以调用如下两种方法：

1.          Context.startService()

2.          Context.bindService()

l          发送广播 Intent( 所有已注册的拥有与之相匹配 IntenFilter 的 BroadcastReceiv 就会被激活 ) ，可以调用如下三种方法：

1.          Context.sendBroadcast()

2.          Context.sendOrderBroadcast()

3.          Context.sendStickBroadcast()

Intent 一旦发出， Android 都会准确找到相匹配的一个或多个 Activity 、 Service 或 BroadcastReceiver 作响应。所以，不同类型的 Intent 消息不会出现重叠， BroadcastIntent 消息只会发送给 BroadcastReceiver ，而绝不可能发送给 Activity 或 Server 。有 startActivity() 传递的消息也只可能发送给 Activity ，由 startService() 传递的 Intent 只可能发送给 Service 。

 

       Intent 对象抽象地描述了执行操作， Intent 的主要组成部分；

1.          目标组件名称。 [ 可选项 ]

a)          组件名称是一个 ComponentName 对象，是目标组件类名和目标组件所在应用程序包的组合

b)         组件中的包名不一定要和 manifes 文件中包名完全匹配

c)         如果 Intent 消息中指明了目标组件的名称，这就是一个显示消息， Intent 会传递给指明的组件。

d)         如果目标组件名称并没有指定， Android 则通过 Intent 内的其他信息和已注册的 IntentFilter 的比较来选择合适的目标组件

2.          Action [ 隐式比较 ]

a)          描述 Intent 所触发动作的名字字符串。

b)         理论上 Action 可以为任何字符串，而与 Android 系统应用有关的 Action 字符串以静态字符串常量的形式定义在了 Intent 类中。

3.          Data [ 隐式比较 ]

a)          描述 Intent 要操作的的数据的 URI 和数据类型。

b)         正确设置 Intent 的数据对于 Android 寻找系统中匹配 Intent 请求的组件很重要。

4.          Category [ 隐式比较 ]

a)          是对被请求组件的额外描述信息。

b)         Android 也在 Intent 类中定义了一组静态字符串常量表示 Intent 不同的类别。

5.          Extra

a)          当我们使用 Intent 连接不同组件时，有时需要在 Intent 中附加额外的信息，以便将数据传递给目标 Activity 。

b)         Extra 用键值对结构保存在 Intent 对象当中， Intent 对象通过调用方法 putExtras() 和 getExtras() 来存储和获取 Extra

c)         Extra 是以 Bundle 对象的形式来保存的， Bundle 对象提供了一系列 put 和 get 方法来设置、提取相应键值信息。

d)         在 Intent 类中同样为 Android 系统应用的一些 Extra 的键值定义了静态字符串常量。

6.          Flag

 

决定 Intent 目标组件的因素：

n          在显式 Intent 消息中，决定目标组件的唯一要素就是组件名称（不用再定义其他 Intent 内容）

n          而隐式 Intent 消息中，由于没有目标组件名称，所以必须由 Android 系统帮助应用程序寻找与 Intent 请求意图最匹配的组件。

n          隐式 Intent 消息中目标组件具体选择方法是： android 将 Intent 的请求内容和一个叫做 IntentFilter 的过滤器比较， IntentFilter 中包含系统中所有可能的待选组件。如果 IntentFilter 中某一个组件匹配隐式 Intent 请求内容，那么 Android 就选择该组件作为该隐式 Intent 的目标组件。

 

IntenFilter

       应用程序的组件为了告诉 Android 自己能响应、处理哪些隐式 Intent 请求，可以声明一个甚至多个 IntentFilter 。

       每个 IntentFilter 描述该组件所能响应 Intent 请求的能力 —— 组件希望接收什么类型的请求行为，什么类型的请求数据。

       隐式 Intent 和 IntentFilter 进行比较时的三要素： Action 、 Data 、 Category 。

       一个隐式 Intent 请求要能够传递给目标组件，必需通过以上三个方面的检查。如果任何一方面不匹配， Android 都不会将该隐式 Intent 传递给目标组件。

       <intent-filter>

              <action android:name=””/>

              <category android:name=””/>

              <data android:type=”” android:scheme=”” android:authority=”” android:path=””/>

       </intent-filter>

1.          动作测试

a)          一条 <intent-filter> 中至少应该包含一个 <action>, 否则任何 Intent 请求都不能和该 <intent-filter> 匹配。

b)         如果 IntentFilter 中没有包含任何 Actino 类型，那么无论什么 Intent 请求都无法和这条 IntentFilter 匹配。

c)         如果 Intent 请求中没有设定 Action 类型，那么只要 IntentFilter 中包含有 Action 类型，这个 Intent 请求将顺利通过 IntentFilter 的测试。

2.          类别测试

a)          只有当 Intent 请求中所有的 Category 与组件中的某一个 IntentFilter 的 category 完全匹配，才会让该 Intent 请求通过测试， IntentFilter 中的多余 category 声明并不会导致匹配失败。

b)         一个没有指定任何类别的 IntentFilter 仅仅只会匹配没有设置类别的 Intent 请求。

3.          数据测试

a)          <data> 元素指定了希望接受的 Intent 请求的数据 URI 和数据类型： URI 被分成三部分类进行匹配， scheme 、 authority 和 path.

b)         使用 setData 设定的 Intent 请求的 URI 数据类型和 scheme ，必须与 IntentFilter 中指定的一致

若 IntentFilter 中还指定了 authority 或 path ，他们也需要相匹配才会通过测试。