Device Technologies I J2ME & WinCE

Transcription

1 Device Technologies I J2ME & WinCE Patrick J. Stockreisser p.j.stockreisser@cs.cardiff.ac.uk

2 Lecture Outline In the lecture we will: Look at considerations needed to run applications on mobile or pervasive devices Take GUI Considerations as an example Recap on Device Requirements Look at some specific device technologies An introduction to WinCE (example OS) An introduction to J2ME (example Software Language)

3 Device Technologies What is a Handheld Device? A portable device supporting wireless communications and/or information management (e.g. mobile phone,pda,smartphone ) What is a Mobile Phone? Handheld telecommunication device for use in an area divided into cells. What is a PDA? Handheld device providing applications for personal information management. What is a Smartphone? Handheld device integrating mobile phone, PDA or laptop computer functionalities (e.g. phone, PIM, ).

4 Device Topology

5 Device Limitations Limited Power Limited Processing Limited Memory Limits on Connectivity Smaller GUI Limited Size/Space for input or output Environment Considerations noise, hands free, day or night.

6 Scenario Considerations? Search and Rescue Communications Car Anti-Collision System (CACS)

7 Platform Characteristics

8 Comparison of Mobile Devices

9 Device Input and Output Microphone Voice Input Voice Commands Keypad Predictive Text Input Navigation Controls 2 or 4 way directional keypad Roller wheel (can be pushed to make selection or activation) Rocker control (can be pushed to make selection, activation and allow to adjust the scrolling speed) Hardware Buttons Standard layout Feedback (tactile, visual and auditive) Label or Icon (visible, readable and meaningful) Touch screen Input Controlled by stylus or finger Activation Selection Scrolling Data Input: (un)dedicated area or electronic ink handwriting recognition On-screen or hardware keyboard Display Design for the lowest resolutions: 4 lines x 12 characters including softkey labels Do not use blank lines to make content separations Guidance issue in case scrolling is necessary Speakers Headphones Output

10 Common and Accepted UI Components Menu Bar Pop-up Menus Input Fields/Forms Check Boxes Option Buttons Push Buttons Icons Sound effects Progress Bar Dialog Boxes (Error message, confirmation message )

11 Lecture Outline In the lecture we will: Look at considerations needed to run applications on mobile or pervasive devices Take GUI Considerations as an example Recap on Device Requirements Look at some specific device technologies An introduction to WinCE (example OS) An introduction to J2ME (example Software Language)

12 Windows CE Windows CE (often abbreviated to WinCE) is a variation of Microsoft's Windows operating system for minimalist computers and embedded systems. Windows CE has a distinctly different kernel, rather than a "trimmed down" version of desktop Windows. Windows Consumer Electronics?

13 Main features of Windows CE Provides a modular operating system that can be customised for specific products. Runs on a wide variety of platforms. The basic core operating system requires less than 200 KB of ROM. Provides interrupt delivery, prioritizing, and servicing. Supports more than 1,000 of the most frequently used Microsoft Win32 functions, along with familiar development models and tools. Supports a variety of user-interface hardware, including touch screen and colour displays with up to 32-bits-per-pixel colour depth. Supports a variety of serial and network communication technologies. Supports Mobile Channels to provide Web services for WinCE users. Supports COM/OLE, Automation, and other advanced methods of interprocess communication.

14 Windows CE architecture Windows CE has four primary modules or groups of modules: 2. The kernel supports basic services, such as process and thread handling and memory management. 3. The file system supports persistent storage of information. 4. The graphics windowing and events subsystem (GWES) controls graphics and window-related features. 5. The communications interface supports the exchange of information with other devices.

15 The Kernel The Kernel is the core of the operating system and provides system services for managing threads, memory, and resources. It includes: Pre-emptive, priority-based thread scheduling based on the Win32 process and thread model. Predictable thread synchronization mechanisms, including wait objects. Efficient memory management based on dynamic-link libraries (DLLs), which link user applications at run-time. A flat, virtual address space, with 32 MB of memory reserved for each process. On-demand paging for both read-only memory (ROM) and random access memory (RAM). Heap size that is limited only by available memory. Control of interrupt handling. You can map interrupt requests (IRQs) to hardware interrupts and implement your own interrupt service routines and interrupt service threads. Extensive debugging support, such as including just-in-time debugging.

16 Persistent Storage Supports FAT file systems with up to nine FAT volumes. Transactional file handling to protect against data loss. Demand paging for devices that support paging. FAT file system mirroring to allow preservation of the file system if power is lost or cold reset is needed. Installable block device drivers.

17 Communications Interface The communications interface supports a wide range of technologies. It includes: Support for serial communications, including infrared links. Support for Internet client applications, including HTTP and FTP A Common Internet File System (CIFS) redirector for access to remote file systems by means of the Internet. A subset of Windows Sockets (Winsock) version 1.1, plus support for Secure Sockets. A Transmission Control Protocol/Internet Protocol (TCP/IP) transport layer configurable for wireless networking. An Infrared Data Association (IrDA) transport layer for robust infrared communication. Both Point-to-Point Protocol (PPP) and Serial Line Internet Protocol (SLIP) for serial-link networking. Support for local area networking through the network driver interface specification (NDIS). Support for managing phone connections with the Telephony API (TAPI). A Remote Access Service (RAS) client for connections to remote file systems by modem.

18 Graphics, Windowing, and Events Subsystem (GWES) The GWES module supports the graphics and windowing functionality needed to display text and images and to receive user input. It includes: Support for a broad range of window styles, including overlapping windows. A large selection of customizable controls. Support for keyboard and stylus input. A command bar combining the functionality of a toolbar and a menu bar. An Out of Memory dialog box that requests user action when the system is low on memory. Full UNICODE support. A multiplatform graphics device interface (GDI) that supports the following features: Both color and grayscale displays, with color depths of up to 32 bits per pixel. Palette management. TrueType and raster fonts. Printer, memory, and display device contexts (DCs). Advanced shape drawing and bit block transfer capabilities

19 GWES Represents the GUI between the user, your application, and the operating system. Handles user input by translating keystrokes, stylus movements, and control selections into messages that convey information to applications and the operating system. Handles output to the user by creating and managing the windows, graphics, and text that are displayed on display devices and printers.

20 GWES GWES supports all the windows, dialog boxes, controls, menus, and resources that make up the WinCE user interface. This interface allows users to control applications by choosing menu commands, pushing buttons, checking and un-checking boxes, and manipulating a variety of other controls. GWES provides information to the user in the form of bitmaps, cursors, text, and icons. Even WinCE-based platforms that lack a graphical user interface use GWES basic windowing and messaging capabilities. These provide the means for communication between the user, the application, and the operating system.

21 GWES Power Management As part of GWES, WinCE provides support for active power management to extend the limited lifetime of battery-operated devices. The operating system automatically determines a power consumption level to match the state of operation of the device.

22 Window Management The most central feature of GWES is the window. In WinCE-based platforms with traditional graphical displays, the window is the rectangular area of the screen where an application displays output and receives input from the user. However, all applications need windows in order to receive messages from the operating system, even those created for devices that lack graphical displays. When you create a window, WinCE creates a message queue for the window. The operating system translates the information it receives from the user into messages which it places into the message queue of the active window. The application processes most of these messages, and passes the rest back to WinCE for processing.

23 Window Handling WinCE does not send applications any messages dealing with the non-client area of the window. A window's non-client area is the area of the window where an application is not allowed to draw, such as the title bar and scroll bars. The window manager controls the non-client area. WinCE does not support the Maximize and Minimize buttons. A user can send the window to the back of the Z order by tapping the window's button on the taskbar. The user restores the window by tapping its taskbar button again. The taskbar is always visible on WinCE. You cannot hide the taskbar or use the full screen to display a window.

24 Controls, Menus, Dialogue Boxes and Resources GWES provides controls, menus, dialog boxes, and resources to provide the user with a standard way to make selections, carry out commands, and perform input and output tasks. Controls and dialog boxes are child windows that allow users to view and organize information and to set or change attributes. A dialog box is a window that contains controls. All menus in WinCE are implemented as top-level, pop-up windows. WinCE supports scrolling menus that automatically add scroll arrows when a menu does not fit on the screen. WinCE does not support menu bars, but it does support command bars, which combine the functionality of a menu bar and tool bar in one control. Command bars make efficient use of the limited space available on many WinCE-based devices.

25 Lecture Outline In the lecture we will: Look at considerations needed to run applications on mobile or pervasive devices Take GUI Considerations as an example Recap on Device Requirements Look at some specific device technologies An introduction to WinCE (example OS) An introduction to J2ME (example Software Language)

26 A History of Java Java started small, aimed at television set top boxes and other interactive devices. At some point it aimed towards web browsers and applets and suddenly the brakes were off. The platform got all kinds of amazing features like Swing, Java 2D, Java 3D, JDBC, EJB, and so on. With each new API, the size of the platform got bigger and bigger and bigger. So did the runtime footprint. It is not uncommon to see Java virtual machines with a gigabyte or more of heap space. Java 1 platform was big, Java 2 platform is huge. Obviously, the large size of the platform conflicts with the goal of WORA (write once, run anywhere). Not every device that needs programming can support a multimegabyte process size.

27 Introducing J2ME As time and technology moved on, Sun recognized the need to collect the device-oriented platforms under one umbrella. In 1999, Sun introduced the Java 2 Micro Edition. J2ME is not a specific virtual machine, API, or specification. Instead, J2ME provides a modular, scalable architecture to support a flexible deployment of Java technology to devices with diverse features and functions. A J2ME "configuration" targets devices with a specific range of capabilities. A J2ME "profile" selects a configuration and a set of APIs to target a specific domain of applications. By selecting the best configuration and profile, a vendor can produce a wide range of flexible applications. Since lightweight appliances do not need to support the entire Java 2 platform, their resource requirements (and therefore cost) will be reduced. At the same time, by allowing modular extensions, J2ME allows vendors to differentiate themselves by producing innovative applications and incorporating value-added features.

28 Java 2 Micro Edition J2ME combines a resource-constrained JVM and a set of Java APIs for developing applications for mobile devices. J2ME applications are also known as MIDlets Simply put J2ME is a set of Java APIs. Since these APIs cannot run on a traditional JVM due to the limited size of mobile devices in regards to memory and resource availability, J2ME defines a limited version of the JVM as well. Device manufacturers install and pre-package their devices with this JVM (and associated APIs). It is most likely your mobile phone has a version of J2ME!

29 J2ME Games and Applications

30 J2ME J2ME can be divided into three parts: 3. A configuration contains the JVM (not the traditional JVM, but the cut-down version) and some class libraries; 4. A profile builds on top of these base class libraries by providing a useful set of APIs; 5. Optional packages, are an optional set of APIs that you may or may not use when creating your applications. Optional packages are traditionally not packaged by the device manufacturers, and you have to package and distribute them with your application. The configuration and profile are supplied by the device manufacturers and they embedded them in the devices.

31 Configurations A J2ME configuration defines an API and a virtual machine optimised to service devices that fall into a particular range of capabilities and resources. Two configurations have been defined: 1. Connected, Limited Device Configuration (CLDC) 2. Connected Device Configuration (CDC)

32 CLDC The Connected, Limited Device Configuration provides a platform for more resource constrained, but still network-connected devices. (The network connection may be intermittent.) Limited configurations for example, devices that have only 128 to 512KB of memory available for Java applications. Consequently, the JVM that it provides is very limited and supports only a small number of traditional Java classes. (This limited JVM is actually called the KVM.)

33 CDC The Connected Device Configuration (CDC) expects devices with substantial resources. The CDC is for devices with at least 2MB of memory available and supports a more feature-rich JVM (but still not a standard JVM). 128K to 512K total memory available with <= 256K ROM/Flash and <= 256K RAM. In most cases devices will have more ROM than RAM or Flash memory. Most devices with have limited power, often battery operation. Connectivity to some type of network, although with possibly limited (9600/bps or less) bandwidth. User interfaces with varying degrees of sophistication down to and including none. This category of device includes mobile phones, two way pagers, and PDAs.

34 Profiles J2ME Profiles define additional class libraries and APIs needed to enable domain-specific applications on a particular configuration. Profiles provide the vertical specialization built upon the horizontal configurations. For instance, the Mobile Information Device Profile requires at least the Connected, Limited Device Configuration. It enables development of applications to provide wireless access to information. The most basic profile is the Foundation Profile. The Foundation Profile requires the Connected Device Configuration. It explicitly supports devices with no user interface whatsoever, but which do have networking support.

35 MIDP The MID profile complements the CLDC configuration very well because it minimizes both the memory and power required for limited devices. It provides the basic API that is used for creating application for these devices. For example, it provides the javax.microedition.lcdui package that allows us to create the GUI elements that can be shown on a (limited) device running the MID profile on top of a CLDC configuration. Note that MIDP cannot be used with CDC devices. CDC devices get their own set of profiles, like the Foundation and Personal profiles (not covered) The most popular profile and configuration that Sun provides is the Connected Limited Device Configuration (CLDC) with the Mobile Information Device Profile (MIDP)

36 The 'K' Virtual Machine Sun has introduced a new Java virtual machine to support J2ME on 16 or 32 bit microcontrollers. Aimed at the Connected, Limited Device Configuration, the KVM is only 40K of object code and needs only "a few tens of kilobytes" at runtime.

37 KVM + The Good KVM is small, in fact, very very small! In its tightest configuration, it requires only about 40 kilobytes. It can also be customized. Several Java language and virtual machine features not required by most applications have been made optional. A particular J2ME configuration defines which of these optional features must be included in the KVM implementation. The follow features are optional: Long, float, and double Multi-dimensional arrays Class file verification Recoverable handling of Error classes Threads Event Handling JNI Class loaders Finalization

38 KVM The Bad The KVM weaknesses are directly connected to its biggest strength. In order to make it so small, Sun made some compromises in the Java language and virtual machine. This seems to be the long-feared fragmentation of Java s dominance. Programming Java for J2ME is not like programming desktop Java or enterprise Java. More than even, it will be practically impossible for a developer to keep current on "Java Technology" as a whole. Specialization will be more necessary in the future. (Remember this when looking for work!) The KVM does not implement the Java Virtual Machine Specification! It implements a subset of that specification. What does this mean? Do not expect WORA in all J2ME applications. A smart phone application will be extremely unlikely to work on a PalmPilot, or vice versa. This seems like it should be obvious, since the two devices have totally different capabilities, but since portability has been so much a part of the Java message, it pays to note its limitations under the J2ME. In general, J2ME applications will be portable across the profile they were designed for. In many cases, an application will also be portable from one profile to a more capable profile.

39 Java Overview

40 Lecture Summary In the lecture we have: Looked at considerations needed to run applications on mobile or pervasive devices Taken GUI considerations as an example Had a recap on specific device requirements Looked at some specific device technologies WinCE (as an example OS) We have introduced J2ME (as an example Application Language)