Application Structure and Composition

Recent mobile application models impose some surprising straightjackets that defeat the ability to compose applications from constituent parts.

On the desktop, composition support is de rigeur. On Windows it’s possible because there simply aren’t many rules. Want to use a DLL that uses another DLL that loads some external resources? There’s an API for that. Well, APIs, anyway. You can string them together by solving for units, which by the way also works wonders in high school physics.

On Mac OS composition is by design. Which is fortunate, since otherwise it probably wouldn’t be allowed. Depend on a framework? There’s a place to put it. Framework depends on another framework? Yes, there’s a place for that, too. All places rationally named, everything is a bundle, layout standardized.

iOS? Not so much. Mostly because dynamic code loading isn’t allowed, at least not outside of OS frameworks. We have to revert to linking everything together into one big blob. And then all linker symbols appear in a common namespace, so we’re denied the pleasure of embedding multiple copies of the PNG library into the same application without modifying any of them to use unique prefixes.

The real surprise for me, though, was Android. Surely an open platform would support composition? But alas, resources on Android get compiled into one big block of unique IDs. No way to use this mechanism to create a library beforehand with its own set, because there’s only one R.java file to rule them all.

No doubt there’s a method to the madness that I just can’t see. Maybe they can break it down into pieces for me.