Contains notes on

Intents
Intent Filters
Categories
Intent Filter Rules
Old references on Intents
API references

satya - Wednesday, August 11, 2010 10:28:02 AM

On Pending Intents

On Pending Intents

A brief research note on pending intents. There is not much in here. I have included here for completeness.

satya - Wednesday, August 11, 2010 10:33:10 AM

Previous notes on intents, Sept 2008

Previous notes on intents

My very first research notes on intents. Lot of material with cross links, questions, code samples, just plain walk-around (meander)

satya - Wednesday, August 11, 2010 10:43:56 AM

Rough draft of an old chapter on intents

Rough draft of an old chapter on intents

This includes some topics on intent that was left out from the recent chapters.

satya - Wednesday, August 11, 2010 1:02:32 PM

Google List of Intents

Google List of Intents

You will see here how to invoke

Browser
Map
Dialer
Google Street View

satya - Wednesday, August 11, 2010 1:04:34 PM

NotePad Sample application from the SDK

NotePad Sample application from the SDK

You can examine here how intents are used with in the notepad application.

satya - Wednesday, August 11, 2010 1:05:41 PM

Lets see whats new here

http://www.openintents.org/

satya - Wednesday, August 11, 2010 1:07:47 PM

You can download a sample project to test intents from here

You can download a sample project to test intents from here

From the list look for a project called "ProAndroid3_ch05_TestIntents.zip"

satya - Wednesday, August 11, 2010 1:16:09 PM

Here is what goes into a 'data' element

Here is what goes into a "data" element fo the intent filter

You will know here that the data element of an intent filter contains

host
mimetype
pathPattern
pathPrefix
port
scheme

satya - Wednesday, August 11, 2010 1:18:21 PM

Exampels


<intent-filter . . . >    
<data android:scheme="something" android:host="project.example.com" />    
. . .
</intent-filter>

<intent-filter . . . >    
   <data android:scheme="something" />    
   <data android:host="project.example.com" />    
   . . .
</intent-filter>

satya - Thursday, August 19, 2010 10:12:13 AM

Basic rule for matching intents

An incoming intent's action, category and data characteristics MUST match (or present) those specified in the intent filter. An intent filter, unlike an intent, can specify multiple actions, categories, and data attributes. This means same intent filter can satisfy multiple intents. This means an activity can respond to vary many intents. However the meaning of "match" differs among actions, data attributes, and categories. This require elboration.

satya - Thursday, August 19, 2010 10:14:03 AM

Action

if an intent filter doesn't define an action, then that intent filter is a match for any incoming intent action. If one or more actions are specified in the intent filter then at least one of the actions must match the incoming intents action.

Stated from an intents perspective, if an intent has an action on it, the intent filter must have that action as part of its action list or not have any actions at all.

satya - Thursday, August 19, 2010 10:15:56 AM

data in general

if no data characteristis are specified in an intent filter it does not match an incoming intent that carries any data or data attribute. This means it will only look for intents that have "no data" specified at all.

lack of data and lack of action (in the filter) works the opposite. If no action, then every thing is a match. if no data, then every data in the intent is a mismatch.

satya - Thursday, August 19, 2010 10:21:15 AM

data type

The incoming intents data type must be one of the data types that is specified in the intent filter. The data type must be present in the intent filter.

The incoming intents data type is determined in one of two ways. It is a content uri or a file uri. in which case the content provider or android will figure out the type. The second way is to look at the "explicit" data type of the intent. For this to work the incoming intent should not have a data uri set. This is automatically taken care of when "setType" is called on the intent.

Android also allows as part of its mime type specification to have a "*" as its subtype to cover all possible sub types.

The data type in addition is case sensitive.

satya - Thursday, August 19, 2010 10:22:47 AM

data scheme

the incoming intent data scheme must be one of the specified in the intent filter. In other words the incoming data scheme must be present in the intent filter.

The incoming intents scheme is the first part of the data uri. On an intent there is no method to set the scheme. It is purely derived from the intent data uri that looks like "http://www.somesite.com/somepath".

The scheme in addition is case sensitive.

satya - Thursday, August 19, 2010 10:23:25 AM

data authority

no authorities in the filter means a match. If an authority is specified in the filter, ex: www.somesite.com, then one scheme and one authority should match the incomign intents data uri.

In otherwords if we say "www.somesite.com" in the intent filter and the scheme as "https" then it will fail to match the "http://www.somesite.com/somepath".

The authority in addition is case sensitive.

satya - Thursday, August 19, 2010 10:24:31 AM

data path

no data paths in the filter means a match. if a path is specified in the filter, ex: somepath, then one scheme and one authority and one data path should match the incoming intents data uri.

In otherwords scheme, authority, and path works together to validate an incoming intent uri such as: "http://www.somesite.com/somepath". So the "path", "authority", and "scheme" don't work in isolation but work together.

The path in addition is case sensitive.

satya - Thursday, August 19, 2010 10:42:28 AM

Can I have multiple filters?

A component can have any number of intent filters, each one declaring a different set of capabilities. If it doesn't have any filters, it can be activated only by intents that explicitly name the component as the target.

satya - Thursday, August 19, 2010 10:46:03 AM

The sneaky category

In principle, therefore, an Intent object with no categories should always pass this test, regardless of what's in the filter. That's mostly true. However, with one exception, Android treats all implicit intents passed to startActivity() as if they contained at least one category: "android.intent.category.DEFAULT" (the CATEGORY_DEFAULT constant). Therefore, activities that are willing to receive implicit intents must include "android.intent.category.DEFAULT" in their intent filters. (Filters with "android.intent.action.MAIN" and "android.intent.category.LAUNCHER" settings are the exception. They mark activities that begin new tasks and that are represented on the launcher screen. They can include "android.intent.category.DEFAULT" in the list of categories, but don't need to.) See Using intent matching, later, for more on these filters.)

satya - Thursday, August 19, 2010 10:46:49 AM

You can read more about that here

SDK ref on intents and filters

satya - Thursday, August 19, 2010 10:58:51 AM

Category rules

Every category in the incoming intent must be present in the filter category list. More categories in the filter is ok. if a fitler doesnt have categories it will only match with one that doesnt have any categories mentioned.

However there is a caveat. Android treats all intents passed to startActivity() as if they contained at least one category: "android.intent.category.DEFAULT". So every activity that is wanting to be invoked must include the default category in its filters.

There is an additional wrinkle where Android states that the default category is unnecessary if the activity is intended to be invoked only from launcher screens. So these activities tend to have only MAIN and LAUNCHER categories as part of their filters. However DEFAULT category can be optionally specified for these activities as well.

satya - Thursday, August 19, 2010 11:05:56 AM

More exceptions to the rules

The last rule shown above for the data test, rule (d), reflects the expectation that components are able to get local data from a file or content provider. Therefore, their filters can list just a data type and do not need to explicitly name the content: and file: schemes. This is a typical case.

satya - Thursday, August 19, 2010 11:08:01 AM

data URI rule

if the data uri is content: or file: then it is considered a match irrespective of the filter scheme, domain, and path

satya - Thursday, August 19, 2010 11:09:07 AM

why is that?

Because every component is expected to know how to read data from a content or a file url which are essentially local. In other wors all components are expected to support these two types of urls.

satya - Thursday, August 19, 2010 11:55:56 AM

Here is how you can query for activities based on intents


public static void testQueries(Activity activity)
{
    Intent mainIntent = new Intent(Intent.ACTION_MAIN, null);
    mainIntent.addCategory(Intent.CATEGORY_LAUNCHER);
    PackageManager pm = activity.getPackageManager();
    List<ResolveInfo> list = pm.queryIntentActivities(mainIntent, 0);
    for(ResolveInfo ri: list)
    {
        //ri.activityInfo.
        Log.d("test",ri.toString());
        String packagename = ri.activityInfo.packageName;
        String classname = ri.activityInfo.name;
        Log.d("test", packagename + ":" + classname);
    }
}

satya - Thursday, August 19, 2010 11:56:49 AM

Here is how you can start one of those


public static void invokeQueriedActivity(Activity activity)
{
    Intent mainIntent = new Intent(Intent.ACTION_MAIN, null);
    mainIntent.addCategory(Intent.CATEGORY_LAUNCHER);
    PackageManager pm = activity.getPackageManager();
    List<ResolveInfo> list = pm.queryIntentActivities(mainIntent, 0);
    for(ResolveInfo ri: list)
    {
        //ri.activityInfo.
        Log.d("test",ri.toString());
        String packagename = ri.activityInfo.packageName;
        String classname = ri.activityInfo.name;
        Log.d("test", packagename + ":" + classname);
        if (classname.equals("com.ai.android.book.resources.TestActivity"))
        {
            Intent ni = new Intent();
            ni.setClassName(packagename,classname);
            activity.startActivity(ni);
        }
    }
}

satya - Friday, August 20, 2010 2:46:41 PM

More on default category

An activity can register in the manifest without any intent filters. This is called an implicit activity. This activity then can be invoked only by specifying its classname.

There by

This activity is declaring to the world that it doesn't WANT to be invoked through intent filtering mechanism. The moment this activity considers to be invoked through an intent filter such as through an action string, then it has to, IN ADDITION, also specify the category as default. If not it will fail.

satya - Friday, August 20, 2010 2:49:34 PM

Default category and a broadcast receiver

The default category doesn't seem to be needed if what is being invoked is a receiver. For example the following receiver is perfectly fine to be invoked based on an action with out a category.


<receiver android:name=".StandaloneReceiver">
  <intent-filter>
      <action android:name="com.ai.android.intents.testbc"/>
  </intent-filter>
</receiver>

As stated this won't work for an activity with out a default category.

satya - Friday, August 20, 2010 2:52:01 PM

However I suspect...

Even if an activity doesn't have the default category in its intent filter, if you know its explicit component names, you may be able to start it like the launcher does.

So if you were to explicitly search for matching intents yourself with out having a default category as a search criteria you may be able to start those activities that way.

In that sense this DEFAULT category seems to be an artifact of the "startActivity" implementation and not an inherent behavior of filters.