Hacking Instagram

This week saw the release of Instagram. The app has been a huge hit on the iPhone and so it has been eagerly awaited on Android. Will it be as big a hit on Android? Who knows. However it has certainly caused its share of controversy. From my perspective as a long time Android user, I have a couple of complaints. First, it looks like an iOS app, not an Android app. Whenever I see an app like that, I figure the makers are lazy and don't really care about Android users. The app still might be useful, but it creates an expectation of poor quality for me and definitely curbs my enthusiasm. Still, this is something that can be overcome.

My second complaint is that Instagram just does not play well with others. What I mean is that most Android apps make use of Android's use of typed sharing (i.e. I want to share a picture, or a link, or a video, etc.) to allow you to create or find something with one app, and share it with another. Instagram does not allow this. Now it does let you share something to Twitter, Facebook, or Tumblr. Even better, it lets you share to all three at once. That's a great feature. However, your sharing is limited to what the makers decided to put it into, and that's too bad. What if I want to share to Path or Google+? The only place where Instagram allows you to use another app for sharing is for a picture that you have already taken. Then it doesn't let you share the picture, but only a URL to the picture on the Instagram website.

Now I definitely understand part of why Instagram does things this way, or at least I think I do. I think Instagram wants to be a social network, first, and provides a mobile app simply as a way to create content for their network. So any "sharing" is a link back to the Instagram social network. Allowing me to create a photo with Instagram and then share it to Path with no link back to Instagram would be of no value (perhaps even negative value) to Instagram. However, it might be of value of me. And maybe to you too. So here's how to do it.

First off, go ahead and create a picture with Instagram. Take a pic, apply filters, borders, etc. just like usual:

Now when you get to the Upload screen, just exit Instagram. Of course you can upload it and use their sharing options if that is interesting to you. If you want to share you creation in some other way, open up your Gallery app and look for the Instagram folder. Your creation will be in there, and you can then select it and share it using the app of your choice:

You can also copy the photo from you phone; it's stored in /Pictures/Instagram. The point is that you can take advantage of some of the photo editing tools in Instagram, even if you have no interest in the Instagram social network, and even though Instagram doesn't support this kind of usage. Of course there are already a lot of other photo editing/sharing apps available on Android. Some of my favorites are Lightbox, Camera ZOOM FX, and Diptic. 

Diversions in C Minor

Last year we saw the passing of Dennis Ritchie. I was one of the lucky students who used the K&R book as a text book in college. Actually it's pretty amazing that the text books for CS first years were K&R and The Mythical Man-Month. There was pretty much no excuse for me to F up after being taught from those two books. The untimely passing of Ritchie made me recollect that I never really finished K&R. My professor used many of the chapters as reference material, and of course at some point I figured that I already knew everything so well that I didn't need no stinkin' book. So I decided then that I would re-read the book including all of its problems.

Of course I didn't start re-reading K&R right then as I should have. But I did get around to it recently. The very first problem in chapter two asked the reader to calculate the minimum signed chars, shorts, ints, and longs, and the maximum of those plus their unsigned cousins. These are all very straightforward things to calculate for anyone with an understanding of modular arithmetic. The book then mentions a more challenging problem: calculating minimum and maximum floats. No problemo I thought: Obviously that doesn't work, or this would be a pretty boring blog post. Here's where the awesome comes in. On my MacBook Air, this prints 1.175494e-38 for FLT_MIN but the second line prints 1.401298e-45 for the "calculated" minimum float. That's right it calculates a value that is smaller than FLT_MIN.

Experienced C developers will surely recognize what is going on here but I was flummoxed. It was only upon looking at some of the other constants defined in float.h that I started to figure out what was going on. In particular I noticed that on my MBA, FLT_MIN * FLT_EPS = 1.401298e-45. FLT_EPS is "float epsilon" and is defined as the smallest x for which 1+x != x. This is sort of the standard error on the system, i.e. any calculation could be off by a factor of FLT_EPS. I decided to calculate this in my program and then to also use it to calculate FLT_MAX: The FLT_MAX calculation takes a long time, since it uses such a small increment. I'm sure a bigger increment could be used to speed it up.

The JavaScript assembler

Earlier this week, the third part in a series of articles I wrote was published on developerWorks. The series is on CoffeeScript, a language that I first learned of about a year ago. Last summer I read CoffeeScript by Trevor Burnham over the course of a week while on a cruise ship. Later that summer I was at the Strange Loop conference, and serendipitously wound up at a dinner table with several of the guys who develop Clojure. A lot of the conversation that evening was on ClojureScript.

As a  long time web developer I am not surprised by the growing interest in programming languages that compile into JavaScript. The browser has never been more important, and thus JavaScript has never been more important. Most programmers that I know find that JavaScript leaves a lot to be desired. This is not just a matter of taste, JS is fucking weird. In fact for years, a lot of the more "serious" programmers I knew would turn up their noses at JS. They were too good for that trash, so they kept to the back-end. It's become tougher and tougher to avoid JS, so ... use a different programming language that compiles to JS. Brilliant!

This idea is hardly new. Personally, I can't help but think of Google Web Toolkit. For years GWT has let your write in Java and compile to JS. So why bother with CoffeeScript, ClojureScript, and probably some other awesomes that I'm leaving out? One obvious thing is that Java is an existing language and is statically typed. So it has its own baggage (which includes excellent tooling, but still) and of course many developers do not like statically typed languages. In fact, many argue that web development with a statically typed language is an impedance mismatch of the highest order. Personally I think GWT was also hurt by initially defaulting to producing highly obfuscated "production ready" JS. I always thought that was developer unfriendly. I think that may have changed over the years, but sometimes it's hard to overcome an initial impression. I think one of CoffeeScript's great strengths is that it produces very developer friendly JS by default. I've never built any huge apps in either language, but in my limited experience I found that debugging was easier in CoffeeScript. I could usually figure out what I had done wrong just by looking at the error message.

Any discussion like this would be amiss without mentioning Dart. It gives you dynamic and static aspects, in a way that reminds me of ActionScript. Personally I think optional typing works best when use variable:type style declarations, like ActionScript and Scala, but that's a minor nit. Of course when you consider that "native Dart" is supported in a version of the world's most popular browser, the possibilities start to get really interesting. I attended a Dart meetup recently where the Chrome developer tools allowed breakpoints and the like directly in the Dart script that was running. The SourceMap proposal would allow this kind of debugging of other higher level languages like CoffeeScript and ClojureScript.

The future seems bright for languages targeting a JavaScript runtime. I haven't even mentioned node.js and how that makes these languages viable for both client and server applications. To me CoffeeScript, Dart, and ClojureScript are all promising. Each seems to have a large target audience. If you like dynamic languages like Python and Ruby, CoffeeScript fits right in. If you prefer statically typed languages like Java and C++ and all of the nice tools that come with them, then Dart is attractive. If you like pure functional languages like Haskell and Lisp, then ClojureScript is a fun way to get your lambda calculus kicks in the browser. Of course there is a lot of anti-Lisp bias out there, so maybe there's room for another functional language that targets a JS runtime, something like a F#-script or ScalaScript.

Mobile Application Architecture, Part 3

[Note: So it's taken me a long time to get this third part out. I changed jobs in the middle of writing all of this, and there's a lot to learn at the new gig. Also in case you are wondering, this is heavily based on my experiences working on eBay Mobile for Android and Bump for Android. Both apps use an event driven architecture in places, or at least they did while I was working on them. What follows is not the secret sauce from either application, but some good things that were common to both along with some ideas for improving on the patterns.]

This is the third post in a series on the architecture of mobile applications. In the first post we looked at the classical architecture of mobile apps that evolved from web apps. In the second post we looked at event driven architecture and when it should be used. Now we're going to dive a little deeper into event driven architectures and in particular talk about some of the significant design decisions that must be made and the pitfalls that need to be avoided.

So you say you want an event driven architecture? I'll assume you've done your homework and aren't just doing this to because it seems like the cool thing to do. I'll assume that it really fits your application. One of the first things that you will realize as you get started is that event driven architecture does not exempt you from many important aspects. Security is a great example. You must figure out how you will authenticate with your server and how to secure any sensitive information that you send over the wire. Just because you are no longer in the world of HTTP and HTTPS does not mean that you get to send over people's credit card numbers in plain text. It's not any harder to sniff your bits and chances are that you are just as vulnerable to things like man-in-the-middle attacks. So go read up on things like TCP headers and TLS.

Once the basics are in place, you can think more about the architecture of your application. Your servers are going to be sending events to your application. So what is going to receive them? Do you have each UI (controller, Activity, etc.) receive them? How about something that is more long-lived. The most important thing to remember is that whatever receives events generally has to be able to deal with any kind of event. You can never assume that just because your controller only cares about some small set of events that those will be the only events that it ever receives. Thus you probably need to have an event receiver whose lifecyle extends beyond that of any given screen in your application and can handle any and all events. Now keep in mind that it will often delegate events to other components in your application, so no need to worry about this global receiver being stuffed with knowledge of your app. On Android you could use a Service for this or even a subclass of Application. You could also create some other singleton object that is tied to your application's lifecycle.

Now you might ask does this really need to be a singleton? Not necessarily. However I think that in many (most?) circumstances that a singleton will simplify things for you. What happens to those events that are not needed by the UI? Such events probably mutate some internal state of your application. If that internal state is transient, then it probably makes sense for there to be only one copy of it. If it is persistent... 

Inevitably there will be some events coming in from your server that you do care about at the UI level. These things will probably be "second-hand", i.e. the events will have been received by the longer-lived object we talked about above. Now you need to deal with how to get these events to the UI. The most accepted way to do this is to use an Observer pattern. You define an interface for an object that cares about a certain event (or certain set of related events potentially.) Then the object registers itself with the central receiver. When a new event comes in from the server, the central receiver examines it and decides on who to delegate it to.

I must add a few words of caution here. For each event you can easily wind up with a class for the event's data structure, an interface for the observer, and an implementation of the observer. The last of these things is often handled by having the Activity/Fragment/controller implement the interface, or by using an anonymous inner class to implement it. In any case, you wind up with multiple types being defined for each event. So if you have many types of events that your server will push to your application then you can end up with an explosion of code. Android developers should consider using Handlers and Messages as a leaner, more de-coupled solution. The big downside is that you may windup doing manual type checking and casting. This can be avoided by late binding, i.e. keep the data from the server raw as long as possible and do the parsing after the dispatch to the observer.

Finally I will close this long series of posts with a brief word about server side technologies. This post in particular has focussed on how to write your mobile/client applications with an event driven architecture. There is a flip-side to this and that is how to implement an event driven architecture on your server. Just like in our classical architectures, most servers are dominated by HTTP. That is not only the default interface into them, but it is at the heart of the server's architecture. A connection is a short-lived, usually stateless object. There is generally a one-to-one mapping of HTTP requests to either threads or processes. This is a poor fit for event driven architectures where a connection is extremely long lived. It only dies when the client app dies or explicitly closes it for some reason.

Fortunately there are numerous server side technologies that do not use the request-per-thread/process model. Certainly the most hyped one of these is Node.js. The Internet is chock full of benchmarks showing how Node's non-blocking out-scales Apache, Nginx, etc. However there are numerous other event driven app servers in Python, Java, Ruby, etc. Personally I have a bias towards my ex-colleague Jamie Turner's Diesel framework. The point is that there are many choices on the server and I expect that you will see many more moving forward.