C++: Hiding the implementation

C++ is a powerful language, but it does have a few aggravations (some would quibble with "a few"; others would quibble with "some"). Large among them is the header/source file dichotomy. If you have a class that you want to make visible to the rest of your application, you need to write an outline-like definition of it in one file (an #include-able header), and put the actual code for its methods in another (a source file).

For example, the header for a class representing a monster in an RPG might look like this:

Standard header file

// Revenant.h

#include "Armor.h"

class Revenant
{
public:
 Revenant();

 int GetHp() const;
 void SetHp(int newHp);

 void TakeAttack(int attackPower);

private:
 int GetDamageFromAttack(int attackPower) const;

private:
 static const int STARTING_HP = 20;

 int m_hp;
 Armor m_armor;
};

The corresponding source file might look  like this:

Standard source file

// Revenant.cpp

#include "Revenant.h"
#include "ArmorFactory.h"

Revenant::Revenant()
 : m_hp(STARTING_HP)
 , m_armor(ArmorFactory::CreatePlateArmor())
{
}

int Revenant::GetHp() const
{
 return m_hp;
}

void Revenant::SetHp(int newHp)
{
 m_hp = newHp;
}

void Revenant::TakeAttack(int attackPower)
{
 int damage = attackPower;
 GetDamageFromAttack(attackPower);
 SetHp(GetHp() - damage);
}

int Revenant::GetDamageFromAttack(int attackPower) const
{
 int damage = attackPower;
 damage -= m_armor.MitigateDamage(damage);
 // apply more mitigations, etc.
 return damage;
}

The problem with header files

Right away you should notice one of the problems with the header file approach—you're forced to repeat a great deal of information. Luckily you don't need to worry about the two copies gradually drifting out of sync because, with a couple of exceptions, the compiler won't let you get away with that. But it's still extra work. Writing code in the source file and decide you want to add a private function? You'll need to switch to the header, scroll to the correct position, write the new function's signature, switch back to the implementation and write the same signature again (with a syntax that is just different enough to prevent you from using straight copy/paste), and only then start writing the actual code. There are some good tools that can automate much of this, but it's still a hassle, and you can't depend on automatic tools to keep things organized as well as you could by hand.

The other, bigger problem is more subtle. The need to declare all your member variables and functions in the header forces you to expose the private workings of your class to the entire outside world. Anyone reading Revenant.h will see that a Revenant starts with 20 HP, and may come to depend on that detail. More damningly, because Revenant has a private member variable of type Armor, any file that wants to use Revenant will need to #include Armor.h, even if it never actually uses Armor directly. In addition to making more work for the preprocessor, this means that any change to Armor.h will require all consumers of Revenant to be recompiled. Something similar happens if you decide to change Revenant's implementation details, perhaps by splitting GetDamageFromAttack() into several functions that each apply a different type of mitigation. This would mean that everyone using Revenant would need to be recompiled, even though no one should need to care about the details of how you calculate damage. Thanks to transitive dependencies, over time this sort of arrangement can easily lead to a situation where changing a single "hot" header file causes a good chunk of the source files in the project to be recompiled.

pimpl: A partial solution

A big part of the reason we need to fuss around with all this header stuff is because the compiler needs to know the size of any object that you pass around. This means if you declare a parameter or variable of type MyAwesomeObject, the compiler will need to read all of MyAwesomeObject's details from its header file so it can determine how much space to set aside for it. But there is a loophole—if we replace all those MyAwesomeObjects with pointers to MyAwesomeObjects, and we never try to dereference any of those pointers, then we no longer need to tell the compiler anything about MyAwesomeObject except that it is the name of a class. This is because pointers are always the same size no matter what they point to. This is true for smart pointers too, since they are just glorified wrappers around raw pointers when all is said and done.

This fact is exploited in the idiom known as pimpl (either "private implementation" or "pointer to implementation"), which solves some of the header file issues by hiding implementation details in the source file. The basic idea is to define a second, private "impl" class within the source file to hold all the private methods and members of the public "interface" class. Your public class then declares a private pointer to an instance of the impl and no other private functions or variables. You still need to forward-declare the impl in the header so the compiler can make sense of the symbol, but includers don't need to know anything about it beyond its name. Revenant might look like this after being pimpled:

pimpl example

// Revenant.h

// forward declaration for the impl
// #includers don't get to know anything about it except its name
class RevenantImpl;

class Revenant
{
public:
 Revenant();
 Revenant(const Revenant& other);
 Revenant& operator =(const Revenant& other);
 
 int GetHp() const;
 void SetHp(int newHp);

 void TakeAttack(int attackPower);

private:
 // all (other) private implementation contained within
 std::shared_ptr<RevenantImpl> m_impl;
};



// Revenant.cpp

#include "Revenant.h"
#include "Armor.h"
#include "ArmorFactory.h"

class RevenantImpl
{
private:
 static const int STARTING_HP = 20;

 int m_hp;
 Armor m_armor;

public:
 RevenantImpl()
  : m_hp(STARTING_HP)
  , m_armor(ArmorFactory::CreatePlateArmor())
 {
 }

 int GetHp() const
 {
  return m_hp;
 }

 void SetHp(int newHp)
 {
  m_hp = newHp;
 }

 void TakeAttack(int attackPower)
 {
  int damage = GetDamageFromAttack(attackPower);
  SetHp(GetHp() - damage);
 }

private:
 int GetDamageFromAttack(int attackPower) const
 {
  int damage = attackPower;
  damage -= m_armor.MitigateDamage(damage);
  // apply more mitigations, etc.
  return damage;
 }
};



Revenant::Revenant()
 : m_impl(std::make_shared<RevenantImpl>())
{
}

Revenant::Revenant(const Revenant& other)
{
 *this = other;
}

Revenant& Revenant::operator =(const Revenant& other)
{
 *m_impl = *other.m_impl;
 return *this;
}

int Revenant::GetHp() const
{
 return m_impl->GetHp();
}

void Revenant::SetHp(int newHp)
{
 m_impl->SetHp(newHp);
}

void Revenant::TakeAttack(int attackPower)
{
 m_impl->TakeAttack(attackPower);
}

This has solved our biggest problems—other coders won't see our starting HP anymore unless they deliberately go looking for it, Revenant's consumers don't need to know anything about Armor, and we can modify the impl all day long without forcing anyone else to recompile.

But we've only solved the repetition problem for the private functions. For the public ones we've actually made things worse since we now need to write each one's signature three times. We also had to jump through some hoops to add deep-copy semantics to the class (another option would have been to make the object noncopyable). Finally, we've got all these stub functions that do nothing but delegate to identical functions in the impl. The performance impact is minimal, but it's that much extra code to read and write. This final point can be ameliorated somewhat by making everything in the impl public and dividing the logic between the two classes:

A more freeform pimpl example

// Revenant.cpp

#include "Revenant.h"
#include "Armor.h"
#include "ArmorFactory.h"

class RevenantImpl
{
public:
 static const int STARTING_HP = 20;

 int m_hp;
 Armor m_armor;

public:
 RevenantImpl()
  : m_hp(STARTING_HP)
  , m_armor(ArmorFactory::CreatePlateArmor())
 {
 }

 int GetDamageFromAttack(int attackPower) const
 {
  int damage = attackPower;
  damage -= m_armor.MitigateDamage(damage);
  // apply more mitigations, etc.
  return damage;
 }
};



Revenant::Revenant()
 : m_impl(std::make_shared<RevenantImpl>())
{
}

Revenant::Revenant(const Revenant& other)
{
 *this = other;
}

Revenant& Revenant::operator =(const Revenant& other)
{
 *m_impl = *other.m_impl;
 return *this;
}

int Revenant::GetHp() const
{
 return m_impl->m_hp;
}

void Revenant::SetHp(int newHp)
{
 m_impl->m_hp = newHp;
}

void Revenant::TakeAttack(int attackPower)
{
 int damage = m_impl->GetDamageFromAttack(attackPower);
 SetHp(GetHp() - damage);
}

This works, but it's ugly. The code is scattered across two locations. Sometimes you need to prefix a member's name with m_impl-> and sometimes you don't, and if you move code from one class to the other, you'll need to either add or remove those prefixes. Further, although I don't show it here, in a real class it's likely that at some point the impl will need to call a function in the outer class, which means it must be provided with a reference to it. All this adds up to one more piece of state information you need to keep in your head when you're reading and writing code, and there's enough of that already.

Interface-based programming: a better solution

A technique called interface-based programming takes things one step farther in an attempt to solve the same problems pimpl addresses without introducing the new ones it creates (I am not the biggest fan of the name "interface-based programming" since that term already has a similar but broader definition, but that's what people call it). With interface-based programming, the header file contains nothing but a pure, abstract definition of the class's public interface and a free or static factory function for creating concrete instances. The concrete class itself lives entirely within the source file. Let's take a look at Revenant again:

Interface-based programming example

// Revenant.h

class Revenant
{
public:
 // static factory function instead of ctor
 static std::shared_ptr<Revenant> Create();
 
 // virtual dtor is essential!
 virtual ~Revenant() = 0 {}
 
 // interface requires clone semantics instead of copy
 virtual std::shared_ptr<Revenant> Clone() const = 0;

 virtual int GetHp() const = 0;
 virtual void SetHp(int newHp) = 0;

 virtual void TakeAttack(int attackPower) = 0;

private:
 // copy not implemented; hide the assignment operator
 Revenant& operator =(const Revenant&);
};



// Revenant.cpp

#include "Revenant.h"
#include "Armor.h"
#include "ArmorFactory.h"

namespace
{
 class RevenantImpl : public Revenant
 {
 private:
  static const int STARTING_HP = 20;

  int m_hp;
  Armor m_armor;

 public:
  RevenantImpl()
   : m_hp(STARTING_HP)
   , m_armor(ArmorFactory::CreatePlateArmor())
  {
  }

  virtual std::shared_ptr<Revenant> Clone() const override
  {
   auto clone = std::make_shared<RevenantImpl>();
   clone->m_hp = m_hp;
   clone->m_armor = m_armor;
   return clone;
  }

  virtual int Revenant::GetHp() const override
  {
   return m_hp;
  }

  virtual void Revenant::SetHp(int newHp) override
  {
   m_hp = newHp;
  }

  virtual void Revenant::TakeAttack(int attackPower) override
  {
   int damage = GetDamageFromAttack(attackPower);
   SetHp(GetHp() - damage);
  }

 private:
  int GetDamageFromAttack(int attackPower)
  {
   int damage = attackPower;
   damage -= m_armor.MitigateDamage(damage);
   // apply more mitigations, etc.
   return damage;
  }
 };
}

std::shared_ptr<Revenant> Revenant::Create()
{
 return std::make_shared<RevenantImpl>();
}

This really gives us the best of both worlds. As with pimpl, the header only communicates the class's public interface. But unlike pimpl, the entire implementation is now contained within a single class. We've also gotten rid of pimpl's stub functions and triple-repeats, though we still had to write the signatures of the public methods twice (that's as good as we're going to do). As an added bonus, Revenant is now a true interface in the technical sense of the word, which means we gain the ability to mock and stub it in tests for free.

A couple details to note: first, since client code can only access RevenantImpl via a pointer to the base class Revenant, it is essential that Revenant have a virtual destructor; otherwise deleting a Revenant would have undefined behavior. If this hadn't been done in the code above, for example, it's likely that the Armor member variable's  destructor would not be called properly, and any resources it held would be leaked.

Second, since Revenant is an interface now, it no longer makes sense to copy instances of it—we need to use clone semantics instead. In addition to adding Clone() to the interface, this means we should hide the assignment operator. If we didn't, someone could get away with writing "*revenantPointer1 = *revenantPointer2". The compiler would accept this, but the call would do nothing since the Revenant interface itself doesn't contain anything to copy.

Inheritance

If I've neglected to mention inheritance in any of the above, it's because I practically never use it—I've been pretty thoroughly converted to the composition camp. But if you want to hide your private implementation and retain the ability for other classes to derive from you, all is not lost. You're pretty much out of luck with interface-based programming, but pimpl can still get the job done. You'll just need to add any protected methods or members you want to expose to your descendants to your header—anything in your private impl will be invisible to them (they'll be able to see the m_impl pointer itself if you make it protected, but they won't know anything about the structure of the object it points to).

pimpl vs. interface-based programming

I've described two different techniques for hiding implementation details in C++ here; how do you decide which to use when? Or when to use them at all? A lot of it is personal preference, but I follow an algorithm that goes something like this:

• I don't bother hiding implementation at all if:
• It's a simple object where any of this would be overkill
• I need all the object's data to be contiguous in memory
• I don't want to allocate anything on the heap
• Performance is so critical that I can't afford either interface-based-programming's virtual calls or pimpl's extra delegations (very, very rare)
• Otherwise, I use pimpl if:
• I need to be able to allocate instances on the stack
• I can't afford the extra overhead of the virtual function calls
• I'm working with some monster legacy class that can't easily be converted to interface-based programming. In this case, I'll add an impl to hold new private data and functionality while leaving everything else the way it is.
• I need to be able to inherit from the class
• Otherwise, the default choice is interface-based programming

Wrapup

Implementation-hiding is one of those game-changing concepts that can radically alter how you design and think about your code. I use it for virtually every class I write these days, and can hardly imagine doing things any other way (every time I have to go back and read something I wrote n years ago before I learned about these concepts, I die a little inside). Interface-based programming in particular has a way of forcing you to design your code in a way that makes it more modular and testable almost by accident. And anything that makes you think about your class's public interface up-front and enforces not just a conceptual but also a physical separation between interface and implementation can only be a good thing.

RingtonePreference and SharedPreferences.OnSharedPreferenceChangeListener

Revision

This problem was actually something different than what I (and stackoverflow) originally thought. RingtonePreference notifies listeners just fine—it has to, because the notification happens at the level of the SharedPreference file, and there's nothing client code can do to shut that behavior off. What was actually happening was this: RingtonePreference launches a new activity that partially conceals the PreferenceActivity. This causes the PreferenceActivity to be paused. And I was unregistering my listener in onPause(). I switched the (un)registration to onStart()/onStop() instead, and everything worked fine.

Original Post

Since I seem to have gotten into the habit of documenting Android framework bugs and surprises as I encounter them, here's another. RingtonePreference doesn't notify the underlying SharedPreference file's OnSharedPreferenceChangeListeners when it persists its changes. A workaround is to register a Preference.OnPreferenceChangeListener on each individual RingtonePreference instead. Just remember that this handler is notified before the change gets persisted to storage, so if you need to use the new value in the handler, get it from the Object that is passed in rather than from the SharedPreferences file itself.

Also remember that both OnPreferenceChangeListener and OnSharedPreferenceChangeListener are notified before any dependency-related updates are applied, so for a Preference whose enabled state is linked to a different Preference, you can't rely on isEnabled() returning the correct value inside either type of handler.

The revamped C++11 auto keyword: blessing and curse

In 2011, the C++11 (aka C++0x) standard was accepted and subsequently implemented at least in part by most major compilers. One of the more talked-about changes to the language was the expansion of the auto keyword.

auto has been in C since the beginning as a way to denote automatic (as opposed to static, register, or external) storage for a variable. But since auto is implied by default when no storage class is specified, no one ever bothered to actually write it. Until 2011. With C++11, the word auto can also be used in place of a type identifier when creating a variable as a way to tell the compiler to deduce the type from context. This change was nominally motivated by a need to support template programming techniques where the type really can't be known until compile time, but what auto really gets used for 99% of the time is saving keystrokes. No longer must you, weary coder, suffer wrist strain from typing out travesties like:

Some::Long::Namespace::SomeLongClassName<SomeTemplateType>* myVar =
   new Some::Long::Namespace::SomeLongClassName<SomeTemplateType>();

Instead, you can write:

auto myVar = new Some::Long::Namespace::SomeLongClassName<SomeTemplateType>();

Voila! auto has nearly halved the number of characters needed to construct a new instance of this particular object. And if that's as far as things went, I doubt anyone would have a problem with it. But like any good thing, auto can be taken too far. The existence of auto means that authors in principle need never write a typename on the left side of an assignment again, and more than a few do exactly that. This certainly makes things more convenient for you as a writer. The problem is that—hate to break it to you—the writer's convenience doesn't matter. Code should always be written for the convenience of the reader. The crucial question, then, is: does auto make code easier or harder to read? And the answer to that question, as usual, is that it depends.

But before going further, let's address a couple pro-auto arguments I simply don't buy. You'll hear that if you really want to know what an auto is, any modern IDE will have intellisense features that can tell you with little fuss. With C++ that may or may not be true. C++ is a notoriously difficult language to parse in real time, and while there are a bunch of tools that can make reasonable guesses and be right most of the time as long as you don't try to do anything too tricky, only the compiler is able to make a final, authoritative judgement. Further, code is not always read in an IDE. If I'm doing a diff, or getting a snippet in an email, or reading something that's been posted online, there are no tools available to help figure out what that auto actually is, and I just have to hope it doesn't matter.

Next, some people will tell you you shouldn't be overly-concerned with types when you're reading code anyway, and that it's better to create good variable names and have the types abstracted away so you can reason about the code at a higher level. And if a high-level overview is what I'm after, that may be a valid point. But what if it's not? What if the code doesn't work, and the whole reason I'm reading it is to figure out where it's wrong? Bugs and the devil are in the details, and they're that much harder to find when the details are hidden. Now, if I've got decent intellisense (again, by no means a given with C++), I can hover over a variable name and get a popup telling me what its type is. But I'll probably forget as soon as I start thinking about something else, especially if there are multiple auto variables I'm trying to track at the same time. When you're debugging, you want to maximize the amount of information you can access at a glance. auto is your enemy here.

Others will claim that auto makes refactoring easier. If GetValue() returns int, but everyone who calls it stores the result in an auto, I can later change it to return double without breaking compilation all over the place. My response to that is if you're going to change something as fundamental as a function's return type, you darn well better take the time to examine each and every caller and make sure it will still function correctly after the change. The fact that the code won't compile until you do so helps enforce that sort of diligence, and using auto to get around the "problem" just makes it that much easier to write bugs.

So when is it ok to use auto? My opinions are always evolving and I've gotten quite a bit more permissive as time has gone by, but here are the cases where I currently allow myself the convenience:

1) The type already appears on the right-hand side of the expression.

auto somethingConcrete = dynamic_cast<LongConcreteName*>(somethingAbstract);

We're typing enough here already without repeating LongConcreteName. I don't feel the slightest bit of ambivalence about using auto in these situations.

Sometimes the type isn't strictly quoted on the right side, but can be confidently deduced from what is there.

auto mySuperWidget = SuperWidget::Create();

SuperWidget::Create() had better return a SuperWidget. True, we don't know if we're getting a SuperWidget*, a shared_ptr<SuperWidget>, or a stack SuperWidget. This used to bother me and I can contrive situations where making the wrong assumption would cause a bug, but I've learned to be a little flexible here. These days I tend to always return shared_ptr from my factory functions, so I typically use auto in those cases and only write the type out when it needs to be something different.

A more dicey example is something like this:

auto mySuperWidget = myWidgetFactory.CreateSuperWidget();

Am I getting a concrete SuperWidget? An ISuperWidget? An IWidget whose concrete type is SuperWidget? I go back and forth on cases like this. It comes down to how much ambiguity there really is given the classes and interfaces that really exist in the codebase, and what kind of mood I'm in.

2) You're capturing the return value from some function, and you're not doing anything with it except passing it off to someone else.

auto result = ComputeResult();
return FilteredResult(result);

This is not fundamentally different from:

return FilteredResult(ComputeResult());

3) You're capturing the return value from a well-known library function that any likely reader will be familiar with.

auto it = myStlCollection.begin();

I think it's safe to assume that anyone who's working with a C++/STL codebase will know that begin() returns some sort of iterator. In addition, the full typenames for STL iterators are really ugly if you have to write them out completely. Which leads to...

4) The actual typename is really long and ugly. A project I'm working on right now has a function that returns:

std::shared_ptr<Reactive::IObservable<std::shared_ptr<std::vector<double>>>> 

(it actually has quite a lot of functions that return things of that sort). Although having that all in front of you does communicate a lot of important information, this is a case where the inconvenience of having to look the type up may be less than the inconvenience of having a nearly 80-character typename filling up the screen. In situations like these it's usually better to use a typedef to communicate the gist of the type with a smaller number of characters (although many of the complaints I have about auto work against typedef too), but if you have a whole bunch of functions all returning ugly types and they're all just a little bit different from each other, that may not be practical.

What all of these except #4 boil down to is simply this: only use auto when the reader will know what the type is anyway. If I only got one rule, that's what it would be.

Used, properly, auto is great for both writer and reader. After getting used to having it, I've been surprised how frustrating it is to work in languages like Java that lack an equivalent, and I certainly wouldn't want to go back to the days before it existed. But used willy-nilly by authors who don't want to type ten characters instead of four, or (worse) who can't be bothered to check what the result of some expression is, it can lead to incomprehensible, bug-prone code that can't be debugged. Enjoy responsibly.

Listening to Preferences

We'll keep this one quick. Before you spend a frustrating evening trying to figure out why sometimes your SharedPreferences.OnSharedPreferenceChangeListener is called and sometimes it isn't, and before you take up astrology due to a growing conviction that it is somehow related to the alignment of the stars, take note of the fact that SharedPreferences stores its listeners internally as weak references (with good reason; see addendum). No, they don't bother to document this fact. So if you do this:

PreferenceManager.getDefaultSharedPreferences(this)
    .registerOnSharedPreferenceChangeListener(
        new SharedPreferences.OnSharedPreferenceChangeListener()
        {
            @Override public void onSharedPreferenceChanged(
                SharedPreferences sharedPreferences, String key)
            {
                // do important things
            }
        });

your anonymous listener immediately becomes a candidate for garbage collection. But you can't predict exactly when that will happen. Sometimes it will work (for a while), sometimes it won't. Do this instead:

mListener = new SharedPreferences.OnSharedPreferenceChangeListener()
{
    @Override public void onSharedPreferenceChanged(
        SharedPreferences sharedPreferences, String key)
    {
        // do important things
    }
};

PreferenceManager.getDefaultSharedPreferences(this)
    .registerOnSharedPreferenceChangeListener(mListener);

It's one more obnoxious member variable to keep around (or interface for your class to implement if you choose that route), but it's what you've gotta do.

Addendum

I think it actually makes good sense to use weak registration for observers, and that is in fact how I have typically implemented things in my own frameworks (in a perfect world, observers could choose whether they wanted to register strongly or weakly). The reason is that strong registration can easily lead to memory leaks when the observed is a persistent object and the observers are (meant to be!) transient. If SharedPreferences did in fact use strong observer registration and I did something like the first code snippet in an Activity, it would be a big problem--since the anonymous observer has an implicit reference to its outer class and there is no way to unregister it, the Activity object would be leaked and kept alive until whenever the SharedPreferences was destroyed. In my case the outer class is the Application object and I want that observer to stick around for as long as my app is running, but I imagine it's concerns like these that led to the choice of weak registration in the first place.

So: a sound decision, but since it differs from the decision made in (so far as I know) all other cases, they should have documented it. :)

Dynamic BroadcastReceiver Registration and Explicit Intents

Suppose your Android app posts a notification, and suppose you'd like to be informed when that notification is dismissed. There are a variety of good reasons you might want to do this--in my case, I wanted to avoid annoying a user who'd actively removed my notification by re-posting it the next time I had progress to report.

The Plan

Android provides a (relatively) straightforward mechanism for detecting when a notification you post is dismissed: you can attach a PendingIntent to its delete action. Seemed fairly simple; the plan was:

1. Define a String called notification_dismissed to identify the dismiss action.
2. Create a BroadcastReceiver and have its onReceive() react to notification_dismissed by setting an mIsNotificationVisible flag to false.
3. Use PendingIntent.getBroadcast() to create a PendingIntent that will broadcast notification_dismissed when it's triggered. For security reasons, make this an explicit intent that will only deliver to my specific BroadcastReceiver class.
4. Use Notfication.deleteIntent() to attach the PendingIntent to my notification as its delete action.
5. Use Context.registerReceiver() to register an instance of my BroadcastReceiver with the system (registering through the manifest would have caused a new BroadcastReceiver to be instantiated for each notification, which would have made it tough to get to that mIsNotificationVisible flag without doing something ugly).

The Problem

The plan sounded good, but it had one small flaw--it didn't work at all. My BroadcastReceiver simply wasn't called when the notification was dismissed. After a few hours of pulling my hair out, I stumbled upon a solution more or less by accident. If I used an implicit intent (i.e one that is not addressed to a particular class) instead of an explicit one, everything worked fine. It seems that a dynamically-registered BroadcastReceiver cannot receive explicit intents (one mikro2nd describes this is a little more detail. If only I'd found that post about 5 hours earlier!). So far as I know, this is not documented anywhere.

I could have stopped there, used implicit intents, and everything probably would have been fine. But I really didn't like the security hole it would have created (imagine some malicious app catching your broadcasts and reacting to them by popping up a dialog that impersonates you).

The solution

They say all problems in computer science can be solved by adding another layer of abstraction, and so it proved here. My solution was to add a second BroadcastReceiver that would accept explicit intents and rebroadcast them internally as implicit intents using a LocalBroadcastManager.

Since the original intent is explicit, malicious apps cannot intercept or mimic it. Since the secondary implicit intent is sent through a LocalBroadcastManager, no one outside my app can see it. Best of both worlds. In more detail:

1. Create a BroadcastReceiver named Rebroadcaster and register it in the manifest without an <intent-filter> (this means it can only receive explicit intents, which is what we want).
2. Rebroadcaster creates a copy of each Intent it receives, calls setComponent(null) on the copy to make it implicit, and then sends the copy out through the LocalBroadcastManager.
3. Address the notification's deleteIntent to Rebroadcaster.
4. Register the final BroadcastReceiver with the LocalBroadcastManager instead of a Context.

tl;dr

Dynamically-registered BroadcastReceivers can't receive explicit intents. If you're not comfortable sending implicit broadcast PendingIntents outside your app, you can use a separate statically-registered BroadcastReceiver to accept explicit intents and rebroadcast them internally as implicit intents through the LocalBroadcastManager.

The code

Rebroadcaster:

public class Rebroadcaster extends BroadcastReceiver
{
  @Override public void onReceive(Context context, Intent intent)
  {
    LocalBroadcastManager manager = LocalBroadcastManager.getInstance(context);
    if (manager == null)
      return;
    Intent modifiedIntent = new Intent(intent);
    modifiedIntent.setComponent(null);
    manager.sendBroadcast(modifiedIntent);
  }
}

In the manifest:

<!-- No intent-filter means we can only receive explicit intents. -->
<receiver
  android:name="packageName.Rebroadcaster"
  android:exported="false"
  />

Creating the PendingIntent:

private PendingIntent getNotificationDismissedIntent(Context context)
{
  Intent intent = new Intent(context, Rebroadcaster.class);
  intent.setAction(context.getString(R.string.notification_dismissed));
  return PendingIntent.getBroadcast(
    context, NOTIFICATION_ID, intent, PendingIntent.FLAG_CANCEL_CURRENT);
}

private Notification buildNotification(Context context)
{
  return new NotificationCompat.Builder(context)
    // lots of configuration
    .setDeleteIntent(getNotificationDismissedIntent(context))
    .build();
}

Registering the real BroadcastReceiver:

final String deletedAction = context.getString(R.string.notification_dismissed);
LocalBroadcastManager.getInstance(context).registerReceiver(
  new BroadcastReceiver()
  {
    @Override public void onReceive(Context context, Intent intent)
    {
      if (intent.getAction() == null)
        return;
      if (!intent.getAction().equals(deletedAction))
        return;
      mIsNotificationVisible = false; // member of enclosing class
    }
  },
  new IntentFilter(deletedAction)
);