Mobile, Handheld Computing Devices: Where Does the Web Developer Fit In?

Recently, I was involved in a lively discussion at a ColdFusion and Flex developer conference (BFusion/BFlex) held on the campus of Indiana University in beautiful Bloomington, Indiana. Michael Labriola led the discussion, which took place during his keynote presentation, between a panel of many other developers who are active in the ColdFusion and/or Flex communities. Sometimes it's difficult to articulate your thoughts at the time of a discussion, hence I'm using this medium to do a sort of brain flush at the moment. I'm doing this also because I think the topic of discussion is an important one to consider for those of us who primarily develop applications for the web.

As for expanding the definition of 'who' actually develops applications for the web, I hope to include anyone who is involved in the process of creating rich internet applications (stakeholders, account executives, creative's, designers, developers, etc.).

Mobile Phone vs. Handheld Device

First, I think it's important for 'web' developers to try to disassociate the word 'mobile' from the word 'phone.' I myself prefer to use the word 'handheld' when referring to any type of 'mobile' device. 'Handheld' feels much more inclusive to me than 'mobile.' Whereas 'mobile,' while by itself is probably a more appropriate descriptor, can be more exclusive sounding due to its association with the more specific type of handheld device commonly known as a 'cell phone.' So when I use the word 'handheld,' I am attempting to include 'any type of compact, portable computing device.' I am purposely using a broad definition here since mobile phones only constitute one slice of the larger 'handheld, mobile computing' marketplace.

Don't Hate Apple Because Their Beautiful

Let's face it, Apple has definitely shaken up the market with their lineup of handheld devices including the iPhone and iPod touch. Whether you love, hate or are indifferent to Apple's handheld products, you can't deny that Apple's use of interface design and touchscreen technology has transformed the way other companies are designing and building handheld devices. Not to mention the number of features and available applications! I'm sure that there have been, and will continue to be, many conversations around conference tables about what works, what doesn't work and how the iPhone and iPod touch interfaces can be improved upon. Rather than throw my own subjective opinions into the mix at the moment, I will say that as an iPhone user, I certainly have my list of gripes. However, Apple has most certainly revolutionized how people can actually use a handheld device and interact with each other, the web and beyond.

Application Distribution

Take a moment to review this list of digital distribution platforms for mobile devices from Wikipedia. Considering the fact that the Apple App Store opened on July 10, 2008 and as of September 28, 2009 there are over 85,000 third-party applications available and over 2 billion application downloads to iPhone and iPod touch users, I'd argue Apple has definitely made some in-roads with software developers and end-users alike. Compare that with Google's Android Market with 10,200 applications as of September 2009 and you just might agree.

I'm not suggesting that the model Apple used to create their 'Application Empire' is the right one, but without a doubt, they appear to be doing something right. I most definitely don't agree with some of their practices, but one can't deny their level of success when compared to any other digital distribution platform.

Distributing Handheld Applications via the Web

As of today, reliably deploying an application on the web that is specifically targeted to handheld devices with a web browser is extremely difficult to do, assuming you want to offer anything more than some basic text and a few form fields. While work is currently being done to improve standards on 'technologies to enable Web access anywhere, anytime, using any device,' developers are pretty much left in the rain waiting for handheld manufacturers to adopt these standards and turn them into practices.

Once again, Apple has made significant strides in getting their handheld users online. In AdMob's Mobile Metrics August 2009 report, iPhone's worldwide operating system share has grown from 33 percent to 40 percent in the preceding six months. In addition, iPhone represented 50 percent of US smartphone usage in AdMob's network in August 2009, followed by RIM and Android devices at 14 and 13 percent, respectively.

What truly makes these numbers phenomenal is that Apple's handheld devices actually account for less than 15% of the overall Smartphone OS Market Share. Yet, this small group of users account for half of the US smartphone usage within AdMobs's network. This information more than suggests, it screams that iPhone and iPod touch users are actually using their handheld devices to go online.

As a side note however, it is frustrating that Adobe Flash is not yet supported on Apple's iPhone or iPod touch. Sure, efforts have been made so that iPhone and iPod touch applications can be developed with Flash and ActionScript 3, but users still won't be able to view Flash content delivered via the browser. To be clear, this is not the fault of Adobe. Apple, for whatever reason(s), has chosen not to support Flash at this time.

Final Thoughts

I think it's important for those of us who primarily develop applications for the web to continue our discussions and thoughts on how we can better address the needs of the ever-growing handheld device marketplace.

I believe we can learn from Apple's strengths and weaknesses to find and improve a model of 'handheld application development and distribution.'

I think if designers and developers can learn how to better account for users of handheld devices regardless of whether or not they visit a web site, overall usability can be improved for these users as they look for goods, services and/or information.

These are merely thoughts, and obviously they're constantly evolving ... even while I've been writing this article. I hope my thoughts also inspire you to think about this topic and look forward to reading and/or hearing your thoughts on this subject as well.


I don't work for Apple nor have I received any compensation from Apple for writing this article. I wouldn't mind it if they decided to do so, but as of the date of publication, this has not actually happened. Finally, no handheld devices were harmed in the writing of this article.

Launched A ColdFusion + ActionScript + Flash Site: was developed as one part of a larger initiative for Aqua-Aerobic Systems, Inc. located in Rockford, Illinois. The initiative focuses on going "blue" instead of the typical "green" since their primary business centers around "providing sustainable, innovative wastewater treatment solutions." In fact visit the site, "join their cause" and they will donate $1 to the WateReuse Foundation!

The site is powered by Adobe® ColdFusion® along with Adobe® Flash®, ActionScript 3.0 and Microsoft® SQL Server. The eye-catching design and interface was created by Gordon B.
Designer: Gordon B.| Developer: Stephen Withington

Using ColdFusion's onRequestStart Method Adds Whitespace to Templates

After banging my head against my desk (which is glass by the way!) I finally figured out how to resolve an issue that may affect others out there using the ColdFusion onRequestStart method in their Application.cfc.

What Happened?
I was attempting to build a dynamic page that returned only text so that I could consume it in Flash using some ActionScript magic. After getting some errors from Flash, I decided to check the ColdFusion template I was trying to access. On the surface, everything looked fine. However, once I did a "View Source", I noticed that the ColdFusion page had some extra whitespace and carriage returns in it. This is not good, because ActionScript wants to read the entire document, whitespace and all!

So off I went, trying <cfsetting enablecfoutputonly="true">. That didn't do a thing! So I threw another CF bomb at it by wrapping everything in <cfprocessingdirective suppresswhitespace="true"></cfprocessingdirective>. Nothing. I know, you're thinking <cfsilent> aren't you? It was already there my friends, and nada. I'm telling you I removed every extra space in that template's code and didn't get any closer to getting rid of the extra space.

And that's when it hit me ... check the Application.cfc and see if there's anything in there that might be generating it. So off I went again, going through each line of code in my Application.cfc. I decided to start commenting out some of the methods to see what, if any, impact it might have on the template. When I worked my way down to onRequestStart() and commented it out ... everything worked as it should! Well, that's great! BUT ... I still wanted to use my onRequestStart() code.

So to start with, let's take a look at some generic onRequestStart code:

    <cffunction name="onRequestStart">
        <cfargument name="request" required="true" />
        <!--- re-start application from URL with ?init --->
        <cfif isDefined("url.init")>
            <cfset onApplicationStart() />


In order to still use the onRequestStart method, it turns out all I have to do is remove any and all white space and carriage returns in the onRequestStart method. So the revised code would look something like this:

<cffunction name="onRequestStart" access="public" output="true" hint="Fires when prior to page processing."><cfargument name="request" required="true" /><!--- re-start application from URL with ?init ---><cfif isDefined("url.init")><cfset onApplicationStart() /></cfif></cffunction>

Hopefully this saves someone else from a sore forehead.

© 2024, Stephen J. Withington, Jr.  |  Hosted by

Creative Commons License   |   This work is licensed under a Creative Commons Attribution 3.0 Unported License.