For a long time, cell phone developers comprised a small sect of a slightly larger group of developers known as embedded device developers. Seen as a less “glamorous” sibling to desktop—and later web—development, embedded device development typically got the proverbial short end of the stick as far as hardware and operating system features, because embedded device manufacturers were notoriously stingy on feature support. Embedded device manufacturers typically needed to guard their hardware secrets closely, so they gave embedded device developers few libraries to call when trying to interact with a specific device.
Embedded devices differ from desktops in that an embedded device is typically a
“computer on a chip.” For example, consider your standard television remote control; it is
not really seen as an overwhelming achievement of technological complexity. When any
button is pressed, a chip interprets the signal in a way that has been programmed into the
device. This allows the device to know what to expect from the input device (key pad),
and how to respond to those commands (for example, turn on the television). This is a
simple form of embedded device programming. However, believe it or not, simple
devices such as these are definitely related to the roots of early cell phone devices and
development.
Most embedded devices ran (and in some cases still run) proprietary operating
systems. The reason for choosing to create a proprietary operating system rather than use
any consumer system was really a product of necessity. Simple devices did not need very
robust and optimized operating systems.
As a product of device evolution, many of the more complex embedded devices, such
as early PDAs, household security systems, and GPSs, moved to somewhat standardized
operating system platforms about five years ago. Small-footprint operating systems such
as Linux, or even an embedded version of Microsoft Windows, have become more
prevalent on many embedded devices. Around this time in device evolution, cell phones
branched from other embedded devices onto their own path. This branching is evident
when you examine their architecture.
Nearly since their inception, cell phones have been fringe devices insofar as they run
on proprietary software—software that is owned and controlled by the manufacturer, and is almost always considered to be a “closed” system. The practice of manufacturers using proprietary operating systems began more out of necessity than any other reason. That is, cell phone manufacturers typically used hardware that was completely developed in-house, or at least hardware that was specifically developed for the purposes of running cell phone equipment. As a result, there were no openly available, off-the-shelf software packages or solutions that would reliably interact with their hardware. Since the manufacturers also wanted to guard very closely their hardware trade secrets, some of which could be revealed by allowing access to the software level of the device, the common practice was, and in most cases still is, to use completely proprietary and closed software to run their devices. The downside to this is that anyone who wanted to develop applications for cell phones needed to have intimate knowledge of the proprietary environment within which it was to run. The solution was to purchase expensive development tools directly from the manufacturer. This isolated many of the “homebrew” developers.
Another, more compelling “necessity” that kept cell phone development out of
the hands of the everyday developer was the hardware manufacturers’ solution to the
“memory versus need” dilemma. Until recently, cell phones did little more than execute
and receive phone calls, track your contacts, and possibly send and receive short text
messages; not really the “Swiss army knives” of technology they are today. Even as late
as 2002, cell phones with cameras were not commonly found in the hands of consumers.
By 1997, small applications such as calculators and games (Tetris, for example) crept
their way onto cell phones, but the overwhelming function was still that of a phone dialer
itself. Cell phones had not yet become the multiuse, multifunction personal tools they
are today. No one yet saw the need for Internet browsing, MP3 playing, or any of the
multitudes of functions we are accustomed to using today. It is possible that the cell
phone manufacturers of 1997 did not fully perceive the need consumers would have
for an all-in-one device. However, even if the need was present, a lack of device memory
and storage capacity was an even bigger obstacle to overcome. More people may have
wanted their devices to be all-in-one tools, but manufacturers still had to climb the
memory hurdle.
To put the problem simply, it takes memory to store and run applications on any
device, cell phones included. Cell phones, as a device, until recently did not have the
amount of memory available to them that would facilitate the inclusion of “extra”
programs. Within the last two years, the price of memory has reached very low levels.
Device manufacturers now have the ability to include more memory at lower prices.
Many cell phones now have more standard memory than the average PC had in the
mid-1990s. So, now that we have the need, and the memory, we can all jump in and
develop cool applications for cell phones around the world, right? Not exactly.
Device manufacturers still closely guard the operating systems that run on their
devices. While a few have opened up to the point where they will allow some Java-based
applications to run within a small environment on the phone, many do not allow this.
Even the systems that do allow some Java apps to run do not allow the kind of access
to the “core” system that standard desktop developers are accustomed to having.