Welcome to part 4 this review of the Pluralsight course Android Programming with Intents by Jim Wilson

Jim has over 30 years of software engineering experience, with the past 15 years heavily focused on creating mobile device and location-based solutions. He has co-founded multiple software-related startups and has served in a consulting role at several more.

After nearly a decade as a Microsoft Device Application Development MVP, Jim now focuses on developing Android and iOS device applications. Jim’s passion is mentoring software developers. He blogs at hedgehogjim.wordpress.com.

Android Programming with Intents is the 6th course in the Pluralsight learning path for Android, and this month I am reviewing every course in this learning path.

Also in this series:

Part 1 – Android Late Binding and Intents
Part 2 – Android Programming with Intents: Component activation
Part 3 – Android Delegation and Callbacks through PendingIntents
Part 4 – Android Programming with Intents: IntentFilter data tests
Part 5 – Android Platform Features Through Intents

IntentFilter data tests

Data test basics

Jim starts by saying the URI represents where the data is coming from. This is a single value composed of multiple parts.

A URI is made up of Scheme, Host, Port and Path.

Jim explains these as elements of the following URI:

http://www.pluralsight.com:80/microsoft/courses/index

The Host and Port combination is known as the Authority.

The path is always resolved within this scope.

Describing a data test

A couple of minutes into this lesson, Jim explains the data element, which identifies the intent filter data tests.

We can check each attribute of the URI e.g.

Not all parts are required. We can also set the mimeType:

As mentioned in a previous module, all data tests are case sensitive so watch out for that.

URI test requirements

There are a few different rules. We must include at least a scheme. If we specify a port, we must also specify the host.

And if we specify either the path, pathPrefix or pathPattern, we must specify a host.

We see an illustration here to clarify this.

Finally, Jim explains that the data element is just one part of the filter, and writing an intent filter with only data tests is a very rare scenario.

Almost every test will include at least one action category.

Relationship of data attributes

All data test attributes within an intent-filter are used collectively.

While Jim is explaining the details, we see an example Intent filter with:

• a data element with scheme and host attributes
• a category
• an action

We also see that we can create the scheme and host attributes as two data elements if we prefer:

This works exactly the same as having them specified together:

android:host="pluralsight.com"/>

Jim also explains how we can do “OR” tests.

If we want to allow http or https protocols for pluralsight.com OR pluralsight-training.net, we could specify 4 separate intent filters.

But a cleaner/easier to read way to do this is to write all tests in the same intent filter.

So we would have four data elements in the intent filter: two scheme attributes and two host attributes. A much more succinct way of specifying.

Demo: Relationship of data attributes

In this lesson Jim shows some examples of using the data rules in our intent filters.

URI Paths

We learn that we can specify the URI path in whole or in part.

Jim discusses the three attributes:

• path
• pathPrefix
• pathPattern

Demo: URI Paths

Mime types