Macadamian Blog

The Smartphone as a Distributed Computing Platform

A while ago, a friend of mine asked me about some mad-scientist research I have been doing on and off for the better part of a decade. It rekindled my interest in the project, and led me down a path of re-architecting my project to leverage the mobile network (more on that in a minute). In so doing, I realized that the though process I was going through to pick a Smartphone platform was probably similar to what every Smartphone developer goes through in trying to decide on which platform they were going to place their bets.

A bit of history: I had started the work in PERL, largely because it was portable, supported anonymous functions (otherwise known as lambda expressions), and self-modifying code. Not only that, but with a bit of hacking, it's capable of re-writing its own source files for on-the-fly re-interpretation of code. It had everything I needed to jump-start my research, with the exception of a captive audience.A big audience is crucial for my experiment. My theory is that given enough resources and minimal external stimuli, software can self-grow and expand beyond its original capabilities, mimicking organic life (and allowing me to take over the world!).

So, instead of using big-iron servers, which would be limited to running a handful of simulations at a time, I needed to use a distributed approach. Typically, you'd use desktop cycles, but I got thinking about mobile platforms. There are more than 50 million smartphones, they pack a lot of processing power, and best yet, can be easily accessed via the already defined app stores. Moreover, with a bit of marketing, mobile users could be swayed to spare a couple cycles, as long as it didn't have a big impact on battery life or carrier charges.

And so, with a baggage of PERL code and no audience, I decided that starting over with a mobile architecture might be my best bet. The mobile framework would need to be portable enough to let me run the code on and off the device with little recompilation, let me use of external libraries, and have the ability to manipulate anonymous functions or classes.

iOS and Symbian came up short. Even though they had most of the support I needed, like multi-tasking, their closed-development nature meant that the project would forever be tightly coupled with the devices.

Next on my list was Windows Phone 7. With support for .NET and the amount of research Microsoft was pouring into it, it had potential. But, its lack of multitasking, stringent limitations on hardware access, and sluggish market uptakemade it a non-contender, at least for now.

Finally, that leaves me with the Java-based OSes, Blackberry and Android. Since RIM had put its weight behind Java ME with its highly limited library set, and recent announcement on moving to QNX, I was weary to place my bets on the Blackberry. That leaves Android. It matches my criteria almost verbatim, and what it lacks (running of external libraries), it makes up for in a huge community of like-minded developers and supporters that are willing to go the extra distance.

Even though each platform has it's own appeal, Android marries the best of both worlds. Don't be swayed by hype, or who's first to market, when choosing which platform to support. Some platforms will support what you are trying to do better than others - as we found out the hard way, video on Blackberry is a pain. More importantly, which platform is your audience using? For my project, it's Android. If you're selling enterprise software, it might be Blackberry.

Stay tuned for more as I work on my organic smartphone experiment, and try to take over the world.