XMobile: a MB-UID environment for semi-automatic generation of adaptive applications for mobile devices

Transcription

1 XMobile: a MB-UID environment for semi-automatic generation of adaptive applications for mobile devices Windson Viana 1, Rossana M. C. Andrade 2 1 LIG Université Joseph Fourier (UJF), Grenoble I, France 2 Department of Computer Science Federal University of Ceará (UFC), Brazil Windson.Viana-de-Carvalho@imag.fr, rossana@ufc.br Abstract. Ubiquitous Computing promises seamless access to information anytime, anywhere with different and heterogeneous devices. This kind of environment imposes new challenges to software development. For example, information and user interface should be adapted according to contextual characteristics such as user, environment, and access device. In case of device adaptation, the development challenge is related to the heterogeneity of the devices, which requires software engineers to create different versions for each type of device and every platform. This paper proposes a MB-UID (Model-Based User Interface Development) approach for semi-automatic generation of adaptive applications for mobile devices. An environment, called XMobile, offers a device-independent user interface framework and a code generation tool for providing fast development of multi-platform and adaptive applications according to device and platform features. A case study is also presented to illustrate how the environment can be used for constructing an application for heterogeneous devices with different network connectivity modes. 1. Introduction The miniaturization of computational devices as well as the wide-spread availability of wireless communication resources makes possible the initial vision of ubiquitous computing described by Mark Weiser [ 20]. In the Weiser vision, the computational devices are inserted in the environment and allow a user to access information naturally, anywhere and with multiple types of interaction (e.g., visual, voice). An example of a ubiquitous application is an intelligent system for sharing digital photos and comments, where a user could employ his personal devices (e.g., handheld or a mobile phone with a built in camera) to take photos and to send them to his blog. The system detects where the photo was taken automatically and adds annotations, for example, about the location and the weather conditions. The user could also visualize photos of his/her friends that were taken near the place where the user is currently located. Many research projects already discuss the development of these ubiquitous systems [ 7, 10, 11]. However, these systems have never been widely available to everyday users. One of the critical aspects is the execution of applications in different computational devices [ 9, 13]. Personal mobile devices (MDs) such as PDA (Personal Digital Assistant), mobile phones and smartphones illustrate part of the heterogeneity problem. These devices are characterized by different restrictions of processing, memory, battery, and communication bandwidth. They also present differences in the

2 display properties and in how users interact with them. In addition, the support of programming platforms changes from one device to another, which makes it difficult to adopt a single platform for the application development process [ 13]. Hence, the conception and the design of ubiquitous applications becomes a challenge to a software engineer [ 9]. For instance, in the previously described ubiquitous system, different versions of the mobile application should be created. Each version should adjust its interface, its execution behavior and its functionalities to the characteristics of each user personal device. In spite of this, the creation of different application versions can be inadequate for human codification due to the diversity of platforms and available devices. Therefore, it is necessary to create tools to customize the development of these applications [ 9]. There have been many research and commercial projects in the area of automatic generation, mainly in the model-based user interface community. Generally, these tools use a hierarchy of description models in order to dissociate the final presentation of a user interface from its initial definition (i.e., components, style, and data) [ 16]. This interface design approach is called MB-UID (Model-Based User Interface Development). Model-based systems attempt to formally describe tasks, data, and users for an application, and then use these formal models to guide its generation. Particularly, MB-UID offers an infrastructure for the development of methods and tools that generates the user interface automatically [ 19]. In this context, this article presents a MB-UID environment, called XMobile, for the automatic generation of application interfaces that execute in mobile devices. The main goal of XMobile is to reduce the prototyping time of an application and to provide various adaptation levels of the user interface. XMobile differs from other MB-UID approaches, like XIML 16] and TERESA [ 1]. These approaches only allow the description of simple interfaces that could be not useful for real applications. In spite of this, XMobile can be used to describe the interface in a more detailed way in order to generate richer interfaces. Moreover, it does not limit the types of application that can be built with the environment. XMobile allows the developers to describe the graphic interfaces with a subset of the W3C standards [ 25]. This choice facilitates the learning process of XMobile and its integration with other development tools such as Eclipse [ 26]. The XMobile environment is composed of the XFormUI framework and the UIG (Use Interface Generator) tool. The framework XFormUI is a toolkit for creation of graphic interfaces independent of a particular device and from a certain programming platform. XMobile allows software engineers to describe the graphic interfaces with the following W3C standards: XHtml, XForms, XMLSchema and CSS (Cascading Style Sheets). The developer also describes the navigation graph associated with the application. Using this initial description, the UIG tool generates, in an adaptive and automatic way, the final code for different programming platforms. For the code generation, the tool uses a set of mapping rules that describe how the interfaces are adapted according to a class of devices (PDA, portable telephone), and to a programming platform. In addition, this generated code uses the framework XFormUI to build the final interface. Thus, XMobile allows a hybrid adaptation of the interface, which is a static adaptation with UIG, and, on the other hand, a dynamic adaptation with XFormUI.

3 This article is organized as follows: section 2 presents concepts about code generation and MB-UID; section 3 shows an overview of the proposed environment; section 4 discusses the types of user interface adaptation supported by XMobile; section 5 and section 6 describe, in details, respectively, the XFormUI framework and the UIG tool; section 7 presents a case study that illustrates how the environment is used to build an application for heterogeneous devices; and, finally, in section 8, final remarks as well as potential future works are outlined. 2. MB-UID and Code Generation Automatic generation of user interfaces (UIs) is extremely useful in the application design. It provides a division between the interface description and the application logic [ 5]. Generally, environments for construction and generation of UIs use a hierarchy of description layers or models to dissociate the interface definition from how it is rendered [ 16]. These declarative user interface models (UIM) allow modeling the interface in different levels of descriptions. UIM increase the possibility of reusing interfaces specifications. In addition, UIM provide an infrastructure for the development of methods and tools that generates the user interface automatically [ 19]. For instance, an interface form to share photos can be specified in three models: A more abstract model describes the interface components and functionalities. In this case, the model contains a text input component and a component to visualize images. Moreover, it includes the functionalities of sending a photo, posting comments and viewing friends photos; A second model specifies the interface composition and layout. This model describes that the text input should be replaced after the image component and the sending photo functionality should be presented together with the posting comments functionality. A third concrete model maps components to real widgets of a programming platform. For instance, a code generation process of J2ME MIDP platform will transform the component to visualize images in an ImageItem component. In ubiquitous computing, the use of interface description in many levels allows a single interface to define more than one model of composition and layout. Furthermore, different mapping models for real widgets can be described, which allows a unique description of an interface to be reused for various rendering situations. The choice of which models are used can be associated to different use contexts. Thus, the interface can be rendered in an adapted way according to the device, to the programming platform, to the user s preferences and to the characteristics of the environment the user is inserted in User Interface Description Languages Many languages based in XML have been developed with the goal of dissociating the interface definition from its final presentation, such as: UIML [ 23], XIML [ 16], XForms [ 25], UID [ 17], XML AWD [ 3], SUIML [ 18], and Teresa XML [ 1]. These languages are characterized by their power of expression, the set of available user interface components, and the techniques of mapping among description models.

4 XIML and Teresa XML are more general languages. They afford the ability to describe a user interface without any concern about the implementation. Besides the description of components, a software engineer specifies the knowledge related to the interaction between user and application. XIML and Teresa XML are used during the whole software development process, including design and analysis phases. To illustrate that, the business domain characteristics, the environment properties, and the user s activities can be specified. UIML and XML AWD offer a less general level of user interface description. They allow the specification of the interface independent from a specific programming platform or device. They also give the possibility of describing the style and the data associated with the user interface, which make them more adequate to the implementation phase. The XML user interface description languages organize the levels of UI definition in different ways. For instance, XIML uses an ontological representation, called attribute-value pairs, to describe the objects of each abstraction level. XIML organizes this description in five models: Task, Domain, User, Presentation, and Dialog. Similarly, UIML separates the interface definition in five levels: description, structure, data, style, and events. <description>, <structure>, and <data> describe, respectively, the components, their composition, and the data that will be shown. In <style> and <events>, the mapping rules of the visual components and their events are defined in a programming language (e.g., Java). On the other hand, Teresa XML uses a division in three models: Task, Abstract Interface, and Concrete Interface. Teresa XML allows the automatic generation of user interfaces using a tree of tasks described in ConcurTaskTree (CTT) [ 2]. In this work, we split the user interface description into five levels (detailed in section 3): Abstract Interface, Presentation, Data and Validation, Dialog and Concrete Interface. The first four models are described by the developer, whereas the last model is generated by the UIG tool. Similarly to UIML and XML AWD, the interface description in XMobile is used in the last development stages. First, the system functionalities are specified and associated to a use context (for example, using a use case diagram). After that, the developer can create an initial specification of the user interfaces. The developer uses XForms, a new W3C standard, to create this specification. XForms is an effort of W3C to replace HTML forms with a more adequate format to be rendered by heterogeneous devices. The XForm components were created independent of the mouse access paradigm and also from a visual exhibition in a display. This creation process provides the form description independent of an interaction modality (e.g., visual or audible) and of the device characteristics, in which the application executes. For this reason, the use of XForms enables to the developer to describe, in a detailed way, the user interfaces, without the need for preliminary knowledge of the characteristics of the target device Strategies for Code Generation Usually, the approaches for automatic generation of user interfaces employ two strategies: Generation at development time. In this case, the described interfaces are generated during the development process (i.e., before the execution of the

5 application). Many versions of the user interfaces are generated for different execution contexts. Later, according to the current use context, the generated versions are chosen. Examples of works that use this strategy are MultiMad [ 29], SEFAGI [ 3], Teresa [ 1], and UID [ 17]. Generation at execution time. In this case, the interface definition is mapped during the execution of the application. Generally, this approach is used for adaptation of Web systems based on request/response. The mapping process can be a transcoding between two tag languages (e.g.; XHTML towards WML), or a generation using an abstract definition of the user interface. During the code generation process, the attributes of the context of use (such as the devices characteristics, the user profile) can be used in order to adapt the final presentation of the interface. Usually, the user interfaces are mapped to Web technologies such as WML, XHTML and VoiceXML depending on the requesting device. Works like LiquidUI [ 23], Icrafter [ 18], Roam [ 13] use this strategy. For example, LiquidiUI uses the parameters of a HTTP request in order to discover the access device characteristics. With this information, the tool generates documents in XHTML, WML and VoiceXML from a starting document described in UIML. It seems to us that the generation at execution time restricts the types of applications that can be created by this strategy. Since a strong constraint is that the application must remains connected to the server all the time. In general, works that apply this approach focus on Web technologies like WML, XHTML and VoiceXML. However, these technologies restrict access to the mobile devices functionalities [ 15]. In this work, we choose the generation at development time, since this approach lets the developer verify the generated concrete interface, and adds specific functionalities to each generated version. In addition, the software engineers could create applications with programming platforms such as J2ME MIDP, SuperWaba, Mophun and Doja I-Mode, which are supported by mobile devices. These technologies present high user interactivity, data input customization, and access to several new mobile device functionalities (e.g., bluetooth, cameras, GPS, MP3 players). Besides that, this strategy allows the construction of applications with different connectivity modes (e.g.; always connected, disconnected with later synchronization) and with different communication protocols (e.g.; HTTP, HTTPs, XML-RPC, SOAP). 3. XMobile environment The XMobile environment, which we propose in this paper, helps the development of applications for mobile devices. This environment includes mechanisms to reduce the heterogeneity problem related to this type of development. Since XMobile is designed to be used in a prototyping development process, it allows a rapid user interface construction in order to evaluate the usability of the applications in many devices and programming platforms. The environment generates the user interface at development time, allowing the creation of applications with different network connectivity modes.

6 3.1. Requirements The following requirements, which are pointed out in [ 6, 8, and 16] as essentials to the development of adaptive interface construction environments, have been used to develop XMobile,: A. Design process orientation and Interoperability. A tool used for user interface construction must be easily inserted inside a software development process. Besides that, the tool has to be easily integrated with other development environments. Particularly, UI tools for ubiquitous applications require this integration due to the evidence that the heterogeneity problem makes it impractical to conceive a unique tool for the entire application development. B. Variety of components and extensibility. It is important for a software engineer to have available a large variety of interface components, and a set of restriction and validation methods for data input. Then, functions for navigation among interfaces as well as for display of warning messages, and mechanisms for event handling should be available. However, all these functionalities have to be implemented with extensibility support due to the fast evolution of programming platforms and mobile devices. C. Multi-Modality and Independence of platform and device. The environment should allow the interface description in a dissociated way of a modality, a platform or a device to facilitate the adaptation process. However, this description cannot be restricted to a minimum group of common functionalities among the devices or the programming platforms, since it would limit the interface characteristics. D. Similarity and consistency. The environment has to ensure a minimum degree of similarity and consistency among different generated interfaces. For instance, a user, who runs the same application in different devices, should experience a similar access to the functionalities, and to the navigation among interfaces Components XMobile is composed of an interface component framework, called XFormUI, and a User Interface Generator (UIG) tool. The framework offers an infrastructure for the construction of adaptive forms-based applications. XFormUI is implemented for three different target programming platforms: SuperWaba [ 27], J2ME MIDP 1.0, and J2ME MIDP2.0 [ 28]. XFormUI provides a single way to describe the composed interface, and hides from the user (i.e., a software engineer) the mode, by which the APIs (i.e. Application Programming Interface) of each platform are called by the framework. In Figure 1, an overview of XMobile and the association between the framework XFormUI and the UIG tool is presented.

7 Figure 1 XMobile Environment XMobile allows a software engineer to describe the application forms using the following standards: XForms to define the components; CSS to define the style (e.g., colors and layout); and XML Schema to define the restrictions to the data input fields of the form. After that, the software engineer, using an Eclipse plug-in, creates a XML file, manifest.xml. This file defines the navigability amongst the interfaces and the mapping rules to an executable code of a specific programming platform. The Eclipse plug-in triggers the UIG tool to generate the code of the interface. This generated code uses the framework XFormUI to compose the form interface. The mapping process is facilitated due to XFormUI having been designed to have components with the same name and behavior of the XForms components User Interface Models XMobile is a Model-Based User Interface Development Environment (MB-UIDE), which enables the application modeling according to various levels of abstraction. It provides separation of the main user interface information, as follows: components, data, style, and layout. In XMobile, the interface definition is done in five models: Abstract Interface, Presentation, Data and Validation, Dialog and Concrete Interface. Relations between documents described by the software engineer and the five models are illustrated in Figure 2. Figure 2 XMobile User Interface Models The Abstract Interface model contains the description of the components that take part in the interface. The software engineer describes these components in the element View of XForms. XMobile supports a subset of the XForms components: data input components (e.g., Input, Secret, TextArea), selection components (e.g., Select,

8 Select1, SelectBoolean, Range), data output components (e.g., Output), and event handlers (e.g., Submit, Trigger). In the Presentation model, the developer describes the style and the spatial relations among the components. The style is described using a CSS document. By using CSS, the software engineer can, for example, change the colour properties of each user interface component. The software engineer uses XHTML tags to express the spatial relations and the composition. For instance, the software engineer uses the tag <xhtm:p> in order to define an order relation (e.g., a component must be placed before another) or a grouping relation (e.g., a component is logically dependent on another). For relative spatial position (e.g., centred, on the right of a window), the software engineer uses the "align" attribute. This information is investigated during the code generation process. The UIG tool uses the relations described to guide the adaptation process according to the device space limitations for presentation (e.g., the display size) and according to the presentation restrictions imposed by the target programming platform (e.g., J2ME MIDP 1.0 neither does enable the association of colours to an interface component, nor the presentation of two components in the same line). The Data and Validation model has the initial data associated to the interface and its type restrictions. The initial data (e.g., the default content value of a component) is described using XML at the Model element of the XForms document. The software engineer can also link a XMLSchema to the XML data. This information is used to generate, in the final application code, the Class constructors and the functions to validate the type restrictions. The Dialog model, which comes from XIML, defines the event actions of each interface and the graph of navigation among them. The software engineer associates to each event handler the screens that must be shown with their activation. For example, it can associate the selection of a Trigger in a screen A to the opening of a screen B. This information is described in the Manifest file and is linked to the events described in the Control element of XForms. The Concrete Interface model corresponds to the final code of the user interface in a programming platform. This code is automatically generated by the UIG tool with the descriptions of the other models. As a consequence of the generation at development time, the software engineer can add specific functionalities to each version of the generated code. Figure 3 presents an example of the use of the XMobile models. The example is a login form of a mobile blog application. It is described by three XML documents: one XHTML/XFORMS (Figure 3a), one CSS (Figure 3b) and one XMLSchema (Figure 3c). The form described by the XHTML/XFORMS contains five components: one Image, one Output, one Input, one Secret, and one Submit. The Submit component is associated with the action "Enter". The properties of these components are described by the View element (<xhtml:body>) of the XHTML/XFORMS document (Figure 3a). For instance, the View element describes that the Secret component has Password: as the value of its label and it also describes that the source of the image is on the path /res/mphlog.jpg. This XML document also contains the Model element that describes the initials values of the form (e.g., the title is Mobile Photolog ) and the restriction of value presence of the Input login (i.e., "required=true").

9 Figure 3 - Example of the XMobile Models The CSS document (Figure 3b) describes the color information related to the presentation (e.g., the color of the Input label is red). The XMLSchema document (Figure 3c) associates a simpletype "pass" to the Secret component value. This new type is a string with length between three and nine. This information is used during the code generation process in order to generate a function to validate this restriction. The UIG tool is able to generate the code for a programming platform using these three documents. Figure 3d presents the execution of the generated code to the J2ME MIDP 2.0 platform. The five components are mapped to J2ME MIDP. A code for validation of the restrictions is generated and is linked to the Submit component action ("Enter"). This action is shown in Figure 3d, an alert message is displayed after the Submit action ("Enter"), since the length of the field "Pass:" is less than three.

10 4. Types of Adaptation The programming platforms for mobile devices, either SuperWaba or J2ME MIDP, provide functions for dynamic adaptation of user interfaces. These methods enable a certain code independence of a specific device. For example, the components layout in the interface can be described in a relative manner among the components (e.g., a component A is on the left of a component B). Furthermore, the action and the selection components modify the presentation style in accordance to the interaction modality of the device (e.g., using a stylus pen or using a phone keyboard). Unfortunately, these programming platforms are not supported in a homogeneous way by the operational systems of the mobile devices. This is the main reason for the difficulty in achieving an agreement for a unique platform for the application development. XMobile enables three types of user interface adaptation with the goal of reducing the problem of platform heterogeneity. In addition, XMobile reuse the available adaptation functions in the platforms. These types of user interface adaptation are: i) adaptation according to classes of device, ii) programming platform adaptation, and iii) specific device adaptation. Figure 4 presents these types of adaptation and how they are linked during the process of code generation. The first ones are supported directly by the XMobile environment during the creation of different application versions. On the other hand, the specific device adaptation comes from the structure of the generated code. The interfaces produced by the UIG tool use the framework XFormUI. The framework is specially designed to reuse the functionalities of dynamic adaptation available in the programming platforms. The type of adaptation according to classes of device consists in limiting the number of components presented in an interface (or screen). For each class of device, the tool determines a maximum number of components per interface (Nmax). When an interface has more components than the allowed Nmax, the UIG tool starts the process of interface division (i.e., the screen is mapped to several consecutive screens in order to show each component). This division also takes into account the spatial, order, and grouping relations described by the software engineer. Five rules are used for the division process: a) the relation of order is used in order to select N first components that should be showed in the first interface where N <= Nmax; b) if the Nth component takes part of a group, all the group components must be shown simultaneously in the following interface; c) if a group has more components than Nmax, the generation is stopped and a error message is written in the tool log; d) the components that were not shown in the first interface are shown in the following interface also using the order relation; and e) if the following interface contains more components than Nmax, a new process of interface division is started. In the environment, three classes of device have been defined: mobile phone, smartphone, and PDA. For each device class, Nmax was defined by usability tests. For example, for the mobile phone device class, Nmax is eight. Hence, if an interface contains more than eight components and the chosen device class for the mapping is mobile phone, then this interface is divided. It is important to note that a software engineer can, if he/she wants, change Nmax for each device class. In order to enable the division interface process, the description of XForms is divided into forms using

11 the Wizard Dialog Pattern [ 22]. This pattern allows the construction of a sequence of linked interfaces, and was initially created to adapt Web forms to the display of mobile phones. Besides that, Triggers are added to the new forms (i.e.: next and previous) in order to link them. The initial Triggers contained in the original XForms description are set in the last form of the Wizard sequence. For this reason, the generated code achieves similarity and maintains the desired consistency of the user interface. Figure 4 - XMobile types of adaptation The programming platform adaptation is provided in two forms in the UIG tool. The first one also corresponds to the strategy of interface division. The tool initiates this strategy when the target platform of the generation process does not allow simultaneous presentation of certain components. For instance, J2ME MIDP denies showing a text input component (TextBox) and other data input field in the same interface. In these cases, the UIG tool divides the interface in two screens. The second form of programming platform adaptation is related to the style functions of presentation (i.e., colors, layout). UIG uses the information described in the CSS document, only if the target platform supports these types of functions (e.g., change of colors). This UIG behavior aims at optimizing the generated code in order to better use the resources of interface definition available on each platform. Figure 5 illustrates the platform adaptation process. The figure shows an interface to visualize a new photo and to write comments about it. The description of this interface was written once and after, the UIG tool generated three different codes. The interface was divided into forms for J2ME MIDP 1.0 and 2.0 due to the presentation restriction of these platforms (i.e., the TextBox component can not be showed with the ImageItem component in the same interface.). The XFormUI functions of color changing and layout are started only in the code generated for the platforms SuperWaba and J2ME MIDP 2.0, since these functions are available at these platforms, but not in J2ME MIDP 1.0.

12 Figure 5 Examples of interface adaptation 5. Framework XFormUI SuperWaba, J2ME MIDP, J2ME DOJA and J2ME Personal Java are programming platforms based on the Java programming language. They allow the construction of applications for mobile devices. Unfortunately, these platforms have different APIs for interface definition, data recording, and data transmission that prevents code migration among them. XFormUI offers abstraction of these different platform APIs and reuses their functions of user interface adaptation, since is developed using a bottom-up strategy. The framework XFormUI consists of a platform-independent toolkit of user interface components. Besides the components, XFormUI provides functions to navigate among the interfaces, to restrict data input (e.g., limitation of numeric types, existential quantifiers), to validate data input automatically, and mechanisms to define the forms layout and style. Four approaches have been used to guide the XFormUI design, as follows: Generalization. A study about the main programming platforms for mobile devices has been done in order to allow the implementation of the framework XFormUI in many platforms. The goal of this study was to identify common characteristics of these platforms and to incorporate these common functions in the framework. This generalization process is mainly related to the structure of the core classes of these platforms (e.g., MIDlet in J2ME MIDP and MainWindow in Superwaba). Figure 6a presents an example of this approach. The MainXForm class of the framework XFormUI contains the common structure of execution of the classes MIDlet and MainWindow. Figure 6 - Examples of XFormUI strategies

13 Transparency. Every method of the framework XFormUI abstracts the calls for the APIs of the platforms. This approach enables the constructed interfaces to execute in every platform in which the framework is implemented. For example, XFormUI offers a showmessage() method to display the messages at the interface. The developer uses this method without knowing how showmessage() calls the functions of the Alert component in J2ME MIDP, and those of the MessageBox component in SuperWaba. Combination of Components. Not all XForms components have corresponding components on the programming platform. In such cases, platform components are assembled to construct the XFormUI components. This approach achieves, in part, the similarity among the implementations. We present in Figure 6b an example of this approach. The XFormItem class of the framework XFormUI is composed in different modes on each platform. Specificity. Functions that do not correspond to the common functionalities of the studied programming platforms are added to the XFormUI framework to avoid the limitation of the framework to their minimal common characteristics. These functions are mainly related to the layout management, which is not available in some programming platforms such as J2ME MIDP 1.0. If a function cannot be completely implemented in a programming platform, the implementation of the corresponding methods in the framework cannot execute anything, or execute what is possible only in a partial way. The advantage of this design choice is that the software engineer can improve the interfaces. Thus, the framework tries to present them in the most accurate way using the functionalities available at the target programming platforms. For instance, if the platform supports colors, the application components became colorful. Figure 7 presents an overview of XFormUI. The framework is divided in four parts: Forms, Core and Events, Components, and Validation and Restriction. Figure 7 - Framework XFormUI Three types of forms can be constructed using the framework XFormUI: TextArea, Select1Full and XForm. TextArea corresponds to a textbox form, which has to fill the entire device screen. Select1Full is a menu list form in which the user selects one option. XForm corresponds to a standard form to which many components can be added (e.g., data input fields, selection components). Core and Events contains three

14 main classes of the framework: MainXForm, XFormItem and Trigger. MainXForm is an abstract class and contains the onstart() and onexit() methods. These methods are rewritten by the software engineer in order to define what happens when the application is initialized and finished. The Components part is composed of eight classes that can be added to an XForms form. These classes together provide data input (i.e., text, dates, and passwords), display of texts and images, and selection of options. The Validation and Restriction part is composed of classes that enable the software engineer to define data input restrictions. In addition, the framework checks if the data input does not violate these restrictions. Classes such as StringRestriction, StringValidator, BindRestriction, BindValidator, NumberRestriction and NumberValidator compose this part. For instance, restrictions, such as maximal and minimal character numbers in a text, and a valid interval for a numeric value, can be expressed using methods of the Validation and Restriction classes. Table 1 shows how some classes and methods of the framework are mapped to the programming platforms. XFormUI J2ME MIDP 1.0 J2ME MIDP 2.0 Superwaba MainXFform Midlet Midlet MainWindow TextArea TextBox TextBox Container with a ListBox XFormItem Item Item e ColorLabel Control and Label Input It can contain a TextField or a DateField ColorLabel and can contain a TextField or a DateField Edit and Label. In the case of date restriction, a Calendar is associated Output StringItem StringItem and ColorLabel Label Select1 ChoiceGroup with the ColorLabel and restriction Exclusive ChoiceGroup with the restriction Label and ComboBox or RadioGroup or a ListBox Exclusive or Popup triggerevent() commandaction() commandaction() onevent() setforecolor() - ColorLabel.setForeColor() Control.setForeColor() Table 1 - Mapping of the Framework classes 6. UIG The User Interface Generator (UIG) tool was developed to enable the mapping of the documents that describe the user interfaces (i.e., XForms, CSS, XMLSchema and Manifest.xml) into an executable code. The tool achieves this code generation using XSL [ 25] (i.e., extensible Stylesheet Language). This markup language based on XML allows the creation of stylesheets or mapping documents called XSLT (i.e., XSL mapping). The XSLT enables the definition of rules to map the tags from an XML document to another description. The advantage of XSLT comes from the availability of several XSL parsers. These XSL processors execute all the mapping process only with two documents: the XML original document and the XSLT mapping document. Figure 8 presents the code generation process of the UIG tool. As mentioned before, the tool uses XSLT to execute mappings from XML documents into Java code. However, one of the tool entries is a CSS document, which is not based on the XML standard. Therefore, to complete the mapping process, the first step is to map CSS into a XML document. For this reason, the XCSS was created, which specifies an XML document to support the attributes of a CSS document. After the XCSS generation, the UIG tool, using the XForms, XML Schema, and the XCSS documents, generates an intermediate document, XMLMiddleForm.

15 The XMLMiddleForm is a canonic form defined by UIG in order to facilitate programming platforms mapping process. XForms, XCSS and XMLSchema documents are firstly mapped into XmlMiddleForm and, then, from XMLMiddleForm to the programming platform code. This approach is the application of the Meta-Model design pattern, described in [ 24]. Meta-Model presents the advantage of easy extensibility of the tool for addition of new target platforms (e.g., generation to the BREW platform). After the XMLMiddleForm generation, the Manifest.xml file is read. Thus, UIG identifies the target platform and the required device class of the mapping. Hence, the tool sends the specific template of the device class to the XSLT processor. In this template, functions verify the need of execution of the form division process. Next, templates that map from XMLMiddleForm to Java classes are executed. The construction of the UIG tool was reached in Java by using JAXP (i.e., Java API for XML Processing). The JAXP contains several classes that enable the manipulation of XML documents. In addition, JAXP includes an XSLT processor capable of achieving the desired mappings. Figure 8 Mapping process of the UIG tool The generated code of the forms follows a model similar to MVC (Model/Viewer/Controller). For each form, three classes are generated: Interface, Bean and Controller. The Interface class defines the View part of the form in which the graphic components and their composition are described. The graphic components are instances of the XFormUI classes. Besides that, different contructors are generated to the Interface class allowing its instantiation with static and dynamic data. The Bean class contains attributes related to the form data. Consequently, this class corresponds to the model part. The Controller class contains the execution methods for each Trigger in the forms as well as the methods for data validation and navigability amongst the interfaces. Since the software engineer can focus on the writing of the controlling class that refers to the business rules of the application, the generated code model enables rapid application development. 7. Related works In this section, the following works that are strictly related to this paper s proposal are discussed: MultiMAD [ 29], SEFAGI [ 3], Roam [ 13], and ICrafter [ 18].

16 MultiMAD, for instance, is a visual tool for the generation of multi-modal applications for mobile devices [ 29]. It enables the construction of four types of forms with a limited group of generic components. Besides this, a software engineer can add specific visual components of a certain platform to the application. Nevertheless, the tool will generate code only for the specific platform. MultiMad presents two types of code generators: one for J2ME MIDP and another for WML 1.1/2.0. Different from the XMobile environment proposed in this article, MultiMAD does not offer dynamic adaptation. SEFAGI is architecture for automatic interface generation of Web-Services based applications [ 3]. The application windows are defined in XML AWD (Abstract Window Description) using a panel composition (e.g., video exhibition panel, table exhibition panel) and each panel is associated to a Web Service. Adaptation rules are defined to generate the executable code of the user interfaces. These rules define the widget mapping from AWD panel to a platform component as well as the user interface layout (e.g., components position, window division). The main inconvenience of using the SEFAGI tool comes from the need of creating for each new constructed component, a corresponding component in the AWD description. Furthermore, SEFAGI limits the application to a Web-Service client. Thus, in comparison with XMobile, SEFAGI limits the types of applications that can be constructed. Roam is a component framework for the construction of applications, which execute in heterogeneous devices and can migrate among them [ 13]. Roam allows the designer to define the application interface using a device-independent component toolkit that is similar to the graphic components of the Java Swing API. The Roam framework uses a structure of agents to assure the capture and the transference of the application status when the application migrates among the devices. The software engineer describes how the components should be adapted to a device-platform pair and if the application logic should migrate to a higher capacity device (e.g., a desktop computer). During the application migration, a Roam agent is responsible for choosing how the interface will be exhibited in the new device using the previously described adaptation strategies. The main difference of XMobile, which is presented in this paper, from Roam is the simultaneous support of static adaptation and dynamic adaptation. ICrafter is a framework for interface adaptation in interactive spaces [ 18]. In ICrafter, the environment devices (e.g., a blackboard, a PDA) require a service using a request to a UI (User Interface) server. The framework verifies the environment context and identifies the type of the requesting device. After this, ICrafter instantiates an interface generator, which creates a description of the service based on the current context. Furthermore, the generator delivers the description to the device that builds the interface. ICrafter generates UIs in VoiceXML, HTML and SUIML (Swing UI Markup Language). Similar to SEFAGI, ICrafter has limitations for the types of applications that can be constructed, in contrast to XMobile. Table 2 presents a summary of the comparison between the related works and the XMobile environment. This table shows the interface adaptation types supported by the environments and the main differences among them, as follows: types of applications, target platforms, user interface components, and other specific

17 characteristics. In short, the main difference of XMobile, which is presented in this paper, from the other environments mentioned before is the simultaneous support of static adaptation, with the UIG tool, and dynamic adaptation, with the framework XFormUI. In contrast with ICrafter and SEFAGI, there is no limitation in XMobile for the types of applications that can be constructed. Moreover, the use of W3C standards facilitates the XMobile learning curve and the interoperability of the UIG tool. ICrafter SEFAGI Types of Applications Applications for interactive spaces Online applications based on Web- Services MultiMAD Online/offline applications Roam XMobile Mobile applications Online/offline applications Target Platforms VoiceXML, HTML and SUIML J2SE and J2ME WML 1.0/2.0, J2ME MIDP 1.0 and J2ME MIDP 2.0 J2SE, Personal Java and J2ME Doja Superwaba, J2ME MIDP 1.0 and and J2ME MIDP 2.0 Interface Components UIs for each service of the interactive space Panels with component groups (i.e., grid, list, images) Lists, texts, forms with date and data input fields Similar components to the Java Swing API 10 XForms components and the XHtml image Types of Interface Adaptation Platform Dynamic Adaptation Platform Static Adaptation and Device Dynamic Adaptation Platform Static Adaptation Platform and Class of Device Dynamic Adaptation Platform and Class of Device Static Adaptation. Device Dynamic Adaptation Table 2 Related works to adaptive interfaces generation Specific Characteristics Templates to map the UIs in services. It requires a middleware for the SUIML in MDs Adaptation rules tables to map AWD in specific components, and form division. Visual tool and MobileVC code Code migration and recovering of application status XSLT for code generation, CSS and XML Schema support, Eclipse plug-in, Manifest.xml for navigation among interfaces, and form division. 8. Case Studies We developed a mobile photolog in order to validate the XMobile environment. The mobile photolog allows users to post their comments and pictures using a personal computer or a mobile device. The photolog website, called M-Phlog, can be accessed by a large number of users and it should be able to answer to the requests in a suitable time. During the website conception, the following non-functional requirements are identified: Adaptation of client application. Different users will access M-Phlog from devices with different characteristics. For this reason, the application should be able to execute in a large number of devices and programming platforms. Adaptation of accessed images. Image adaptation is required due to the effort that a mobile device makes to access a Web picture, because of its size and format. Different connectivity modes. The application should allow storage and access to the users preferred pictures in the device itself as a way of avoiding excessive package transmission. Access to multimedia functionalities. The M-Phlog client can use the mobile device camera, in case it has one, and the MMS protocol to send pictures. Although this case study is a basic application, it can not be developed with [ 23], which only provide interface adaptation based on Web technologies for mobile phones (i.e., WML and XHTML). Furthermore, this application can not be developed with [ 3]

18 or [ 13], which are works based on online connectivity model, once the last two requirements are not satisfied. In Figure 9, we present an overview of M-Phlog, which is composed of a client application that executes in mobile devices and a Web server. The XMobile environment is used to build the client application. The user interfaces forms are specified in XForms, CSS and XML Schema. In this case study, these forms, after being generated, were used for login data input, images and comments visualization, image search, update in the user s preferences, and post new comments. After writing these forms, a Manifest.xml file was created. The Manifest.xml document contains the directives of generation and the description of the navigation graph among the interfaces. Three code versions were then generated: J2ME MIDP 1.0 with a mobile phone device class, J2ME MIDP 2.0 with a smartphone device class and SuperWaba with a PDA device class. The maximum time for the code generation of all forms for these platforms was 9.52 seconds. It should be mentioned that UIG was executed on an AMD Athlon 2400Hz, 512 MB of RAM with Windows XP Pro. Figure 9 M-Phlog Architecture M-Phlog server was constructed with the Mobile Adapter framework [ 4], which provides the construction of applications for content adaptation according to the user s preferences and the device characteristics. Thus, a module for image adaptation was constructed to change the image properties conforming to the device display dimensions and the described user s preferences. More details on this adaptation process are described in [ 4]. The Controller classes of the generated code are associated to the frameworks Requisitor and MobAC [ 4] in order to achieve the communication between the applications and the M-Phlog server. These frameworks provide communication functions and context acquisition methods. The code written on the controllers is portable among the target programming platforms, once the frameworks are based on Java and also implemented using these platforms. Therefore, every function of data validation, data exchange among the forms and communication with the M-Phlog server have been written only once by the software engineer. In the mobile photolog application, local storage of the user s favorite images was created using FramePersist [ 12], which provides serialization, object persistence and

19 search methods. This framework is implemented using the RMS and Catalog APIs, respectively, of the MIDP and SuperWaba platforms. Camera access was achieved only on the J2ME MIDP 2.0 platform using Mobile Media API (MMA). The client versions were executed in three devices, as follows: an HP ipaq 4100 with SuperWaba; the cell phone Motorola A388 with MIDP 1.0; and the smartphone P900 with MIDP 2.0. Figure 10 presents an execution flow of the M-Flog client application on the P900 emulator, in which different visual components of the framework XFormUI are illustrated. Figure 10 - Flow of the M-Phlog client on the P900 emulator 7. Conclusion and Future Works The XMobile environment consists of a framework and a generation tool that facilitates the fast prototyping for pervasive applications in heterogeneous mobile devices. In addition, XMobile provides different levels of user interface adaptation. The framework XFormUI enables the construction of graphical interfaces with resources of data validation and component layout. XFormUI implementations allow a software engineer to write the graphical interfaces only once and to execute them in an adaptive way on the following platforms: Superwaba, J2ME MIDP 1.0, and J2ME MIDP 2.0. The UIG tool for code generation allows the definition of interfaces, styles and data validation by using the following declarative languages: XForms, CSS and XML Schema. This tool also provides the interface adaptation in relation to the device classes with user interface form division, and automatically produces the code for navigation among them. Another important contribution of this tool is the code generated model that makes it possible for a software engineer to write only the controllers of the user interface forms, and, as a consequence, to concentrate on the application business rules, since the interfaces have been already constructed.