04 September 2013

Darker Corners of Android: BroadcastReceivers and Intents

Not all in Android-land is lightness and brightness. A few dark corners and cul de sacs await the unwary, ready to trap us in sticky tarbaby snares of mystery debugging. One such is a case we recently encountered in relation to BroadcastReceivers and the way Intents get delivered to them.

I've written previously about implicit Intents versus explicit Intents in the context of describing a useful code-pattern for preparing Intents. To briefly recap, explicit Intents name the class of the component they are aimed at whilst implicit Intents simply describe the desired action they intend to trigger and allow the Android intent-delivery system to find the best-matching component to handle the Intent. Indeed, a better naming scheme might have been "broadcast Intent" for implicit Intents and "unicast Intent" for explicit Intents.

BroadcastReceivers can be registered for receiving broadcast Intents in one of two ways, either through a declaration in the Android manifest file, or via a dynamic registration by another component.

If you register a BroadcastReceiver via a manifest declaration, then you must provide the class-name of the receiver implementation. To communicate with the receiver, you broadcast an Intent – either one that matches the receiver's intent-filter (if it was declared to have one) or an Intent that specifies the class-name of the receiver. In this latter case it's hardly a broadcast, really, since the Intent is directed at a specific target receiver. Nevertheless, this is a perfectly valid way to send events and information to a BroadcastReceiver.

If you dynamically register a BroadcastReceiver – by calling Context.registerReceiver() – you supply a BroadcastReceiver instance and an IntentFilter describing the sorts of Intents that should be passed to the receiver. And herein lies a small gotcha. You register an instance.

If you try to send an Intent to the receiver by naming the class of the BroadcastReceiver, it will never get delivered. Sending the Intent using something like

Intent i = new Intent( this, MessageReceiver.class );
sendBroadcast( i );

won't work. The Android system will not match the Intent you declared to the class of the BroadcastReceiver instance you registered. The only way to send Intents to dynamically registered BroadcastReceivers is by having them match the IntentFilter attached to the receiver when it gets registered.

Explicit Intent matching just doesn't work in this case.

I've put some example code on github that demonstrates all this. There's a simple BroadcastReceiver (the MessageReceiver class) that gets registered dynamically by the MainActivity. The MainActivity instance then tries to send Intents to this receiver instance using two different methods. First it sends an Intent that matches the Action declared in the receiver's intent-filter. That Intent gets through successfully. Then it tries to send an Intent that explicitly names the MessageReceiver class. It never arrives.

As much as I love the eventful nature of Android software architecture I view this as a bug (Come on guys... How hard would it be to do a getClass() on the instance that gets registered?) but it is what it is. It took us a day or so to figure out why Intents were mysteriously failing to be delivered to an otherwise perfectly ordinary BroadcastReceiver, so I thought I'd save you, Dear Reader, the trouble. It's pretty straightforward to cope with (rely on Intent actions rather than explicit Intents) once you know of this issue, but I have not seen it documented anywhere in the Android reference materialsε.

Share and Enjoy.

ε If anyone does spot a description of this in the official docs, please do let me know!

27 July 2013

Android Patterns: Manufacturing Intents

Activities, Services and BroadcastListeners are the basic components of application structure in Android. They are all started by firing an Intent that causes the Android system to activate them. There are two very different kinds of Intent that might activate an Activity: implicit Intents, and explicit Intents.

We present here a useful pattern for creating those Intents in a way that makes code more robust and easier to maintain.

For the purpose of simpler description we'll talk about starting Activities using Intents, though the same pattern makes most sense when used (with due care and discretion) for all components.

Implicit Intents

Implicit Intents do not name the specific Activity they trigger. Instead Android looks for the best match between an Intent's content and any Intent Filters declared by the Activity. This is what happens when your application's main Activity is started by an Intent that has its action set to ACTION_MAIN and its category set to CATEGORY_LAUNCHER.

Implicit Intents and their matching by IntentFilters is the key way that applications are able to interact with the entire ecosystem of applications and services in an Android system. It allows us to run an application that (for example) makes use of a web-browser or email client without having to embed all the functionality of a browser or email client in the application itself; we can merely assume that a suitable application exists in the ecosystem, and all our application has to do to leverage that capability is to fire the right Intent. This system of implicit Intents is one of the most powerful aspect of Android, and one which many applications fail to use well. How many applications have we seen that try to provide their own web-browsing capability, ending up providing some half-baked, crippled web-page fetcher-and-renderer, while we know perfectly well that the system almost certainly hosts one or more full-fledged, powerful web-browsers, if only they would just fire an appropriate Intent instead of trying to go it alone.

Explicit Intents

Explicit Intents are Intents that name a specific component – an Activity, Service or BroadcastReceiver – as the thing to be activated using the components class name. As soon as an Intent names a specific component, all other forms of Intent matching against filters is abandoned, and Android activates only the specific component, without any regard for the other bits of data the Intent may carry.

In terms of Activities, explicit Intents are used to implement in-application navigation between Activities, and many of the target Activities will not have any associated IntentFilter at all, so there is no other way to activate them other than with explicit Intents fired form other parts of the application.


Each Activity, Service or BroadcastReceiver should provide a factory that returns template Intents for starting that Activity, Service or BroadcastReceiver. In the simplest case – say an Activity started by an explicit Intent – this might be a simple factory method:

public class ListManagerActivity extends Activity {

    public static Intent getStartIntent( Context context ){
        return new Intent( context, ListManagerActivity.class );

In this most elementary form such a factory method is not, by itself, very useful. It becomes ''much'' more compelling when the Activity in question expects or requires certain additional data to be present in its starter Intent:

public class ListManagerActivity extends Activity {
  public static Intent getStartIntent( Context context, UserInfo userData ){
    checkNotNull( userData );
    final Intent startIntent = new Intent( context, ListManagerActivity.class );
    startIntent.putExtra( EXTRA_USERINFO, userData );
    return startIntent;

In this case we achieve two worthy objectives with this simple factory method:

  1. We make sure that the Intent that starts the ListManagerActivity always contains the userInfo extra that (presumably) the activity absolutely requires in order to behave correctly, provided, of course, that we only ever manufacture start Intents for ListManagerActivity using this method, and never by calling new Intent(...) – something that can quite easily be checked using various code-quality audit tools.
  2. We keep the code that builds start Intents (with their extra data) close to the code that consumes those Intents (and that extra data) so that, if we change the notion of what data an Activity requires, we're already in the right place in the code to make the corresponding fixes to the manufacture of those Intents, rather than having to hunt around all over our codebase.

There might be more complex cases where components get started using a variety of different Intents. Perhaps Intents might carry different extra objects or flags affecting the component's behaviour. Perhaps the component might be activates using implicit intents with varying options for their data URI. Indeed, a common mistake when passing a data URI in an implicit Intent is forgetting to correctly set the mime-type for the data URI, in which case matching the Intent against an IntentFilter mysteriously fails.

In such complex cases it may be appropriate to supply several Intent-factory methods in the class that gets activated. It may even be desirable to provide an Intent Builder class:

public class ListManagerActivity extends Activity {
    public static class Builder {
        private Intent startIntent;
        public Builder( Context context, Foo mandatoryData ){
            startIntent = new Intent( ListManagerActivity.class );
            startIntent.addExtra( EXTRA_FOO, mandatoryData );
            startIntent.addFlags( FLAG_ALLOW_NEW_ITEMS );
        public Builder addVitamins( final Vitamin nutrient ){
            startIntent.addExtra( EXTRA_VITAMIN_ID, nutrient.getId() );
            return this;
        public Intent build(){
            final Intent constructedIntent = startIntent;
            startIntent = null;
            return constructedIntent;


Don't create start Intents for Activities, Services and BroadcastListeners willy-nilly in myriad and random places all over your codebase. Rather have each such component class provide factory methods or builders to manufacture those start Intents.

This ensures that
  • the Intents carry all the necessary data that the component expects, 
  • that the data is added in close proximity to the places where it is consumed, so that changes in the requirement are easily mirrored in the corresponding changes in the creation and structuring of that data, and
  • mandatory data required by the component can be reflected by mandatory arguments in the signature of factory methods, ensuring that required data cannot be easily forgotten.

21 May 2013

Netbeans EE Dependency Madness

Dredging up an ancient persona-time web-project and dusting it off caused me to reinstall the Base-EE module for Netbeans - long my IDE of choice. To my dismay, Netbeans pops up the following list of dependent modules:
This is madness!

I will never be using JSF, IceFaces, PrimeFaces or Struts. There will be frost on the ground in Hades before I ever use any part of Spring Framework without being severely and repeatedly bludgeoned with a blunt instrument. And if I ever do choose to host a webapp "in the cloud", Oracle is probably going to be my very last choice, though I can understand them being desperate to punt their wares in an IDE that they do, after all, fund in some measure.

So why are these listed as required dependencies? It might be that the EE Base module uses some features from those modules, in which case, why have those not been broken out as separate modules, this being one of the huge strengths of the Netbeans Platform?

Something is very smelly in the nation of Netbeans!

29 November 2012

Web-design HowNotTo

Seen recently on a mailing-list I receive:

> These guys stock 29mm Crown Caps http://www.africancork.co.za

Went off to take a look at their website...

"You have to be logged in to view our products"

They have to be joking! I can only assume that they actively hate it when people want to buy their stuff. Needless to say, I bounced.

Do people really still misunderstand the nature of the web that badly when we're already more than 10% of the way through the 21st Century?

05 November 2012

Google Groups: The Orphan Child

It's been quite a while, now, since Google rearranged the menus providing links to their various sites and tools. And right from the start Google Groups has been Missing In Action. At first I thought it might just be a small oversight, but evidently it's a deliberate design decision.
Google Groups: Nowhere to be found.

I wonder why... I find Google Groups to be one of the most useful tools they offer, especially when I am working with people who are not very net-savvy -- those who are not as comfortable with web-based tools as I am. The only rationale I can come up with is that Google would like us all to migrate over to g+ and abandon the somewhat old-school "forum" style that is Groups. Ain't gonna happen!

Unless they force the issue by killing-off Groups, in which case I will hazard a guess that existing fora using Google Groups as their carrier will simply hike on over to elsewhere that does provide a forum-style interface.

I'm not a huge fan of forum-style UX, and I avoid it as far as possible, but it is something simple and familiar to many people, and so sweetly occupies a place where it is the best thing to use because it is the simplest thing for the largest number of users. I do hope it's not going to vanish completely in a stupid attempt to force everyone over to g+... (Like what Microsoft seem to be trying to do to their user-base.) That would be,... well, not quite Evil, I guess,... but certainly quite an unfriendly move.

29 October 2012

Unit-testing Android Apps: Netbeans and Robolectric

Testing for Android Apps is a bit of a mess. The Android Test Framework dismally fails to make a clear distinction between unit tests, functional/integration tests and UI tests, and assumes that all tests will be run as an Android application on a device or emulator (AVD) as Dalvik code. For unit testing this is extremely clunky. It means that unit tests must be written as a standalone Android project, built as an APK and deployed to the device running a build of the application under test, where it takes over the running of the application to instrument it for testing. This is quite a slow process, and slowness is the very opposite of what we want for unit tests.

All I wanted, though, was to run (quickly!) some simple unit tests against domain classes. There might be some Android mocks needed where my application classes rub up against the SDK, but that's just accidental.

Then, too, there is (currently) a bug in the Ant build script for the Android Test Framework that means that, out of the box, tests cannot be built or run using Ant. I neither know, nor do I care, whether the test might be runnable if I were using Eclipse; I'm a diehard Netbeans user, and Netbeans uses Ant (or Maven, and possibly soon, Gradle) rather than relying on a parallel build system of its own. I think this is one of Netbeans's key strengths. Along with the still-evolving NBAndroid Module and Netbeans's superb out-of-the-box handling of XML files, I've been finding it an absolute pleasure to use for Android development. But unit-testing remained an itch that I had to scratch.

The upshot of all this is that I could not find a satisfactory -- or, indeed, a working -- way to write and run unit tests for the Android project I'm working on.

Down into a Rabbit Hole I went!

Emerging a couple of days later, here's the solution I came up with... It's probably not the best solution ever. It's certainly not definitive. But it Works For Me.

I'm using Robolectric -- a framework that modifies Android platform methods on the fly and provides shadow classes for Android platform classes so that unit test can be run in a standard JVM on my development machine.

Predictably, it was not all Plain Sailing!

The Robolectric documentation is pretty sparse, and very strongly oriented towards IntelliJ and/or Maven-and-Eclipse usage (didn't investigate too closely, don't care!) If I'm going to be shafted into using Maven, then my unit testing is so slow that I might just as well stick with using the standard Android Way of Testing, so I wanted to avoid that. Additionally, this brings the advantage that I can use JUnit-4 style tests (with a caveat - see below.)

The first step is to create a standard Java Project in Netbeans. We already have a directory structure like


so I created my unit-test project on the same level as the main project:


In Netbeans add at least the following libraries as dependencies for your test project:

  • Your main project's bin/classes directory - otherwise the test-project cannot find the classes you want to test.
  • JUnit
  • Any mocking library you might choose to use - PowerMock looks pretty good, though I haven't used it beyond tyre-kicking yet.
  • android.jar for the SDK version you have as your targetSdkVersion in the AndroidManifest of your main project. This is important, since the Robolectric framework uses a custom test-runner (which we'll slightly modify as described below) that examines your AndroidManifest to figure out where to find resources.

The order you specify the libraries is critical: android.jar must come after junit in the classpath for your unit-tests.

Now only one more things remains: telling Robolectric where to find your main project's manifest file and resources...

In your test-project, create a custom test-runner like


import java.io.File;

import org.junit.runners.model.*;
import com.xtremelabs.robolectric.RobolectricConfig;
import com.xtremelabs.robolectric.RobolectricTestRunner;

public class MyTestRunner extends RobolectricTestRunner {
    public MyTestRunner( final Class<?> testClass )
        throws InitializationError
        super( testClass, new RobolectricConfig(
            new File( "../android-main-project" )

Of course you should now annotate your test classes using

    @RunWith( MyTestRunner.class )
    public class DeviceIdTest{

Now you can "Test" your test project to run all unit tests, select just a single unit-test class to run, or even debug unit-tests without leaving Netbeans at all. And you can run them in a CI server.

Slightly less convenient than unit-testing a non-Android project, but still way better than the alternatives (no testing, Eclipse or Maven, or the bloody slow Android Test Framework.)

My thanks to Justin Schultz who's Eclipse Robolectric Example put me on the right track. All I've done is adapt his hard work for Netbeans use.

11 August 2012

Moving Furniture: The Scrum Way

As a housewife, my wife
Wants the bed in one room swapped with the couch/futon/bed in another
So that  she can more comfortably sit and watch the Olympics on TV in the sunnier, warmer room.

With 3 programmers in the room, it was inevitable that we would choose an Agile approach to this requirement. The User Story above was our first step, and was duly agreed to by said wife as Accurately Describing What She Wanted and its Business Value.

Given the constraint that both rooms involved are too small to contain both pieces of furniture simultaneously, we realised that we would need a temporary variable as a swap space. I'm pretty sure that, barring some major advance in our understanding of Quantum Mechanics, pieces of furniture can't be swapped by being XOR'd through each other.

We broke the Story down into some Tasks:

  1. Remove the bed from Room 1 into the Swap Space.
  2. Remove the Futon from Room 2 into the Swap Space.
  3. Move the Futon Base (a finger-eating piece of folding woodworkery) from Room 2 into Room 1 and position it in its final position.
  4. Move the Futon from the Swap Space into Room 1 and position it on its Wooden Base.
  5. Move the bed base from the Swap Space into Room 2 and position it in its final position.
  6. Move the mattress from the Swap Space into Room 2 and place it on its base.

Seemed like a reasonable breakdown at the time. We did some estimations and figured we could fit it all into a single Sprint.

Here's how it played...

Task-1 went quite smoothly. Mattress and bed base moved to the Swap Space.
Task-2 also went well. Please bear in mind that the futon and mattress are large, floppy and heavy items, so not all that easy to move about.
Martin and I -- Pair Moving -- make an attempt at Task-3. Space is very constrained, so moving the Futon-base into Room 1 involves a brief detour into Room 3. Halfway there we suddenly realise that -- because the base is asymmetric -- we have to turn it around in the Swap Space before it can be Deployed into Production.
We complete Task-4, only to realise that we were entirely wrong about which way round the base has to go. We've moved it into the room the wrong way round. And the room is too small for us to turn it around short of Interesting Topological Manoeuvres.

So we back out again, via Room 3, back into the Swap Space where there is sufficient room to turn the base around.
Some discussion ensues. We realise that we should have had better Unit Tests in place for this Task. Finally we manage to complete the Task.
It's a tight fit, but the Futon/couch will serve our User perfectly as she wished.
Sadly there's an unforeseen bug. A small drawer unit now blocks the doorway, making for extremely poor UX. Not our problem, though. We've met our spec and implemented the Story. People will simply have to leap over the drawer-unit for the time being. Changes will have to be the subject of a subsequent Sprint.

Happily I can report that the rest of the Sprint went quite as anticipated. We were even able to implement a small Improvement Task by orienting the bed in Room 2 in a much more User Friendly fashion.

I do wish Furniture Topology was amenable to Version Control, though. It would have made our Task-4 issues a bit simpler to resolve. But then, perhaps we should have abandoned the Sprint at that point.

Still not quite sure how all the Scrum ceremony helped, though.
Related Posts Plugin for WordPress, Blogger...