Overview of a Model-to-Code Transformation Approach for Generating Service-based Interactive Applications for Google Android Marius Feldmann, Vladyslav Oleniuk, Larissa Globa, Alexander Schill Fakultät Informatik, Institut für Systemarchitektur, Lehrstuhl Rechnernetze Technische Universität Dresden Germany E-mail:
[email protected] Abstract – This paper reports on an approach for generating interactive applications for Google Android within a Model-driven development chain. The described Model-to-Code transformation is used within a methodology applying a visual authoring approach of interactive applications upon Service infrastructures. The central contribution of this paper is a proof-of-concept that the Meta-Model developed for this approach to describe complete Service-based interactive applications and intended to express models close to the final platforms can be applied to the generation of fat clients running on mobile devices.
I. Introduction Service-orientation is a well-established concept for building applications from reusable functional fragments in the area of Business-to-Business communication. However, the creation of interactive applications upon composed Services is still a time-consuming task. For this reason a unique development approach for a visual composition of Services enhanced by reusable parts of User Interfaces and of interactive applications (Service annotations) is currently worked out. The information fragments created by the visual authoring tool are transformed automatically to the source code that can be compiled, packaged and deployed in a last step. The defined methodology should be used within an end-user development approach [4]. In order to first bring the model representing the complete interactive Service-based application closer to the finally generated result and thus to ease the code generation, an intermediary Model-toModel transformation step is applied. The methodology currently developed for the creation of the interactive applications can be applied to the application development for different platforms. Thus the two intermediary models have to be reusable for holding all necessary information for different target platforms. Currently it is evaluated if the Meta-Model used as a target during the Model-to-Model transformation fulfills this requirement. In order to prove the applicability for generating applications for mobile fat client applications, this paper reports on the Model-toCode generation for the Google Android platform. Though Model-driven development approaches for Android (e.g. [1]) exist, to our knowledge none of them is embedded into a visual development of interactive applications upon Service infrastructures. The paper is structured as follows: In section II an overview of the Meta-Model used to describe source models for the Model-to-Code mapping is provided in order to give a basic understanding of its structure and contained information fragments. In section III the mapping of application models to the Google Android platform is described. The concrete realization of this mapping is explained in some more details in section IV. The paper concludes with a summary and outlook in section V.
II. Overview of Meta-Model The developed Meta-Model has been designed with respect to enable the description of models of interactive applications that 1. are intended for different target platforms 2. differ in the way of application partitioning
3. may be build upon heterogeneous Service technologies 4. offer dynamic and reactive User Interfaces 5. enable a mapping between different data types used by the Service infrastructure and the UIs 6. support basic Service composition patterns Furthermore, the description of models should be close to the final source code thus avoiding complex Model-to-Code transformation steps for the intended platforms. The Meta-Model is structured into three central areas: The UIManager, the Model-Controll-Adapter (MCA) and the ServiceManager (depicted in figure 1). The stateless ServiceManager is responsible for the Service invocation. It contains one ServiceController that itself contains the (potentially technological heterogeneous) Services used by the interactive application. It holds a reference to the functional interface description of a Service and the operation signatures (input/output parameter names and types) of used Service operations. The MCA forms the central part of the Meta-Model. It coordinates the interaction between the User Interface and the Service infrastructure. Its glue component is the StateController. It contains a set of States and transitions between them. Every State manages a set of StateModelEntities for storing State-wide data or data shared between States. The StateModelEntities may be constants or dynamic values. Both variants have a type definition associated with them. The type can be specified by just using a type name (as a string). Furthermore the State has got a defined behavior. It is expressed by a contained set of Activities formed by sequences of reusable atomic Actions with well-defined semantics. An Action may be for example a transition between states or an interaction with the UIManager or with the ServiceManager. Every state is associated with exactly one Page.
Figure 1. Structural overview The Page builds the entry point into the UIManager. This part of the application defines the structure and layout of every Page. Furthermore it assigns a PageModel to every Page containing several PageModelEntities e.g. to store the values of UI Interactors. Analogous to the StateModelEntities the PageModelEntities may be constants or dynamic values.
Due to the fact that dynamic and reactive UIs should be supported, a Page includes a behavior. It is defined analogously to the behavior of a State. The structure of a page is defined by a set of ViewGroups which are made up of ContentGroups and PresentationAreaContainers. A ContentGroup contains a set of Interactors such as text fields, buttons or lists of items. An Interactor offers an attribute for specifying its concrete representation after the Model-to-Code transformation. The Interactors are connected to model entities located within the Page. The PresentationAreaContainer is intended to encapsulate content that can be replaced by other content. By this structural element a partial exchange of content within a Page is enabled. Interactors intended for user input are associated with events. The root of the Meta-Model is formed by the Application (figure 2) class. It aggregates the StateController and ServiceController. Furthermore it may contain a LanguageKeyValueMap for supporting internationalization and a set of Properties to describe for example namespaces used by the application.
Figure 2. Root classes of the Ecore Meta-Model The interaction between the ServiceManager, the MCA and the UIManager is realized by using Commands. The Commands are named in regards of the receiving party. Thus PageCommands, StateCommands and ServiceCommands can be instantiated. The PageCommands and the StateCommands are linked to Activities defined by the different Pages and States. Thereby the commands trigger their behavior. The Commands themselves contain CommandModelEntites. In the case of the PageCommands and StateCommands these entities are associated with model entities contained in the command source and the command target. By this relation the model entities located in the Page or the State are associated with each other. Every ServiceCommand is mapped to a Service operation. The model entities contained in this command are associated with parameters of the appropriate Service operation; the Services’ return value is mapped to a StateCommand. Commands can be triggered by specific Actions available within the Activities of the UIManager and State, by the return of a Service invocation or by events taking place within the Page.
III. Structure of generated applications After providing an overview of the Meta-Model and introducing the necessary vocabulary, this section is intended to provide an insight into the relations between Meta-Model elements and the Google Android platform. Classes and constructs used by this platform are formatted in italic. Definitions of these terms can be found in [2]. The starting point of the platform mapping builds the generation of an Activity from every State contained in the source model. Every StateCommand used to access one of these states is transformed to a method embedded into the appropriate Activity. The implementation of these methods is formed by the different Actions defined within the Activity associated with the StateCommand. The same mechanism of method generation is applied to every Pa-
geCommand. Thus the scheduling of a PageInterAction leads to the invocation of a method implementing the actions triggered by the appropriate PageCommand. In the case of a StateTransitionAction (Action leading to the activation of a new State), the Google Android Intent mechanism is used in order to navigate to the new Activity generated from the target state. For every Activity a model for storing all necessary model entities is generated. If the Page- and StateModelEntities of the source State and associated Page are connected with each other via a CommandModelEntity, they are merged. All constant values are mapped to data embedded into an XML file created for the apropriate Activity within the Android’s “res/values” folder. PageModelEntities representing the values of interactors are mapped to instances of a specifically introduced class that binds the model entity to the UI element. Further model entities are mapped to objects storing the value and the type information. Before a command is sent, its contained model entities have to be set to the intended values. The code for this purpose can be derived easily from the instances of the Meta-Model as well. The User Interface for every generated Activity is inferred from the Page assigned to the appropriate State. For every Page a file for storing an XML-based UI definition is created. Every ContentGroup is mapped to an appropriate layout definition (such as LinearLayout) embedded into this file. The PresentationAreaContainers are transformed into ViewSwitcher objects. Every Interactor contained in one of these ViewGroups is transformed to the concrete UI elements specified by the type definition attribute of the Interactor. If no concrete UI element is specified, a simple mapping from the types of associated model entities to default UI elements is applied. Events associated with the interactors are registered as native Google Android UI events.
Figure 3. Structure of generated applications The overall structure of a generated application is depicted in figure 3. Every Activity is executed within an own thread (of the Google Android operating system). Events created by the user within the view of this Activity result in the invocation of methods associated formerly to the PageCommand triggered by this event. If the Activity associated with this PageCommand contains a StateInterAction, a method conforming to the former StateCommand is invoked. In the case the StateCommand schedules a ServiceInterAction, a ServiceCommand is sent to a thread running in the background. This implies that the ServiceCommands are mapped one to one from the model to source code. The receiving thread has been generated to handle the interaction with the Service infrastructure. Every instantiated ServiceCommand is mapped during execution of the application to a method call within the Singleton ServiceManager by an application component named ServiceCommandResolver. Based on the Service command name the right method within the ServiceManager is derived and invoked. The source code embedded into the abstract parent class of every created Activity handling this mapping is depicted in figure 4. The method invoked within the ServiceManager hands over the control to the stub generated for every Service.
The stubs are generated from the information fragments within the ServiceManager. A reference to every stub is included into the ServiceManager during the code generation. For invoking the physical Service only the operation name and the necessary parameters have to be sent by the ServiceManager to the Service stub. ServiceCommand ServiceCommand = (ServiceCommand) msg.obj; Object[] args = ServiceCommand.getArguments(); String commandName = ServiceCommand.getName(); ServiceManager smInstance = ServiceManager .getInstance(); Method method = smInstance.getClass().getMethod( "process"+ commandName.substring(0, 1). toUpperCase()+ commandName.substring(1), getClassArray(args)); method.invoke(smInstance, args);
Figure 4. Service command to method invocation The inverse communication back to the UI is done via a native application of State Commands. The ServiceManager instantiates a class named StateCommand in order to reply the return values of a Service invocation to an Activity. The command is sent to a Singleton named CommandDistributor. This component holds a reference to the currently activated Activity and forwards the command to a component offered within all Activities named StateCommandHandler. It is intended for invoking the methods generated from the StateCommand by mapping the name of the state command to the appropriate method name. The mechanism of the CommandDistributor implies that every started Activity has to fetch the instance of this Singleton and has to register itself as current Activity.
Figure 5. Role of Command Resolver and Forwarder Figure 5 summarizes the role of the CommandResolver used to map commands intended for the ServiceManager to one of its methods and of the CommandDistributor used to map commands - generated after a Service invokation returned - to methods within the currently scheduled Activity. The described mechanisms show that the command concept used within the model of the application can be natively applied to the interaction with the ServiceManager within the generated application instance. It leads to a very generic concept of command-to-method mapping based on reusable code.
IV. Implementation of code generation The described mapping from a model conforming to the described Meta-Model to source code fragments has been implemented by using the openArchitectureWare (oAW, [5]) generator framework. It requires the definition of a Workflow file that triggers the different generation steps. The oAW workflow is triggered by a separate Apache Ant [6] script. After generating the code it builds and signs the application package thus preparing it for the direct deployment. Thus the complete process from Model-to-Code mapping to the deployment is realized fully automatically.
The oAW workflow triggers Xpand templates that realize the following six coarse-grained steps: 1. Generation of the res/value/values.xml files for constants within a State and Page aggregated to one Google Android Activity 2. Generation of the appropriate res/layout/ .xml files for every page 3. Generating a /activities /.java file for every Activity that contains the complete source code for executing the Activity thus it embeds e.g. the methods implementing the different Page- and StateCommands 4. Generating the ServiceManager file with the different method hooks for invoking the Services 5. Generating the data objects for the PageModelEntities and store them in file conforming to the schema /dataobjects /.java 6. Generating the stubs for the Service invocation The test applications used WSDL described Services and XML-RPC Services. For the realization of the stub for accessing the WSDL described Services via SOAP, kSOAP 2 [7] has been used. For invoking XML-RPC operations the android-xmlrpc library has been utilized. Our implementation has been applied to several test scenarios proving that the code generation for the described source model can be realized in a straight-forward manner for the Google Android platform.
V. Summary and Outlook This paper provided an overview of a code-generation approach for creating interactive Service-based applications for the Google Android platform. It has been demonstrated that the Meta-Model intended to describe models for various platforms can be applied to the generation of fat clients. Some of the fundamental concepts used within the Meta-Model such as the command triggered Service invocation and the Service return to StateCommand mapping have been applied in the resulting application one-byone. Future work will focus on developing further platform mappings. Currently a Model-to-Code transformation for the Spring framework is under development. After the usability of the Meta-Model as a source for the code generation step for very diverse target platforms has been proven, the Model-to-Model transformation step mentioned in the introduction will be implemented.
VI. References [1] AndroMate – The Android Modeller and Code generator: http://www.lab.telin.nl/~msteen/andromate/ [2] Developer resources for Google Android: http://developer.android.com/ [3] ServFace project website: http://www.servface.eu [4] Burnett M.,”What is End-User Software Engineering and Why Does It Matter?”, IS-EUD 2009, LNCS 5435, 2009, pp.15-28 [5] openArchitectureWare project website: http://www.openarchitectureware.org/ [6] Apache Ant project website: http://ant.apache.org/ [7] kSOAP project website: http://ksoap2.sourceforge.net/ [8] XMLRPC library for the Google Android platform: http://code.google.com/p/android-xmlrpc/
Acknowledgment Parts of the results presented in this paper have been achieved within the FP7 project ServFace [3].
