2. Overview
Overview
• What is J2ME.
• How does J2ME work?
• Java J2ME Carriers and Products.
• The Two Configuration of J2ME.
• Profiles in J2ME
• MIDP & MIDlets
• Wireless Java
• J2ME Vendors and Products
• References
3. What is J2ME
What is J2ME
J2ME is a family of specifications that
defines various downsized versions of the
standard Java 2 platform; these
downsized versions can be used to
program consumer electronic devices
ranging from cell phones to highly
capable Personal Data Assistants (PDAs),
smart phones, and set-top boxes.
---J2ME in a Nutshell -A Desktop Quick Reference
By Kim Topley
5. J2ME Category
J2ME Category
•
Principle: Different hardware corresponds different JVM
s, hardware which base on CDC have powerful JVMs, an
d hardware which base on CIDC have KVM to support.
----Picture form Java.sun.com
6. two configurations J2ME
currently defines 1
Connected Limited Device Configuration (CLDC)
CLDC is aimed at the low end of the consumer electronics range.
A typical CLDC platform is a cell phone or PDA with around 512
KB of available memory. For this reason, CLDC is closely
associated with wireless Java, which is concerned with allowing
cell phone users to purchase and download small Java
applications known as MIDlets to their handsets. A large and
growing number of cell phone vendors have signed agreements
with Sun Microsystems that will allow them to begin using this
technology, so the number of handsets with the capability to be
programmed in Java will probably grow rapidly in the next few
years.
----- J2ME in a Nutshell -A Desktop Quick Reference
By Kim Topley
7. two configurations J2ME
currently defines 2
Connected Device Configuration (CDC)
CDC addresses the needs of devices that lie between those
addressed by CLDC and the full desktop systems running
J2SE. These devices have more memory (typically 2 MB
or more) and more capable processors, and they can,
therefore, support a much more complete Java software
environment. CDC might be found on high-end PDAs
and in smart phones, web telephones, residential gateways,
and set-top boxes.
----- J2ME in a Nutshell -A Desktop Quick Reference
By Kim Topley
8. Profiles J2ME currently defines
Mobile Information Device Profile (MIDP)
Mobile Information Device Profile (MIDP)
PDA Profile (PDAP)
PDA Profile (PDAP)
Foundation Profile
Foundation Profile
Personal Basis and Personal Profiles
Personal Basis and Personal Profiles
RMI Profile
RMI Profile
Game Profile
Game Profile
9. The Mobile Information Dev
ice Profile and MIDlets
• The Mobile Information Device Profile, or
MIDP for short, is one such profile, intende
d for use on small footprint devices with a li
mited user interface in the form of a small s
creen with some kind of input capability.
• Java applications that run on MIDP devices
are known as MIDlets. A MIDlet consists of
atleast one Java class
10. MIDP Hardware Requirements
Hardware Minimum Requirement
Display 96 X 54 Pixels 65,536 colors
Memory 32 KB workspace
128KB MIDP Implementation
8KB for MIDlets run
Input Device the device has the equivalent of a keypad that allo
ws the user to type the numbers 0 through 9,together
with the equivalent of arrow keys and a select button
Connectivity HTTP 1.1; TCP/IP
11. MIDlet Security
• No “sand Box” as J2EE or J2SE. Because it is
expensive in terms of memory resources.
• No MIDlet APIs that allow access to information
already on the device, such as address and
telephone number lists or calendars, and it is not
possible for a MIDlet to directly control the device.
• A MIDlet can store information on a device, but
that storage is private to that MIDlet and its suite,
so the MIDlet can harm only its own data.
12. Wireless Java: Networking
Wireless Java: Networking
and Persistent Storage
and Persistent Storage
Two Essentials
Two Essentials
• The devices that the J2ME platform is intended for
are, by their nature, reliant for their usefulness on t
he ability to communicate with the outside world.
• The ability to store information and access it from
applications running on that device. The type of st
orage available, and the amount of space available,
varies greatly from device to device.
13. MIDlet Management and Storage
MIDlet Management and Storage
A MIDlet consists of one or more class files and associated reso
urces stored in a JAR file. Several MIDlets may be combined int
o a MIDlet suite. All the MIDlets that make up a given suite are
packaged in the same JAR file and are managed as a single unit:
they are installed together in the simulated nonvolatile device st
orage Furthermore, they all execute in the same instance of the J
ava VM. MIDlets almost always be installed over a network or v
ia a local connection to an associated host system. Because the J
AR file that contains a MIDlet suite may be large, each suite has
an associated Java Archive Descriptor file (JAD) that is small en
ough to download quickly, but which contains enough informati
on about the suite to allow the user to decide whether to install it.
The Application Management Software of a MIDP device (such
as a cell phone) typically first downloads the JAD file, whose lo
cation is specified by its URL. If the user decides to install the
MIDlet suite, the AMS downloads the JAR file, which can be lo
cated by using one of the attributes in the JAD. The MIDlet suit
e is then stored on the device, and subsequently, the MIDlets it c
ontains can be loaded from the locally installed copy..
14. How does J2ME work?
How does J2ME work?
The latest Java-enabled mobile devices, you can view
a list of applications, games, and services and
choose which one interests you. The application is
then sent over the air to your handset, where it is
installed and instantly available to use. You are no
longer limited to the small selection of games and
applications that came with your phone. And with
new content being released daily from top
entertainment and software companies, you can
always find new, fun applications to download.
15. Networking Architecture for
Networking Architecture for
Small Devices
Small Devices
• Memory requirements
Was judged to be too great for the small footprint devices that C
LDC is designed for.
• Consistency
The differences are significant when it comes to using a serial d
evice, because you need to install an extra package and use yet a
nother programming model. Given the diversity of devices and c
ommunication mechanisms that the CLDC might be required to
support, a more uniform API was clearly required.
• Implementation flexibility
An architecture based entirely around interfaces, so that applicat
ion code would not be tied to particular classes. Thus, vendors a
re free to provide socket and HTTP implementations that are ap
propriate for their specific devices.
16. HTTP Connections
HTTP Connections
• The only communications protocol that ever
y MIDP device is required to provide
• HTTP makes use of stream sockets to carry
messages between an HTTP client (usually
a web browser) and a web server that often
(but not always) returns an HTML page to t
he client.
17. Two Potential Problems
Two Potential Problems
• Many of handset devices, particularly cell phones, do not have a direct
connection to the internet and therefore almost certainly do not suppor
t sockets.
• The MIDP user interface components do not provide any support for d
isplaying HTML, so there is no built-in browser capability in a MIDP
device.
Answer
Answer
It is the responsibility of the device vendor to arrange for the device to
be able to support HTTP even if it does not have a direct connection to
the Internet. In most cases, this means that the device needs to connect
to a gateway that can switch HTTP messages to whatever protocol is u
sed to connect to the Internet gateway. In the wireless environment, fo
r example, the device might use WSP (the Wireless Session Protocol) t
o connect to a WAP gateway that can bridge between a wireless netwo
rk and the Internet. However this mapping is achieved, it must be done
in such a way that the MIDP application cannot tell whether it is direct
ly connected to the Internet.
19. Java Technology Handsets
Java Technology Handsets
To date, over 250 different handset models from more than 40
manufacturers have been developed with Java technology, with
more than 100 million of these handsets shipped worldwide.
---http://www.java.com/en/learn/mobile_(2003)
20. J2ME Programming Environments
• JBUILDER 7 OR 8 + BORLAND MOBIL
ESET 3.1 (Most Power Developing tools)
• SUN JDK 1.4 + J2ME Wireless Toolkit
• Jdk1.4+J2ME CLDC 1.04 ， MIDP 2.0
• SDKs from the mobile providers, e.g. Nokia
etc.
#6: A configuration is a specification that defines the software environment for a range of devices
defined by a set of characteristics that the specification relies on, usually such things as:
• The types and amount of memory available
• The processor type and speed
• The type of network connection available to the device
A configuration is supposed to represent the minimum platform for its target device and is not
permitted to define optional features. Vendors are required to implement the specification
fully so that developers can rely on a consistent programming environment and, therefore,
create applications that are as device-independent as possible.
No display, no user input interface…
#7: A configuration is a specification that defines the software environment for a range of devices
defined by a set of characteristics that the specification relies on, usually such things as:
• The types and amount of memory available
• The processor type and speed
• The type of network connection available to the device
A configuration is supposed to represent the minimum platform for its target device and is not
permitted to define optional features. Vendors are required to implement the specification
fully so that developers can rely on a consistent programming environment and, therefore,
create applications that are as device-independent as possible.
#8: A profile complements a configuration by adding additional classes that provide features
appropriate to a particular type of device or to a specific vertical market segment. Both J2ME
configurations have one or more associated profiles, some of which may themselves rely on
other profiles. These processes are described
in the following list:
Mobile Information Device Profile (MIDP)
This profile adds networking, user interface components, and local storage to CLDC.
This profile is primarily aimed at the limited display and storage facilities of mobile
phones, and it therefore provides a relatively simple user interface and basic
networking based on HTTP 1.1. MIDP is the best known of the J2ME profiles because
it is the basis for Wireless Java and is currently the only profile available for PalmOSbased
handhelds.
PDA Profile (PDAP)
The PDA Profile is similar to MIDP, but it is aimed at PDAs that have better screens
and more memory than cell phones. The PDA profile, which is not complete at the
time of writing, will offer a more sophisticated user interface library and a Java-based
API for accessing useful features of the host operating system. When this profile
becomes available, it is likely to take over from MIDP as the J2ME platform for small
handheld computers such as those from Palm and Handspring.
Foundation Profile
The Foundation Profile extends the CDC to include almost all of the core Java 2
Version 1.3 core libraries. As its name suggests, it is intended to be used as the basis
for most of the other CDC profiles.
Personal Basis and Personal Profiles
The Personal Basis Profile adds basic user interface functionality to the Foundation
Profile. It is intended to be used on devices that have an unsophisticated user interface
capability, and it therefore does not allow more than one window to be active at any
time. Platforms that can support a more complex user interface will use the Personal
Profile instead. At the time of writing, both these profiles are in the process of being
specified.
RMI Profile
The RMI Profile adds the J2SE Remote Method Invocation libraries to the Foundation
Profile. Only the client side of this API is supported.
Game Profile
The Game Profile, which is still in the process of being defined, will provide a
platform for writing games software on CDC devices. At the time of writing, it is not
certain whether this profile will be derived from the Foundation Profile or based
directly on CDC.
#9: 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.
In the longer term, it is intended that these devices use the PDA profile, which is also hosted by CLDC
#12: The devices that the J2ME platform is intended for are, by their nature, reliant for their
usefulness on the ability to communicate with the outside world. Cell phones, of course, serve
no real purpose other than to exist on a network, while PDAs would be much less useful if
you could not connect them occasionally to a desktop computer to save your new customer
orders or upload more appointments from your departmental calendar. As important as
networking is, however, there is a certain cost to be paid for it in terms of the resources
needed for the software that implements the various networking protocols in use today. Given
the relatively small amount of memory and processing power available in cell phones and the
smaller PDAs, compromises have to be made in order to provide networking support for the
type of hardware on which profiles designed for the CLDC are run. The same constraints do
not exist for the larger devices that host CDC profiles. Not surprisingly, then, these two
different profile families incorporate completely different communication software
architectures. This chapter looks at networking and communications in the context of the
CLDC configuration and MIDP, which differs greatly from its CDC equivalent,
#17: Although HTTP is predominantly used to carry HTML from web servers to web browsers, it
is also possible to use it to carry other types of information such as XML, images, or even
binary data. This is because one of the message headers specifies the type of the data in the
message body. Furthermore, the communicating parties do not have to be a browser and a
web server. The examples in this section all involve MIDlets talking to a web server, but
HTTP is routinely used for other purposes, such as tunneling protocols. These allow the
transmission of data that would otherwise be barred from passing through corporate firewalls,
since most companies allow HTTP to transmitted through their firewalls or via a proxy server.
The HTTP support in J2ME gives you access to all these possibilities.
#18: More than half of the tele-companies support J2ME lies in Asia, because of culture???
The people in North American don’t like add too many extra functions on their mobiles???
Comparing “Short-message service” in these two areas is a good example.
#19: Mobiles, PDAs or COMBOs (Palm-based phone, Microsoft smart-phone, Blackberry…etc) , We will see the J2ME in many electronics soon, even in microwave ovens??
So we can upgrade our home electronics for new functions for a very low price, even for free in the near future.
