Micro Java

1
Micro Java

• Background Mobic
• Status J2me
• J2me as mobile client
• J2me and network support

tore_at_mobic.com
2
About Mobic
3
Mobilinfo - Why Java?

• Mobilinfo sms plattform developed in 1996
• Mobilinfo is a server application, offering sms
  services to mobile terminals
• Java was not the preferred telecom language in
  1996
• But we had a long term perspective
• We expected that in the future, mobile clients
  would be java enabled
• So we wanted to build the correct core competency
• Finally, 5 years later, java is available on
  mobile terminals

4
Mobile service technologies

• Alternative technologies
• Technology will be fragmented for a while
• Application architecture should be flexible, and
  support different access terminals
• Technologies will converge after a dominance
  war
• J2me has good potential

SMS
5
(No Transcript)
6
J2me building blocks
7
CONFIGURATION

• A configuration is comprised of a virtual
  machine, core libraries, classes and APIs.
  Currently, there are two J2ME configurations the
  Connected Limited Device Configuration (CLDC) and
  the Connected Device Configuration (CDC).
• CLDC is designed for devices with constrained CPU
  and memory resources. Typically, these devices
  run on either a 16- or 32-bit CPU and have 512
  Kbytes or less memory available for the Java
  platform and applications.
• CDC is designed for next-generation devices with
  more robust resources. Typically, these devices
  run on a 32-bit CPU and have 2 Mbytes or more
  memory available for the Java platform and
  applications.

8
J2me architecture
9
MIDP

• The minimum MID supported by the MID Profile must
  have a display that is 96 pixels wide by 54
  pixels high and 1-bit in depth (black and white).
• The device must support either a one-handed or
  two-handed input mechanism.
• A one-handed keyboard is a term commonly used
  to describe an ITU-T phone keypad. An ITU-T phone
  keypad typically has the numbers 1-9, an asterisk
  (), and a pound sign ().
• A two-handed keyboard is a term commonly used
  to describe a QWERTY keyboard (as might be used
  by a pager).

10
High level API

• portability
• high level of abstraction
• Typical applications using a highlevel API are
  stock transactions, travel reservations, online
  purchase of concert tickets, news headlines,
  weather updates, and traffic information
• Functions available
• Form, Ticker, Alert, List etc

11
Low-level api

• Full control of graphics
• very little abstraction
• requires a bit more design work to remain
  portable.
• applications that need precise placement and
  control of graphic elements, as well as access to
  low-level input events.
• The low-level API allows the application to
  access special, devicespecific features.
• Games are a typical application using this API.

12
GUIPC vs Micro Java Devices

• a major difference that designers and developers
  must take into consideration is the absence of
  windows or a windowing system. Instead, the
  central abstraction of the MID Profile UI API is
  the screen.
• Only one screen is visible at a time,
• The screen handles all events
• Only high-level events are passed on to the
  application.
• Screens scroll vertically only there is no
  horizontal scrolling.

13
Screen Types

• The MID Profile makes use of four types of
  screens List, Alert, Text Box and Form.
• The List screen provides three variations an
  implicit (menu) list a single-choice list and a
  multiple-choice list. The implicit list can be
  used to display a list of menu commands inside of
  the application.
• The Alert and Text Box screens should seem
  familiar to developers acquainted with the
  desktop world with the caveat that content must
  adapt to the MIDs limited resources and screen
  size. Alerts are much simpler and use the entire
  screen. Text boxes generally will not support
  fancy text formatting or font styles and allow
  only the basic text editing capabilities.
• A Form is a screen that contains an arbitrary mix
  of items including images, readonly text,
  editable text, date and time fields, gauges and
  choice groups. The form screen is where
  developers will be most able to use their design
  and development skills to create a winning
  application within the MID Profile constraints.

14
Abstract Commands

• map between the buttons on a device and the set
  of commands that an application developer
  attaches to a screen.
• Developers gain the freedom of creating portable
  applications, but lose control over where each
  specific command will map on the device.
• If an application asks for more abstract commands
  than there are available buttons, the MID Profile
  reference implementation, for example, uses
  another UI mechanism, the menu, to make the
  commands accessible to the user.

15
Typical Menu Screens
16
Network support

• The MIDP 1.0 Spec defines that a complian
  implementation must impleament at least HTTP 1.1
  strea,-based client connections
• No support for rmi, thus no support for direct
  ejb communications
• More information on networking
  http//download.forum.nokia.com/download/Networked
  MIDletsv0_9.pdf

17
Example Display Operator Logos

• Source format in ejb Nokia OTA bitmap
• Dynamic creation of png format using java servlet
  and java image api
• Accessing EJB application through servlet
• Same servlet for dynamic image generation on web
  and j2me terminal
• Conclusion jsp/servlet layer is needed due to
  limited networking support in midp

Dynamic PNG generation Servlet
EJB
MySQL
18
J2me and bluetooth

• How can j2me use bluetooth?
• Transparent ip communication over a bluetooth LAN
  connection
• Terminal uses bluetooth to enable transparent ip
  access
• J2me uses standard network support to connect
• Access bluetooth functions directly from j2me
• Function as server or client
• Direct lookup and usage of services

19
J2me bluetooth

• The Java API for Bluetooth Wireless Technology
  will not actually implement the Bluetooth
  specification. It will provide a set of APIs to
  access and control a Bluetooth System.
• A Bluetooth System is made up of a Bluetooth
  Stack and Bluetooth radio. The stack drives the
  radio. Our API is mainly concerned with providing
  Bluetooth capabilities to Java 2, Micro Edition
  (J2METM) devices and not with implementing
  Bluetooth technology.
• This is similar to TCP/IP where the stack or
  driver is written in C while the Java API exposes
  those capabilities.

20
J2me bluetooth

• Estimates
• The plan is to finish the Specification for
  participant review in October and hopefully
  public review in November or December.
• Depending on how this goes, the Specification
  will go to 1.0 late this year or in January of
  next year.

21
J2me bluetooth

• The Bluetooth API is being developed as part of
  the J2ME family of specifications.
• The Bluetooth API will be considered an "optional
  package" that can be used in conjunction with any
  of the J2ME Profiles such as the MIDP profile.
• A separate reference implementation is being
  developed for Bluetooth that will run over the
  Connected Limited Device Configuration (CLDC).
• Whether the Bluetooth APIs will be included in
  the various J2ME toolkits that are being
  developed, is unclear at this point, but we hope
  so.

22
J2me bluetooth

• There are three parts of our API
• Discovery,
• IO, and
• Management.
• The API will provide device and service discovery
  capabilities. This includes advertising services
  that are available on the local device. The API
  also allows sending and receiving of data only.
  (Voice is not part of the API.)
• Finally, the API will provide management
  capabilities. These include setting security
  requirements and controlling the local Bluetooth
  system.

23
Terminal availability, J2me gsm

• Motorola Accompli
• Siemens (not gprs)
• More to come.