Programming Mobile and Wireless Devices using J2ME - PowerPoint PPT Presentation

1 / 49
About This Presentation
Title:

Programming Mobile and Wireless Devices using J2ME

Description:

Programming Mobile and Wireless Devices using J2ME Ola B Motivation Content Overview over the J2ME-plattform Close up of technologies for Mobile and Wireless ... – PowerPoint PPT presentation

Number of Views:205
Avg rating:3.0/5.0
Slides: 50
Provided by: kursinfoH
Category:

less

Transcript and Presenter's Notes

Title: Programming Mobile and Wireless Devices using J2ME


1
Programming Mobile and Wireless Devices using J2ME
  • Ola Bø

2
Motivation
added nov 2005
3
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

4
J2ME in the Java landscape
Set top boxes
Smartphones
(Source Sun Microsystems Inc.)
5
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

6
J2ME Configurations
  • add material from mikkonen
  • 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 PDAs
  • CDC Connected Device Configuration
  • Set top boxes
  • High end wireless devices

7
J2ME Profiles
  • add material from mikkonen
  • MIDP Mobile Information Device Profile
  • Foundation Profile (non gui networked device)
  • Personal basis, Personal and RMI Profiles

8
JCP Java Community processJSR 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

9
Four Generations Nokia
  • 2003
  • 2002
  • 2004
  • 2005

10
Top end devices 2007
  • Sony Ericsson P1
  • Nokia E90 Communicator

11
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
12
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.

13
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

14
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
  • Command line tools
  • KToolbar in the WTK
  • An IDE

Myapp.jar
Packaging
15
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.profile
    s"), 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

16
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

17
MIDP applications AKA midlets
  • JAR File
  • A MIDP application is called a MIDlet
  • Must extend the MIDlet class
  • A midlet suite is a bundle of midlets.
  • 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.)

18
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

19
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

20
Application LifeCycle
Initialised and ready to run
Resources acquired, application running
All resources released, All threads stopped
21
Application LifeCycle methods(source javadoc for
class javax.microedition.MIDlet, consult
documentation for details)
Called by device Called by midlet
startApp() Tells MIDlet it has entered the active state and can start working resumeRequest() Tells device midlet want to continue
pauseApp() Tells MIDlet it has been paused notifyPaused() Tells device midlet wants to pause
destroyApp(boolean) Tells MIDlet to release resources and stop threads notifyDestroyed() 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 MIDlet.
22
MIDP 1.0 High Level User Interface
  • Windowing not appropriate on limited devices
  • Interface using whole Screens four kinds
  • 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)

23
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
  • EMAILADDR
  • NUMERIC
  • PHONENUMBER
  • URL
  • DECIMAL
  • How are these input constraints related to the
    limited input capabilities of mobile devices and
    to the T9 algorithm?
  • PASSWORD
  • UNEDITABLE (MIDP 2.0)
  • SENSITIVE (MIDP 2.0)
  • NON_PREDICTIVE(MIDP 2.0)
  • INITIAL_CAPS_WORD(MIDP 2.0)
  • INITIAL_CAPS_SENTENCE(MIDP 2.0)

24
Texbox Code
Initial text
Title
Command
Constraint
Maximum text length
Soft Key
25
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)

26
Alert and CommandListenerCode
27
List
  • Uses the whole screen for a list
  • Three use scenarios depending on Choice.type
  • IMPLICIT selecting invokes command
  • EXCLUSIVE selecting one deselects previous
  • MULTIPLE selecting more than one possible

28
Code for Implicit List
29
Code for Multiple List
30
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(...)

31
Form
  • A form displays a number of Items
  • Items can be
  • 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
  • Commands can be connected to Items
  • Layout is specified both in form and in items
  • Layout directives are hints only.
  • If form too high for display, it will scroll
  • What Items where used on the form shown?
  • ImageItem, StringItem and two Textfields

32
High Level Interface an Overview
33
Same Form, different devices, different results
34
Form Code
35
High level UI Form an overview
36
Guidelines for UI Design
  • HCI on mobile and wireless devices a challenge!
  • Why?
  • Use simple forms with few Items
  • Remember Small screen size, mobile context of
    use
  • Can you avoid scrolling?
  • Minimize input, use RMS to store user settings
  • Use static form content
  • 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
  • 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

37
Top 10 Usability Guidelines for Enterprise
Applications (Nokia 2004) http//www.forum.nokia.
com/main/0,,23_56,00.htmltips
  • Provide a clear navigation model
  • 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.
  • Use familiar language
  • 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
  • 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
  • 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.

38
More guidelines
  • Provide a simple Options menu
  • 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.
  • Use tabs wisely
  • 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
  • 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
  • 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.

39
Low Level UI CanvasLi 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

40
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)

41
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

42
Low Level UI, an overview
43
MIDP 1.0 Communication
  • Device must implement a HTTP 1.1 client interface
  • Transport is not necessarily over TCP/IP

Source Bill Day J2ME
44
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
    URL-approach Connector.open("ltprotocolgt//ltaddres
    sgtltparametersgt")
  • 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//960018N")

45
SMS-messaging from Java ch11WMA 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

46
WMA-an overview
47
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 )

48
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.
49
Transfer from/to record store
  • A record may be assembled with a DataOutputStream
  • ByteArrayOutputStream baosnew ByteArrayOutputStre
    am(barr)
  • DataOutputStream doutnew DataOutputStream(baos)
  • dout.writeUTF(url)
  • dout.writeInt(qid)
  • dout.writeLong(timestamp)
  • dout.flush()
  • answerStore.addRecord(baos.toByteArray(),0,baos.si
    ze())
  • dout.close()
  • baos.close()
  • A Record may be disassebled with a
    DataInputStream
  • RecordStore answerStoreRecordStore.openRecordStor
    e(answer,true)
  • ByteArrayInputStream baisnew ByteArrayInputStream
    (answerStore.getRecord(recordid))
  • DataInputStream dinnew DataInputStream(bais)
  • String urldin.readUTF()
  • int qiddin.readInt()
  • long timeStampdin.readLong()
Write a Comment
User Comments (0)
About PowerShow.com