This is the first of a series of posts on our most recent Stampy Day, a company-wide hack day here at Paperless Post. We hope you enjoy reading about some of the projects that came out of that day.

This Stampy Day, Ivan, Teresa, and I decided to play around with Android to see if we could get a very minimal Paperless Post app working. Our goals for the app were to create a home page with package promotions, to get a simple tab bar working to switch back and forth between views, and to load and display some basic packages from the PP API.

The parallels between the general structure of iOS and Android apps were immediately apparent. Each page usually consists of a controller that contains a root view. There are callbacks for every change in the view/controller lifecycle, from its creation, movement to the foreground and background, and deallocation, among other things. There is a navigation stack that is automatically maintained by the system. There are even similar UI elements like table views and grid views, with similar delegation patterns for supplying these UI elements with the data it needs to configure itself.

Despite feeling at home with Android after some basic tutorials, I found a number of things I really didn’t like. I wish to discuss only one of them here in the interest of brevity.

The thing that stood out most to me was the concept of an Intent. Android allows you to send an Intent to certain objects, which is basically a data structure that holds arbitrary information. The object that receives the Intent is then supposed to use this information as it sees fit. This pattern is often used when creating a new Activity (Android’s poorly named version of the UIViewController, basically a controller containing a view hierarchy). One Activity will pass an Intent to a new Activity so that the new one can use the information provided in the Intent to set itself up.

In order for one object to send a useful Intent to another object, it must know what the other object needs, yet I found no clear way for this second object to enforce or signal to other objects what exactly those needs are. This is in contrast to an interface in iOS, where an object will provide you with a method for initialization, specifying exactly what parameters it needs when initializing itself.

The object sending the Intent therefore must make certain assumptions about what the receiving object needs, based on the programmer figuring that out by looking at the internal implementation of the receiving object. This is very prone to breaking because if the internal implementation of the receiver object ever changes, its needs might change, yet outside objects have no idea, and even worse the receiver object itself has no way to tell them! In iOS, we might simply change the method signature of the initialization method to include a new parameter, and any other object calling the old initialization method would no longer be calling a valid method. This would simply cause the app to not compile.

This seems like a blatant violation of the basic design pattern paradigm we all know as decoupling. In the case of one Activity presenting another, the presenting activity is coupled to the presented activity because it is relying on the internal implementation of the presented activity in order to set that activity up.

Overall, playing with Android was a fun and worthwhile experiment. It was cool to see another perspective on native mobile development. For the record, we did get a solid homepage (though with weird image drawing issues) working, with a tab bar and some paper packages loaded in a list view.