CM0256 Pervasive Computing Lecture 17 Software Development Approaches Tom Goodale t.r.goodale@cs.cardiff.ac.uk
Lecture Outline In this lecture we: J2ME applications Palm.
Device Limitations Limited Power Limited Processing Limited Memory Limits on Connectivity Smaller/no GUI Limited Size/Space for input or output Environment Considerations noise, hands free, day or night.
J2ME Games and Applications
J2ME J2ME can be divided into three parts: A configuration contains the JVM (not the traditional JVM, but the cut down version) and some class libraries; A profile builds on top of these base class libraries by providing a useful set of APIs; 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.
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)
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.)
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.
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.
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)
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.
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
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.
Java Overview
Developing Midlets There are seven steps to develop midlets Designing, coding, compiling, preverification, packaging, testing, and deployment Most of these are familier, but preverification is new.
Preverification Before you can deploy your MIDlet class, it needs to be preverified. Verification of byte code is a step performed by the JVM before it runs any class file to ensure that the class file is structurally and conceptually correct as per the JVM specification. If the class file fails this check, it is rejected and the JVM shuts down, indicating either security or integrity violation of the class file. This verification is done by all JVMs, even the tiny JVM contained in a CLDC configuration for a J2ME device. Although this is not a problem for "normal" applications, verification in J2ME devices is a resource and memory constraint that they simply cannot handle (or should not handle). Therefore, the need for preverification.
Preverification Preverification is one part of a special two step verification process, especially designed for constrained devices, such as the ones running CLDC based JVMs. The idea is to let a developer preverify his classes, which limits the amount of work needed to be performed when the classes are verified in the device. This preverification process adds special information to the classes that identifies them as preverified and makes the process on the device much more efficient.
ktoolbar The J2ME comes with a applications ktoolbar which helps with developing applications for generic devices. Ktoolbar provides an integrated environment for creating, testing and packaging a midlet.
Palm OS Overview Developing for the Palm OS is in some ways similar to other platforms and in other ways strikingly different. Two important similarities are as follows: Applications are event driven. You can use anything from C++, to standard C code, to assembler, to scripting.
Overview Differences tend to center around features crucial to the device size and purpose. These include how the Palm OS handles: Memory requirements Application and data storage Connectivity of the device to the desktop
Overview Most importantly, you should remember that the relationship between the device and the OS is extremely tight. Further, everything has been built on the premise that the handheld is an extension, not a miniature version, of the desktop. It specializes in ensuring that mobile tasks are simple and fast.
Interaction Between an Application and the OS The Palm OS runs on top of a preemptive multitasking kernel. One task runs the UI, while other tasks handle things like monitoring input from the stylus. The UI permits only one application to be open at a time. Thus, when your application is open, it (more or less) has control of the entire screen. Because applications run within the single user interface thread and can't, themselves, be multithreaded, the multitasking provided by the kernel is for the operating system's use only, and isn't available to you.
Memory Memory is handled in an unusual fashion. The RAM on a Palm OS device is used for two purposes: Dynamic memory allocation This is memory your application or the system needs while it is running. It also includes the stack your application requires. On a reset, this memory is cleared. This portion of memory is analogous to RAM in a traditional OS. Permanent storage This includes downloaded applications as well as data that the user will view, create, and/or edit. To dos, names and phone numbers, memos, and all the other data for built in applications also use this memory. On a reset, it is not cleared. This portion of memory is analogous to files on a hard disk in a traditional OS.
Memory For both kinds of memory, allocation is done as chunks. The permanent storage holds databases, with related chunks kept in a single database. For example, all the memos are stored (each as a separate chunk or database record) in a single database. Another database holds all records from the Address application. A database that has been copied to the desktop is stored with a.pdb extension often called PDB files.
Memory Unlike in a traditional desktop operating system, data and code are not copied from permanent storage to dynamic memory; they are used inplace. For example, when your code executes, it is executing in place from the permanent storage. Since the permanent store itself is in RAM, it can be read by the CPU like any other RAM. Similarly, data can be read (and displayed) directly from storage.
Memory Palm has been careful to protect permanent storage against accidental overwrites. Palm reasoned that users would be unhappy if one bug in a single application caused all their data to be lost. So while the permanent storage can be read like any other RAM, it is write protected by the device. In order to write to specific chunks within permanent memory, you have to use the operating system's mechanism, which includes a check against attempts to write to places outside the chunk.
Events A Palm OS application is event driven; everything it does is an event. Events arrive, like pendownevent or keydownevent, and your application responds to them. Some events are handled by your application; others are handled by the operating system. Once your application gets started, it enters an event loop, repeatedly getting, then handling event after event. The loop continues until the user launches another application, which causes your application to quit.
Resources An application on the Palm OS is a resource database that contains many different resources. A resource is simply a database record that has a type and an ID. Stored within these resources are the guts and skin of your application. On the desktop, these resource databases have.prc extensions. You'll often find them referred to as PRC files.
Resources Examples of the types of things stored in resources are as follows: Your code UI elements Text strings Forms Icons
Resources The UI elements that appear on the Palm device are initialized based on the contents found in these resources. Because the initialization is not embedded within your code, you can change the appearance of your application (for instance, to localize it for another language) without modifying the code itself. Another advantage is that you can use visual editors to display and edit the UI portions of your application. Such editors allow you to tweak the look or presentation of data easily without recompiling and re downloading your application.
Forms and Controls The Palm OS has built in support for various controls and for managing forms. Forms are similar to windows on a desktop operating system. Because of the simpler UI on the Palm OS, only one form is active even though several forms may be displayed. The Palm OS provides a rich API for forms that includes many UI elements (form objects). E.g.: Checkboxes,Radio buttons,push buttons,pickers (pop up lists),lists (one column),tables (multicolumn),scrollbars,static text labels,editable text fields,menus
Forms and controls Because these elements are stored as resources rather than in your code, you can create a prototype of your application very quickly. The simplicity of adding the UI elements and the variety of them that are available makes it easy to try out various application designs.
Communications The Palm OS supports a variety of communication methods. As communicating is an essential aspect of the Palm's success, you should expect this area of the OS to be critical in both current and future applications. Some communication pathways are: Serial communication. TCP/IP with a socket interface. Infrared. Low level infrared support is via Infrared Data Association (IrDA) protocols. Bluetooth Obex A higher level object exchange that allows exchanging information between Palm devices and other devices. Obexcurrently runs over IrDA, BlueTooth and SMS.
Support is provided for converting from native time format (minutes since midnight, January 1, 1904) to printable format, and to separate day/month/etc. In addition, there are APIs that allow the user to select a day or a time. Miscellaneous The Palm OS has various other APIs for features such as: Strings There are APIs for searching within strings, copying, and converting to and from numbers. Date and time
Miscellaneous Alarms Your application can set an alarm for a particular date and time. Your application is then notified when that date and time are reached (even though it may not be running at the time). Find The Palm OS provides a device wide Find that allows the user to search for a string anywhere within the device. Each application does its part by searching for the specified string within its own databases.
Lecture Summary In this lecture we have: Looked at two different development environments for mobile devices.
End of Lecture