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!

Android Nails Sandboxing

So I'm learning to programme the Android platform. Despite constantly typing it as "Androind" finding programming fun again after many years of regarding it as somewhere between tiresome drudgery and only mildly interesting in sporadic parts.

It's early days, yet, but I do think that Android's architects had one flash of brilliant insight: Using Unix user and group permissions to sandbox applications. Brilliant! We've had this mechanism since forever, and let's be honest, it's never been all that useful except in the very early years of Unix when we actually did have to put multiple users on a single computer. And even then, most users didn't understand it. Questions about umask and file permissions are among the commonest of Unix confusions I've run across for the past 25-odd years.

Warping the idea to mean that every application is a unique user is a flash of inspiration.

Design using Other Peoples' APIs

Where you are dependant upon somebody else's API, decouple from that API at the earliest possible opportunity so that the remainder of your system works in terms of your own abstractions rather than that somebody else's. This shields you from the random, spurious, and often unwarned changes they may make. It also enables you to place guards against the various stupidities they may likely perpetrate in the name of fashion or unthinkingness, and ensures that you are - as much as possible - forced to deal only with your own stupidities and unthinkingess.

This injunction includes decoupling from your own APIs where those are non-core to the subsystem under design.

Test-First for Mental Health

I've been thinking recently about how a Test-First approach to development is good for our emotional well-being and psychological balance, and I believe this may be the most important reason to adopt test-driven  development.

Consider how we would traditionally develop software using a conventional Test-Last approach. We read our requirement spec (whatever form that takes), perform some design work -- as much as we feel we need to go forward with some confidence, and we start cutting code. Time goes by. Our codebase grows. We're doing some informal testing as we go along to feel confident that the code under development does what we think it should be doing...

And here's Important Point Number One: "the code does what we (the developers!) think it should be doing". Not what the business thinks it ought to be doing. See? We're inherently unsure -- even if only subconsciously -- whether we're doing work that actually serves the business. And unsureness is insidious and destructive to our well-being. We feel much better about ourselves as developers when we know that we're producing useful stuff that really has value. So here's the first way that having tests defined up-front helps us preserve our mental balance: With a reasonable set of tests1, defined together with our business partners, there's no bullshit involved; no trying to convince ourselves of the (probably shaky) value of our ever-growing codebase. We have an external, automated, objective, easily understood yardstick of value.

But there is, I think, a deeper psychological value to the Test-First approach.

So much of the time -- I will thumbsuck something like 99% of the time -- our code is broken. The system we're working on doesn't work. This is inherent in the fact that it takes us time to design and write software, and the continual not-workingness can be powerfully demoralising. Especially when we (finally, right towards the end of the project lifecycle) start formal testing, and our tester (often users) start coming back with bug after bug after bug after bug, and all that beautiful code we're so proud of is labelled "Less Than Satisfactory" -- usually in much stronger language than that.

Herein lies the secret destructiveness of Test-Last. Our code is always broken, and we can never do more than run after the brokenness trying to patch it up, until, at last, demoralised and exhausted, we move on to the next job or project.

Contrast this with a Test-First pattern.

We first write a bunch of tests. Sure it takes some time, can often be pretty tedious, and is frequently little more than a first-pass best-guess at what the code is supposed to do. Almost certainly we will add more tests as our code grows and evolves and begins to tell us the shape it wants and needs to be. But at least we start with a battery of (automated!) tests. And we start with the expectation of them all failing. This is by definition! We haven't written the necessary code, yet. A short time later we may have enough of the boilerplate in place that we can at least compile everything and actually run our tests, but we still expect them all to fail because our methods all read

throw new UnsupportedOperationExcetion( "TODO" );

So we run our tests, and they all fail. And we're happy about that! Everything went as we predicted. We feel in control.

As we go along replacing those stubbed-out methods, some of our tests begin to go green. We're making visible progress towards a well-defined end goal. We gain an ever-increasing feeling of confidence and accomplishment. We have tangible, objective evidence that we're making progress. Even when we make some of the "test bar" revert somewhat to red -- because we add new tests, or because we do some large-scale refactoring that breaks stuff -- we still feel good about it, because we know that our self-built safety-net is working! We've actually decreased the likelihood of things going wrong, so we know we're enhancing the quality of our product. (And every good developer I've ever worked with has an inner Proud Craftsman lurking in their soul.)

So it seems to me that Test-First builds our confidence and self-esteem as we go along, whereas Test-Last contains an inherently destructive, soul-sapping subversiveness to it.

I think this value outweighs the sum of all the other benefits (many though they are) of Test-First.

---

[1] Note that I make no distinction, here, between Unit Tests, Functional Tests, or System Tests (which would probably involve real databases, external systems, and so forth, albeit serving test data to our system-under-test.) I don't really care what form of Test-First is most useful to your team and situation. It's the principle that counts!

Boolean Illogic

Why do Java programmers hate the boolean XOR operator?

Is it that they are just generally ignorant about the full-eval boolean operators in general? You know, the operators that look like &, | and ^. Perhaps its that most Java developers are under the impression that they only operate on bits, an are ignorant of the fact that they operate on booleans (and Booleans with that fucking horrible autoboxing/unboxing nonsense.)

I know that 99 time out of 100 we prefer the early-out operators && and || for their efficiency, but a simple ^ can save a hell of a lot of unreadable and less-understandable if-then-else logic. For example, I've just refactored (somebody else's code)

if( check ){
    if( !user.isAnonymousUser() ) doStuff();
}else{
    if( user.isAnonymousUser() ) doStuff();
}

which I find nasty as hell to be sure is doing what it's supposed to, into

if( check ^ user.isAnonymouseUser() ) doStuff();

Much easier to understand, no?

Wizzards

Programming software is Magic.

I don't mean that there's something mystical about it, nor that it is intrinsically inaccessible to ordinary people. Nor (I emphatically add) do mean that it is like Magic. In every aspect I can think of, the act of Programming software meets all the criteria for performing Magic. Magic in the Swords and Sorcerers or Unseen University sense. "Alakazam!" and the Prince turns into a Frog. "Shazam!" and you're whisked away to a far, far place at high speed.

Just look at the facts: We (programmers) write programmes -- spells -- in arcane and cryptic symbol languages unknown to the common mob.  Get the slightest part of the spell wrong, and, at best, it fails utterly to do anything.  At worst it runs amok and fearful consequences ensue -- fires, floods, loss of money and even life!  Get it just right, in every teensy, tiny, ball-aching, nit-picking detail², and Lo! out of nothing, stuff happens in the real world.  Gold changes hands.  Trains run on schedule.  Music plays and Feyries dance¹.

Where nothing was before the spell was cast, something comes about solely because of the spell.  That's Magic.

And, just like in the fantasies where Wizards keep pet Dragons and dribbly candles set atop skulls are the acme of interior decoration, programmers frequently work at odd hours, with intense, monomanic concentration bordering on the inhuman.  And, like the traditional Wizardly Schools, programmers are admitted to different schools of various arts and degrees.  So we have Clerics -- programmers content to churn out the boilerplate code needed to keep the wheels of commerce (and most web applications) running, but lacking any true proficiency with martial weapons of higher degree; Monks -- who eschew the use of particular weaponry but, ninja-style, willingly embrace whatever comes to hand as combat fodder; Wizards -- capable of serious Magic, but forget their spells once cast, capable of wonderful stuff, but doomed to repeat it -- with minor variations -- time after time; and then there are the Sourcerers -- Masters of The Source³ whose code is so elegant and expressive, so parsimonious and pretty as to make brave Programmers weep with envy and admiration.

No, you can not deny.  Programming really is the realisation of the ancient idea of Magic.  Say the Magic Spell and Change Reality.

---

[1] Well, anybody who wants to dance, I suppose, really.
[2] ...and My God, there's an inordinate amount of crappy detail that all has to be Just So!
[3] Waves to Ken, Doug, Dave, Jason, Paul, Johan, Bob, Brian, John and several dozen others...

Netbeans Collab Modules

Installed the Netbeans Developer-Collaboration Module yesterday, and gave it a trial-run together with Jason.  Wow! 

The chat-client is pretty standard; not much to say there.  The only thing we both disliked was that you have to use "Control-Enter" (or "Alt-N") to send your text rather than plain "Enter".  Probably we could reconfigure the keybindings somewhere...

But!  The ability to drag a file, folder, Java package or, indeed, entire project into the collab area, and then have both people (and presumably everybody in the chat session) simultaneously able to edit the same files, seeing each other's edits live,... pretty cool.

The real OhMiGod Factor was when Jason hit "compile" on the shared file, to have it compile on my PC (since the original file came from there,) with both of us seeing the compile output.  Very, very cool!

We were speculating about some alternative form of development setup where all the code (and docs, web-pages, and other project components) get stored in a wiki-like (auto-versioned, of course) system so that its not just one developer's PC that gets to do the work...  Just daydreaming, really.  For now.

If you're working in Java, C/C++ or Ruby, and you work with other faraway developers (even occasionally -- the dowload is only a couple of meg) you owe it to yourself to explore the Netbeans Collab stuff.  I am pretty sure that what we're seeing now is only the start.

Fun Being a Techie

Having fun being a techie again, catching up on some gaps in my knowledge of building webapps in Java. Its fun stuff, and I find myself wondering why so many webapps are so badly designed and implemented; many of them are truly awful. (No, I won't mention them by name :-)

It's soooo tempting to just stay with doing "real" stuff, rather than "suit" stuff.