Android Intents和Intent过滤器(二)

86 阅读 0 评论 57 点赞

我是靠谱客的博主缓慢小刺猬，最近开发中收集的这篇文章主要介绍Android Intents和Intent过滤器(二)，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

Intent对象解析

Intent能够被分成两组：

1. 用组件的名称把Intent对象明确的指向目标组件（在Intent对象的组件名字段指定目标组件名）。因为一般情况下其他应用的开发者不会了解目标组件的名字，所以通常针对应用程序的内部消息使用明确命名的Intent对象，如一个Activity启动一个下属服务或启动一个姊妹Activity。

2. 没有命名目标（Intent对象的组件名字段是空的）的隐式的Intent对象。隐式的Intent对象经常被用于激活其他应用程序中的组件。

Android系统把一个明确命名的Intent对象发送给目标类的一个实例。除了组件名以外，不再用Intent对象内任何其他信息来判断哪个组件应该获得这个Intent对象。

对于隐式的Intent对象，需要不同的分类。在缺少目标组件的情况下，Android系统必须查找最适合的组件（一个能够执行请求动作的Activity或Service，或者是一组能够响应广播通知的Broadcast Receiver）来处理这个Intent对象。系统通过把Intent对象的内容跟Intent过滤器比较，跟组件的结构关联就能够潜在接收Intent对象。过滤器会公开组件的能力和它能够处理的Intent对象限制。它们打开组件接收可能的公开类型的隐式Intent对象。如果组件没有任何过滤器，那么它仅能接收明确命名的Intent对象。带有过滤器的组件能够接收命名和匿名的Intent对象。

Intent过滤器会参考Intent对象以下三个方面来检测是否接收这个Intent对象：

1. 动作（action）

2. 数据（URI和数据类型）

3. 分类（category）

附加信息（extras）和标记（flags）不作为判断哪个组件接收这个Intent对象标准。

Intent过滤器

Intent过滤器是用来通知系统它们能够处理那种类型隐式的Intent对象，Activity、Service、Broadcast Receiver能够有一个或多个Intent过滤器。每个过滤器都描述了组件的一种能力，说明了组件将会接受的Intent对象集。它滤如有效的期望类型的Intent对象，滤出不想要的Intent对象---但是仅是不想要的隐式Intent对象（那些没有命名目标类的Intent对象）。一个有明确命名的Intent对象总是包被发送给它的目标类的实例，而不管它包含了什么；过滤器不起作用。但是隐式的Intent对象仅能发送给能够通过组件的一个过滤器来传递它的一个组件。

对于组件能够做的每项工作，它都会有一个独立的过滤器，并且每一工作都能够展现给用户。例如，实例应用Note Pad应用程序的NoteEditor Activity就有两个过滤器---一个是用于启动带有用户能够查看或编辑的特定注释信息的过滤器；另一个是用于启动一个新的，用户能够填充和保存的空白注释过滤器。（Note Pad的所有过滤器在“Note Pad示例”一节中介绍）

一个Intent过滤器是IntentFilter类的实例。但是因为Android系统在它启动组件之前必须了解有关组件的能力，所以Intent过滤器通常都不是用Java代码来建立的，而是在应用程序的清单文件（AndroidManifest.xml）中用<intent-filter>元素来声明。（通过调用Context.registerReceiver()方法来动态注册的Broadcast Receiver是一个例外，它们直接创建IntentFilter对象做为过滤器。）

过滤器有类似于Intent对象的动作、数据、和分类的字段，过滤器会用这三个域来检测一个隐式的Intent对象。对于要传递给拥有过滤器的组件的Intent对象，必须传递所有的这三个要检测的字段。如果其中之一失败了，Android系统也不会把它发送给对应的组件---至少在基于那个过滤器的基础上不会发送。但是，因为一个组件能够有多个Intent过滤器，即使不能通过组件的一个过滤器来传递Intent对象，也可以使用其他的过滤器。

以下详细说明对三个域的检测

1. 动作域检测

在清单文件中的<intent-filter>元素内列出对应动作的<action>子元素。如：

<intent-filter . . . >
<action android:name="com.example.project.SHOW_CURRENT" />
<action android:name="com.example.project.SHOW_RECENT" />
<action android:name="com.example.project.SHOW_PENDING" />
. . .
</intent-filter>

像上例显示的那样，一个Intent对象就是一个命名动作，一个过滤器可以列出多个动作。这个列表不能是空的，一个过滤器必须包含至少一个<action>元素，否则它会阻塞所有的Intent对象。

要通过这个检测，在Intent对象中指定的动作必须跟这个过滤器的动作列表中动作一致匹配。如果Intent对象或过滤器没有指定的动作，会产生以下结果：

A. 如果对列表中所有动作都过滤失败，那么对于要匹配的Intent对象不做任何事情，而且所有的其他Intent检测都失败。没有Intent对象能够通过这个过滤器；

B. 另一方面，没有指定动作的Intent对象会自动的通过检测---只要这个过滤器包含至少一个动作。

2. 分类域检测

<intent-filter>元素也要列出分类作为子元素。例如：

<intent-filter . . . >
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
. . .
</intent-filter>

注意，对于清单文件中的动作和分类没有使用早先介绍的常量，而是使用了完整字符串值来替代。例如，上例中“android.intent.category.BROWSABLE”字符串对应本文档前面提到的CATEGOR_BROWSABLE常量。类似的“android.intent.action.EDIT”字符串对应ACTION_EDIT常量。

对于一个要通过分类检测的Intent对象，在Intent对象中每个分类都必须跟过滤器中的一个分类匹配。过滤器能够列出额外的分类，但是它不能忽略Intent对象中的任何分类。

因此，原则上一个没有分类的Intent对象应该始终通过这个检测，而不管过滤器中声明的分类。大多数情况都是这样的，但是，有一个例外，Android处理所有传递给startActivity()方法的隐式Intent对象，就像它们至少包含了一个“android.intent.category.DEFAULT(对应CATEGORY_DEFAULT常量)”分类一样。因此接收隐式Intent对象的Activity必须在它们的Intent过滤器中包含“android.intent.category.DEFAULT”分类。（带有“android.intent,action.MAIN”和“android.intent.category.LAUNCHER”设置的过滤器是个例外。因为它们把Activity标记为新任务的开始，并且代表了启动屏。它们能够在分类列表中包含“android.intent.category.DEFAULT”，但是不需要。）

3. 数据域检测

像动作分类检测一样，针对Intent过滤器的数据规则也要包含在一个子元素中，并且，跟动作和分类的情况一样，这个子元素也能够出现多次，或者不出现。例如：

<intent-filter . . . >
<data android:mimeType="video/mpeg" android:scheme="http" . . . />
<data android:mimeType="audio/mpeg" android:scheme="http" . . . />
. . .
</intent-filter>

每个<data>元素能够指定一个URI和一个数据类型（MIME媒体类型）对于每个URI部分都会有独立的属性---scheme、host、port、path：scheme://host:port/path

例如，以下URI：

content://com.example.project:200/folder/subfolder/etc

scheme是content，host是“com.example.project”，port是“200”，path是“folder/subfolder/etc”。host和port一起构成了URI授权，如果没有指定host，那么port也会被忽略。

这些属性是可选的，但是，它们不是彼此独立的，如一个授权意味着必须指定一个scheme，一个path意味着必须指定scheme和授权。

当Intent对象中的URI跟过滤器的一个URI规则比较时，它仅比较在过滤器总实际提到的URI部分。如，如果一个过滤器仅指定了一个scheme，那么带有这个scheme的所有的URIs都会跟这个过滤器匹配。如果一个过滤器指定了一个scheme和授权，但是没有路径，那么带有相同scheme和授权的所有URIs的Intent对象都会匹配，而不管它们的路径。如果一个过滤器指定了一个scheme、授权、和路径，那么就只有相同的scheme、授权和路径Intent对象才会匹配。但是，在过滤器中的路径规则能够包含只要求路径部分匹配的通配符。

<data>元素的type属性指定了数据的MIME类型。它在过滤器中比URI更共同。对于子类型域，Intent对象和过滤器都能够使用“*”通配符---例如，“text/*”或“audio/*”指明可以跟任意子类型匹配。

数据检测会比较Intent对象和过滤器中的URI和数据类型。规则如下：

A．只有过滤器没有指定任何URI或数据类型的情况下，既没有URI也没有数据类型的Intent对象才能通过检测；

B．一个包含URI但没有数据类型的Intent对象（并且不能从URI中推断出数据类型）只有跟过滤器中的一个URI匹配，并且同样这个过滤器没有指定数据类型时，才能通过检测。这种情况仅针对不指向实际数据的URIs，如mailto:和tel:。

C．一个包含了数据类型但不没有URI的Intent对象，只有过滤器也列出相同的数据类型，并也没有指定URI的情况下，才能通过检测。

D．包含了URI和数据类型的Intent对象（或者是数据类型能够从URI中推断出来）只有它的类型跟过滤器中列出的一个类型匹配，才能通过数据类型部分的检测，如果它的URI部分跟过滤器中的一个URI匹配或者Intent对象有一个content:或file:URI并且过滤器没有指定URI，那么才能能够URI部分的检测。换句话说，如果过滤器仅列出了数据类型，那么一个组件被假设为支持content:和file:数据。

如果一个Intent对象能够通过多个过滤器传递给一个Activity或Service，那么可以询问用户要激活哪个组件。如果没有找到目标，就会产生一个异常。

常见情况

以上数据检测规则中的最后一条（规则d），反映了组件能够获得从文件或内容提供器中获取本地数据的期望。因此，它们的过滤器能够只列出数据类型，并且不需要明确的命名content:和file:方案。这是一种典型的情况。例如，像下面的<data>元素那样，告诉Android，组件能够从一个内容提供器中获取图片并显示它：<data android:mimeType="image/*" />

因为大多数有效的数据是通过内容提供器来配发的，所以，指定一个数据类型但没有URI的过滤器或许是最常见的。

另一个常见的配置是带有方案和数据类型的过滤器。例如，像下面这样的<data>元素会告诉Android组件能够从网络上获取视频并显示它。

例如，我们来研究一下当用户点击一个网页上的一个链接时，浏览器应用程序要做的事情。首先，它会试着来显示数据（如果这个链接是一个HTML页，那么就显示）。如果不能显示这个数据，那么就会把方案和数据类型一起放到一个隐式Intent对象中，并试着启动一个能够做这项工作的Activity，如果没有接受者，它就会要求下载管理器来下载数据。然后把数据放在一个内容提供器的控制之下，以便一个潜在的更大的Activity池（那些只带有命名数据类型的过滤器）能够响应。

大多数应用程序都有不引用任何特殊数据就启动刷新的方法。能够初始启动应用程序的Activity都有带有“android.intent.action.MAIN”作为指定动作的过滤器。如果它们代表了在应用程序中的启动器，那么它们也要指定“android.intent.category.LAUNCHER”分类：

<intent-filter . . . >
<action android:name="code android.intent.action.MAIN" />
<category android:name="code android.intent.category.LAUNCHER" />
</intent-filter>

使用Intent对象进行匹配

Intent对象跟过滤器匹配不仅是要发现要激活的目标组件，而且也发现设备上有关组件集的一些事情。例如，Android系统通过查找所有的拥有指定的“android.intent.action.MAIN”动作和“android.intent.category.LAUNCHER”分类的过滤器的Activity，把它们填充到应用程序的启动器，把用户启动的有效的应用程序显示在屏幕的顶层，然后显示启动器中的那些Activity的图标和标签。类似地，系统通过查找它的过滤中带有“android.intent.category.HOME”的Activity来发现主屏界面。

应用程序能够用于Intent对象匹配的是组类似的方法。PackageManager类中有一组query…()方法，它们返回能够接受一个特殊Intent对象的所有组件，并且还有一组类似的resolve…（）方法，用来判断响应一个Intent对象的最好组件。例如，queryIntentActivities()方法返回一个能够执行这个Intent对象要求动作的所有Activity；queryIntentServices()方法类似地返回Service列表。这些方法都不激活组件，它们只是列出能够响应这个Intent对象的所有组件。对于Broadcast Receiver也有类似的方法：queryBroadcastReceivers()。