Programming Mobile and Wireless Devices using J2ME
Download
Report
Transcript Programming Mobile and Wireless Devices using J2ME
Programming Mobile
and Wireless Devices
using J2ME
Ola Bø
Molde University College INF 245 Fall 2007
OBø
1
Motivation
added nov 2005
Molde University College INF 245 Fall 2007
OBø
2
Content
Overview over the J2ME-plattform
Close up of technologies for Mobile and
Wireless applications
CLDC Connected Limited Device Configuration
MIDP Mobile Information Device Profile
Molde University College INF 245 Fall 2007
OBø
3
J2ME in the Java landscape
Set top boxes
Smartphones
(Source
Sun
Microsyste
ms Inc.)
Molde University College INF 245 Fall 2007
OBø
4
Problem and solution
The problem is device heterogeneity
Memory, Screen, Filesystem, Available storage for libraries,
Camera, GPS, ... differs widely
That means the Java Platform can not be the same on all
devices
Solution:
Different configurations and profiles in different devices
Extensions called JSRs
Nightmare
Programming an application aimed at a wide selection of
heterogeneous devices is arduous even with J2ME.
Making the same application ”native” is probably far worse.
Even if a device has a certain functionality (GPS, Camera, MP3
player...), the functionality can only be controlled from a J2ME
program through a working JSR library in device firmware.
No library – no control
Molde University College INF 245 Fall 2007
OBø
5
add
material from mikkonen
J2ME Configurations
A configuration sets a standard for the
available Java technology on a class of
devices
CLDC Connected Limited Device Configuration
Limited devices (160-512k RAM total for Java)
Mobile phones and PDA’s
CDC Connected Device Configuration
Set top boxes
High end wireless devices
Molde University College INF 245 Fall 2007
OBø
6
add
material from mikkonen
J2ME Profiles
MIDP Mobile Information Device Profile
Foundation Profile (non gui networked device)
Personal basis, Personal and RMI Profiles
Molde University College INF 245 Fall 2007
OBø
7
JCP Java Community process
JSR Java Specification Requests
JCP organises further
standardisation of Java
When new requirements
emerges a new JSR is
created
Requirement work is driven
by people from various
industrial companies
JSR makes the extension of
Java flexible
Implementation of new
JSRs in mobile devices
gives steadily increased
in the potential
functionality of Java
devices
The specifications are
available at jcp.org
Molde University College INF 245 Fall 2007
OBø
8
Four Generations Nokia
2002
2003
2004
Molde University College INF 245 Fall 2007
OBø
2005
9
Top end devices
2007
Sony Ericsson P1
Nokia E90 Communicator
Molde University College INF 245 Fall 2007
OBø
10
J2ME for mobile and wireless
devices
Special libraries for mobile and
wireless devices: GUI, storage
A subset of the Java libraries
adapted to a lowest common
denominator for mobile devices
The virtual machine –
corresponding to JVM in
standard Java
Molde University College INF 245 Fall 2007
OBø
11
What does CLDC contain
Core java language and library
Libraries for i/o and communication
Security
Internationalization
The content is partly inherited from J2SE
java.lang.*, java.util.*, java.io.*
and partly new
java.microedition.*
And what does CLDC not contain:
UI, application life cycle, Persistence, and special
interfaces for the device.
Molde University College INF 245 Fall 2007
OBø
12
CLDC is limited
That means some Java language features
are missing
CLDC 1.0
No Floating point
No Finalization, No Thread Groups, No JNI
Limited Error Handling
CLDC 1.1
Floating point INCLUDED
Molde University College INF 245 Fall 2007
OBø
13
CLDC based classes need
special handlig
Preverification and
Package steps are
mandatory for classes
to be run over CLDC.
Supports faster start
up of CLDC based
apps.
Preverification and
packaging may be
done using
Myapp.jar
Packaging
Command line tools
KToolbar in the WTK
An IDE
Molde University College INF 245 Fall 2007
OBø
14
CLDC System Properties
Can ask for property to ascertain what profile we
have on the device
Can adapt the application to the capabilities of the
CLDC and MIDP present in the device
java.lang.System.getProperty("microedition.profiles"), will
return "MIDP-1.0" if this is the profile implemented in the
phone.
Other possible properties are for example:
microedition.platform
microedition.encoding
microedition.configuration
Molde University College INF 245 Fall 2007
OBø
15
MIDP 1.0
MIDP 1.0 covers:
Application Life Cycle
Toolkit for user interface – display and input
Device independent persistent data storage
GCF based networking using HTTP 1.1
New standard MIDP 2.0 released nov. 2002
There will still be an installed base of MIDP 1.0
devices for some time.
New possibilities in MIDP 2.0 may be enticing
Molde University College INF 245 Fall 2007
OBø
16
MIDP applications AKA midlets
JAR
A MIDP application is called a MIDlet
Must extend the MIDlet class
A midlet suite is a bundle of midlets.
File
can access same persistent data
Packaging
Midlet suites are packaged in JAR files
The preverified class files in the suite
Resource files (for example icons,
sounds)
A manifest with application properties
Each JAR file corresponds to a JAD file
describing its contents for deployment
(name, description, version etc.)
Molde University College INF 245 Fall 2007
OBø
17
Provisioning
Provisioning is getting the application into the
device. Several scenarios for download:
"Over The Air (OTA) " using HTTP over wireless
protocols
By device synchronization software from a
desktop computer using serial, usb, IR or
bluetooth
Not standardized in MIDP 1.0,
OTA provisioning standardized in MIDP 2.0
Molde University College INF 245 Fall 2007
OBø
18
Midlet Application Skeleton
All MIDlets have this
common skeleton
Constructor called once
startApp() called at start or
after pause
pauseApp() called at
pause – timer events may
be received
destroyApp() called when
application is terminated
Molde University College INF 245 Fall 2007
OBø
19
Application LifeCycle
Initialised and ready to
run
Paused
PauseApp StartApp
DestroyApp
Active
Resources acquired,
application running
DestroyApp
Destroyed
All resources released,
All threads stopped
Molde University College INF 245 Fall 2007
OBø
20
Application LifeCycle methods
(source javadoc for class javax.microedition.MIDlet, consult documentation for details)
Called by device
Called by midlet
startApp()*
resumeRequest()
Tells MIDlet it has entered the
active state and can start working
Tells device midlet want to
continue
pauseApp()*
notifyPaused()
Tells MIDlet it has been paused
Tells device midlet wants to pause
destroyApp(boolean)*
notifyDestroyed()
Tells MIDlet to release resources
and stop threads
Tells device midlet wants to be
destroyed. All resources and
threads should already have been
released
* abstract methods, to be implemented by programmer when subclassing
Molde University College INF 245 Fall 2007
21
MIDlet.
OBø
MIDP 1.0 High Level User
Interface
Windowing not appropriate on limited devices
Interface using whole Screens – four kinds
1.
2.
3.
4.
Alert - message
TextBox – Editable or non-editable textbox
Form
List
Screens have a title
Commands can be added to screens
How commands appear is device dependent
(Soft key, Menu item, ... )
Commands must be handled by class implementing the
CommandListener Interface
(for further details see javax microedition.lcdui.Command)
Show a screen by using display.setCurrent(myForm)
Molde University College INF 245 Fall 2007
OBø
22
TextBox, a high level screen
Used to show or edit a text on the whole screen
Input constraints specifies content type and other
aspects of the TextBox
ANY
•PASSWORD
•UNEDITABLE (MIDP 2.0)
EMAILADDR
•SENSITIVE (MIDP 2.0)
NUMERIC
•NON_PREDICTIVE(MIDP 2.0)
PHONENUMBER
•INITIAL_CAPS_WORD(MIDP 2.0)
•INITIAL_CAPS_SENTENCE(MIDP 2.0)
URL
DECIMAL
How are these input constraints related to the limited input
capabilities of mobile devices and to the T9 algorithm?
Molde University College INF 245 Fall 2007
OBø
23
Texbox Code
Title
Command
Initial text
Constraint
Maximum
text length
Soft Key
Molde University College INF 245 Fall 2007
OBø
24
MIDP UI – Alert a high level
screen
Used to show a message
A timeout can be set
An image can be added
A gauge can be added showing progress (MIDP
2.0)
Is displayed by a special version of
display.setCurrent(Alert,Screen)
The second parameter is what to display when alert
screen gone. (display.getCurrent can be used here)
Molde University College INF 245 Fall 2007
OBø
25
Alert and CommandListener
Code
Molde University College INF 245 Fall 2007
OBø
26
List
Uses the whole screen for a list
Three use scenarios depending on
Choice.type
1.
2.
3.
IMPLICIT selecting invokes command
EXCLUSIVE selecting one deselects previous
MULTIPLE selecting more than one possible
Molde University College INF 245 Fall 2007
OBø
27
Code for Implicit List
Molde University College INF 245 Fall 2007
OBø
28
Code for Multiple List
Molde University College INF 245 Fall 2007
OBø
29
Code for implicit list
String[] elements = { ... }; //Menu items as List elements
List menuList = new List("Menu", List.IMPLICIT, elements, null);
Command selectCommand = new Command("Open", Command.ITEM, 1);
menuList.setSelectCommand(selectCommand);
menuList.setCommandListener(...);
Molde University College INF 245 Fall 2007
OBø
30
Form
A form displays a number of Items
Items can be:
Commands can be connected to Items
Layout is specified both in form and in items
Texfield for flexible text entry
StringItem for text display
ImageItem for image display
DateField for date display and entry
Choicegroup selectable list of text and/or images
Gauge a bargraph display of a numeric quantity
CustomItem an item you can develop
Spacer, a layout assistance item
Layout directives are hints only.
If form too high for display, it will scroll
What Items where used on the form shown?
ImageItem, StringItem
two
Textfields
Moldeand
University
College
INF 245 Fall 2007
OBø
31
High Level Interface – an Overview
Same Form, different devices,
different results
Molde University College INF 245 Fall 2007
OBø
33
Form Code
Molde University College INF 245 Fall 2007
OBø
34
High level UI – Form
an overview
Molde University College INF 245 Fall 2007
OBø
35
Guidelines for UI Design
HCI on mobile and wireless devices a challenge!
Use simple forms with few Items
Small screen means small changes not easy to spot
Use uniform appearance for easy learning
Always provide commands like OK, BACK and EXIT on screen
Remember: Small screen size, mobile context of use
Can you avoid scrolling?
Minimize input, use RMS to store user settings
Use static form content
Why?
use uniform command configuration on all forms to ease
learning and use
Use soft keys rather than on-screen keys
Use Threads and Gauges to avoid UI-blocking during network IO
improves user experience
Molde University College INF 245 Fall 2007
OBø
36
Top 10 Usability Guidelines
for Enterprise Applications
(Nokia 2004) http://www.forum.nokia.com/main/0,,23_56,00.html#tips
Provide a clear navigation model
Use familiar language
Short network coverage problems should not stop or cause loss of users' work
Connection status should be displayed clearly.
Synchronization should be automatic but under user control.
Provide useful feedback
Terminology familiar to target users should be used instead of technical terminology.
Terminology should be consistent with the Series 60 UI style.
Target users’ native language should be used.
Hide the complexity of connectivity
Core features of the application should be available from the main view.
Navigation model should be focused on the main tasks.
Advanced functionality should be hidden from novice users.
Let the user know if an action was succesful or not.
If processing takes more than 0.5 seconds, indicate that something is happening.
Be consistent with controls
Minimize errors and the need for learning by using softkeys as in the Series 60 UI style
Build shortcuts for advanced users, use shortcuts similar to other applications.
Molde University College INF 245 Fall 2007
OBø
37
More guidelines
Provide a simple Options menu
Use tabs wisely
Instead of text entry, prefer alternative forms of information entry, such as selecting
from a list or capturing images.
Offer reasonable default values.
Information presentation
The most essential functionality should be provided in the first tab. Underlying tabs can
be used to hide advanced functionality.
If more than five tabs are needed, use a list for accessing the tabs (see the Settings
application).
Text is preferable to icons in tab titles.
Make entering information easy
Navigation key default action(s) should also be available in an Options menu.
Sort items in the Options menu according to Series 60 UI Style Guide.
Main actions should be available without scrolling.
Display the most relevant information first.
Essential information should not be displayed with icons only.
Use colors and symbols for highlighting and grouping items.
Provide Help
Context-sensitive help should be provided in the application.
More detailed help should be provided on a Web site or in the user guide.
Molde University College INF 245 Fall 2007
OBø
38
Low Level UI – Canvas
Li and Knudsen Chapter 4
Canvas is a displayable that is completely controlled
by program
An application can combine canvases and screens
A list to choose racing track
A canvas to do the racing
Methods to handle game actions and pointer events
A Canvas must be subclassed!
paint method for painting must be implemented
The paint method provides a Graphics object having
methods for painting
Molde University College INF 245 Fall 2007
OBø
39
Canvas methods
Event delivery methods used to send events to application. Event delivery methods are called
serially
showNotify() // called before canvas becomes visible
hideNotify() // called after canvas has been hidden
keyPressed(), keyRepeated(), keyReleased()
pointerPressed(), pointerDragged(), pointerReleased()
(hasPointerEvents() checks if device supports a poiner)
paint() // tells app to paint screen again. (Not to be called by app)
sizeChanged()
Methods used by application to learn the meaning of the key pressed
getKeyCode() (returns KEY_NUM0..KEY_NUM9, KEY_STAR,...)
getGameAction() (returns UP, DOWN,.., FIRE, GAME_A, ..,GAME_D)
getKeyName() (returns a text describing the key)
Methods used by application
repaint() requests repaint of whole or partial screen
serviceRepaints() forces pending repaint requests
callSerially()
setFullScreenMode(boolean)
Molde University College INF 245 Fall 2007
OBø
40
Graphics Methods
DrawLine
DrawRect
DrawRoundRect
FillRect
drawString
drawArc
FillArc
drawChar
drawChars
drawImage
drawRegion
setFont
setColor
setStrokeStyle
setClip //sets region that will be changed by drawing
translate //sets origin for drawing
Molde University College INF 245 Fall 2007
OBø
41
Low Level UI, an overview
Molde University College INF 245 Fall 2007
OBø
42
MIDP 1.0 Communication
Device must implement
a HTTP 1.1 client
interface
Transport is not
necessarily over TCP/IP
Source: Bill Day J2ME
Molde University College INF 245 Fall 2007
OBø
43
Networking using GCF
Need a more compact solution, than the standard
libraries
GCF: General Connection Framework is the answer
In GCF all protocols can be specified using an URLapproach:
Connector.open("<protocol>://<address>:<parameters>")
But no network protocol is mandatory in CLDC
What protocol can actually be used depend on the device
and the profile
Examples
Connector.open("http://www.sis.pitt.edu/mwap/test.html")
Connector.open("file://pictures/picture12.jpg")
Connector.open("comm://9600:18N")
Molde University College INF 245 Fall 2007
OBø
44
SMS-messaging from Java ch11
WMA Wireless Messaging Api – JSR 120
Supports
sending ordinary SMS
App to App communication using SMS over a port
Simple API
Connector
MessageConnection
Message
BinaryMessage
TextMessage
MessageListener
Molde University College INF 245 Fall 2007
OBø
45
WMA-an overview
Molde University College INF 245 Fall 2007
OBø
46
Persistent storage
Li and Knudsen chapter 8
Problem and solution
Device storage mechanisms far from standardized
MIDP provides a standardized interface to device storage
called Record Management System – RMS
The Device platform – that is the MIDP implementation for
the device is responsible for best effort storing to what
media is available.
Atomic, synchronous, serialized record updates
guaranteed by implementation (no manual locking)
RMS store data as byte arrays in a named
RecordStore. Each byte array is accessible via an
integer record number. (A very crude solution indeed
– but standardized )
Molde University College INF 245 Fall 2007
OBø
47
Persistent storage methods
(Source Javadoc for class javax.microedition.rms – consult documetation for details)
static RecordStore openRecordStore(String recordStoreName,
boolean createIfNecessary)
Open (and possibly create) a record store associated with the given MIDlet
suite.
closeRecordStore()
This method is called when the MIDlet requests to have the record store
closed.
static void deleteRecordStore(String recordStoreName)
int addRecord(byte[] data, int offset, int numBytes)
void setRecord(int recordId, byte[] newData, int offset,
int numBytes)
byte[] getRecord(int recordId)
RecordEnumeration enumerateRecords(RecordFilter filter,
RecordComparator comparator, boolean keepUpdated)
Returns an enumeration for traversing a set of records in the record store in an
optionally specified order.
Molde University College INF 245 Fall 2007
OBø
48
Transfer from/to record store
A record may be assembled with a DataOutputStream
ByteArrayOutputStream baos=new ByteArrayOutputStream(barr);
DataOutputStream dout=new DataOutputStream(baos);
dout.writeUTF(url);
dout.writeInt(qid);
dout.writeLong(timestamp);
dout.flush();
answerStore.addRecord(baos.toByteArray(),0,baos.size());
dout.close();
baos.close();
A Record may be disassebled with a DataInputStream
RecordStore answerStore=RecordStore.openRecordStore(”answer”,true);
ByteArrayInputStream bais=new
ByteArrayInputStream(answerStore.getRecord(recordid)):
DataInputStream din=new DataInputStream(bais);
String url=din.readUTF();
int qid=din.readInt();
long timeStamp=din.readLong();
Molde University College INF 245 Fall 2007
OBø
49