Buster Keaton — The Battling Butler

Intents are an essential part of the Android ecosystem. They are used to express an action to be performed and can be classified into implicit and explicit intents. In an abstract way, all intents together define a navigation layer inside an application. In this article we will explain why the Android way to create explicit intents is error-prone and also show some problematic ways to solve it. Finally, we will introduce Dart & Henson, a library that generates this navigation layer and make it easy, convenient, fast and robust to navigate among your activities and services.

Explicit intents are used to run specific components, habitually application internal activities or services. Together with the intent, additional information can be provided to the target components using extras. For instance, the following code creates an explicit intent and triggers an activity:

And this could be the activity being started:

This mechanism is great for component creation and communication, but there are some issues to keep in mind:

The target component as an entity, does not have any control over its input . In our example, itemId is mandatory , but the “best” DetailActivity can do is to fail at runtime.

over its . In our example, itemId is , but the “best” DetailActivity can do is to fail at runtime. The intent creation is not robust (at all), there is no check on the keys or values attached to the extra bundle.

An ounce of prevention is worth a pound of cure.

Problematic ways

A possible solution to those concerns is the Intent Factory pattern. It mainly consists in a factory class which encapsulates methods for every kind of Intent that an application needs. For our example, this might be the Intent Factory:

However, this approach is far from a suitable solution considering that it comes with some constraints: