J2ME Bootcamp

1
J2ME Bootcamp
2
Who is Sue?

• President of Switchback Software LLC
• 18 years hands-on enterprise and mobile
  application development experience
• Author, technology columnist, magazine
  contributor, JSP 2.1 EG member

3
Objective

• Provide a J2ME overview so that when you leave
  here youll be able to get started doing J2ME
  development.

4
Content

• J2ME overview and the mobile landscape
• Configurations and Profiles
• How development is done with J2ME
• Build Environment
• MIDlet Development
• Building a UI
• Event Management
• Networking
• Working with Threads
• Using a Record Store
• Enterprise J2ME
• kXML-RPC Usage
• Couple of advanced topicsif we have time.

5
J2ME Overview and the Mobile Landscape
6
Java Technology Editions

• Java 2 Platform, Enterprise Edition (J2EE)
• Enterprise solutions ecommerce, ebusiness
• Java 2 Platform, Standard Edition (J2SE)
• Desktop solutions standalone apps, applets
• Java 2 Platform, Micro Edition (J2ME)
• Consumer solutions cell phones, PDAs, TV, STBs,
  cars
• All based on the Java programming language
• Different JVMs and APIs

7
Java 2 Micro Edition

• Java 2 platform targeted at embedded and consumer
  electronics
• embedded systems, cell phones, pagers, PDAs, TV,
  STBs
• Consists of a VM and APIs tailored for such
  environments
• Modular architecture
• Configurations
• Profiles
• Vendors have their own SDKs on top of J2ME with
  optional packages (Motorola, Nokia,)

8
Id Like to Buy a Vowel

• CDC Connected Device Configuration
• CLDC Connected Limited Device Configuration
• MIDP Mobile Information Device Profile
• MIDlet Mobile app based on MIDP
• AMS Application Management System
• LBS Location Based Services
• OTA Over The Air
• KVM Kilobyte Virtual Machine
• WTK Suns Wireless Toolkit
• WICS Wireless Is Cool Stuff! (ok, I made this
  one up)

9
Java Micro Platforms
Device Version PC J2SE PDA and
Communicators J2ME/CDC Phones and
Pagers J2ME/CLDC Embedded Devices J2ME/CLDC Sm
artCards JavaCard
10

• Pretty much any type of mobile app you can think
  of!
• Client-only, CRM, ERP, Field data services, POS,
  LBS/GPS, P2P Messaging, PIM, Multi-media, Sales
  Force Automation, Information servicesyou get
  the picture

11
Configurations and Profiles
12
J2ME Components
Optional Packages RMI, JDBC and Advanced
Graphics (Swing an Java 2D)
Optional PackagesPDA (File and PIM), Mobile
Media, Wireless Messaging, Mobile 3D, Location,
Bluetooth, Web Services
Personal Profile
Personal Basis
Game Profile
MIDP
Foundation Profile
CLDC
CDC
JavaOS or VMs on top of BREW or .NET
Java2 VM
KVM
OS
Device Hardware
InternetAppliances
PDAs
Pagers
Layout Source Enterprise J2ME, Yuan. PH 2003
13
Configurations

• Specific to a family of devices
• i.e Common features of a device CPU, RAM, ROM,
  etc.
• Comprised of
• Virtual Machine
• Core libraries
• Classes, APIs
• 2 Configurations
• Connected Device Config (CDC)
• Connected Limited Device Config (CLDC)

14
CDC

• Next generation devices
• Smart communicators, two-way pagers, home
  appliances, auto systems, interactive TV-set top
  boxes
• 32 bit CPUs
• Min 512KB ROM, 256KB RAM (usually greater than 2
  MB memory)
• Fully featured Java 2 VM and can use J2SE
  libraries
• Foundation Profile
• Based on J2SE 1.3

15
CLDC

• Designed for devices with resource constraints
• Cell phones, PDAs, pagers, mobile POS
• Target Device
• 16 bit/16 MHz or higher CPU
• 160 - 512 KB memory (192KB min in CLDC 1.1)
• Limited power, often battery powered
• Limited bandwidth connectivity (lt9.6Kbps)
• Uses KVM

16
KVM

• Sun's Kilobyte virtual machine
• 50K
• With libraries KVM 130K
• Designed from ground up to meet needs to mobile
  devices
• Highly configurable but limits us because of size
  restrictions

17
KVM Limitations

• Doesnt support float or double data types (CLDC
  1.1 does)
• java.util greatly reduced
• Limited string, and I/O functionality
• No JNI or custom class loaders
• java.lang subset and in some cases modified
  interface and implementation signatures
• Runtime - Reduced signature to memory operations
  - freeMemory(), gc(), totalMemory()) and exit()
• System (reduced signature)
• Threading limited number of Threads, no thread
  pooling
• File System replaced with RMS
• Unicode is supported, but far fewer encodings are
  supported

18
What Youre Basically Working With
java.io
java.lang
java.util
InputStream InputStreamReader DataInput DataOutput
ByteArrayInputStream ByteArrayOutputStream Output
Stream OutputStreamWriter PrintStream Reader Write
r
Boolean Short Byte String Character StringBuffer C
lass System (limited) Integer Thread
(limited) Long Throwable Math (Very different
signature) Runnable Runtime (limited)
Enumeration Data Hashtable Random Stack Timer Time
rTask TimeZone Vector Date Calendar DateField
(DateFormat) TimeZone
19
Profiles

• Defined through JCP (what isnt?)
• Sits on top of, and specifies a configuration
• Specific to meet need of an industry or class of
  devices
• Specifies classes and methods needed for a
  complete runtime environment

20
MIDP

• Mobile Information Device Profile
• Targeted at medium- to low-end cell phones and
  two-way pagers
• Spec addresses issues such as
• Application life cycle
• User interface
• Persistent storage
• Networking
• If you really have trouble sleepingyou can read
  through the MIDP 2.0 spec _at_ http//jcp.org/jsr/det
  ail/118.jsp

21

• MIDP 2.0 is the latest version of the spec with
  lots of cool new features. MIDP 1.0 is still
  around and is still the predominate version
  supported on devices.

22
MIDP 2.0

• JSR-118 (a subset of Mobile Media JSR-135)
• Formally includes OTA
• Enhancements to enable reliable delivery of
  services
• Notifications enabled for success of install or
  deletion of a MIDlet
• Sockets
• UDP Datagrams, Secure Sockets
• Options, info, dynamic port addresses

23
MIDP 2.0 Secure Sockets

• HTTPS HTTP over SSL
• SSL is a socket protocol that encrypts data sent
  over the network and provides authentication for
  the socket endpoints
• Also includes javax.microedition.io.SecurityInfo,
  which contains information about a secure
  connection
• javax.microedition.pki.Certificate, which
  represents a cryptographic certificate

24
MIDP 2.0 - MMAPI

• Subset of Mobile Media API (MMAPI)
• http//jcp.org/en/jsr/detail?id135
• Enhanced UI
• Custom Item support
• Layout control
• Graphical enhancements (like transparency)
• 2D Game API
• Sound
• Rich audio tone generation
• Sampled sounds

25
MIDP 2.0 - Security

• Protection Domains for MIDlet and MIDlet suites
• Recognizes the concepts of trusted and untrusted
  code and permissions.
• Untrusted code cannot make connections at will
  it must receive permission from the user.
• Can indicate required and optional permissions in
  a MIDlet suite using MIDlet-Permissions and
  MIDlet-Permissions-Opt descriptor attributes
• Code can be designated as trusted if the
  developer digitally signs it and the user's
  device can verify the signature.

26
MIDP 2.0

• A push registry that allows MIDlets to be
  launched in response to incoming network
  connections
• For example, maybe have a server socket listening
  on the device for an SMS message that can then
  activate a MIDlet

27
How J2ME Development is Done
28
J2ME Steps

• Slightly different than J2SE
• Code
• Compile
• Preverify
• Create JAD Manifest File
• Package
• Deploy (maybe)
• Emulate/Run

29
(No Transcript)
30
Getting Started

• Start with JDK 1.4.2 (or at least 1.3) to get the
  platform, compiler, and other tools the WTK uses.
• Download and install the WTK 2.1 from
  http//java.sun.com/products/j2mewtoolkit/
• Create a project, code, build, run
• WTK will take care of javac bootclasspath and
  preverify for youor you can write your own Ant
  build.xml to do everything.

31
Dev environments IDEs

• Can pretty much use whatever IDE you want. Some
  are better than others.
• Limited set of good tools at this point, but
  improving
• High End costs
• Borlands JBuilder Mobile Edition
  http//www.borland.com/jbuilder
• Metrowerks CodeWarrior http//www.metrowerks.com
• IBM WebSphere Studio Device Developer 5.6
• Free
• Suns Wireless Toolkit (WTK) 2.1
  http//java.sun.com/products/j2mewtoolkit/
• Eclipse http//www.eclipse.org with use of plugins

32
Emulators

• Necessary for testing device specific supplied
  by vendors (like Motorola,Nokia,etc)
• Not always the same as running on the device
• Network Latency
• File system access
• Object creation during processing
• Specifically, XML to Java object processing
• Screen sizes
• Fonts and shading
• Layout

33
Ant

• Ant is a Java-based build tool
• Makes a repeatable build process possible
• Found at http//ant.apache.org
• Used for all aspects of the build process
• Can easily enhance the build.xml
• Helpful to separate the build into MIDlet and
  Server-side for easier maintainability

34
Other Tools Antenna

• A set of Ant tasks for developing MIDP apps
• Provides tasks for compile, preverify, package,
  obfuscate, running MIDlets, manipulating JAD
  files and more
• Tasks are named ltwtk
• v0.9.12
• http//antenna.sourceforge.net
• HUGE timesaver! (unless you like inflicting
  suffering on yourself)

ltANTENNA/gt
35
Other Tools Proguard

• Obfuscator - detects and remove unused classes,
  fields, methods, and attributes
• Can rename remaining classes, fields, and methods
  using short meaningless names
• Results in smaller jars that are harder to
  reverse-engineer
• http//proguard.sourceforge.net

36
CLDC 1.1 3rd Party Libraries

• Provides a subset of J2SE APIs available in
  various libraries.
• java.lang
• java.io
• java.util
• Additional classes are provided in
  javax.microedition.
• Vendor Specific APIs if you are working with a
  specific SDK
• kXMLRPC v1.0 for J2ME/J2EE interaction

37
Build Environment
38
Our Goals for Efficient Builds

• Eliminate manual steps whenever possible
• Create targets that can be chained together
• Take advantage of depends
• Support full compile, test, package, and deploy
  functionality
• Eliminate developer management of names,
  settings, locations, output dirs, etc.
• Provide a mechanism so that all developers have
  identical base development areas
• IDEs are a personal choice, while build, package
  and deploy directories are not

39
Build Orientation

• All paths are relative
• relative paths from project dir to tools dir
  defined in build.properties
• Use of tools/toolname/versions
• Virtually all build artifacts go into ./build.
• This is so the entire ./build dir can get deleted
  and recreated via a very small set of build
  targets.
• Nothing in build is permanent.
• Lets see what it looks like

40
Dir Structure
41
Build Environment

• The build environment is critical for productive
  J2ME development
• Sample build.xml targets
• clean cleans all build files
• core cleans and then build the client and
  server
• client preverify and builds the midlet
• package packages midlet with jar and jad files
• pingserver run a test program to test the
  server availability
• banner print out some build information
• deletedirs Cleans any output/intermediate files
  from previous builds.
• mkdirs creates new directory structure
• init initializes project scope variables

42
Why Preverify?

• In the JVM we have bytecode verification, an
  important step in the Java security model
• Most of the bytecode verifier is not included
  with the KVM because of size constraints
• Preverifier makes sure the equivalent security
  checks still take place
• Needs to be a separate step, which is why we have
  a preverified directory, and then a classes
  directory (which have been preverified)

43
Building the MIDlet

• The client target uses Antenna to compile and
  preverify in one step
• ltwtkbuild srcdir"dir.source"
  includes"include.midlet" classpath"midlet.c
  lasspath" destdir"dir.midlet.classes.nonprever
  ified" preverify"true"/gt

44
Packaging

• lttarget name"package" depends"init, banner,
  core"gt
• ltwtkpackage jarfile"dir.midlet.deploy/mi
  dlet.name.jar" jadfile"dir.config/midlet.na
  me.jad" preverify"true" autoversion"true"
  libclasspath"gps.classpathkxmlrpc.classpath
  " obfuscate"false"gt
• ltfileset dir"dir.midlet.classes.nonprever
  ified"/gt
• ltfileset dir"dir.resource"/gt
• lt/wtkpackagegt
• lt!-- Copy and rename our project template JAD
  to the deploy directory
• so it is side-by-side with the Jar file. This
  is needed so both Jad and Jar reside together for
  deployment to a phone. --gt
• ltcopy file"dir.config/midlet.name.jad
  tofile"dir.midlet.deploy/midlet.
  name.jad"/gt
• lt!-- Copy just created Jar to the config
  directory. This is needed to synchronize the
  deploy and Motorola emulation areas. In our
  setup, Motorola emulates out of the config dir.
  --gt
• ltcopy file"dir.midlet.deploy/midlet.name
  .jar" tofile"dir.config/midlet.name.jar"/gt
  
• lt/targetgt

45
JAD File

• Used by AMS to manage MIDlets
• Has to be supplied to run a CLDC-compliant app
• File extension of .jad
• Some attributes of the manifest file are
  duplicated in the JAD
• MUST match information in the JAR Manifest
  otherwise MIDlet wont load
• Name/Value pair, separated by a colon and
  optional whitespace
• For a full list of supported JAD entries
  reference http//java.sun.com/j2me/docs/wtk2.0/us
  er_html/Ap_Attributes.html
• Usually build JAD by hand first time, but update
  via Antenna WtkJad build task

46
Sample JAD

• MIDlet-1 MyMIDlet, MyMIDlet.png, MyMIDlet
• MIDlet-2 FirstConnection, , FirstConnection
• MIDlet-Jar-Size 100
• MIDlet-Jar-URL MyMIDlet.jar
• MIDlet-Name MyMIDlet
• MIDlet-Vendor Switchback Software
• MIDlet-Version 1.0
• MicroEdition-Configuration CLDC-1.1
• MicroEdition-Profile MIDP-2.0

47
Manifest Files

• Need both a manifest file for the JAR as well as
  a JAD file.
• Need to have matching information.
• Why then do we need to duplicate info?
• MIDP devices fetch the JAD first (much smaller)
  before downloading the JAR.
• Gives a user a chance to determine whether they
  want the download to continue

48
MIDlet Suites

• Weve provided Homebase1, Homebase2, and Homebase
  in a MIDlet suite
• MIDlet suite is a JAR file that contains 1 or
  more MIDlets
• MIDlet-ltngt contains info about that MIDlet
• MIDlet-1 HomeBase, , com.sb.dwm.midlet.HomeBase
• MIDlet-2 HomeBase1, , com.sb.dwm.midlet.HomeBase1
  
• ltngt MIDlets get packaged in the same JAR file
• AMS gives choice for loading each MIDlet

49
Emulators

• Necessary for testing device specific supplied
  by vendors (like Motorola,Nokia,etc)
• Not always the same as running on the device
• Network Latency
• File system access
• Object creation during processing
• Specifically, XML to Java object processing
• Screen sizes
• Fonts and shading
• Layout

50
Deploying onto devices

• 2 ways serial cable or OTA
• Hook up a serial cable from your dev machine to
  your device
• Usually vendor will provide some type of
  development tool
• Motorola has the WebJAL which is goodwhen it
  works.
• Over the air provisioning is a standard protocol
  for downloading
• Can test OTA in WTK 2.1
• Basically, you need to read (and carefully
  follow) the docs for whatever device you are
  working with.

51
Deploying on Device

• Usually you also need some type of developer
  account with a device vendor.
• iDEN for Motorola
• If you deploy on a device you also need to make
  sure that you have the correct kind of developer
  carrier account
• Nextel has a developer rate plan that has data
  access
• Able to provision to a limited of devices (like
  5) before your developer account is disabled.

52
MIDlet Development
53
MIDP

• Mobile Information Device Profile
• Targeted at medium- to low-end cell phones and
  two-way pagers
• Spec addresses issues such as
• Application life cycle
• User interface
• Persistence storage
• Networking
• If you really have trouble sleepingyou can read
  through the MIDP 2.0 spec _at_ http//jcp.org/jsr/det
  ail/118.jsp

54
MIDlets

• MIDP application on a device that is managed by
  the AMS
• MIDlet suite is a JAR file that contains 1 or
  more MIDlets
• MIDlet-ltngt contains info about that MIDlet
• MIDlet-1 MyMIDlet, MyMIDlet.png , MyMIDlet
• MIDlet-2 FirstConnection, , FirstConnection
• ltngt MIDlets get packaged in the same JAR file
• AMS gives choice for loading each MIDlet

55
MIDlet Lifecycle

• MIDlet lifecycle defines the interaction with the
  environment
• Well-defined state machine that is managed by the
  AMS
• States include
• Paused
• Active
• Destroyed
• Lets take a look at how the states interact

56
MIDlet Lifecycle
constructor
new()
Paused
startApp()
DestroyApp()
resumeRequest()
pauseApp()
Active
Destroyed
DestroyApp()
57
Lifecycle Methods

• startApp() Can be called multiple times, need
  to prevent subsequent calls to startApp() from
  starting the UI at the beginning a wizard
• pauseApp() usually used to release any
  resources that were holding on too.
• destroyApp() any cleanup, prevents the user
  from exiting the app if a submission of data is
  in progress.
• Screen interactions are handled by the
  commandAction() which well talk about shortly...

58
startApp()

• Starts the applications, called from the AMS
• Maybe called multiple times, so needs to account
  for both initial and normal running semantics
• Should try and return quickly because the
  applications Displayable is not shown until after
  this method exits.
• Throws MIDletStateChangeException if app cant
  start now, but might be able to start at a later
  time.

59
startApp()

• Prevents subsequent calls to startApp() from
  starting the UI at the beginning of the wizard
• protected void startApp() throws
  javax.microedition.midlet.
• MIDletStateChangeException
• if (false this.m_bInitialized)
• m_bInitialized true
• startUI()

60
Whats Available?
MIDP 2.0
javax.microedition.lcdui
javax.microedition.lcdui.game
javax.microedition.media
javax.microedition.media.control
javax.microedition.MIDlet
javax.microedition.pki
javax.microedition.rms
means new for this revision
Layout Wireless JavaDeveloping With J2ME,
Knudsen Apress 2003
61
What Were Using

• Application Lifecycle package
• javax.microedition.midlet
• User Interface package
• javax.microedition.lcdui
• Networking package
• javax.microedition.io
• Core packages
• java.lang, java.io, java.util

62
MIDP/CLDC

• No dynamic loading of user defined classes
• No object finalization
• Java refresher finalization is when an object
  can clean up after itself before being reclaimed
  by the GC
• No reflection
• Means no RMIno RMI means no JINI
• No native methods
• Cant access platform specific features
• Usually access is provided by vendor specific
  APIs anyway

63
javax.microedition.midlet

• All applications must extend
• public abstract class MIDlet extends Object
• AMS uses this interface for state changes
• destroyApp(boolean unconditional)
• getAppProperty(String key)
• notifyDestroyed()
• notifyPaused()
• pauseApp()
• resumeRequest()
• startApp()
• checkPermission(String permission)
• platformRequest(String URL)

MIDlet to AMS method
64
javax.microedition.lcdui

• High-level APIs for high portability (Screen)
• Apps run and are useable on all devices
• No direct access to device features
• Color, device inputs, screen size
• Implementation provides interaction (scrolling,
  navigation, drawing)
• Low-level APIs (Canvas)
• Mostly for games
• Also new GameCanvas in lcdui.games package
• Key events
• Drawing primitives
• Compromises portability

65
javax.microedition.io

• Flexible API for network connections using the
  generic connection framework
• Based around the Connection interface
• MIDP 2.0 requires HTTP and HTTPS support
• Optional connections include Socket, Server
  Socket, TLS or SSL socket, Serial port
• Formalized the connection strings
• MIDP 2.0 security architecture protects users
  from unauthorized network use

66
Networking

• Connector.open(ltprotocolgt,ltpathgtltparamsgt)
• Stream
• Connector.open(socket//192.168.0.190)
• Content
• Connector.open(file test.bat)
• HTTP
• Connector.open(http//www.switchbacksoftware.com
  )
• Well be going into more details in the next
  module..

67
RMS Record Management System

• Provides MIDlet persistent storage
• Simple record-oriented database
• APIs found in javax.microedition.rms
• Supports enumeration, sorting, filtering of
  records
• Shared within a MIDlet suite
• Well talk more about this in the advanced topics
  module

68
Optional Packages

• PDA adds more PDA specific APIs like Personal
  Information Managers (PIM)
• MM API mobile media supports audio/video
  controls, streaming media
• WMA API wireless messaging, SMS and MMS
  (multimedia messaging systems)
• Location API tracking of wireless devices
• J2ME Web Services API web services related XML
  processing
• Bluetooth API Bluetooth communications protocol
• Security and Trust API interaction with
  security smart card
• And a couple of others

69
i730 Optional Packages

• The i730 SDK has some interesting optional APIs
  (although we arent going to go into all of them
  in this course)
• Interconnect/Phone call Initiation
• Call receiving
• Recent calls
• Phonebook
• Datebook
• Micro 3D
• Lighting
• Vibrator
• Customer Care

70
Building a UI
71

• Somewhatbut its not as bad as it seems. Lets
  see how/why.

72
Lets Talk UI

• This is a particularly difficult area of mobile
  development.
• Different devices, different screen sizes,
  grayscale, color, color depth, input
  capabilities.
• Abstraction define UI in abstract terms, rely
  on MIDP implementation to create concrete
  component
• Discovery finds out about device at runtime and
  tailors UI. Mostly used for gaming apps.
• Were using the Abstraction approach

73
UI Basics

• User-interface classes in javax.microedition.lcdui
  (and lcdui.games)
• Devices display is represented by an instance of
  Display.
• Accessed from factory method getDisplay()
• Display keeps track of what is currently visible,
  which is an instance of Displayable

Displayable
Display
74
UI Basics

• Current state of the screen is changed by passing
  Displayable instances to Displays setCurrent()
  method.
• What usually happens is
• Show a Displayable
• Wait for some type of input
• Determine what Displayable should be shown next
• Rinse and Repeat

75
Interaction of UI with Lifecycle

• startApp()
• setCurrent() called for first screen, if not
  called yet
• AMS makes Displayable visible upon return from
  startApp()
• Possibly called several times
• Dont do initialization within startApp()!

76
Interaction of UI with Lifecycle

• pauseApp()
• App can resume with another screen when
  reactivated
• Done by using setCurrent() with the new screen
• destroyApp()
• UI components are freed along with other resources

77
Class Hierarchy
78
Screen Design

• Screen is central abstraction for MIDPs UI
• Can have many screens in an app, but only one
  screen visible at a time
• Implementation handles events
• Encapsulates
• Device specific graphic rendering
• User input

Strings of all types must be very very short.
Screen size is so tiny. Esoteric acronyms are OK
because this is a well defined audience.
79
Couple Things to Note

• These examples are _very_ UI oriented, meaning we
  use vastly more global variables than usual.
• Also, there is a coupled management of the Wizard
  between different parts of the MIDlet.
• Control/management tends to spread out across
  methods. Examples include
• submitTask()s removal of commands from the
  Summary Form
• In the commandAction() methods of the
  CommandListeners (e.g. UI movement between
  Displayables),
• And even in some of the lifecycle methods
  (destoryApp() throwing an exception when
  submitTask thread is incomplete to force the user
  to be notified by an alert and to wait.)

80
Demo
81
MyMIDlet

• import javax.microedition.midlet.
• import javax.microedition.lcdui.
• // A first MIDlet with simple text and a few
  commands.
• public class MyMIDlet extends MIDlet
• implements CommandListener
• //Commands
• private Command exitCommand
• //The display for this MIDlet
• private Display display
• public MyMIDlet()
• display Display.getDisplay(this)
• exitCommand new Command("Exit",
  Command.SCREEN, 1)

82
MyMIDlet (cont)

• // Start the MIDlet by creating the TextBox and
• // associating the exit command and listener.
• public void startApp()
• TextBox t new TextBox(MyMIDlet",
• "Welcome to the J2ME
  Bootcamp!", 256, 0)
• t.addCommand(exitCommand)
• t.setCommandListener(this)
• display.setCurrent(t)
• // Pause is a no-op because there are no
  background
• // activities or record stores to be closed.
• public void pauseApp()
• // Destroy must cleanup everything not handled
• // by the garbage collector.
• // In this case there is nothing to cleanup.
• public void destroyApp(boolean unconditional)
  

83
MyMIDlet (cont)

• // Respond to commands. Here we are only
  implementing
• // the exit command. In the exit command,
  cleanup and
• // notify that the MIDlet has been destroyed.
• public void commandAction(Command c,
  Displayable s)
• if (c exitCommand)
• destroyApp(false)
• notifyDestroyed()

84
Event Management
85
User Input

• User events defined by Command and handled by
  CommandListeners
• Can have many screens in an app, but only one
  screen visible at a time
• Implementation handles events
• Encapsulates
• Device specific graphic rendering
• User input

Strings of all types must be very very short.
Screen size is so tiny. Esoteric acronyms are OK
because this is a well defined audience.
86
Commands

• Object used for event handling
• CommandListener does actual work
• Follows basic form of JavaBean event model One
  event each time a Command is invoked
• Follow unicast listener pattern vs. multicast
  pattern
• Displayable can only have one listener object
• Add commands to screens by using addCommand()

87
Create a Command

• m_CommandSubmit new Command("Submit",
  Command.SCREEN, 0)
• String label text used to by UI
• int type hint to convey meaning of Command in
  terms of commonly required application operations
• int priority hint used by MIDP implementation
  to determine the relative importance of the
  command
• Determines screen location
• Visible as soft key or relegated to menu
• Dont bet on how the device will do the display
  but more importantly, dont care!

88
UI Methods

• buildUI() is where the actions is
  (remembercalled from constructor)
• commandAction() is used for handling
• Commands by command instance
• Displayable by displayable instance
• Use of Alerts
• Other method interaction such as handleExit() and
  destroyApp() for protecting against shutting down
  before submission to server is completed

89
Event Management

• Two CommandListener event management approaches
  we recommend
• Create an inner local CommandListener class for
  Displayable
• Put all command processing within the MIDlets
  commandAction(). Have MIDlet implement
  CommandListener and assign the MIDlet as the
  CommandListener for the Displayable
• Weve included both within the examples for
  learning purposes. Task list uses approach 1
  with utility methods shared by all
  CommandListeners

90
Event Management

• While in the long run its probably a better,
  more object oriented approach, to create a
  CommandListener for each Displayable.
• However, if there are common commands shared by
  many Displayables, then there tends to be
  duplicated code among the dedicated
  CommandListeners. In this case, utility methods
  in the MIDlet (e.g. handleExit() ) can be created
  and used by the different CommandListeners.

91
Event Handling Code

• public class MyMIDlet extends MIDlet implements
  CommandListener
• private Command exitCommand
• ...
• public MyMIDlet() ...
• exitCommand new Command("Exit",
  Command.SCREEN, 1)
• public void commandAction(Command c, Displayable
  s)
• if (c exitCommand)
• destroyApp(false)
• notifyDestroyed()

Strings of all types must be very very short.
Screen size is so tiny. Esoteric acronyms are OK
because this is a well defined audience.
92
Networking
93
A Bit About Networking

• We are dealing with a simple HTTP (or HTTPS in
  MIDP 2.0) connection to defined IP address that
  has a Servlet running.
• CLDC defines a flexible API called the Generic
  Connection Framework
• javax.microedition.io package
• Based on the Connection interface
• Our networking concerns are handled under the
  covers for us by the kXML-RPC implementation, but
  its important to understand how the mechanism
  works

94
Generic Connection Framework

• Objective of GCF is to isolate the differences
  between the use of one protocol and another into
  a string characterizing the type of connection.
• App code stays the same regardless of what type
  of connection is being used.
• CLDC doesnt provide the implementation, but
  rather the framework that can be used by the
  profile (MIDP)

95
Connection Interface Hierarchy
Connection
StreamConnectionNotifier
DatagramConnection
InputConnection
OutputConnection
StreamConnection
ContentConnection
HttpConnection
96
javax.microedition.io

• MIDP 2.0 requires HTTP and HTTPS support
• Optional connections include Socket, Server
  Socket, TLS or SSL socket, Serial port
• Formalized the connection strings
• Connector.open(ltprotocolgt,ltpathgtltparamsgt)
• Ex. Connector.open(socket//192.168.0.190)
• Connector.open(filetest.bat)
• Connector.open(http//www.denverjug.org)
• MIDP 2.0 security architecture protects users
  from unauthorized network use
• Quick Demo

97
HttpConnection

• MIDP implements a subset of HTTP 1.1 (GET, POST,
  HEAD)
• Methods are related to dealing with http
• Getting header fields dates
• Getting request and response information
• HttpConnection con null
• String url "http//" hostname "" port
• con ( HttpConnection ) Connector.open( url,
  Connector.READ_WRITE )
• con.setRequestMethod( HttpConnection.POST )
• con.setRequestProperty( "Content-Length",
  Integer.toString( messageLength ) )
• con.setRequestProperty( "Content-Type",
  "text/xml" )

98
Working with Threads
99
Use of Threads

• CLDC provides threads, but not the creation of a
  daemon thread or ThreadGroup
• Can create your own Collection at app level and
  manage Threads yourself if you really wanted too
• Synchronized keyword
• java.lang.Object wait(), notify(), notifyAll()
  available to Thread class
• No dumpStack() method, need to throw an exception
• CLDC 1.1 allows for naming of a Thread and
  supports the interrupt() method
• Supports Thread priorities
• Always use for I/O, GPS

100
Record Management Store
101

• By using the RMSlets see how.

102
Persistent Storage Basics

• Simple record-oriented database (RMS) stored in
  Flash mem
• Device-independent API
• Records are arrays of bytes that live in record
  stores
• Record stores are shared within MIDlet suite
• MIDP 2.0 allows for optional sharing of record
  stores between MIDlet suites
• Support for enumeration, sorting, and filtering
• Atomic update for single records

103
RMS Classes and Interfaces

• Defined in javax.microedition.rms package
• RecordStore
• Collection of records
• RecordEnumerator
• RecordStore enumerator
• Interfaces
• RecordComparator
• RecordFilter
• RecordListener

104
Using Records
OldRecordStore
J2MERecordStore

• Nothing fancy here
• Array of bytes
• Integer values used a unique ID
• Records can be written using java.io APIs in
  CLDC support
• DataInputStream DataOutputStream
• ByteArrayInputStream ByteArrayOutputStream

105
RecordStore Operations

• Standard operations you would expect
• openRecordStore(name,create)
• removeRecordStore(name)
• Get list of all known record stores in a MIDlet
  suite
• listRecordStores()
• Get the size of the RS
• int getSize() - of bytes used by the RS
• Int getSizeAvailable() get amount of space
  available for both record data and overhead

106
Creating a RecordStore

• Centered around record stores
• Small database that contains data called records
• javax.microedition.rms.RecordStore
• Record stores are identified by name
• public static final String RS_NAME "Tasks"
• try
• m_RS RecordStore.openRecordStore(RS_NAME,
  bCreateIfNecessary)
• catch (RecordStoreException ex)
• this.m_bRecordStoreError true
• this.m_sRecordStoreError ex.toString()

107
Closing/Deleting RecordStore

• Need to make sure that you release the resource
• protected void destroyApp(boolean parm1) throws
  javax.microedition.midlet.
• MIDletStateChangeException
• try
• m_RS.closeRecordStore()
• RecordStore.deleteRecordStore(RS_NAME)
• catch (RecordStoreException ex)
• ex.printStackTrace()
• System.out.println(ex.getMessage())

108
RMSMidlet

• Sample MIDlet so that you can become familiar
  with RMS and take a little tour.
• com.sb.samples.midlet.rms package
• Our objective is to introduce RMS basics
  including
• RecordStore creation/closing
• Record adding
• Record lookup filtering via RecordFilter
• RecordStore deletion (no deletions take place
  though very easy to add)
• Encapsulating RecordStore I/O operations in
  static Utility Class methods for consistency and
  program simplification

109
RMSMidlet Description

• Very simple
• Creates 5 TaskRow objects.
• Only object 3 has been designated as 'already
  uploaded to server'.
• Shows a single form with only those TaskRows that
  have not been uploaded to the server (there are 4
  of them in this case).
• On the form is the Record ID of the Task
• User can press 'View' button to see Task
  information

110
TaskRow Class

• com.sb.samples.midlet.rms.TaskRow class that acts
  as
• Container object for Task values
• Decouples Task data from RecordStore
  representation
• Static utility tool for consistent, maintainable
  TaskRow-to-RecordStore I/O

111
Adding Records

• TaskRow offers a number of ways to add, read, and
  update a record
• public static int addRecord(RecordStore rs,
  TaskRow taskRow) throws Exception
• byte bData TaskRow.toByteArray(taskRow)
  
• int iRecordID rs.addRecord(bData, 0,
  bData.length)
• return iRecordID
• public static void updateRecord(RecordStore rs,
  TaskRow taskRow) throws Exception
• byte bData TaskRow.toByteArray(taskRow)
  
• rs.setRecord(taskRow.iID, bData, 0,
  bData.length)

112
Read Record

• public static TaskRow readRecord(RecordStore rs,
  int iRecordID) throws Exception
• byte bData rs.getRecord(iRecordID)
• TaskRow tr readRecord(bData)
• tr.iID iRecordID
• return tr
• // Maintain a single, consistent
  InputStream-based read mechanism
• // for use by readRecord and any other usage
• public static TaskRow readRecord(DataInputStream
  dis) throws Exception
• TaskRow tr new TaskRow()
• // the order of these reads must match
• // the reads in TaskRow.toByteArray() with
  respect to
• // 1) the ordering of the values
• // 2) the data type of each value
• tr.iRadioID dis.readInt()
• tr.bUploaded dis.readBoolean()

113
Read Record Byte Array

• // Offer a Byte Array-based reader for parts of
  the program that
• // do not have a reference to RecordStore
• // (e.g. by RecordFilter or RecordComparator
  that receive only byte arrays)
• public static TaskRow readRecord(byte bData)
  throws Exception
• ByteArrayInputStream bais new
  ByteArrayInputStream(bData)
• DataInputStream dis new DataInputStream(bais
  )
• try
• return readRecord(dis)
• finally
• if (null ! dis)
• try
• dis.close()
• catch (Exception e)

114
Lookup Filtering

• The RMSMidlet keeps track of records that have
  not been uploaded to a server.
• And then we use a Filter to determine which
  records need to be uploaded.

115
Filter for Records

• protected TaskRow getUnuploadedTaskRows()
  throws Exception
• // Filter for tasks not yet uploaded to
  server
• RecordFilter rf new RecordFilterTaskNotUpl
  oaded()
• // If we cared about ordering (e.g. Data
  created), we'd
• // create a RecordComparator for that
  purpose. For now, don't sort.
• RecordComparator nullRecordComparator
  null
• boolean bKeepUpdated false
• RecordEnumeration re m_RS.enumerateRecords
  (rf,nullRecordComparator, bKeepUpdated)
• TaskRow aTaskRows new TaskRowre.numRecord
  s()
• int i 0
• while (re.hasNextElement())
• int iNextRecord 0
• try
• iNextRecord re.nextRecordId()
• TaskRow tr TaskRow.readRecord(m_RS,
  iNextRecord)
• aTaskRowsi tr
• i
• catch (Exception ex)

116
RecordFilterTaskNotUploaded Class

• public class RecordFilterTaskNotUploaded
• implements RecordFilter
• // only allow TaskRows that have not been
  uploaded to
• // be accepted
• public boolean matches(byte bCandidate)
• try
• TaskRow tr TaskRow.readRecord(bCandidate)
  
• if (tr.bUploaded false)
• return true
• else
• return false
• catch (Exception e)
• return false

117
RMS Tour

• That concludes our RMS tour.
• Unlike most tours, our RMS tour doesnt end at a
  gift shop

118
Enterprise J2ME(The whirlwind tour)
119
J2ME and J2EE

• MIDP Apps become a client with Middle-tier
  access
• XML data provided by a Servlet at well-known URL
  or through Web Services
• Received as streaming data using networking APIs
• Converted to String for parsing (i.e. kXML)
• Display using MIDP UI elements

120
Wireless Enterprise
Business Tier
Web Tier
Mobile Services
Tomcat
BackendSystems

• DMZ

XMLRPCServlet
HTTP
121
kXML-RPC Usage
122
MIDP XML

• MIDP networking allows access to data formats
  like WML, XML
• Were just interested in XML
• Upside
• Easy to work with
• Most are familiar with XML
• Downside
• Expensive
• Heavy String manipulation
• Footprint for the parser
• For some devices, not as big a deal because
  available resources are greater

123
MIDP XML Parsers

• A few parsers are available for MIDP
• kXML
• http//www.kxml.org
• Pull parser
• SAX and DOM support
• Written for J2ME/CLDC/MIDP
• NanoXml
• http//nanoxml.sourceforge.net/kvm.html
• DOM
• Ported
• Both support XSLT

124
kXML-RPC

• kXML-RPC is a J2ME implementation of the XML-RPC
  protocol built on top of the kXML parser.
• Extremely lightweight mechanism for exchanging
  data and invoking web services in a neutral,
  standardized XML format.
• Hides the implementation of kXML

125
Dealing with Payloads

• Not really all that much to do here when using
  kXML-RPC, the payload is handled for you on the
  client, and the server uses a TaskHandler to get
  the parameters
• Lets look at making a call, and then a sample of
  what a payload might look like if you wanted to
  sniff the wire

126
Making an XML-RPC Call

• Using XML-RPC is as simple as doing the
  following
• String connect http//www.switchbacksoftware.co
  m/service.do
• String ticker "Submitting to Server"
• updateUI()
• XmlRpcClient xmlrpc new XmlRpcClient(connect
  )
• try
• String result (String)
  xmlrpc.execute(SB.submitTaskInfo, paramsArray)

127
Payload Example

• ltmethodCallgt
• ltmethodNamegtSB.submitTaskInfolt/methodNamegt
• ltparamsgt
• ltparamgt
• ltvaluegt
• ltstringgtTask1lt/stringgt
• lt/valuegt
• lt/paramgt
• ltparamgt
• ltvaluegt
• ltstringgtW 12.32560lt/stringgt
• lt/valuegt
• lt/paramgt
• ltparamgt
• ltvaluegt
• ltstringgtN 72.09090lt/stringgt
• lt/valuegt
• lt/paramgt
• lt/paramsgt

128

• J2ME Web Services API (WSA) JSR-172 (CLDC 1.0
  1.1) - API's standardize remote service
  invocation and XML parsing - subsets of based on
  JAX-RPC 1.1 and SAX2
• WTK 2.1, includes the libraries you need to
  develop MIDlets that take advantage of J2ME WS
  and also includes a JAX-RPC stub generator
• Good article ?http//developers.sun.com/techtopics
  /mobility/apis/articles/wsa/

129
Couple more advanced topics Timers System
Properties
130
Timer and TimerTask

• Introduced in J2SE 1.3 to schedule tasks for
  execution by a background thread
• MIDP includes the Timer and TimerTask classes
• Only J2SE classes that are not included in the
  CLDC but are included in MIDP
• Timer API identical to J2SE version except
  (theres always an exception) the constructor
  that specifies whether the thread is a daemon is
  missing.
• Rememberdaemon threads arent supported in MIDP
• TimerTask exactly the same in J2SE MIDP

131
Timer MIDlet

• Found in com.sb.samples.midlet.timer package
• Objectives
• Introduce Timer and TimerTask
• Extend RMS basics to include an Updating Task
  Records

132
TimerMIDLet Description

• Creates a TimerTask that does the following each
  time it is invoked
• Scans RecordStore for TaskRows that have 'not
  yet been uploaded
• Picks the first Task in the list and uploads it
  via submitTask()
• Updates it's status value and flags it as
  'uploaded
• Updates the respective record in the RecordStore
• Makes a sound upon upload
• Rebuilds the UI to reflect a dwindling list of
  'not uploaded' Tasks

133
Developer Note

• Were not going to walk through the building of
  the UI, since weve already seen how Commands are
  added and handled in other examples

134
TimerMidlet

• public class TimerMidlet extends RMSMidlet
• Command m_CommandRefresh null
• Timer m_TimerUpload null
• TimerTask m_TimerTaskUploadATaskRow null
• public TimerMidlet()
• super()
• // need to create a TimerTask that gets the
  list of not uploaded TaskRows and
• // uploads them (or just the first) and
• // updates the record to bUploade true
• //
• m_TimerTaskUploadATaskRow new TimerTask()

135
TimerMidlet

• public void run()
• try
• // Get the list of un-uploaded Tasks
• TaskRow aTaskRows
  getUnuploadedTaskRows()
• if (aTaskRows.length gt 0)
• TaskRow tr m_aTaskRows0
• // Submit them to server
• submitTask(tr)
• try
• // and update the RMS record
• TaskRow.updateRecord(m_RS, tr)

136
TimerMidlet

• catch (Exception ex)
• Alert a new Alert("Task", "Error
  updating task " tr.sTask ""
  ex.getMessage(), null, AlertType.ERROR)
• a.setTimeout(Alert.FOREVER)
• AlertType.ERROR.playSound(m_Display)
  
• m_Display.setCurrent(a,
  m_Display.getCurrent())
• try
• buildUI()
• catch (Exception e)
• m_Display.setCurrent(m_FormTasks)
• catch (Exception e)

137
Start the Timer

• m_TimerUpload new Timer() m_TimerUpload.sched
  ule(this.m_TimerTaskUploadATaskRow, 5000, 10000)

138
Submitting The Task

• protected void submitTask(TaskRow tr)
• Vector vParams new Vector()
• vParams.addElement(tr.sTask)
• vParams.addElement(tr.sLongitude)
• vParams.addElement(tr.sLatitude)
• vParams.addElement(new Integer(tr.iRadioID))
  // radio Id
• String sResult null
• // normally would use a constants file or
  properties singleton
• // or MIDlet attributes
• String sConnect HomeBase1.HOME_BASE_SERVER
  HomeBase1.HOME_BASE_URL_FILE
• XmlRpcClient xmlrpc new XmlRpcClient(sConnec
  t)
• try
• sResult (String) xmlrpc.execute(HomeBase1.
  HOME_BASE_SUBMIT_RPC, vParams)
• // When not using real phone, sleep so tos
• // simulate delay for testing
  destroyApp(false)
• // Thread.sleep(10000)
• AlertType.INFO.playSound(m_Display)

139
System Properties
140
Use of System Properties

• CLDC does not include the java.util.Properties
  class
• Limited set of properties available using
  System.getProperty( String key)
• microedition.platform - Name of the host platform
  or device (implementation-dependent)
• microedition.encoding - Default character
  encoding Default valueISO-8859-1
• microedition.configuration - Name and version of
  the supported configuration CLDC-1.1
• microedition.profiles - Names of the supported
  profiles (implementation-dependent)

141
Bootcamp Wrap-up

• J2ME is an exciting development opportunity
• Fairly easy to transition to if you are at
  Java-eese.
• Need to make some adjustments in your programming
  habits (Come to the J2ME Best Practices session
  to find out more!)
• J2ME/J2EE integration will be powerful for a new
  breed of applications
• If your company is interested in the full 2-day
  intensive J2ME developer bootcamp or requires
  contracting services for mobile projects, contact
  me directly at sspielman_at_switchbacksoftware.com
• Thanks!