

Introducing Android

  • Print
  • + Share This
This chapter is from the book




A Brief History of Mobile Software Development


Way Back When


Figure 1.1

Figure 1.1 Mobile phones have become a crucial shopping accessory.

Those days are long gone. Today, commonplace problems like these are easily solved with a one-button speed dial or a simple text message like “WRU?” or “20?” or “Milk and?”

Our mobile phones keep us safe and connected. Nowadays, we roam around freely, relying on our phones not only to keep in touch with friends, family, and coworkers, but also to tell us where to go, what to do, and how to do it. Even the most domestic of events seem to revolve around my mobile phone.

Consider the following true, but slightly enhanced for effect, story:

  • The first thing I did—while ducking—was pull out my cell and send a text message to my husband, who was across the country at the time: “There’s a bat in the house!”
  • My husband did not immediately respond (a divorce-worthy incident, I thought at the time), so I called my Dad and asked him for suggestions on how to get rid of the bat.
  • He just laughed.



As a user, I found the experience functional, but not terribly inspiring. As a mobile developer, I wished for an opportunity to create a more seamless and powerful application that could handle all I’d done and more. I wanted to build a better bat trap, if you will.



“The Brick”




Figure 1.2

Figure 1.2 The first commercially available mobile phone: the Motorala DynaTAC.

These first-generation mobile phones were designed and developed by the handset manufacturers. Competition was fierce and trade secrets were closely guarded. Manufacturers didn’t want to expose the internal workings of their handsets, so they usually developed the phone software in-house. As a developer, if you weren’t part of this inner circle, you had no opportunity to write applications for the phones.

It was during this period that we saw the first “time-waster” games begin to appear. Nokia was famous for putting the 1970s video game Snake on some of its earliest monochrome phones. Other manufacturers followed, adding games like Pong, Tetris, and Tic-Tac-Toe.


Customers began pushing for more features and more games. But, there was a problem. The handset manufacturers didn’t have the motivation or the resources to build every application users wanted. They needed some way to provide a portal for entertainment and information services without allowing direct access to the handset.

And what better way to provide these services than the Internet?

Wireless Application Protocol (WAP)

It turned out allowing direct phone access to the Internet didn’t scale well for mobile.

By this time, professional Web sites were full color and chock full of text, images, and other sorts of media. These sites relied on JavaScript, Flash, and other technologies to enhance the user experience and were often designed with a target resolution of 800×600 pixels and higher.

When the first clamshell phone, the Motorola StarTAC, was released in 1996, it merely had a LCD 10-digit segmented display. (Later models would add a dot-matrix type display.) Meanwhile, Nokia released one of the first slider phones, the 8110—fondly referred to as “The Matrix Phone,” as the phone was heavily used in films. The 8110 could display four lines of text with 13 characters per line. Figure 1.3 shows some of the common phone form factors.

Figure 1.3


With their postage stamp-sized low-resolution screens and limited storage and processing power, these phones couldn’t handle the data-intensive operations required by traditional Web browsers. The bandwidth requirements for data transmission were also costly to the user.

The Wireless Application Protocol (WAP) standard emerged to address these concerns. Simply put, WAP was a stripped-down version of HTTP, which is the backbone protocol of the Internet. Unlike traditional Web browsers, WAP browsers were designed to run within the memory and bandwidth constraints of the phone. Third-party WAP sites served up pages written in a markup language called Wireless Markup Language (WML). These pages were then displayed on the phone’s WAP browser. Users navigated as they would on the Web, but the pages were much simpler in design.



Developers and content providers didn’t deliver. For the first time, developers had a chance to develop content for phone users, and some did so, with limited success.

Most of the early WAP sites were extensions of popular branded Web sites, such as CNN.com and ESPN.com, looking for new ways to extend their readership. Suddenly phone users accessed the news, stock market quotes, and sports scores on their phones.

Commercializing WAP applications was difficult, and there was no built-in billing mechanism. Some of the most popular commercial WAP applications that emerged during this time were simple wallpaper and ringtone catalogues, allowing users to personalize their phones for the first time. For example, the users browsed a WAP site and requested a specific item. They filled out a simple order form with their phone number and their handset model. It was up to the content provider to deliver an image or audio file compatible with the given phone. Payment and verification were handled through various premium-priced delivery mechanisms such as Short Message Service (SMS), Enhanced Messaging Service (EMS), Multimedia Messaging Service (MMS), and WAP Push.

WAP browsers, especially in the early days, were slow and frustrating. Typing long URLs with the numeric keypad was onerous. WAP pages were often difficult to navigate. Most WAP sites were written once for all phones and did not account for individual phone specifications. It didn’t matter if the end-user’s phone had a big color screen or a postage stamp-sized monochrome one; the developer couldn’t tailor the user’s experience. The result was a mediocre and not very compelling experience for everyone involved.


WAP fell short of commercial expectations. In some markets, such as Japan, it flourished, whereas in others, like the United States, it failed to take off. Handset screens were too small for surfing. Reading a sentence fragment at a time, and then waiting seconds for the next segment to download, ruined the user experience, especially because every second of downloading was often charged to the user. Critics began to call WAP “Wait and Pay.”

Finally, the mobile operators who provided the WAP portal (the default home page loaded when you started your WAP browser) often restricted which WAP sites were accessible. The portal allowed the operator to restrict the number of sites users could browse and to funnel subscribers to the operator’s preferred content providers and exclude competing sites. This kind of walled garden approach further discouraged third-party developers, who already faced difficulties in monetizing applications, from writing applications.

Proprietary Mobile Platforms

It came as no surprise when users wanted more—they will always want more.

Writing robust applications such as graphic-intensive video games with WAP was nearly impossible. The 18-year-old to 25-year-old sweet-spot demographic—the kids with the disposable income most likely to personalize their phones with wallpapers and ringtones—looked at their portable gaming systems and asked for a device that was both a phone and a gaming device or a phone and a music player. They argued that if devices such as Nintendo’s Game Boy could provide hours of entertainment with only five buttons, why not just add phone capabilities? Others looked to their digital cameras, Palms, Blackberries, iPods, and even their laptops and asked the same question. The market seemed to be teetering on the edge of device convergence.

Memory was getting cheaper; batteries were getting better; and PDAs and other embedded devices were beginning to run compact versions of common operating systems such as Linux and Windows. The traditional desktop application developer was suddenly a player in the embedded device market, especially with Smartphone technologies such as Windows Mobile, which they found familiar.

Handset manufacturers realized that if they wanted to continue to sell traditional handsets, they needed to change their protectionist policies pertaining to handset design and expose their internal frameworks, at least, to some extent.

A variety of different proprietary platforms emerged—and developers are still actively creating applications for them. Some Smartphone devices ran Palm OS (now Garnet OS) and RIM Blackberry OS. Sun Microsystems took its popular Java platform and J2ME emerged (now known as Java Micro Edition [Java ME]). Chipset maker Qualcomm developed and licensed its Binary Runtime Environment for Wireless (BREW). Other platforms, such as Symbian OS, were developed by handset manufacturers such as Nokia, Sony Ericsson, Motorola, and Samsung. The Apple iPhone OS (OS X iPhone) joined the ranks in 2008. Figure 1.4 shows several different phones, all of which have different development platforms.

Figure 1.4

Figure 1.4 Phones from various mobile device platforms.


Each platform has benefits and drawbacks. Of course, developers love to debate over which platform is “the best.” (Hint: It’s usually the platform we’re currently developing for.)


For manufacturers and mobile operators, handset product lines became complicated fast. Platform market penetration varies greatly by region and user demographic. Instead of choosing just one platform, manufacturers and operators have been forced to sell phones for all the different platforms to compete. We’ve even seen some handsets supporting multiple platforms. (For instance, Symbian phones often also support J2ME.)


It’s a nightmare for the ACME Company wanting a mobile application. Should they develop a J2ME application? BREW? iPhone? Windows Mobile? Everyone has a different kind of phone. ACME is forced to choose one or, worse, all of the above. Some platforms allow for free applications, whereas others do not. Vertical market application opportunities are limited and expensive.


  • + Share This
  • 🔖 Save To Your Account