Data Model Schema

We devise a data model schema of specifying which column of data should be shifted to the client side. So we ask the application providers to write a data model file which should follow our schema. Figure 4-6 is an example for describing the details of the columns using in the data model. The explanations of what the elements do are as follows:

<artdb>

<table ref="AddressBook">

<field ref="Name" />

</table>

</toRMS>

</artdb>

Figure 4 – 6 example of building a data model

z artdb

The element is the root of our data model. We will use the information inside to specify which column is essential and should be shifted into the storage on the client side.

z dbschema

This element can demonstrate how many tables are used in this data model. We can take advantage of the element’s value to build a database using Structured Query Language (SQL) [16].

z table

It manifests the table’s information inside. There is no standard database schema in W3C and still many groups devoted themselves to define a welcome schema. In order to simplify our data model, we define our database schema and take down below the table element. It can be changed into the standard one easily

z primarykey

We use this element to assign which field is the primary key of this table.

z field

This element is used to clearly show the columns in the table. The “name” and

“type” attributes are defined as #REQUIRED, so we cannot miss it. The attributes we defined to describe the field are not very completely corresponding to the relational database nowadays. For example, data length, allow nulls, default value, precision, scale and so forth, are the additional attributes provided by Microsoft SQL server. We simplify the designation and trace out the attributes which is necessary for building up the data model on both client and server side.

z toRMS

The element specifies which field is essential and should be transferred to the Record Management System on the client side. We use the type of “IDREF” at the elements’ attribute to trace out the definition of the element. The functionality of this element can be schematized as figure 4-7. The bottom left of the figure 4-7 indicated “with all columns” is on the behalf of the server side’s data model objects;

it contains all the columns regardless whether the field is essential. And the bottom right of this figure is the data model object specialized for client side storage; it only contains the essential fields which marked in this toRMS element in the data model XML file.

Figure 4 – 7 code generator for data model

In one of our future work is to provide a graphical user interface tool such as IDE (Integrated Development Environment) to ease the development of ART-based mobile applications. By using our IDE, the application providers do not need to learn how to follow our schema and write the data model files; he (she) can just fill up some text fields to finish the data model design. Then the development effort will be decreased.

Chapter 5 Implementation

After introducing our programming framework and how we design the system architecture to attain our objectives, we will go into details to our implementations. This chapter could be partitioned into two parts. The first part includes details of several mechanisms that we transform an ART-based application into a mobile application of MIDP.

The second will show some applications which are suitable for the new capabilities we provide in the ART framework.

5.1 Mechanisms

5.1.1 Writing an ARTApp

ARTApp is the application which written to be run on the ART server, and we need to execute the application through network support. The ARTApp can provide gorgeous capabilities by using the stronger power and rich resource on the server side. The full programming procedure and sample example are shown in the reference at [1]; the following is the brief procedure which can be split into several steps:

1. State initial UI in XUL and save them.

2. Create a new Java file by the name of Main.java, and there must be a class named Main in it.

3. The class Main has to extend from class ARTApp.

4. Developers must implement two method in class Main, startApp and stopApp.

And in the beginning of startApp, developers have to set the ARTApps to

SINGLE or MULTIPLE modes.

5. Before a window is used, its static method getInstance needs to be invoked first.

The return value is a reference of that window. Every widget declared in XUL documents can be used immediately.

6. If the status of a widget needs to be monitored, developers have to create and set a listener for this widget. Listeners will notify ARTServer if events of widgets happen.

But simple and complete ARTClient cannot suit the same listener; for example, number key events are able to be detected by MIDP version but not by WAP version of ARTClient.

7. Developers can write the program logic now.

8. When developers build the Main.java, the code generator that will be discussed in next section transfers XUL files into Java source files first. Then java compiler (javac) will be able to compile them (UI source files and Main.java). Finally, we will get the ART-based mobile application run on the ART servers.

In the procedures, we will see that the mobile application developers just need to specify some widgets in UI model. The remains of the program are program logic, and developers do not need to maintain network status themselves. Thus the programming of mobile applications with ART is very easy.

When developing a mobile application run with database, there is something additional need to set up. On the one hand the developers should build a file system or database system, and on the other hand they need to write a XML file to indicate the data model supported in this mobile application.

5.1.2 Code Generator

The code generator that works within our mechanisms in the logic model and UI model transforms specified source files into target files by checking the API mapping rules written in

L

IM² . The GUI and program logic of a mobile application (ARTApp) can be developed simultaneously by different people. And we will generate the codes separately.

z Code generator in UI model

Figure 5-1 is a collaboration diagram indicates that what components we had implemented to do the work of transforming APIs in UI model into the target source files.

Because the user interfaces are designed in XUL, which is a XML-based language, so we can adopt the available tools from XML to implement our “XULParser”, which is at the top left of this figure. The main object is called “ARTCodeGen”, at the middle of the figure, and it is responsible for generating the UI codes fit the target developing platforms.

Before the transformation, “ARTCodeGen” will first get the XULData from “XULParser”, and get the mapping rule from “IMMLFilter” secondly. “IMMLFilter”, at the top right of the figure, can filter out the mapping rules by our specified target developing platform.

After preprocessing, “ARTCodeGen” will call the compareAPI method provided by

“Transformer”, at the bottom of this figure, to check whether the XULData can be mapped to the target developing platform or not. If the return value is true, we can transform it with ease; otherwise, we will show some error messages to indicate the application provider that there is something wrong during the transformations.

Figure 5 – 1 collaboration diagram for code generator in UI model

z Code generator in logic model

Besides the UI model transformation, we use the similar way to transform the APIs in the logic model. The only difference between these two models is the component we used to read the source files. At the top left of the figure 5-2, it is “JavaParser” instead of

“XULParser” responsible to read the statements of program logical codes. For the explanation of using the “JavaParser”, we must point to the different developing language using in the source files. We noted a little earlier that we choose the Java programming language to develop the server-side and client-side applications. In the section 3-3 and 3-4, we pointed out that the Java programming source file will first be separated into programming block for better performance. Hence the “JavaParser” is implemented by the JavaCC technique and can adequately finish the segmented works.

The follow-up operations are the same with UI model transformation mentioned at the second paragraph from this section. To enumerate the flow of transformation repeatedly would only be tedious for the reader, so I shall waste no words on it.

Figure 5 – 2 collaboration diagram for code generator in logic model

z Code generator in data model

Because the data objects used on the server and client sides are not the same, we provide a “DBObjectGen” to solve this problem. At the top of figure 5-3 is the

“DMFilter” object; it reads the file of data model and parses out the data structure of the records. By setting the argument of the method named codeGenerate, which is the boolean type for specifying if it is a client component or not. When we want to get the

“ServerDataObject”, we will set the parameter into false and the “DBObjectGen” will generate the data object with all fields specified in the data model. Relatively, the

“ClientDataObject” is the necessary fields we will use on the client side and we can depend on the “DBObjectGen” to generate with the parameter setting to true. We had explained it clearly in the section 4.4.2.

Figure 5 – 3 collaboration diagram for code generator in data model

5.1.3 Store Records

In the implementation of storing records on the client side, we consult many investigations on the runtime environment provided for handheld devices. Though a great deal of effort has been made on storing records on handheld devices, the results of investigation lack for a general solution. In order to provide a widely resolution of storing records on the client side, we use the file system which can be supported by all the executable mobile devices for a relay.

Here is a figure which shows the sequence diagram of how we attained our objectives on the MIDP virtual machine. We implement two classes for packing the data information to client side. The first one is the “DBDelegate” class, working at server side, responsible for data retrieving and writing the records to a file. Then, we will package the file and download it with ARTApp to the client runtime environment. When a MIDlet is at its first running, we use the other class we implemented, “ShiftToRMS”, to retrieve the records in the file and store them in the RMS provided by MIDP.

Figure 5 – 4 sequence diagram for running with data model

5.2 Applications

Here, we propose two kinds of usages of ART applications which can be run independently on the client side; they are listed as follows:

1. single player in the multi-player game

We had provided an application usage of ART which can let users collaboratively work with the same application on the ART server. One fascinating application is to provide a game service on the ART server and then the users can act as a player entertaining in the multi-player game on the handheld devices.

By adopting our transforming functionality, when someone wants to play it alone, he does not need to connect to the ART server through network connectivity. It will provide great user experience and costless of the network connectivity’s fee. The most powerful functionality is that the application providers do not need to re-write the game logic for the handheld devices. In our development tools, we can automatically transform the original ARTApp into a MIDP application without additional effort.

In the left of the figure 5-5 is a selecting window in a multi-player game, named

“pushpuzzle” runs on the MIDP emulator; the player can choose which one of the game he wants to join in. And every player must connect to the servers via network connectivity support in order to collaboratively control this multi-player game. The right part of the figure 5-5 is the same application, produced through our transforming tools, which can be executed as a mobile application on the handheld devices independently without porting repeatedly to different developing platforms.

Figure 5 – 5 pushpuzzle

The enormous data storage system on the server side can record multiple kind of information which might be necessary or unnecessary. And we can connect to the persistent data storing services on the server side and operate the information such as inserting, deleting and querying through network support. But there exists a problem, discussed several times in this thesis, is the incapable network support. We cannot access the persistent data storing services without network connectivity.

By adopting our transforming functionality, the information which is necessarily during application executed can be encapsulated into the client side. So we do not need to worry about the operations of query the data will be failed or delayed through the non-robust network environments.

In the left of the figure 5-6 is a resulting window after a query operation on the server side. The data we retrieved are not only the necessarily information, name and email, but also the middle-necessarily or unnecessarily information, age and birth. But when we are in the situations that we must query the data locally on the client side, we can also get the necessarily information to use in no time. The reason why we can just provide the necessarily information is that the handheld devices are always limited-storage against the server level computers.

Figure 5 – 6 querying address book

These two kinds of mobile application have the same benefit of need no network support while executed. We provide a non-porting mechanism to let the ARTApp become disconnected-aware and can be executed independently on the handheld devices. There is no restriction that a disconnected-aware ARTApp must be only one of these two types of applications.

Chapter 6 Conclusion and Future Works

6.1 Conclusion

So far, we have described the merit of providing mobile applications based on our ART framework. The mobile applications can be executed with rich resources and strong computing power on the server side and displayed the executing results by drawing widgets within a window through the network connectivity via the handheld devices on the client side.

But, this powerful adaptive mobile application development framework has some defects that the applications could not work normally in the environment of no network connectivity support.

This paper provides a development kit which can automatically transform the ART-based mobile applications to the applications that can be run on the client side independently. By using these transforming tools we can achieve the objectives mentioned in Chapter 1 and redeem the drawbacks in the original system architecture.

The main advantages of using our development kit are as follows:

z Easily providing disconnected-aware mobile applications.

z Automatically transforming the application from the server version to client version.

z Reducing the porting effort while transforming applications to match the client side runtime environment.

We attain these objectives by designing a XML-based language named IM²L which is

detailed expression through section 4.1 to 4.3. By reading the files written in IM²L and the program logical codes in the original application which is run on the server side, we can achieve the goal of porting the applications to the ones which can be run on the client side. It can not only using the resources provided on the local side within the handheld devices as well but substantially decreasing the repeatedly porting effort about program logical codes and user interface codes on the client side by the application providers.

It should be concluded, from what has been said above, that ART, a mobile application development framework, nowadays can support the mobile applications to be run using the rich resources and the stronger computing power on the server side through network support.

And one other thing that is important for mobile applications is the local computation using the resources provided on the client side. These full-scale of capabilities provided by the ART framework could be applied in enormously aspects.

In order to ease the suffering of mobile application development on the ART framework, there are still several points can be enhanced into our development kit. We place them in the next section and wish that we could make our development kit more completely.

6.2 Future Works

There are several different directions to explore in future development of our development kit. We now provide the API transformation based on the Java^TM programming language at first. But there is not just one developing platform supported on the handheld devices. We wish that the target platform of transformation could be supported more widely and the developing works can be more easily, so we propose a few future works that enhance

z Complete the API mapping rules

The LIM² we defined can be used in multiple aspect, such as logic model and UI model, and it can support multiple developing platforms in using APIs. As we extend the API mapping rules from one developing platform to a new one, we can easily achieve the goal of porting the original application to a new developing platform. The transformations between developing platforms have recently brought to light by the vendors of programming languages. “JUMP to .NET” Strategy [12] is one of the transformations that automatically convert existing Java-language source code into the C# programming language. But it is just a beta version.

z Develop the Graphical Integrated Development Environment

Integrated Development Environment (IDE) is the most convenient development kit to application providers. So in our continuing research, we wish to provide a graphical IDE tools in the development of user interface and the designing of data model in order to let the ART-based mobile applications be developed more facile. There is much truth in this that it will make the progress of mobile computing enormously.

Reference

[1] 姚立三, 袁賢銘, ”An Adaptive Mobile Application Development Framework”, 國立交 通大學電資學院學程碩士班論文，民國 92 年 6 月

[2] 楊淑芬, ”Code Generator for XML-based Universal Service Terminal Framework”，國立 交通大學，碩士, 民國 91 年 6 月

[3] XML User Interface Language (XUL), http://www.xulplanet.com/tutorials/xultu/

[4] Weinsberg, Y., Ben-Shaul, I., “A Programming Model and System Support for Disconnected-Aware Applications on Resource-Constrained Devices”, Software Engineering, 2002. ICSE 2002, Proceedings of the 24rd International Conference on, 19-25, May, 2002

[5] java.net, The Source for Java^TM Technology Collaboration, JavaCC Project, https://javacc.dev.java.net/

[6] Sun Microsystems, “Java 2 Platform, Micro Edition (J2ME)”, http://java.sun.com/j2me/

[7] Sun Microsystems, “CLDC”, http://java.sun.com/products/cldc/

[7] Sun Microsystems, “CLDC”, http://java.sun.com/products/cldc/