Developing Wireless Applications using Java Technology

Bill Day bill.day@sun.com www.billday.com Technology Evangelist Sun Microsystems

Computing Is Ubiquitous
l

Mainframe era: one computer, many people PC era: one person, one computer As computing becomes ubiquitous: one person uses many computers, and these computers are networked

Java + XML + IP

What will we do with ubiquitous computing?

l

Everything imaginable, and more!

Java + XML + IP

In this session, you will learn:

l

What the J2ME Platform is, including the architectural basics as well as some internal details (APIs, VM features, etc.). How the J2ME Platform complements WAP, imode, and other markup based wireless technologies, and how you can use them together in your applications. How to get started building and deploying J2ME-based wireless applications today.

By the time we are done, you will be able to:

l l l

Understand what the J2ME Platform is, and describe it in detail to others. Integrate J2ME components into preexisting wireless applications and services. Build entirely new kinds of graphics rich, secure, network-centric wireless applications for millions of Java powered mobile phones and PDAs the world over.

Agenda
l l l l l

Java 2 Platform and J2ME Platform J2ME Platform and Mobile Service Technologies CLDC Internals and Details MIDP Details Availability and Resources

Java 2 Platform and J2ME Platform

Java 2 Platform
Optional Packages Optional Packages

Java 2 Platform, Micro Edition (J2ME) encompasses VMs and core APIs specified via Configurations as well as vertical or market-specificAPIs specified in Profiles
Personal Profile RMI Profile Other CDC Profiles ...

Java 2 Enterprise Edition (J2EE) Core APIs

Java 2 Standard Edition (J2SE) Core APIs

Foundation Profile

Mobile Information Device Profile

Java 2 Micro Edition Core APIs Java Programming Language

Java HotSpot Java Virtual Machine (JVM) KVM

Java Card APIs

Card VM

What Is a Configuration?
l

A configuration defines the minimum Java technology libraries and virtual machine capabilities that an application developer/content provider can expect to be available on implementing devices A J2ME platform configuration defines a minimum Java platform for a family of devices
Broad range of devices in different areas u Similar requirements of memory size and processing capabilities
u

Configurations
l l l

May not contain any optional features Defined through the Java Community ProcessSM initiative (JCP) Subject to compatibility tests

What Is a Profile?
l

l l

A collection of Java technology-based APIs that supplement a Configuration to provide capabilities for a specific vertical market or device type Defined through Java Community Process initiative Subject to compatibility tests

The J2ME Platform and Mobile Service Technologies

J2ME Platform Connected, Limited Device Configuration (CLDC)

l

Targeted at devices with

u 160KB

to 512KB total memory available for Java technology u Limited power (often battery) u Limited, perhaps intermittent connectivity to a network (often wireless) u Extremely constrained UIs, small screens
l l

CLDC 1.0 specification available for free download now Sun provides CLDC reference implementation built using the KVM

Mobile Information Device Profile (MIDP)

l l

Targets mobile two-way devices implementing J2ME CLDC Profile addresses

u Display

toolkit, User input methods u Persistent data storage using simple record-oriented database model u HTTP-based networking using CLDC Generic Connection framework
l l

MIDP 1.0 spec and implementation available for download now MIDP Next Generation via JCP

Example J2ME Technology Wireless Device Stack

Your MIDlet Mobile Information Device Profile

Yellow Pages, train schedules and ticketing, games UI, HTTP networking...

J2ME core APIs

CLDC = KVM + J2ME Core APIs in this example

KVM
DSP chip (e.g., ARM)

Threads, no Floats 32-bit RISC, 256K ROM, 256K Flash, 64K RAM

What About Web Content for Mobile Devices?

l

Markup languages in use today to deliver Web content to device browsers:

u

Compact HTML (C-HTML) is an HTML-based markup deployed to millions of users in NTT DoCoMos i-mode network u The WAP Forums Wireless Markup Language (WML) is an emerging standard for content (data) delivered to mobile devices u HTML dominates Web content worldwide

WAP specifies its own protocols (Wireless Session Protocol, Wireless Transaction Protocol, etc.)

Wireless Web Content Distribution

Content Producers Carriers or Wireless Portals Client Devices

Static Content

Web Server or WAP Gateway

Web or WML Browser

Java Apps Dynamic Content Content Transcoding

Java Application Manager

Java Applications

Applicati Application on Distribution Distribut ion

MID Profile J2ME CLDC

Example Java Technology Application Loading Process

Advertise App on Web Page User Selects App JAM Downloads App

Web Page

(Name, Version, Size, )

Descriptor File

Network Transfer

Java Application Manager

Jar File

The Future: Transcoding and XHTML

l l

Transcoders are becoming more capable and widely used WML, C-HTML, and HTML are converging towards XHTML
XHTML is the re-writing of HTML as an XMLbased markup language u XHTML Basic will be renderable everywhere u WAP Forum and W3C collaborating on XHTML
u

WML CHTML HTML XHTML

The not too distant future...

CLDC Internals and Details

10

Scope of the CLDC Specification

l

Specifies VM features required of CLDC implementation in terms of additions to and deviations from The Java Virtual Machine Specification by Lindholm and Yellin Specifies requirements for interfaces and APIs for the following:
Input/output, Networking u Security model u Internationalization features
u

Beyond the CLDC Scope

l

Specified in Profiles to be implemented on top of the CLDC:

u User

interface support u Event handling u High-level application model u Persistence support

l

One example specification of these remaining APIs: Mobile Information Device Profile (MIDP)

11

CLDC Language and VM Compatibility

l

General goal:
u Full

Java programming language and Virtual Machine Specification compatibility point not in CLDC 1.0

Only language-level exception:

u Floating
n

No hardware floating point support on most devices due to space limitations n Manufacturers and/or developers may choose to include their own floating point, however

CLDC Language and VM Compatibility

l

VM Implementation differences:
u No

Java Native Interface (JNI) u No reflection u No thread groups u No weak references u No finalization u New implementation of bytecode verification using preverifier and bytecode annotations

12

CLDC Libraries
l

Classes inherited from Java 2 Platform, Standard Edition (J2SE version 1.3) are in packages:
u java.lang.* u java.util.* u java.io.*

New classes introduced by CLDC are in package:

u javax.microedition.*

CLDC Libraries: java.lang.*

l l l l l l l l

java.lang.Object java.lang.Runtime java.lang.Thread java.lang.String java.lang.Math java.lang.Byte java.lang.Integer java.lang.Character

java.lang.Class java.lang.System java.lang.Runnable java.lang.StringBuffer java.lang.Throwable java.lang. Long java.lang.Boolean java.lang.Short

13

CLDC Libraries: java.util.*

l l l

java.util.Vector java.util.Hashtable java.util.Random

java.util.Stack java.util.Enumeration java.util.Calendar

CLDC Libraries: java.io.*

l l l l l l l l

java.io.InputStream java.io.OutputStream java.io.Reader java.io.Writer java.io.DataInput java.io.DataOutput java.io.InputStreamReader java.io.OutputStreamReader java.io.ByteArrayInputStream java.io.ByteArrayOutputStream java.io.PrintStream

14

Comments on CLDC Libraries

l

Internationalization
Limited support for the translation of Unicode characters to and from a sequence of bytes u Implemented using Readers and Writers u By default, the only character encoding for which a converter is provided in ISO-LATIN1 u Localization implemented by manufacturer
u

Property support
No java.util.Properties class u Properties read using System.getProperty(String key) u Limited set of CLDC-specific properties supported
u

Networking, I/O and Storage Libraries

l

Standard Java technology networking, I/O and storage libraries are too large for CLDC devices
than 100 classes u Total static size of classfiles more than 200 KB u Original classes were never designed for small devices
u More

15

Networking, I/O and Storage Libraries

l

CLDC specifies an alternative Generic Connection framework

u More

coherence in supporting different types of I/O u Consistent way of supporting different protocols u Improved portability of applications u Smaller footprint

Generic Connection Possibilities

General form:
Connector.open("<protocol>://<address>:<parameters>");

Files:
Connector.open("file://billday.txt");

HTTP:
Connector.open("http://www.billday.com");

Sockets:
Connector.open("socket://129.144.111.222:9000");

Communication ports:
Connector.open("comm://9600:18N");

16

MIDP Details

Scope of the MIDP Specification

l

Primary goals:
u Size:

MIDP implementation must fit in small footprint (128KB ROM) u Efficiency:

must run on low-end microprocessors n must run in with limited heap size (32200KB RAM) n minimal creation of garbage
n

u Time

to market is critical for manufacturers of Mobile Information Devices

17

Beyond the MIDP Scope

l

To be implemented by device manufacturers, operators, or third party developers:

u How

an application actually gets on the device u The end-to-end security model u System- or OEM-specific technologies

MIDP Application Lifecycle

l l

MIDP applications are known as MIDlets MIDlets move from state to state in the lifecycle, as indicated.
Start acquire resources and start executing u Pause release resources and become quiescent (wait) u Destroy release all resources, destroy threads, and end all activity
u

18

MIDlet Packaging
l

MIDlets are packaged in a JAR file including

u Class

files of the MIDlet(s) u Resource files u Manifest with application properties

l

Application Descriptors accompany MIDlet JARs and provide information including

u Configuration
n

properties u Pre-download properties

Size, version, storage requirements

MIDP Libraries
l

The MIDP specifies APIs for:

u Persistent

Storage u Networking u Timers u User Interface

19

MIDP Persistent Storage

l

Lightweight record oriented database

u u u u u u

Device independent API Unique record ID for each record within a store Records are arrays of bytes Shared within MIDlet suite Atomic update for single records Support for enumeration, sorting and filtering

Device platform is responsible for:

u u

Integrity of data across reboots, battery changes Storage in flash or other device memory

MIDP Persistent Storage: RMS Methods

l

Record Store
u openRecordStore,

closeRecordStore, listRecordStore, deleteRecordStore, getRecordSize, getNumRecords deleteRecord, getRecord, setRecord, getRecordSize RecordFilter,

Record Data
u addRecord,

Record Selection
u RecordEnumeration,

RecordCompare

20

MIDP Networking
l

MIDP devices must implement HTTP protocol, though this may or may not use IP-based transport underneath

MIDP Networking Methods

l

MIDP networking extends from CLDC Generic Connection Framework HttpConnection includes methods:
u get/setRequestProperty u get/setRequestMethod u getResponseCode, u getHeaderField u getURL,

getResponseMessage

getHost, getPort, getFile, getQuery, getRef (Parsed URL components)

21

MIDP Timer Methods

l l

Timer handles queuing and delivery Timer Task

u Multiple u Periodic u Fixed

Tasks per Timer

interval u One shots

MIDP UI Design Principles

l

MIDP must be usable in all devices

Majority of wireless devices are one-hand operated u Small screen (tens of pixels by tens of pixels) u Not all devices have a pointing device
u

Must constantly think of end users:

u

Mobile Information Devices are consumer products, not desktop computers u Unified user interface between MIDP applications and native apps on the device
n

MIDP applications should behave consistently with resident functionality

22

MIDP UI: A Tale of Two Layers

l l

MIDP UIs may be created using one of two layers of APIs Use the high-level APIs for portability
u

Applications using these APIs should be runnable and usable in all MIDP devices u No direct access to native device features Provide access to native drawing primitives, device key events, native input devices, etc. u Allow developers to choose to compromise portability for user experience, if needed
u

Low-level APIs

MIDP Screen-based Design Principles

l l

MIDlet UIs are built using simple screens Screens should contain minimum amount of information required
u Usually

only one "thing"

Screens should require only simple interactions from user

u No

complex traversing, scrolling, or selection metaphors

23

MIDP UI Class Hierarchy (major classes only)

Displayable Canvas 0-n Command Screen TextBox List 1-n Alert Form Item Choice

ChoiceGroup DateField TextField Gauge ImageItem TextItem

MIDP Input Handling

l

High-level API input is handled using abstract commands instead of direct access to soft buttons
u Each

MIDP implementation maps these commands to appropriate soft buttons or menu items for the particular device u MIDlets can provide semantic hints (like back)
l

Low-level API gives developers access to key press events

24

MIDP Input Commands

l

Example MIDP input commands:

new Command("Buy", Command.SCREEN); new Command("Info", Command.SCREEN); new Command("Back", Command.BACK);

Ford Opel BMW Options Back

Buy Info

Pressing "options" opens a menu

Back

MIDP Next Generation

l

MIDP NG Java Specification Request (JSR) states that MIDP NG spec will:
u Maintain

backward compatibility (MIDP 1.0). u Continue focus on high-volume wireless phones. u Maintain small footprint, limit API growth. u Fine tune MIDP 1.0 APIs. u Focus on core functions needed by all compliant devices and applications. u Focus on enabling mobile commerce, service-based applications

25

MIDP Next Generation

l

Areas to be investigated by MIDP NG expert group will likely include:

u HTTPS

and secure networking (SSL/TLS). u Formal inclusion of Over The Air (OTA) Provisioning (Recommended Practice 1 for MIDP 1.0) as part of MIDP NG spec. u Network connectivity via sockets and datagrams. u Domain security model, including signing of applications and verification of certificates.

MIDP Next Generation

l

Additional areas to be investigated for MIDP NG:

u Push

architecture (external events and messages routed to MIDlets). u Extensions to low level (game) LCDUI model to allow greater game functionality and layout control for larger screens. u Possible inclusion of a small XML parser to enabled platform-independent data exchange. u Basic sound API.

26

Availability and Resources

Java Technology in Mobile Devices: Where Are We Today?

l l l

l l

J2ME CLDC and MIDP reference implementations freely available from Sun. KVM ports in various imode handsets, Motorola devices, RIM handhelds, and more. Symbian continues support for Java technology in the EPOC operating system, used in devices such as Nokias 9210 communicator. LG deployed J2ME in Korea beginning summer 2000, NTT DoCoMo deployed in Japan in its imode service in January 2001. Nextel is deploying in the US, Spring 2001. Agreements and projects with Vodaphone AirTouch, Sprint PCS, Telefonica, and others.

27

The J2ME Platform and Mobile Phone Standards

l

Special Mobile Group (SMG)

Working group of European Telecommunications Standards Institute (ETSI) u Specifies Mobile Station Application Execution Environment (MExE) for GSM mobile phone handsets u SMG has adopted PersonalJava technologies as part of the MExE Release 98, classmark 2 spec for GSM handsets
u

3GPP has announced adoption of J2ME CLDC and MIDP technologies for worldwide third generation (3G) mobile standards

J2ME Platform Mobile Tech Availability (as of 28 May 2001)

Technology Connected, Limited Device Configuration Mobile Information Device Profile MIDP Next Generation Type J2ME Config. J2ME Profile J2ME Profile Spec JSR-30, 1.0 JSR-37, 1.0 JSR-118, proposed FAQ Reference Impl. Yes Yes, 1.0.2 (includes KVM) Yes Yes, 1.0.1 Mailing list Yes via KVM interest Yes via KVM interest Yes via KVM interest

Not yet

Not yet

28

J2ME Platform CLDC and MIDP Development Tools

l l l

l l

Sun J2ME Wireless Toolkit (optionally plugs into free Forte for Java IDE) MIDP reference, CLDC/KVM SDK (support for Win32, Solaris platform, Linux, and PalmOS) Metrowerks/Motorola J2ME tools, RIM BlackBerry IDE, Zucotto WHITEboard SDK, and more Any IDE or standard Java tool, including J2SE SDK (aka JDK 1.2.2 or 1.3) Tools from the J2ME Archive (Spotter utility, WBXML package, etc.)

Sun J2ME Wireless Toolkit

29

Other J2ME Tools

Example 1: Zentek i-JADE as P503i

Example 2: Zucotto WHITEboard Emulator

Other J2ME Tools

Example 3: PalmOS Emulator

Example 4: Sun MIDP Reference

Example 5: RIM BlackBerry Java Development Environment

30

J2ME Development Tools

l l l

They are available NOW. They are FREE. They are all you need to start writing great Java applications for mobile devices TODAY.

Discuss the J2ME Platform

l

The kvm-interest mailing list is a free J2ME development list hosted by Sun
u u u

To subscribe, send email to: listserv@java.sun.com In the body of the message, type: subscribe kvm-interest For digest mode, include the following line: set kvm-interest digest

The kvm-interest archive is searchable online at:

archives.java.sun.com/archives/kvm-interest.html

31

J2ME Platform CLDC and MIDP Resources

l l

l l

J2ME: java.sun.com/j2me Connected, Limited Device Configuration specification and SDK: java.sun.com/products/cldc Mobile Information Device Profile specification and reference implementation: java.sun.com/products/midp Download the Sun J2ME Wireless Toolkit: java.sun.com/products/j2mewtoolkit J2ME Webcast: java.sun.com/jdc/onlineTraining/webcasts

Additional Resources
l l l l

l l

J2ME Archive: www.billday.com/j2me jGuru J2ME FAQ: www.jguru.com/faq/J2ME J2ME tutorial articles: java.sun.com/jdc/technicalArticles/wireless J2ME tools CD, available now as part of Java Jumpstart from Sun Developer Connection (SDC) Got questions? Email Suns Technology Evangelists: evangcentral@sun.com Or visit our homepage: www.sun.com/developers/evangcentral

32

For more, please visit SDC at: www.sun.com/developers

Copyright 2001 Sun Microsystems, Inc., All rights reserved. Sun, Sun Microsystems, the Sun logo, Solaris, Java, PersonalJava, Java TV, EmbeddedJava, Java Card, Java Hotspot, JavaOne, JavaScript, iPlanet, JDBC, JDK, JavaCheck, Enterprise JavaBeans, Java Embedded Server, Java Community Process, The Java Coffee Cup Logo, Java Virtual Machine, Java Native Interface, JVM, J2ME, J2SE, and The Network Is The Computer are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Speaker Bio
Bill Day is a Technology Evangelist at Sun Microsystems. Bill created the J2ME Archive to help developers build applications and services using Java technology. He manages jGurus J2ME FAQ. Bill also writes about software development for numerous publications and teaches Java and Wireless development as an extension instructor for the University of California Berkeley. More information is available from Bills web site: www.billday.com

33

34