CSE20 Mobile Application Development Unit II

BREW
Brew ( Binary Runtime Environment for Wireless) is an application development
platform created by Qualcomm, originally for CDMA mobile phones, featuring third party
applications such as mobile games. It is offered in some feature phones but not in smart phones.

It is a lightweight framework that runs between the applications and the chip operating
system software. BREW manages all of the telephony functions on the device, thereby allowing
application developers to create advanced wireless applications without having to program to the
device's system-level interface.

Enables native application development in C,C++. Applications can also be developed in

Java using a Java Virtual Machine (JVM) developed for BREW platform. Handset
manufacturers can integrate BREW into their device by using the BREW Porting kit provided
by QUALCOMM.

Fig. 1: BREW Architecture

BREW is a thin client (about 150K) that sits between a software application and the
Application Specific Integrated Circuit (ASIC) level software. Thus developers can write to
BREW without knowing or caring about the device's chipset or air interface.

BREW Application Development Cycle

 • Software developers can develop applications in C/C++ using the freely downloadable
BREW SDK.
• The SDK comes with a application called BREW Emulator (known as BREW Simulator
from version 3.0). This application simulates the look and behavior of a BREW handset
device and can be used to test and debug BREW applications during development
process.
• Applications to be executed on BREW Emulator are compiled to native code of the
operating system on which the Emulator is running and linked with a compatible x86
BREW runtime library. For instance, if BREW SDK is installed in a windows machine,
BREW applications to be executed on BREW Emulator are compiled to windows native
code and linked with a x86 compatible BREW runtime library
• After the application has been tested thoroughtly with Emulator, it has to be compiled
and link into ARM binary form to run in BREW handset. For that QUALCOMM
provides a GNU Cross compiler which can be freely downloaded and RealView
Compilation Tools for BREW which is available for a fee
• Unlike other mobile handset platforms, BREW applications cannot be directly tested on
BREW handsets. QUALCOMM has implemented this feature for reasons of security as
BREW gives complete control over handset's hardware
• Before testing the applications, they should be digitally signed. QUALCOMM provides
tools for generating digital signatures only to content providers and Authenticated BREW
Developers
• After digitally signing the applications, they can be uploaded to a BREW handset using a
USB or serial cable using a tool called AppLoader. The AppLoader tool is part of the
BREW Testing and Commercialization Utilities provided by QUALCOMM which are
available only to BREW Authenticated Developers
• Once the application has been thoroughly internally tested, it must be submitted to
QUALCOMM for TRUE BREW Testing. Again True BREW Testing is available only
for BREW Authenticated developers
• After the application passes True BREW testing, it may be offered to Mobile Network
operators supporting BREW handsets from which it can be download by subscribers to
their handsets.

BREW Benefits

• Consumers. The benefit for consumers is quite clear-cut: BREW allows for consumers
to download new applications over the air, which means they can personalize their
devices. BREW will promote a whole new range of applications for the consumer,
ranging from instant messaging to location-based services. The consumer will have the
final say in what is deployed to their device; moreover, they will only have to pay for
applications they are interested in.
• Developers. BREW makes it possible for developers to create new applications for
mobile phones. They no longer have to establish a relationship with wireless handset
manufacturers or carriers or have to own a physical device prototype. Instead, developers
can use C/C++ or other high-level languages to create their applications for a wide range
 of BREW-enabled devices. QUALCOMM has also established a TRUE BREW testing
process to ensure application compatibility and quality.
• Handset manufacturers. Once handset manufacturers integrate BREW into their
devices, they will be able to release new products faster. Application testing will no
longer have to be included in the factory integration tasks because they can be deployed
to the device at a later time. In addition, handset manufacturers will be able to use a wide
range of third-party applications, allowing them to spend more time on handset design
and development.
• Wireless operators. Wireless operators benefit from the capability to provide a broader
range of applications for handsets running on their networks. This can help drive mobile
phone adoption, as well as increase airtime usage. In many cases, it is the wireless
operator that provisions the applications, thereby taking a percentage of the application
revenue.

Merits of BREW Platform

• Since BREW runs directly on top of hardware layer, application execution is fast when
compared to other application frameworks like Java Mobile Edition.
• BREW API is consistent across supported handsets than other application frameworks
like Java Mobile Edition API
• Since BREW from version 2.0 allows direct access to screen buffer, developers have lot
of control while creating Graphics intensive applications like Games
• Handset manufacturers can add new features and fix bugs over-the-air to already
deployed BREW handsets by using BREW extensions. BREW extensions are additional
code modules written by OEMs and third party software vendors to include additional
functionalities in the handsets. Some Examples for BREW extensions are Java Virtual
Machine, Game engines etc.

Demerits of BREW Platform

• Unlike other handset platforms, applications cannot be directly tested on BREW handsets
• Only BREW Authenticated Developers can test and deploy applications in handsets.
Becoming a BREW Authenticated Developer involves a set of procedures which is not
freely available for individuals
• Testing and debugging of BREW applications difficult and cumbersome due to
differences in emulation and actual hardware environments

Symbian

It is a proprietary operating system for data-enabled mobile devices developed by

symbian and currently maintained by Nokia.

Key characteristics

integrated multimode mobile telephony

 messaging

open application environment

standards and interoperability

multi-tasking

robustness

flexible user interface design

Architecture :

Symbian OS separates the UI from the engines and services allowing licensees (like
Nokia) to develop their own UIs for the phones.

UI Framework Layer

The topmost layer of Symbian OS, the UI Framework layer provides the frameworks and
libraries for constructing a user interface, including the basic class hierarchies for user interface
controls and other frameworks and utilities used by user interface components.

The UI Framework layer also includes a number of specialists, graphics-based

frameworks which are used by the user interface but which are also available to applications,
including the Animation framework, the Front End Processor (FEP) base framework and Grid.

The Application Services Layer

 The Application Services layer provides support independent of the user interface for
applications on Symbian OS. These services divide into three broad groupings:
• system-level services used by all applications, for example the Application
Architecture or Text Handling.
• services that support generic types of application and application-like services, for
example personal productivity applications (vCard and vCal, Alarm Server) and
data synchronization services (OMA Data Sync, for example); also included are a
number of key application engines which are used and extended by licensees
(Calendar and Agenda Model), as well as legacy engines which licensees may
choose to retain (Data Engine).
• services based on more generic but application-centric technologies, for example
mail, messaging and browsing (Messaging Store, MIME Recognition Framework,
HTTP Transport Framework).

Applications in Symbian OS broadly follow the classic object-oriented

Model–Viewer–Controller (MVC) pattern.

The OS Services Layer

The OS Services layer is, in effect, the ‘middleware’ layer of Symbian OS, providing the servers,
frameworks, and libraries that extend the bare system below it into a complete operating system.
The services are divided into four major blocks, by broad functional area:
• generic operating system services
• communications services
• multimedia and graphics services
• connectivity services.

Together, these provide technology-specific but application-independent services in the

operating system. In particular, the following servers are found here:
• communications framework: the Comms Root Server and ESock (Sockets) Server
provide the foundation for all communications services
• telephony: ETel (Telephony) Server, Fax Server and the principal servers for all
telephony-based services
• networking: the TCP/IPv4/v6 networking stack implementation
• serial communications: the C32 (Serial) Server, providing standard serial
communications support.
• graphics and event handling: the Window Server and Font and Bitmap Server
provide all screen-drawing and font support, as well as systemand application-
event handling.
• connectivity: the Software Install Server, Remote File Server and Secure Backup
Socket Server provide the foundation for connectivity services.
• generic: the Task Scheduler provides scheduled task launching.

The Base Services Layer

The foundational layer of Symbian OS, the Base Services layer provides the lowest level of user-
side services. In particular, the Base Services layer includes the File Server and the User Library.
The microkernel architecture of Symbian OS places them outside the kernel in user space.
Other important system frameworks provided by this layer include the ECom Plug-in
Framework, which implements the standard management interface used by all Symbian OS
framework plug-ins; Store, which provides the persistence model; the Central Repository, the
DBMS framework; and the Cryptography Library.
The Base Services layer also includes the additional components which are needed to
create a fully functioning base port without requiring any further high-level services: the Text
Window Server and the Text Shell.

The Kernel Services and Hardware Interface Layer

The lowest layer of Symbian OS, the Kernel Services and Hardware Interface layer
contains the operating system kernel itself, and the supporting components which abstract the
interfaces to the underlying hardware, including logical and physical device drivers and ‘variant
support’, which implements pre-packaged support for the standard, supported platforms.

Application Development Languages

Symbian C++ is most powerful.

• Provides greatest access to capabilities of OS.
• Fastest because it runs on natively compiled code.

Symbian devices can also be programmed using Python, Java ME, Flash Lite, Ruby,
.NET, Web Runtime (WRT) Widgets and Standard C/C++.

Deployment

Once developed, Symbian applications need to find a route to customers' mobile phones.
They are packaged in SIS files which may be installed over-the-air, via PC connect, Bluetooth or
on a memory card. An alternative is to partner with a phone manufacturer and have the software
included on the phone itself. Applications must be Symbian Signed for Symbian OS 9.x in order
to make use of certain capabilities (system capabilities, restricted capabilities and device
manufacturer capabilities).

The Symbian OS SDK contains:

• Most of the Symbian OS source code

• Associate and public APIs

• Techview UI and source

• Engineering documentation

• Latest Symbian Developer Library

• ROM building and other test tools

Android:

Android is implemented in the form of a software stack architecture consisting of a Linux kernel,
a runtime environment and corresponding libraries, an application framework and a set of applications.
Applications are predominantly written in Java and run within individual instances of the Dalvik virtual
machine. The Android SDK provides the tools and APIs necessary to begin developing applications on
the Android platform using the Java programming language.

Architecture:

Android operating system is a stack of software components which is roughly divided

into five sections and four main layers.

1. linux kernel
2. native libraries (middleware),
3. Android Runtime
4. Application Framework
5. Applications

Linux Kernel Layer:

At the bottom of the layers is Linux - Linux 3.6 with approximately 115 patches. This
provides a level of abstraction between the device hardware and it contains all the essential
hardware drivers like camera, keypad, display etc. Linux kernel is responsible for device
drivers, power management, memory management, device management and resource access.

Libraries:

On top of Linux kernel there is a set of libraries including open-source Web browser
engine WebKit, well known library libc, SQLite database which is a useful repository for
storage and sharing of application data, libraries to play and record audio and video, SSL
libraries responsible for Internet security etc.
Android Libraries
This category encompasses those Java-based libraries that are specific to Android
development. Examples of libraries in this category include the application framework libraries
in addition to those that facilitate user interface building, graphics drawing and database access.
A summary of some key core Android libraries available to the Android developer is as follows:

• android.app − Provides access to the application model and is the cornerstone of all
Android applications.

• android.content − Facilitates content access, publishing and messaging between

applications and application components.

• android.database − Used to access data published by content providers and includes

SQLite database management classes.

• android.opengl − A Java interface to the OpenGL ES 3D graphics rendering API.

 • android.os − Provides applications with access to standard operating system services
including messages, system services and inter-process communication.

• android.text − Used to render and manipulate text on a device display.

• android.view − The fundamental building blocks of application user interfaces.

• android.widget − A rich collection of pre-built user interface components such as

buttons, labels, list views, layout managers, radio buttons etc.

• android.webkit − A set of classes intended to allow web-browsing capabilities to be

built into applications.

Android Runtime
This is the third section of the architecture and available on the second layer from the
bottom. This section provides a key component called Dalvik Virtual Machine which is a kind
of Java Virtual Machine specially designed and optimized for Android.

The Dalvik VM makes use of Linux core features like memory management and multi-
threading, which is intrinsic in the Java language. The Dalvik VM enables every Android
application to run in its own process, with its own instance of the Dalvik virtual machine.

The Android runtime also provides a set of core libraries which enable Android
application developers to write Android applications using standard Java programming
language.

Application Framework
The Application Framework layer provides many higher-level services to applications in the
form of Java classes. Application developers are allowed to make use of these services in their
applications.

The Android framework includes the following key services −

• Activity Manager − Controls all aspects of the application lifecycle and activity stack.

• Content Providers − Allows applications to publish and share data with other
applications.
 • Resource Manager − Provides access to non-code embedded resources such as strings,
color settings and user interface layouts.

• Notifications Manager − Allows applications to display alerts and notifications to the

user.

• View System − An extensible set of views used to create application user interfaces.

Applications
You will find all the Android application at the top layer. You will write your application
to be installed on this layer only. Examples of such applications are Contacts Books, Browser,
Games etc.

Application Development Languages

The official language for Android development is Java. Large parts of Android are
written in Java and its APIs are designed to be called primarily from Java. It is possible to
develop C and C++ app using the Android Native Development Kit (NDK), however it isn't
something that Google promote.

iOS :

iOS is Apple’s mobile operating system which is derived from Mac OS X. Originally
released for iPhone and iPod Touch, it has been extended to support devices like iPad and Apple
TV.

Architecture:
Cocoa Touch Layer:

The Cocoa Touch layer sits at the top of the iPhone OS stack and contains the
frameworks that are most commonly used by iPhone application developers. Cocoa Touch is
primarily written in Objective-C, is based on the standard Mac OS X Cocoa API and has been
extended and modified to meet the needs of the iPhone.

The Cocoa Touch layer provides the following frameworks for iPhone app development:

• UIKit Framework (UIKit.framework)

Some of the key features of UIKit are as follows:

User interface creation and management (text fields, buttons,

labels, colors, fonts etc)
Application lifecycle management
Application event handling (e.g. touch screen user interaction)
Cut, copy, and paste functionality
Web and text content presentation and management
Data handling
Inter-application integration
Push notification in conjunction with Push Notification Service
Accessibility
Accelerometer, battery, proximity sensor, camera and photo library
interaction.

• Map Kit Framework (MapKit.framework)

The Map Kit framework provides you with a programming interface that
enables you to build map based capabilities into your own applications. This
allows you to, amongst other things, display scrollable maps for any location,
display the map corresponding to the current geographical location of the device
and annotate the map in a variety of ways.

• Message UI Framework (MessageUI.framework)

It allows users to compose and send email messages from within the
application. In fact, the framework even provides the user interface elements
through which the user enters the email addressing information and message
content. Alternatively, this information can be pre-defined within the application
and then displayed for the user to edit and approve prior to sending.

• Address Book UI Framework (AddressUI.framework)

 This framework is dedicated to the integration of the address book data
into the applications. The primary purpose of the framework is to enable you to
access, display, edit and enter contact information from the iPhone address book
from within the application.

• Game Kit Framework (GameKit.framework)

The Game Kit framework provides peer-to-peer connectivity and voice

communication between multiple devices and users allowing those running the
same app to interact in multi-player games.

Media Services Layer:

The role of the Media layer is to provide the iPhone OS with audio, video, animation and
graphics capabilities. It provides following frameworks:

Core Graphics Framework ( CoreGraphics.frameworks)

The iPhone Core Graphics Framework (otherwise known as the Quartz 2D API)
provides a lightweight two dimensional rendering engine.

Quartz Core Framework (QuartzCore.framework)

The purpose of the Quartz Core framework is to provide animation capabilities on

the iPhone. It provides the foundation for the majority of the visual effects and animation
used by the UIKit framework and provides an Objective-C based programming interface
for creation of specialized animation within iPhone apps.

OpenGL ES framework (OpenGLES.framework)

OpenGL for Embedded Systems (ES) is a light weight version of the full OpenGL
specification designed specifically for smaller devices such as the iPhone. It provides 2D
and 3D graphics.

AV Foundation framework (AVFoundation.framework)

An Objective-C based framework designed to allow the playback, recording and

management of audio content.

Media Player framework (MediaPlayer.framework)

The iPhone OS Media Player framework is able to play video in .mov, .mp4,
.m4v, and .3gp formats at a variety of compression standards, resolutions and frame rates.
Core Services Layer:

The iPhone Core Services layer provides much of the foundation on which the above
layers are built and consists of the following frameworks.

Address Book framework (AddressBook.framework)

The Address Book framework provides programmatic access to the iPhone

Address Book contact database allowing applications to retrieve and modify contact
entries.

Core Data Framework ( CoreData.framework)

The Core Foundation is a C-based Framework that provides basic functionality such
as data types, string manipulation, raw block data management, URL manipulation, threads
and run loops, date and times, basic XML manipulation and port and socket communication.

Core Location Framework (CoreLocation.framework)

The Core Location framework allows to obtain the current geographical location
of the device (latitude and longitude) and compass readings from with your own
applications.

Store Kit Framework (StoreKit.framework)

The purpose of the Store Kit framework is to facilitate commerce transactions

between application and the Apple App Store.

SQLite Library

Allows for a lightweight, SQL based database to be created and manipulated from
application.

Core OS Layer:

The Core OS Layer is the bottom layer of the iPhone OS stack and sits directly on top of
the device hardware. The layer provides a variety of services including low level networking,
access to external accessories and the usual fundamental operating system services such as
memory management, file system handling and threads.

CFNetwork Framework (CFNetwork.framework)

The CFNetwork framework provides a C-based interface to the TCP/IP

networking protocol stack and low level access to BSD sockets. This enables application
code to be written that works with HTTP, FTP and Domain Name servers and to establish
 secure and encrypted connections using Secure Sockets Layer (SSL) or Transport Layer
Security (TLS).

Security Framework (Security.framework)

The iPhone OS Security framework provides all the security interfaces you would
expect to find on a device that can connect to external networks including certificates,
public and private keys, trust policies, keychains, encryption, digests and Hash-based
Message Authentication Code (HMAC).

System (LibSystem)

This layer includes the operating system kernel (based on the Mach kernel) and
device drivers. The kernel is the foundation on which the entire iPhone OS is built and
provides the low level interface to the underlying hardware. Amongst other things the
kernel is responsible for memory allocation, process lifecycle management, input/output,
inter-process communication, thread management, low level networking, file system
access and thread management.

Development options:

Apple Xcode : Objective – C

Ansca Corona : Lua
Dragon Fire : C,C++
Novell Mono Touch : C#
RhoMobile : JavaScript/HTML/CSS

iOS SDK:

It contains following tools:

• Xcode

Professional text editor

Debugger
GCC compiler

• Interface Builder

For creating User Interface

• Instruments

For optimizing applications

• Dash code
 For creating web applications for safari

• iPhone simulator

Windows Mobile

Windows Mobile is a mobile operating system developed by Microsoft that was used in
smart phones and mobile devices.

Framework:

The .NET framework is a software framework created by Microsoft for use in creating
Windows applications. App developers can develop apps using C# / Visual
Basic.NET (.NET), C++ (CX) or HTML5/Javascript. For Windows Phone 8, there are two
distinct development approaches to create the mobile application.
The first approach is to use Silverlight for Windows Phone. Silverlight was originally
envisioned as a way for developers to create rich internet applications. A Silverlight application
combines declarative markup (called XAML) to construct the user interface and code written in a
.NET framework language to control an application’s behavior. To develop a data driven
application for Windows Phone 8, Silverlight is the right choice.
 Alternatively, you can use the XNA framework to develop your Windows Phone 8 app.
XNA is Microsoft’s game development framework and has been used in recent years to create
both Windows and Xbox 360 applications. To create a game for Windows Phone 7, the XNA
framework is quite powerful, but that power comes with a considerable learning curve and
longer development cycles.
The Common Language Runtime (CLR), the virtual machine component
of Microsoft's .NET framework, manages the execution of .NET programs. A process known
as just-in-time compilation converts compiled code into machine instructions which the
computer's CPU then executes. The CLR provides additional services including memory
management, type safety, exception handling, garbage collection, security and thread
management. All programs written for the .NET framework, regardless of programming
language, are executed by the CLR.

App Model:

Application:
Uniquely identifiable, licensable and serviceable software product packaged as a
XAP.
Application Deployment
Steps include Ingestion, certification and signing.
Application License
Crypto-verifiable object issued to grant rights to an application.

UI Model:

Application

UI and logic for functionality exposed through pages.

Page
 A single screen of user interaction elements.

Session

An ordered workflow of user interactions of spanning applications.

Kernel:

The kernel provides the base OS functionality for any Windows Mobile device. This
functionality includes:

Process Management

Thread Management

Memory Management

File Management

Drivers
– Established driver ecosystem
– Focus on optimized driver
– Better devices, faster
Security
– Hardware-based security of Windows
– Never regret installing an app
– Your content under your control
Networking
– IPV6
– NFC, tap to share
– Improved Bluetooth
Graphics & Media
– Built on hardware accelerated Direct3D
– Media Playback and Record
– High-fidelity experiences

Application Development

Requirements:

Visual Studio 2005 Standard Edition or above, you can author, debug and
package applications for delivery.
 Windows Mobile SDK, development kit, documentation and library files.

ActiveSync or Windows Mobile Device Center, To deploy the application

to a device or to an emulator.

• Languages :

Visual C++ for execution speed, application size and flexibility.

Visual C# and Visual Basic for reliable and rapid application

development, security and language interoperability, C# is simple,
powerful, type-safe, and object-oriented.

J2ME:

Java Platform Micro Edition (Java ME), formerly and popularly known as Java 2 Micro
Edition (J2ME) is a Java platform for embedded devices like mobile phones, PDA's, set-top
boxes etc. J2ME customizes Java to these device capabilities. J2ME is optimized to smaller
memory footprint and the core to this technology is KVM which is an optimized Virtual
Machine for various devices. This optimization is based on memory, power consumption and
connectivity of the respective devices.

When we say devices there can be various devices each having various capabilities, screen
size, functionality etc. It would be meaningless to have a same Virtual Machine for all the
devices. Let us consider following scenarios

• A call handling feature of a mobile device is useless in set-top boxes.

• Mobile device capabilities can vary from device to device, there are devices which
support blue tooth and those which do not support Bluetooth.
• A printing capability of a printer is useless in case of a set-top box.

J2ME takes care of all these scenarios by providing Configurations, Profiles and Optional
Packages.

J2ME Core Concepts:

• Configuration
– Minimum platform required for a group of devices

• Profile Libraries
– Addresses specific Java Language needs of a certain device family

• Optional Packages
Configurations:

• A configuration is a complete Java runtime environment, consisting of:

– Java virtual machine (VM) to execute Java byte code
– Native code to interface to the underlying system
– Set of core Java runtime classes
• To use a configuration, a device must meet certain minimum requirements.
• The set of core classes is normally quite small and must be enhanced with additional
classes supplied by J2ME profiles or by configuration implementer.
• Configurations do not define any user interface classes.
 Fig : General J2ME Architecture

Connected Limited Device Configuration (CLDC):

• CLDC is aimed at the low end of the consumer electronics range.

– 16-bit or 32-bit small computing devices with limited memory.
– These devices usually have between 160KB and 512KB of available memory.
– Usually these are powered by battery.
– They use small-bandwidth network wireless connection.
– These devices include pagers, personal digital assistants, cell phones, dedicated
terminals, and handheld consumer device.

Connected Device Configuration (CDC):

• CDC for plug-in devices: devices use

– 32-bit architecture, have at least 2 MB of memory available
– Implement a complete functional of JVM
– CDC devices include digital set-top boxes, home appliances, navigation systems,
point-of-sale terminals, and smart phones
CLDC vs CDC:
 Fig: Detailed J2ME Architecture

Profiles:

• Adds domain-specific classes to a configuration:

– To fill in missing functionality
– To support specific uses of a device
• Most profiles define user interface classes for building interactive applications.
• To use a profile, the device must meet the minimum requirements of the underlying
configuration and of the profile.
• Profiles built upon CLDC Mobile Information Device Profile (MIDP) and Kjava.
• Profiles built upon CDC Foundation Profile and Personal Profile.

The Mobile Information Device Profile (MIDP) and MIDlets:

• The Mobile Information Device Profile, or MIDP for short, is one such profile, intended
for use on small footprint devices with a limited user interface in the form of a small
screen with some kind of input capability.
• Mobile Information Device Profile (MIDP)
• APIs built on top of the CLDC configuration
• Defines following APIs for cellular devices
• User Interface Components
• Input and Event handling
• Persistent storage
 • Networking and timers
• Common, industry-standard profile
• Not dependent on a specific vendor
• Java applications that run on MIDP devices are known as MIDlets. A MIDlet consists of
atleast one Java class.

MIDlets Life Cycle:

MIDlet application is an applet that runs in small devices. Like an applet the midlet has a
life cycle. The core package which addresses the midlet life cycle is javax.microedition.midlet.
Each state of life cycle is notified to Application Management Software(AMS) and the AMS acts
appropriately. AMS is the device software that handles the midlet lifecycle.

AMS interacts with the MIDlet application in loading and unloading the MIDlet using the
MIDlet's life cycle methods and thus affecting the following midlet states.

• Paused State
• Active State
• Destroyed State

MIDlet class is an Abstract class and your application's root class must extend this class and
override its abstract methods.

Active State

Midlet's startApp() method is called to change the paused state to active state. Here the
midlet is displayed on Electronic Data Interface(EDI) screen of the mobile phone.

Paused State

When MIDlet's pauseApp() is called. The MIDlet frees as much resources as it can.
startApp() can be called after paused state and the application becomes active again.
Destroyed State

MIDlet.destroyApp() is used to do cleaning up before the application exits.

Kjava

– Sun's proprietary profile

– Built on top of the CLDC configuration
– Contains a Sun-specific API
• Which runs on the Palm OS
– It is not a standard J2ME package
• Main package is com.sun.kjava

Foundation Profile

– Intended for embedded and headless devices

– For devices that have no user interface
• Routers
• Gateway devices
– There are other profiles, such as Personal Profile, that are intended to run on top
of the Foundation profile

Personal Profile

– Personal Profile is the JavaME replacement for PersonalJava

– Defines a minimal set of user interface APIs

Optional Packages

• Extend the J2ME platform by adding extra functionality

• Offer standard APIs for using both existing and emerging technologies like
– Database connectivity
– Wireless messaging
– Multimedia
– 3D graphics
– Web Services