Wednesday, July 4, 2007
Mobile Operating Systems
The role of an operating system (OS) within a handset or handheld device is no different
than the OS deployed in computing terminals; the major differences in the
OS between the two environments are the result of handset constraints.
The OS is responsible for a range of tasks, which include management of the
processor, memory, and devices. Processor management determines
when an application can use the central processor and how to manage the resources
when multiple processes have to operate simultaneously. Memory management
allocates memory to processes so that they do not overlap and controls the reading
and writing of data to memory locations. Additionally, the OS will look after storage
of data, perhaps on a card or even a disk, and will also manage devices, or the
input/output (I/O) capabilities. The user interface (UI) is considered part of the OS
although not all OS include a UI that allows licensees to customize a UI to their
own design.
Operating above the OS will in most cases be a series of applications; and to
support these, the OS will have an application programming interface (API), which
abstracts the functionality of the OS for application developers.
In the context of a mobile handset, an OS has a set of limitations placed on it
that are the result of the processor capabilities and limited memory. Therefore, the
OS in these cases needs a very small footprint, which means very efficient code
writing. There are broadly two approaches to writing an OS for mobiles. The first
is to develop an OS from the ground up, specifically for the mobile environment.
The second is to take an OS that is perhaps used in desktop devices and produce a
compact version.
One critical area for mobile OS coders is reliability. The end user of a mobile
device would not tolerate systems crashes and lockups. This means not only reliability,
but also robustness as the underlying connectivity between the device and
the network is error-prone.
The range of handset OSs in today’s market includes completely closed or proprietary
systems through to open platforms (Figure 4.50). There are many variants
in between these two ends of the scale, where developers are able to create content
for a particular OS without having to know its technical details.
Proprietary Operating Systems
Many handset products have an OS that is proprietary, and in many cases the
details of the OS are unavailable, even perhaps to developers. However, the popularity
of smart phones, with comprehensive operating systems, and a recognition
that content developers can generate revenues for carriers, has meant that even
proprietary OS have a degree of openness associated with them.
For example, a proprietary OS will often include Java functionality, which
offers developers a route to content production through standardized, well-published
APIs; meanwhile, the core of the OS that drives the phone functionality
remains hidden. Handset vendors that have moved along this path will generally
offer developer platforms, software development kits (SDKs) and training, documentation,
and support options
than the OS deployed in computing terminals; the major differences in the
OS between the two environments are the result of handset constraints.
The OS is responsible for a range of tasks, which include management of the
processor, memory, and devices. Processor management determines
when an application can use the central processor and how to manage the resources
when multiple processes have to operate simultaneously. Memory management
allocates memory to processes so that they do not overlap and controls the reading
and writing of data to memory locations. Additionally, the OS will look after storage
of data, perhaps on a card or even a disk, and will also manage devices, or the
input/output (I/O) capabilities. The user interface (UI) is considered part of the OS
although not all OS include a UI that allows licensees to customize a UI to their
own design.
Operating above the OS will in most cases be a series of applications; and to
support these, the OS will have an application programming interface (API), which
abstracts the functionality of the OS for application developers.
In the context of a mobile handset, an OS has a set of limitations placed on it
that are the result of the processor capabilities and limited memory. Therefore, the
OS in these cases needs a very small footprint, which means very efficient code
writing. There are broadly two approaches to writing an OS for mobiles. The first
is to develop an OS from the ground up, specifically for the mobile environment.
The second is to take an OS that is perhaps used in desktop devices and produce a
compact version.
One critical area for mobile OS coders is reliability. The end user of a mobile
device would not tolerate systems crashes and lockups. This means not only reliability,
but also robustness as the underlying connectivity between the device and
the network is error-prone.
The range of handset OSs in today’s market includes completely closed or proprietary
systems through to open platforms (Figure 4.50). There are many variants
in between these two ends of the scale, where developers are able to create content
for a particular OS without having to know its technical details.
Proprietary Operating Systems
Many handset products have an OS that is proprietary, and in many cases the
details of the OS are unavailable, even perhaps to developers. However, the popularity
of smart phones, with comprehensive operating systems, and a recognition
that content developers can generate revenues for carriers, has meant that even
proprietary OS have a degree of openness associated with them.
For example, a proprietary OS will often include Java functionality, which
offers developers a route to content production through standardized, well-published
APIs; meanwhile, the core of the OS that drives the phone functionality
remains hidden. Handset vendors that have moved along this path will generally
offer developer platforms, software development kits (SDKs) and training, documentation,
and support options
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment