Download
programming mobile and wireless devices using j2me n.
Skip this Video
Loading SlideShow in 5 Seconds..
Programming Mobile and Wireless Devices using J2ME PowerPoint Presentation
Download Presentation
Programming Mobile and Wireless Devices using J2ME

Programming Mobile and Wireless Devices using J2ME

153 Vues Download Presentation
Télécharger la présentation

Programming Mobile and Wireless Devices using J2ME

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Programming Mobile and Wireless Devices using J2ME Ola Bø Molde University College INF 245 Fall 2007 OBø

  2. Motivation added nov 2005 Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  4. J2ME in the Java landscape Set top boxes Smartphones (Source Sun Microsystems Inc.) Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  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 PDA’s • CDC Connected Device Configuration • Set top boxes • High end wireless devices Molde University College INF 245 Fall 2007 OBø

  7. J2ME Profiles add material from mikkonen • 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ø

  8. 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 JCP Java Community processJSR Java Specification Requests Molde University College INF 245 Fall 2007 OBø

  9. Four Generations Nokia 2002 2003 2004 2005 Molde University College INF 245 Fall 2007 OBø

  10. Nokia E90 Communicator Sony Ericsson P1 Top end devices 2007 Molde University College INF 245 Fall 2007 OBø

  11. J2ME for mobile and wireless devices Molde University College INF 245 Fall 2007 OBø

  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. Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  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.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ø

  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 Molde University College INF 245 Fall 2007 OBø

  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.) Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  20. Application LifeCycle Molde University College INF 245 Fall 2007 OBø

  21. Application LifeCycle methods(source javadoc for class javax.microedition.MIDlet, consult documentation for details) * abstract methods, to be implemented by programmer when subclassing MIDlet. Molde University College INF 245 Fall 2007 OBø

  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) Molde University College INF 245 Fall 2007 OBø

  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) Molde University College INF 245 Fall 2007 OBø

  24. Texbox Code Initial text Title Command Constraint Maximum text length Soft Key Molde University College INF 245 Fall 2007 OBø

  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) Molde University College INF 245 Fall 2007 OBø

  26. Alert and CommandListenerCode Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  28. Code for Implicit List Molde University College INF 245 Fall 2007 OBø

  29. Code for Multiple List Molde University College INF 245 Fall 2007 OBø

  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(...); Molde University College INF 245 Fall 2007 OBø

  31. 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 Form Molde University College INF 245 Fall 2007 OBø

  32. High Level Interface – an Overview

  33. Same Form, different devices, different results Molde University College INF 245 Fall 2007 OBø

  34. Form Code Molde University College INF 245 Fall 2007 OBø

  35. High level UI – Form an overview Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  37. 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 • 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. Molde University College INF 245 Fall 2007 OBø

  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. Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  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) Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  42. Low Level UI, an overview Molde University College INF 245 Fall 2007 OBø

  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 Molde University College INF 245 Fall 2007 OBø

  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("<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ø

  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 Molde University College INF 245 Fall 2007 OBø

  46. WMA-an overview Molde University College INF 245 Fall 2007 OBø

  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 ) Molde University College INF 245 Fall 2007 OBø

  48. Persistent storage methods(Source Javadoc for class javax.microedition.rms – consult documetation for details) Molde University College INF 245 Fall 2007 OBø

  49. 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ø