So recapping from the last post, we're now on a mission to build the ultimate smartphone development and runtime environment. Let's call it Project Portland both because I live near Portland as well as I like the alliteration (would be cool to get to at least three letter Ps though—perhaps Perky Project Portland?). While there are going to be lots of requirements for Project Portland, we know for certain that we are going to need at least one programming language. So which one(s) to choose?

Firstly, let's stop that multiple language nonsense right now. Perhaps it's because I've been entrenched in Microsoft's excellent .NET Framework for too many years, with its Common Language Runtime (and now the Dynamic Language Runtime) where multiple languages all compile to an Intermediate Language which is then executed within the .NET runtime. It doesn't matter if you start out in C#, Visual Basic .NET, managed C++, NetCOBOL, etc. because it all compiles down into IL. Coolness. But is that what we want for Project Portland?

I'm going to say, "No. Not this time. Thanks, but you only get one language." Why? Because we're starting fresh, there's no legacy that needs to get ported over, and we don't want to create sets of examples in the SDK for each language. We don't want any development environment to have to support multiple compilers, templates, debuggers, etc. For Project Portland, we're going to put a stake in the ground and pick just one language.

But which one to choose? There are lots of options, including:

• Java
• ECMAScript (JavaScript/JScript)
• C#
• C/C++
• Ruby
• PHP
• Perl
• Python
• Etc.

The first thing to consider in selecting the language is to better understand what we are going to be using the language for. We want to write general purpose smartphone applications that run on any phone. Do the programs need to run quickly? Yes, of course. But are people going to be performing complex scientific analysis on their smartphones? Nope. So that means scripting languages like Ruby, Perl, and Python are still in the running.

Another key requirement: we need our code to run on a variety of hardware devices. Lots of phones have ARM-based processors, but there are plenty of other CPUs floating around out there. So a strictly compiled language like C++ is a bit dangerous because we'd need compilers for each CPU instruction set. So let's scratch C/C++.

C# is a Microsoft's .NET language. Probably going to be licensing issues with that, so it's cut. Same deal with Java proper—Sun holds the reins on that one, so strike it. Bummer in both respects as I love C# and don't hate Java…

That leaves us with scripting/dynamic languages like: JavaScript, Ruby, Python, Perl, etc. I like the advantages offered by coding with an object oriented language, so good-bye Perl. Recent versions of PHP support object-based features, but PHP was originally designed to run server-side and spit out HTML. And I don't really like PHP's syntax, so, PHP, it's game over.

I believe that leaves us with three contenders, one heavyweight and two middleweights: ECMAScript, Ruby, and Python. ECMAScript is of course the 800 pound gorilla since every web browser under the sun supports it. Ruby is the up-and-comer especially thanks to the Ruby on Rails implementations. And Python is just Python.

Despite the massive support for ECMAScript, its object-based but not object-oriented syntax is off-putting to me. And because some of solution design currently stuck in my brain needs the backing language to be nicely object-oriented, ECMAScript isn't going to cut it. Plus, I just don't like coding in it and most of my colleagues that live in that world echo similar feelings. You're cut too, shushie!

So that leaves Ruby and Python. I looked at Python about ten years ago when I was tinkering with a prototype system for scripting XML-based objects and calling them via HTTP (if only I'd finished up that project!). I liked Python, and it was very easy to embed the interpreter into my own code, so that's a huge plus.

I haven't done squat with Ruby. I remember also looking at it before the whole "Ruby on Rails" thing and finding it interesting, but I didn't have any practical use for it. Now with the Rails craze, it seems like it would be a bad idea to ignore it since if Project Portland came out with Ruby as one of its foundations, it would likely get much more attention than if PP runs on top of Python. I have done some cursory research (read "Google queries") and it does appear to be a bit more work to embed Ruby into your own stuff—possible but not terrifically supported by the Ruby community and a lot of "wait until 2.0 comes out to make it better." So I think there would be a bit more work required there, but perhaps worth it from a marketing/"buzz" perspective.

So I'm going to spend some time comparing these two scripting languages within the context of smartphone development, pick one over the other, and (hopefully) justify why the winner is superior in this case.

Like so many bloggers out there, I must begin this blog entry with, "I apologize that it has been so long since I last made a post. I got caught up with…" In my case, however, the delay since the last post has not been because I didn't have the time to write, it was because I didn't have a clear idea of what to write. Heck, that's the excuse I used to not write a blog for the past three years. And you'd think I had set myself up pretty well this time with a roadmap detailing the challenges of smartphone development—a new blog entry for each challenge should keep me writing for a long time.

But I suppose what's slowed down the writing is that enumerating challenges isn't particularly motivating. Even discussing solutions to each of those challenges since doesn't ring my bell because the items are treated separately and without a comprehensive context. So you should use vector-based graphical elements for your user interface rather than bitmapped ones. Okay, thanks for that tip. So there are different screen resolutions and dot pitches and you should be prepared to handle them. Um, duh.

Someone the other day called me "cynical", and while I prefer to think of myself as full of "dry wit", "ironic", or "sarcastic", let's go with the fact that all of those are in the same family. The bottom line is that when I'm tackling the tough problems (career-wise that is), I find myself doing a lot of deconstruction rather than construction, at least initially. I don't like to buy the marketing hype right out of the box. I want to tear down a problem domain to its fundamentals, then build up the solution space one base-level component at a time after each component has proven itself worthy.

And that was the approach I was going to take to blogging about smartphone development. Pick apart all the tough stuff and offer up solutions. At the end, we're all armed with a toolbox of patterns and approaches to navigate our way through Smartphoneopia to nirvana (and yes, smartphone development is along that path to enlightenment). But just having a box of tools leaves us with just that—tools. How excited can one get about a hammer? Or at least, how long can one be excited about a hammer? (some hammers are cool) But if there is something we could build with the hammer…

The above is a long-winded way of saying that rather than cynically working our way through the various aspects of smartphone development, let's define something to build instead. We need the "children's playhouse project" analog in the smartphone world. In fact, we need the "mansion project" of the smartphone world--why set our sights so low? (Of course, my children are now on year three of waiting for their playhouse to be finished… ;-)

Here's what I want to build: the ultimate, next-generation smartphone development and runtime environment. Period. Endo story.

Will I, you, us, or anyone else actually build such a thing? Doubtful. But working through all of the issues involved to build such a "mansion" will force us to face the issues surrounding current smartphone development and define patterns, best practices, and other patterns to apply constructively within this "solution space." So even if we don't actually create L'Environment Smartphone Magnifique, perhaps we'll learn something along the way, and perhaps existing smartphone and tool vendors will pick up a thing or two (email me for licensing terms :-) and incorporate them into their current products to make everyone's lives a bit simpler.

The Vision

Here's what I want. I want to pretend there is only one smartphone platform in the world. I don't want to care how big its screen is, what its dot pitch happens to be, whether or not it can switch between portrait and landscape mode, how many "real" buttons it has, how many "soft" buttons it has and where those are on the device, what CPU it's got, what manufacturer made it, what operating system is running on it, whether or not it has a still camera or video camera, how many different storage media types it has and how to access them, how it connects to the Internet, how to connect to contacts, how to make a call, how to receive an SMS/MMS message, how to play media files, and on, and on, and on.

I want a development environment that assumes one and only one platform. I want a runtime environment that runs on every device. I want one way of programming to this virtual device. I want a device simulator that runs at blistering speeds so I can test the heck out of my code, then I want to switch it into "emulator" mode so I can experience what end-users will experience. I want canned and customizable device profiles so I can see/test my application's behavior when large feature chunks aren't available (e.g., GPS support) or how my UI reacts to various screen sizes. I want great support for scriptable testing into and out of that simulator so I can create continuous builds of my product that are constantly retested every time a developer checks in a code change.

I want to write code once and have it run everywhere, and in this case "everywhere" means in someone's pocket while they are crawling on their hands and knees in some equatorial desert with a Nokia phone, or dog sledding in an arctic wilderness with a Motorola Q, or in Manhattan with a BlackBerry. I don't want any special-case code to work around defects or other idiosyncrasies of some vendor platform (e.g., "#IF NOKIAS60 #ELSEIF RIM #ELSEIF WINCE4 …"). I want the end user experience to be simple and so identical across all smartphones that I don't have to create device-specific installers, FAQs, and support pages. I want to train customer support reps on the specifics of my application only, not the particulars of each hardware device. And I want install to be as simple as a user navigating to a web page.

"Impossible!" you say? "The devices are too different! The operating systems don't work the same way. It can never be done!" Don't be so cynical… <grin/>

I have no doubts that electronic mail will remain a powerful vector for propagation of viruses and other malware.
Wietse Venema

As discussed last time, smartphones come with tiny little screens in a bunch of different sizes and aspect ratios (some are widescreen, some are "narrowscreen", some are square). Well, duh, everybody knows phones come in different shapes. Different screens are great for providing consumer choice, but painful on software developers because now a moving target must be hit when designing your user interface.

What can we do about this? One design pattern to follow that can help is to use vector graphics for design elements and get out of the habit of using bitmapped-based graphics. What's the difference? Vector graphics are built using basic geometric shapes like lines and arcs, bitmapped graphics (like 80% of all graphics on the web) are built using individual pixels. When you scale up or down vector graphics, there's no loss of detail because the coordinates of the geometric shapes are simply transformed into the new space. With bitmapped graphics, you have to make the dots into squares (there are algorithms to help smooth things out). Here's a rough example illustrating a vector circle magnified 200 times its original size (on the left) versus a bitmap circle magnified the same amount:

Scaling vector graphics (circle on left) doesn't look like crap, unlike scaling bitmap graphics (circle on right).

The difference between vector graphics and bitmapped graphics for smartphone development is that if all of your visual elements are in vector, they are going to look "nice" no matter how you scale them to accommodate different smartphone screen sizes. That vector circle is going to look just as nice at 200x200 as it does at 10x10.

There are cases where you might not want to scale your elements to fit the screen. You might want to use the extra screen real estate to show more of a document's content, for example, rather than making circles bigger. But, if you make your UI elements vector, you open doors. If you stick with bitmap-based elements, you close doors because if you scale, your bitmaps will look like crummy. If you don't scale your bitmaps, they might be too small when displayed on larger screens or screens with a high DPI. You could create sets of bitmaps and use different sets for different screen sizes, but now you've created N times as much work for your UI designer, who's probably charging you by the hour...

On top of that, if for whatever reason you really, really need a bitmap of a UI element, it's easy to convert a vector image into a bitmap-based one, but nigh impossible to convert the other way.

Knowing that , let's start a list of axioms that we can arm ourselves with when tackling smartphone development projects:

Axiom #10: Create your smartphone visual assets using vector-based graphics.

(Where are Axioms #1-9? We're going to start at 10 and skip 10 for each Axiom in case we need to go back and stick a new one somewhere in the middle…BASIC rulz!)

So yesterday the gauntlet was thrown down. Smartphone development is hard stuff. There are tens of thousands of possible permutations and developing, testing, and funding all of them is a difficult problem to solve, and current solutions come at the cost of reduced customer potential. So what are some of the specific challenges faced when attempting smartphone development, especially a development project starting from scratch? Some of these challenges include:

• The various mobile phone operating systems and hardware platforms
• Differing screen sizes, colors, aspect ratios, and dot pitch
• Different user input methods: Text on 9 keys (T9), qwerty keyboards, touch screens lacking any tactile feedback (hello iPhone!), etc.
• Different CPUs, their speeds, and unique capabilities
• Different programming environments
• Etc.

The list of challenges is likely unbounded, so no point in trying to enumerate them all. Let's just pick one and dig right in: differing screens.

Once upon a time, computers had screens that were great for programmers because most typically, they were arranged as a simple grid of characters. While the size of the grid did vary, eventually a large majority of computers settled in on a grid of 80 columns and 25 rows of characters. That "standardization" made it very easy to write code on one computer and know that it would work as expected on any other computer that was also 80x25 which was going to be nearly all of them. And there was much rejoicing…

Of course XEROX PARC, Apple, and others went and created graphical user interfaces and had to ruin our character-display-based fun. Sure, GUIs are better for users, but they are much harder for developers. The good news is that even now, the resolutions at which PCs run is constrained to a few standard possibilities: 800x600 pixels, 1024x768, and probably 1600x1200 as a common upper limit. Yes, there are plenty of less-common settings, DPI mixing up the equation a bit between Mac and PCs, but if your application or web page runs on 800x600, users will likely be happy regardless of their specific setting.

But welcome to smartphone development, where things are completely different! Firstly, screens on those mobile handsets are tiny compared to modern PC screens. Common resolutions include:

• 96x65
• 128x160
• 176x132
• 176x220
• 240x320
• 320x240
• Etc.

A common smartphone screen size is 176x220 which is 38,720 pixels. An average PC running at 1024x768 (today's common lower-limit) has 786,432 pixels, making the smartphone's screen 1/20^th the size of the smallish PC screen. The storm clouds are on the horizon…

Because of the variability of screen sizes and because the smallest smartphone screen is so small, the trick/pattern used on PCs doesn't work anymore. One can't simply target the smallest screen size and target that for all phones. Well, one could do that I suppose, but users are going to get pissed with big blank borders around your application's too-small content on their 320x240 phone, so I don't recommend it. Is that thunder I hear?

In today's world, there are two general approaches:

1. Layout your application's user interface for each anticipated screen size. This will yield the best possible results for users of each screen size since you've tailored your UI elements to each screen size. But have fun, because you'll be tweaking UI elements for days since there are lots of possible screen sizes. Enjoy!
2. Let some sort of UI layout engine handle the display of your UI elements for you, based on the resolution of each phone. This is the approach many Java ME applications take. If you need a text box to collect the user's name, you tell the MIDP UI library that you want a textbox, but besides indicating which control you want the text box to follow and some minor UI hints, you don't really get a chance to tell it where to precisely display that text box. The Java ME MIDP environment figures that out for you based on the capabilities of each device. The advantage here is for the developer: define that text box once and it appears on every device. Schweet! Who loses? The end user (of course!) because what invariably ends up happening is that your UI looks like crap on every device because code libraries don't know much about the aesthetics of a user interface. So a lot of Java developers punt and get a reference to the screen's canvas and start drawing pixels directly to the screen—that puts you right back to approach #1. Here comes the rain…

Game over? Of course not. But do a large percentage of smartphone developers appear to just accept their fate and live with this gunk? It appears so.

Next time, I'll propose an alternative to consider…

After spending the last couple of years developing a middleware application for mobile phones capable of running custom applications, and as SoftSource's Subject Matter Expert on the topic, I've recently come to the conclusion that writing applications for Smartphones is a challenge! I blame no particular platform vendor, device manufacturer, specific programming language, or specific smartphone device (although I wag my finger a bit at BlackBerries). The fact that so many options exist certainly contributes to the problem. And if one steps back and thinks about the variables involved with mobile development for a minute, you can start to see why it's a tough challenge to face (and potentially an expensive one too).

Consider something akin to the Drake equation, but instead of computing the number of alien civilizations with which we could hope to one day communicate, let's attempt to calculate the number of unique smartphone configurations we have to target and support, just to publish a single, wide-reaching mobile application. I see the equation being something like:

N = P × M × D × O × L

where:

N is the number of unique device configurations someone must support for a given mobile application in order to reach the widest possible audience;

and

P is the number of unique smartphone platforms in common use

M is the number of manufacturers of smartphone devices

D is the average number of devices made by each manufacturer

O is the number of mobile network operators in the world (or target region)

L is the number of languages in which to translate your user interface.

There are probably other variables I'm leaving out and some variables are a bit misleading (e.g., not all manufacturers create smartphones for every platform), but let's cram some approximate sample numbers into just these and see where we stand. Let's say the number of platforms in common use today is six (P = 6). I include as major platforms:

• Symbian
• Windows Mobile
• RIM BlackBerry
• Linux
• Palm OS
• iPhone's Mac OS X

Sure, we could argue that Java Micro Edition runs on most of the above so that effectively there are really just two or three platforms, but the fact that various platforms support various optional Java ME packages effectively makes each platform unique (I'm looking at you BlackBerry for your tardy support of JSR 172!).

Let's go with 13 device manufacturers including Motorola, Nokia, RIM, Sony, HTC, etc. There are more than 13, but let's go conservative to balance that not all manufacturers create devices for all platforms. So M = 13.

The number of devices per manufacturer is going to vary dramatically, but let's pick a number and say 5. A manufacturer like Nokia is going to have way more, but in theory each device belongs to a series (e.g., Series 60, Series 80, etc.) and that once you code to a given series, you've nailed dozens of devices (in my experience the reality is somewhat different from the theory, but again, we're ballparking here). So D = 5.

According to Wikipedia (the fountain of all human knowledge) there are 19 major mobile network operators worldwide. So on line 40, LET O = 19

Almost there. Since any "real" application is going to also be used by lots of customers that don't speak English, you need to translate your application's user interface elements into multiple languages. Let's not go crazy and say we'll target only 6 total languages. Thus L = 6.

So our "Mobile Effort Required" equation looks like:

N = 6 × 13 × 5 × 19 × 6
N = 44460

What does that number mean? Well, it doesn't really matter what it means because it's a pretty big number considering the size of the inputs, so no matter what perspective you take, that answer is: that sucks! If you're a developer of mobile applications, it means that you are essentially trying to produce code that runs on 44,460 different device configurations. Um, that sucks. If you are a quality assurance engineer, it means that you need to test 44,460 possible device configurations. Sucks. If you are a product marketing manager, it means you are trying to define a cohesive set of features for 44,460 devices. Suckage. If you are the sponsor of a mobile project, it means you're paying for the development of a product trying to deploy to 44,460 device configurations. That probably sucks most of all!

So is it hopeless? Should one not even bother trying to start? Of course not. This is, after all, the world of software where practically anything is possible. What can one do to mitigate some of these factors to bring some sanity to all of this? The easiest solution is to just start constraining the heck out of the variables. Let's just support Windows Mobile. Congrats, P now equals 1 and you're down to 7410 configurations. Just North American mobile operators! Now O is probably 4 or 5. You get the idea. But each time you constrain a variable, you're whacking chunks of potential users, which most of the time, is an important statistic to keep as large as possible.

So what can be done to decrease "Mobile Effort" but maintain optimal customers? Ah, well that's the golden question that I hope you and I can answer over the coming weeks and months. For starters, one can license feature-rich but moderately priced mobile middleware (<shameless_plug>email me!</shameless_plug>), but more importantly, I think it might be worthwhile to spend some time with blog entries that break down this complex issue into a bunch of digestible, smaller ones. Let's plan to focus on solving each smaller issue with an eye towards constraining a variable without affecting user count so we can minimize the resulting "Mobile Effort" equation but maximize the install base. And the good news is that a lot of the problems plaguing mobile development have been solved elsewhere--there are plenty of non-mobile solutions and patterns we can steal^H^H^H^H^Hborrow^H^H^H^H^H^Hleverage to help us out. And to conjecture a bit more, I suspect along the way we might even find ourselves writing and posting some code or documenting mobile-centric patterns should that makes sense as we tackle these challenges.

And I'll tell you why I'm even bothering because frankly, reading blogs and writing one myself has never really interested me all that much because I don't particularly care what you had for lunch today and I know nobody cares what I had for lunch today (fajita burrito if in fact you do). But I've finally found something compelling to write about that I don't really see anyone else addressing (okay, I read some blogs): simplifying the challenges of smartphone development. The idea that you can take a computer the size of a candy bar, stick it in your pocket, and connect yourself wirelessly almost anywhere in the world to a network of a few billion computers is pretty darn awesome, IMHO. And the fact that writing code for all of those mobile devices is a complex challenge today is also cool because who wants to do something that's easy? How boring is that? Perhaps "boring" isn't the right word, perhaps instead, easy stuff just…sucks.

Cheers,
--SG