1. Programming Handheld and Mobile devices 1 Programming of Handheld and Mobile Devices Lecture 13 lcdui and OXO Rob Pooley rjp@macs.hw.ac.uk

2. Programming Handheld and Mobile devices 2 The Screen The central abstraction of the MIDP’s UI is a screen. –A screen is an object that encapsulates device- specific graphics rendering user input. –Only one screen may be visible at a time, and the user can only traverse through the items on that screen. –The screen takes care of all events that occur as the user navigates in the screen, with only higher-level events being passed on to the application

3. Programming Handheld and Mobile devices 3 Categories of Screen There are three categories of screens: –Screens that encapsulate a complex user interface component (e.g., classes List or TextBox). The structure of these screens is predefined, and the application cannot add other components to these screens. –Generic screens (i.e., class Form) that the application can populate with text, images, and simple sets of related UI components. –Screens that are used in context of the low-level API (i.e., subclasses of class Canvas). Each screen, except the low-level Canvas, can attach a Ticker.

4. Programming Handheld and Mobile devices 4 Class Display The class Display acts as the display manager that is instantiated for each active MIDlet and provides methods to retrieve information about the device’s display capabilities. A Screen is made visible by calling the setCurrent() method of Display.

5. Programming Handheld and Mobile devices 5 Use of Screen types List is used when the user should select from a predefined set of choices. TextBox is used when asking textual input. Alert is used to display temporary messages containing text and images. A special class Form is defined for cases where screens with a predefined structure are not sufficient.

6. Programming Handheld and Mobile devices 6 Using Form Form is designed to contain a small number of closely related UI elements. These elements are the subclasses of Item: ImageItem, StringItem, TextField, ChoiceGroup, and Gauge. The classes ImageItem and StringItem are convenience classes that make certain operations with Form and Alert easier. If the components do not all fit on the screen, the implementation may either make the form scrollable or implement some components so that they can either popup in a new screen or expand when the user edits the element.

7. Programming Handheld and Mobile devices 7 Rules of use getDisplay() is callable from startApp() until destroyApp() is invoked. The Display object is the same until destroyApp() is called. The Displayable object set by setCurrent() is not changed by the application manager. In other words –The Display object is set by the system –The screens are set and changed by your application

8. Programming Handheld and Mobile devices 8 Roles of MIDlet functions startApp - The application may call setCurrent() for the first screen. –The application manager makes Displayable really visible when startApp() returns. –Note that startApp() can be called several times if pauseApp() is called in between. –This means that initialization should not take place, and the application should not accidentally switch to another screen with setCurrent(). pauseApp - The application may pause its threads. –Also, if starting with another screen when the application is re- activated, the new screen should be set with setCurrent(). destroyApp - The application may delete created objects

9. Programming Handheld and Mobile devices 9 Event handling There are four kinds of UI callbacks: Abstract commands that are part of the high-level API Low-level events that represent single key presses and releases (and pointer events, if a pointer is available) Calls to the paint() method of a Canvas class Calls to a Runnable object’s run() method requested by a call to callSerially() of class Display All UI callbacks are serialized, so they will never occur in parallel.

10. Programming Handheld and Mobile devices 10 Abstract Commands MIDP applications define Commands, and the system implements these as abstract buttons, menus, or whatever mechanisms are appropriate for that device. Commands are installed for a Displayable object (Canvas or Screen) with a method addCommand of class Displayable. Command object constructors have three parameters: –Label: Shown to the user as a hint. –CommandType: The meaning of the command. One common hint would be BACK which causes the application to go back to a previous state. Most phone designs have standard policy on which button is used for this operation. The commandType hint allows the implementation to take advantage of that policy. –Priority: Lets the implementation make better mapping to a device’s capabilities.

11. Programming Handheld and Mobile devices 11 CommandListener The handling of events in the high-level API is based on a listener model. Screens and Canvases may have listeners for commands. –An object willing to be a listener should implement an interface CommandListener that has one method: void commandAction(Command c, Displayable d); There is also a listener interface for changes in the state of Items in a Form. –The method void itemStateChanged(Item item); defined in interface ItemStateListener is called when the value of an interactive Gauge, ChoiceGroup, or TextField changes.

12. Programming Handheld and Mobile devices 12 Class Summary Interfaces Choice Choice defines an API for a user interface components implementing selection from predefined number of choices. CommandListener This interface is used by applications which need to receive high-level events from the implementation. ItemStateListener This interface is used by applications which need to receive events that indicate changes in the internal state of the interactive items within a Form screen. Classes Alert An alert is a screen that shows data to the user and waits for a certain period of time before proceeding to the next screen. AlertType The AlertType provides an indication of the nature of alerts. Canvas The Canvas class is a base class for writing applications that need to handle low-level events and to issue graphics calls for drawing to the display. ChoiceGroup A ChoiceGroup is a group of selectable elements intended to be placed within a Form. Command The Command class is a construct that encapsulates the semantic information of an action. DateField A DateField is an editable component for presenting date and time (calendar) information that may be placed into a Form. Display Display represents the manager of the display and input devices of the system. Displayable An object that has the capability of being placed on the display. Font The Font class represents fonts and font metrics. Form A Form is a Screen that contains an arbitrary mixture of items: images, read-only text fields, editable text fields, editable date fields, gauges, and choice groups. Gauge The Gauge class implements a bar graph display of a value intended for use in a form. Graphics Provides simple 2D geometric rendering capability. Image The Image class is used to hold graphical image data. ImageItem A class that provides layout control when Image objects are added to a Form or to an Alert. Item A superclass for components that can be added to a Form and Alert. List The List class is a Screen containing list of choices. Screen The common superclass of all high-level user interface classes. StringItem An item that can contain a string. TextBox The TextBox class is a Screen that allows the user to enter and edit text. TextField A TextField is an editable text component that may be placed into a Form. Ticker Implements a "ticker-tape," a piece of text that runs continuously across the display.

13. Programming Handheld and Mobile devices 13 ChoiceGroup

14. Programming Handheld and Mobile devices 14 Command

15. Programming Handheld and Mobile devices 15 List

16. Programming Handheld and Mobile devices 16 Alert

17. Programming Handheld and Mobile devices 17 Form

18. Programming Handheld and Mobile devices 18 Implementing OXO We can implement some of the OXO game if we use class Canvas This supports lower level graphics It allows us to pick up real button clicks from our device We need to be careful to avoid device dependent features

19. Programming Handheld and Mobile devices 19 class OXOCanvas extends Canvas { String title; int outcome; char [] grid = new char[9]; OXOCanvas(String t) { super(); title = t; for(int i=0;i<9;i++) grid[i] = '\0'; } int checkMove(int x) { return 0; // Should really set outcome } protected void keyPressed(int keyCode) { if(keyCode==KEY_NUM1) outcome = checkMove(0);//code to check move grid[0] = 'X'; } protected void paint(Graphics g) { g.drawString(title,20,40,0); g.drawLine(10,80,120,80); g.drawLine(10,120,120,120); g.drawLine(40,40,40,160); g.drawLine(80,40,80,160); for(int i=0;i<9;i++) if(grid[i]!='\0') g.drawString("X",30,60,0); } }

20. Programming Handheld and Mobile devices 20 public class OXOdemo extends MIDlet implements CommandListener { OXOCanvasmainCanvas; Display display; public void startApp() { display = Display.getDisplay(this); mainCanvas = new OXOCanvas("OXO Game"); Command exitCommand = new Command("Exit", Command.EXIT, 0); Command playCommand = new Command("Refresh", Command.OK, 0); mainCanvas.addCommand(exitCommand); mainCanvas.addCommand(playCommand); mainCanvas.setCommandListener(this); mainCanvas.repaint(); display.setCurrent(mainCanvas); }

21. Programming Handheld and Mobile devices 21 public void pauseApp () {} public void destroyApp(boolean unconditional) {} public void commandAction(Command c, Displayable s) { if (c.getCommandType()==Command.EXIT) notifyDestroyed(); else if (c.getCommandType()==Command.OK) { mainCanvas.repaint(); } else; //default case }

22. Programming Handheld and Mobile devices 22

23. Programming Handheld and Mobile devices 23 Click button 1 Then click Refresh

24. Programming Handheld and Mobile devices 24