Organization

The rest of this thesis is organized as follows. In the next chapter, we review a few background and related works. The development flows of ART-based mobile applications are provided in Chapter 3. It also announces what components we should provide to attain our objectives. In Chapter 4, we will explain how to implement our architecture in transforming and what rules we stand on during transformation taking place. We list several applications which are useful in our scenarios in Chapter 5. Final chapter is the conclusions and future works.

Chapter 2 Background and Related Works

2.1 JavaCC

Java Compiler Compiler^TM (JavaCC^TM) [5] is the most popular parser generator for using with Java^TM applications. A parser generator is a tool that reads a grammar specification and converts it to a Java program that can recognize matches to the grammar. In addition to the parser generator itself, JavaCC provides other standard capabilities related to parser generation such as tree building (via a tool called JJTree included with JavaCC), actions, debugging, etc.

We will use this technique to generate a parser for parsing the mobile applications written in Java. By using it, the performance of our development kit will be enhanced.

2.2 Java 2 Platform, Micro Edition

The Java^TM 2 Platform, Micro Edition (J2ME^TM) [6] is the Java platform for consumer and embedded devices and a broad range of embedded devices, such as mobile phones, PDAs (Personal Data Associate), set-top box and smart cards.

The J2ME platform is a set of standard Java APIs defined through the Java Community Process^SM program by expert groups that include leading device manufacturers, software vendors and service providers.

Figure 2 – 1 Java 2 Platform, Micro Edition source: http://java.sun.com

There are three parts of the J2ME architecture (indicated by Figure 2-1):

configurations, profiles and optional packages. They cooperate to build complete Java runtime environments. Each combination of the three is optimized for the memory, processing power, and I/O capabilities of a related category of devices. The result is a common Java platform that fully leverages each type of device to deliver a rich user experience. The three parts of J2ME are described as follows:

z Configurations provide the base functionality for a particular range of devices that share similar characteristics. They are composed of a minimal set of class libraries based on a virtual machine. There are two J2ME configurations: the Connected Limited Device Configuration (CLDC) [7], and the Connected Device

Configuration (CDC).

z Profiles are a set of higher level APIs that CLDC or CDC must be combined with.

The collaboration provides a complete runtime environment targeted at specific device categories. The profiles define the application life cycle model, the user interface, and access to device specific properties.

z In order to address more specific market requirements, the J2ME platform can be further extended by combining various optional packages. Optional packages offer standard APIs for using both existing and emerging technologies such as Bluetooth, Web services, etc.

In the implementation of this thesis the profile we used is the Mobile Information Device Profile (MIDP) [8]. Combined with CLDC, MIDP provides a complete Java runtime environment that for mobile phones and entry-level PDAs. Added to this, MIDP is designed for mobile phones and entry-level PDAs.

2.3 MIDlet

Like applets, MIDlets are managed in an execution environment that is slightly different from that of a Java application. Java applications that run on MIDP devices are known as MIDlets. A MIDlet consists of at least one Java class that must be derived from the MIDP-defined abstract class javax.microedition.midlet.MIDlet. MIDlets run in an execution environment within the Java VM that provides a well-defined lifecycle, represent diagrammatically at figure 2-2, controlled via methods of the MIDlet class that each MIDlet must implement. We will take advantage of these specifications to promote the performance of our development kit.

notifyDestroyed()

XUL (XML User-interface Language) which was created to make development of the Mozilla browser easier and faster is a cross-platform language for describing user interfaces of applications. It is an XML-based language, so all features available to XML are also available to XUL. Most applications need to be developed using features of a specific platform, and that makes build cross-platform software time-consuming and costly. In mobile computing environment users may want to use an application on different devices such as handheld devices or set-top boxes.

Because XUL has all the advantages of other XML languages, other XML languages, for examples, MathML or XHTML, can be inserted within it. Moreover, text will be easily localizable; it can be translated into other languages with little effort. Style sheets can be applied to modify the appearance of the user interface (much like the skins or themes feature in WinAmp or some window managers).

XUL provides most elements that could be found in modern graphical interfaces. They are:

z Input controls such as textboxes and checkboxes z Toolbars with buttons or other content

z Menus on a menu bar or pop up menus z Tabbed dialogs

z Trees for hierarchical or tabular information z Keyboard shortcuts

The displayed component can be created from a XUL file or some data source. XUL content may be loaded from a local file or a remote site. In this thesis, we take advantage of XUL to implement our UI model. It will be talked about latter.

Chapter 3 Programming Framework

The development flow of mobile applications based on our ART framework can be separated into two parts; one is designing the XUL file for graphical user interface displayed on the client’s monitor, the other is the program logic for specifying what the program can do.

The UI designers and programmers can perform their work independently so that both parts could progress at the same time. Then, we will build the two parts into the applications run on the server side by code generation and compiling. The workflow is represented diagrammatically in Figure 3-1. We use Java^TM programming language [13] to implement our ART framework and the ART-based mobile applications are also developed by Java. So the Figure 3-1 is the workflow of building an ART-based mobile application shown based on the Java platform.

Figure 3 – 1 Workflow of building an ART-based application

3.1 Overview

There are two aspect we considering for designing the programming framework suitable

logic logic Java

for our new Applications. First, we follow the ART’s original programming framework and separate it into two models, UI and logic. So the new application programming framework is compatible with the original one and we do not need to re-develop the existed ART-based mobile applications. The other aspect is adopting the concept of MVC (Model-View- -Controller) pattern [14]. View is seen as UI model, Controller is similar as logic model and Model is drawn out as the data model standing for the data information we may use during the program’s execution time. We will provide some APIs for the application providers to develop the data model within the mobile applications. In the last few years, several articles have been devoted to the study of using data model in the mobile computing [9].

For reasons mentioned above, the programming model in the newly framework can be divided into three components. These three components are the UI model which presents the user interface’s widgets, Logic model which stands for the executed program logic, and Data model which records the information during the program performed, as sketched at Figure 3-2.

Figure 3 – 2 Our application model

3.2 UI model

Talking about the development in UI model, we still use XUL to describe the displayed

display styles of mobile applications. It lets UI designers could develop the user interface in the simplest way without considering the multiple kinds of user environments on the client side. There are many researches focusing on the area of UI adaption [18] but still no excellent solutions. So we will adopt the code generator, talked in section 4-2, to map the displayed components from XUL to other platforms which suitable for showing on the user environments. It is represented diagrammatically in Figure 3-1

Figure 3 – 3 UI model transformations

The “API Mapping Rules” in the below left of the Figure 3-3 is a file which records the displayable UIs’ mapping rules from XUL to other programming language. This file is written by an XML-based programming language designed by us after surveying kinds of platforms. We shall introduce it in detain in the section 4.1. Using this mechanism, the code generator can work more generally and also have much decrease in the porting effort.

3.3 Logic model

The programming codes in the logic model can be classified into three main groups. First one is the server component, second one is the client component, and the third one is the main logic like the application executing flow. The server component means that it can be executed at the server side and could use the strong computing power and the rich resources. The client component means that it can just be executed at the client side using the runtime environment provided by the handheld devices. Over the last few decades, this topic has been the subject of controversy, such as [10].

We use the Java^TM programming language to be our standard language in developing ART-based mobile applications in our newly programming framework. The reasons why we make this decision are as follows:

z The ART-based mobile applications were written in Java^TM programming language in the original programming framework.

z Nowadays, there are more and more handheld devices, such as PDA (personal digital assistant), Smartphone, cell phone, WAP phone, Java-enabled handset and so forth, providing the KVM onto their executing environment.

z Java 2 Micro Edition had provided MIDP (Mobile Information Devices Profile) APIs (Application Programming Interface) for developing mobile applications. We can adopt these APIs to let our developed applications work on the client side.

z MIDlet is the basic unit in mobile applications using MIDP. It defines three states to present the life cycle of the mobile applications. And the scope of MIDP, application model, user interface, persistent storage, networking and timers, are useful for a mobile application to be executed in the handheld devices.

For the reasons mentioned above, we choose the J2ME platform to be our client sides’

programming language for developing the server sides’ ART-based mobile applications and J2ME programming language for the client sides’ mobile applications, they are all defined through the Java Community Process^SM. While transforming the server side’s program into the client side, we do not need to modify the syntaxes. We just need to aim at the API used in the programs and map it to the target platforms.

Same as the UI model, we provide an “API Mapping Rules” file to be the regulations of transformation. The point is that, if we want to port the applications which originally run on the server side to the client side, we just need to transform all the methods invoked by the executing program on the server side into the methods which could be executed on the client side at their running time.

During transformation, if we compare all the statements in the program logical codes to all the API mapping rules, we will not keep performance well. So we try to generate a Java parser which can build a parsing tree and trace out the programming blocks by the program’s architecture. By taking advantage of choosing the programming blocks, the speed of method comparison will be fasten and the performance of API transformation will be promote. Figure 3-4 shows that how we transform the J2SE program into the J2ME program aiming at the programming blocks with the “API Mapping Rules” file.

Figure 3 – 4 logic model transformations

The “API Mapping Rules” here contains the mappings of J2SE APIs to MIDP APIs, and ART APIs to MIDP APIs. After transformation, if the application has some APIs which can not be executed normally on the client environment, we will show some error messages to tell the application provider. Then the programmer should move the method call into the server side’s component, in order to let the API run using the stronger computing power on the server side.

3.4 Data model

We abstract the data model from the application programming framework and provide some mechanisms to let it use both on the client side and the server side. Due to the limited memory size on the mobile devices, we cannot store all the data information on the client side.

The programmer should write some meta-data to point out which field must be stored on the client side. Therefore the data information can be invoked at local storage.

by us) which could be used both in the server components and client components. It let the providers have the common interface to use while retrieving the information. We cannot say for certain that we had totally brought up a complete solution in adopting data model on the client side, because we have not provided the synchronous mechanism from client to server.

But our design, separating out the data model, let the applications retrieve the data and store on the client’s storage. So users can still retrieve the information on the client side when network crashes. It is convenient and common using for the mobile applications.

Chapter 4 System Architecture

In order to automatically port the server side’s applications to the client side’s mobile applications and decrease the effort spent by the application providers, we design a system to attain our objectives.

The whole system architecture is shown as Figure 4-1. There are the three models classified from the abstract view of the programs at the above of the figure. The middle part is the components we provided for attaining our objectives. The middle left side of the figure is the file named “API Mapping Rules”, written in IM²L, which we talked about in section 3.2 and 3.3. And the below parts in the figure are the programs corresponding to the client and server visions. In the following sections, we will orderly introduce what components and mechanisms required in our system when they are operating.

Figure 4 – 1 System architecture

4.1 Interface Mapping Markup Language ( IM

L )

L

IM² is a XML-based language and its objective is to transform the APIs more generally. We use it to describe the rules about API mappings between different developing platforms. This language is defined by us (ART providers) and we consult the difference between different developing platforms in using the APIs and record the API mapping rules in order to transform the programs through diverse platforms. About the example of using the

L

IM² will be discussed further in section 4.2 and 4.3.

The merits of writing the API mappings through IM²L are as the following:

z It matches XML format so it have many available tools that can trace out the rules of mappings.

z It can be used in both Logic model and UI model.

z It can record many kinds of API mappings among different developing platforms.

z It is easy to modify while API revision is occurred. We can directly modify the API mapping rules when there is some change provided by one platform without rewriting a new code generator or altering the old one.

z It can be expanded easily. When one platform has new APIs, we just need to add the new mapping rules into our recorded file. Then our mapping scope will be expanded.

The file which named “API Mapping Rules”, mentioned in Figure 4-1, is written in L

IM² , and it is constructed by many of the API mapping rules. Figure 4-2 explains the concept of what the “API Mapping Rules” is. At the Figure 4-2, we can see that there is a source API which can be mapped to other APIs on different target platforms; this whole small

sketch is called an API mapping rules. The “API Mapping Rules” is the biggest graph at this figure, and it contains some API mapping rules in it.

Figure 4 – 2 drawing of API mapping rules

4.2 UI Model Transformation

In order to make User Interface, written by XUL, be shown on different kinds of developing platforms supported on the handheld devices, we use IM²L to define the transformations of API mappings.

XUL ART-UI MIDP WML

<window> Form Form <wml>+<card>

<canvas> Canvas Canvas <wml>+<card>+4 direction button+<img src=”…”>

<listbox> ChoiceGroup ChoiceGroup <select>

<button> Buttom Buttom <a href>

<textbox> TextField TextField <input>

Table 4-1

The capability of IM²L in User Interface is to record the API mapping rules of widgets which used in the XUL file and the API mapping rules will describe the usages of APIs on different developing platforms. For example, when we want to add a field of input a bunch of words to the display window on the client side, we have to write in different ways for different developing platforms, as Table 4-1.

In the original design, ART providers have to write different kinds of code generator in accordance with every developing platform. These code generators read the XUL file, and sequentially transform each widget in the file. There are some problems in this design:

z It is not easy to maintain the code generators.

The original way is to write the mapping rules in the code generator when there has any necessary transformations between source developing platform and target one. Besides, we have to write a specific generator corresponding to each developing platform. As mentioned above, if we want to modify the statement of transforming the widget, we should trace the programming codes of the code generator and find out the old mapping rules within it for the purpose of substituting the new API for the old one.

z We have to modify each code generator when a new mapping rule appears.

When we provide a new widget for UI designer’s usage, we must modify every generator in each kind of platform in order to update the new way of transforming the widget.

As a result, if we adopt IM²L to trace out the mapping rules, we can overcome the two problems mentioned above more flexibly. This set of mapping rules is provided by ART Framework. For program developer on ART, it needn’t take extra effort to understand the content of the document. Figure 4-3 shows a simple example how IM²L is used when

describing the mapping rules between different developing platform targeting at the specific UI widget. The elements used in Figure 4-3 are introduced as the following:

z InterfaceMapping

The element defines a set of widgets’ API mapping rules on each platform. The detailed mapping rules are illustrated in this section enclosed by the InterfaceMapping element.

z method

Here, we use method to represent each widget’s name defined in XUL. Our code generator will generate a concrete file of UI model according to the methods

Here, we use method to represent each widget’s name defined in XUL. Our code generator will generate a concrete file of UI model according to the methods