Supporting the Development of Multi-Platform Mobile Applications Rita Francese, Michele Risi, Genoveffa Tortora
Giuseppe Scanniello
Dipartimento di Management & Information Technology University of Salerno, Italy {francese, mrisi, tortora}@unisa.it
Dipartimento di Matematica, Informatica e Economia University of Basilicata, Italy
[email protected] programmers are still in charge to design and implement the data flow, the control flow, and the interaction between the used and the mobile application.
Abstract—The number and type of mobile platforms is increasing. Each platform has a specific set of native functionalities (i.e., camera, compass) and provides a specific framework to implement mobile applications exploiting these functionalities. The new features offered by HTML5 together with the PhoneGap framework let the web be a potential candidate for multiplatform mobile development. However, programmers are still in charge of implementing the data flow, the control flow and the interaction. In this paper, we propose a development process to allow the implementation of portable web applications that use native device features. This process is based on the Model-ViewViewModel architectural pattern and provides a framework that exploits the source code generated starting from the design of a State Transition Diagram. The state application logic is described exploiting Javascript. We also provide an example of generated multi-platform application, named Travel Guide.
I.
In this paper, we propose an approach for developing portable web applications that allows the users to use native device features based on the Phonegap framework. To this aim we provide a framework that exploits the source code generated starting from the design of a State Transition Diagram, while the application logic of each state is described exploiting Javascript. The generated application follows the Model-ViewViewModel (MVVM) architectural pattern. We also provide an example of generated multi-platform application, named Travel Guide. The paper is organized as follows: we discuss related work in Section II, while in Section III we describe the main characteristics of the MVVM pattern. In Section IV, we present our development approach, while an example of its is proposed in Section V. Final remarks conclude the paper.
I NTRODUCTION
In the last years, a wide range of mobile devices have been produced. The development of applications portable on different device is a hard tasks. The various type of devices adopt different operating systems such as iOS, Android and Windows Phone and the applications have to be developed using different programming languages [1]. These devices have also specific characteristics concerning the screen dimension, memory size, application switching, Internet connection, sensors (i.e., compass, accelerometer), GPS, and Webcam. In addition, mobile applications are generally of small size, sold at low prices, and developed by small teams [2].
II.
In the recent years a number of research works addressed the problem of the multi-platform development for mobile devices (e.g., [5], [6], [7]). For example, XMobile is a modelbased development environment for the automatic generation of application interfaces for mobile devices [5]. It is composed of a toolkit for the creation of graphic interfaces independent of a particular device and from a programming platform and of a framework to describe the graphic interfaces following the W3C standards. It provides separation among the main user interface aspects, such as data, style, and layout.
One of the main challenge is to let developers produce mobile applications which can be used independently from the device type exploiting the full set of the device features and sold on different marketplaces. Such an environment could save the cost of performing redundant activities, receiving platform-specific training, purchasing proprietary tools [3]. A solution could be to develop a mobile application as a Web application, gaining the portability advantage peculiar of the Web (the application will run on any device that has a Web browser) and also requiring to developers only web development skills. The main disadvantages concern the impossibility to access directly to hardware features of the mobile device and the difficulty to achieve sophisticated user-interface effects [4]. The adoption of a multi-platform framework, such as Phonegap or Titanium, partially solves the problem. These frameworks build hybrid applications for mobile devices using JavaScript, HTML5 and CSS3. The frameworks then compile the application exploiting the native libraries of a specific platform, generating an application for each target platform. However, 978-1-4799-1608-5/13/$31.00 ©2013 IEEE
R ELATED WORK
Choi et al. present in [6] an application framework based on the Model-View-Control (MVC) architectural pattern. Each component in the framework has a transformation rules corresponding to each mobile platform. A component has also an XSLT code template for code generation. In [7] Cimitile et al. propose an approach for generating multi-platform mobile applications based on the MVC architectural pattern and provide a framework that generates the code starting from a formal algebraic specification. III.
T HE M ODEL -V IEW-V IEW M ODEL ARCHITECTURAL PATTERN
The MVVM architectural pattern is useful for User Interface (UI) development platforms which support event-driven 87
Fig. 1: The MVVM architectural pattern.
programming. The MVVM architecture is shown in Fig. 1, and it includes the following elements: •
Model: it refers to a domain model which represents the state content and/or the data;
•
View: it refers to all elements displayed by the graphical UI widgets such as buttons and labels;
•
ViewModel: it is an abstraction of the view that serves in mediating between the view and the model. It acts as a converter that changes model information into view information and passes commands from the view into the model. The use of a declarative data binding simplifies the development of the view layer through the implementation only of the ViewModel layer.
related through the definition of transitions messages from a state to another one. The output is a Javascript source code that implements the requirements of the mobile application and includes the State Machine library. Finally, the Integration & Deployment phase integrates the application source code with the target application framework. The source code is linked to the components of the target platform using an abstract layer implemented by PhoneGap that maps the HTML5 objects and widgets into the target platform objects and widgets, respectively. The output of the integration phase is a customized native mobile application that is deployed on the target device.
This pattern has some limitation: i) the UI is statically composed, ii) the views cannot share the business logic; iii) each view has a own set of data. The approach proposed in this paper follows this architectural pattern. In particular, it implements the View layer using the PhoneGap framework1, which enables to bind the view specified in HTML5 with the one available on the mobile device. PhoneGap is a standards-based, open-source development framework for building cross-platform mobile applications with HTML5, CSS3 and JavaScript technologies. It supports several mobile platform, including iPhone/iPad, Google Android, Symbian, BlackBerry and Windows Mobile. PhoneGap concretizes the View of the MVVM pattern on the mobile device and provides access to the device storage in order to make persistent the data of the Model.
A. The State Diagram Composition
The ViewModel is implemented by a State Machine that controls and handles the states (i.e., the Model) of the mobile application. The communication among the states is implemented by adopting a message passing technique. State Machine has been implemented as a Javascript library. IV.
T HE DEVELOPMENT PROCESS
The proposed process for modeling and developing a mobile application is represented by the UML activity diagram shown in Fig. 2. Rounded rectangles represent process phases, whilst the rectangles are the intermediate artifacts produced at the end of each phase of the process. The development process is composed of three phases: Application Definition, State Diagram Composition, and Integration & Deployment. The Application Definition phase enables the developer to select the target platform framework and the types of native events the application has to handle. Native events are events fired by the mobile device such as the click on the volume buttons. Other events concern the network status, the battery level and hard device buttons. The State Diagram Composition phase enables to define the object data and behavioral aspects of the application. It is composed of two main sub-phases: State Definition and Transition Definition. The State Definition sub-phase enables the specification of both business logic and UI of a single activity (i.e., state) of the mobile application. The Transition Definition sub-phase is in charge of defining how states are 1 www.phonegap.com
978-1-4799-1608-5/13/$31.00 ©2013 IEEE
88
A State Transition Diagram allows a developer to design the dynamic behavior of an application. In particular, it describes all the reachable states that implement the application and the events affecting each state. A State Transition Diagram is instantiated by a State Machine that executes the states and the state transitions. A state is executing when the State Machine waits until an event occurs for that state. In particular, an event occurs in case a specific trigger condition is satisfied or when the user interacts with the application. An event is a relation that links a starting with an ending state. These states are not necessarily distinct. If more than one event occurs at the same time, they are serialized using a priority scheme to execute one event at time. State Machine supports actions that depend on both the executing state and the triggering event. The development of the application also needs the definition of its UI, which is generated starting from the definition of a state. Fig. 2: The mobile development process.
Fig. 5: The Data definition of a state and their initialization and preparation.
Fig. 3: The state abstract definition. var S t a t e = { d o I n i t : f u n c t i o n ( ) {}; d o D e f i n e D a t a : f u n c t i o n ( ) {}; d o D e fi n e V i e w : f u n c t i o n ( ) {}; doBindView : f u n c t i o n ( ) {}; d o P r e p a r e : f u n c t i o n ( ) {}; d o E x e c u t e : f u n c t i o n ( ) {}; d o V a l i d a t i o n : f u n c t i o n ( ) {}; d o S t o r e O b j e c t : f u n c t i o n ( ) {}; d o R e s t o r e O b j e c t s : f u n c t i o n ( ) {}; d o D i s p o s e ( ) : f u n c t i o n ( ) {}; }
s p o t i n f o . doDefineData = function ( ) { this . selected = null ; t h i s . image = n u l l ; ... }; spot info . doRestoreObjects = function ( ) { t h i s . s e l e c t e d = t h i s . r e s t o r e O b j e c t ( t h i s . p r e v S t a t e . name + ’.selected’ ) ; ... }; spot info . doPrepare = function () { var db = d a t a b a s e C o n n e c t i o n ( ’TravelGuideDB’ ) ; t h i s . image = db . g e t F i e l d ( ’Spot’ , t h i s . s e l e c t e d , ’image’ ) ;
The state of a mobile application requires the definition of the following information:
$ ( "#image" ) [ 0 ] = t h i s . image ; ...
•
attributes, data and/or objects (i.e. a map object) identified by a unique qualified name;
};
•
the state behavior, a set of methods working on data and objects;
•
the User Interface (UI) defined by selecting the object data to be displayed by binding them with the HTML5 widgets.
device storage, whereas the doDispose releases the allocated resources and/or objects. During the execution of the business logic, a message is set for the current state, thus the State Machine can perform the properly transition to next one. The attributes of a state are automatically stored/restored into/from the device storage which provides persistence to them also when a state transition occurs. In particular, these attributes are stored (doStoreObjects method) when a state is disposed and are restored (doRestoreObjects method) when the same state is recreated, or when an attribute is referenced by another state. The persistency of these attributes is obtained by referring to their qualified unique name.
Each state is defined by inheriting and implementing a specific abstract definition (see Fig. 3). All the methods have a default behavior and should be overridden to instantiate a state. In particular, a state is initialized by calling the doInit method. The doDefineData method allows to define the attributes and objects of a state. doDefineView specifies the widgets present in the UI of the current state, whereas doBindView binds the events to the defined widgets in order to propagate the fired events to the State Machine, as shown in Fig. 4. When a state is activated, the doRestoreObjects method is invoked in order to restore all the values of the attributes of that state. Successively, the doPrepare method is invoked to set up the state by initializing the widgets and retrieving information from a database, see Fig. 5. Then, the action waits for an event. When an event occurs the method doExecute which implements the business logic of the state is executed. Finally the doStoreObjects method saves the attribute values in the
Once the developer has designed the states, he/she pushes them into the State Machine and specifies the transitions among them, indicating the source state, the event, and the target state for each transition (see Fig. 6). The State Machine executes the change of state by using a message passing approach. There are two kinds of events: local event and native device event. The former is an event that is defined for a specific action (i.e., waiting for an user input, triggering a timeout, updating the GPS status). It can only occur when the defined action is active. The latter occurs independently from the active state. As an example, native device events are related to hard buttons available on the device.
Fig. 4: The UI, event binding, and message passing implementation. s p o t i n f o . d o D e fi n e V i e w = f u n c t i o n ( ) { c r e a t e L a y o u t ( ’info_view’ ) ; $ ( ’#info_view’ ) . a p p e n d ( ’
’ ) ; $ ( "#info_view" ) . a p p e n d ( ’’ ) ; $ ( ’#map’ ) . b u t t o n ( ) ; ... }
To define the UI of a state the developer has to specify the widgets to be shown. Fig. 4 shows the definition of the widgets of the state spot info (doDefineView method), whose layout is shown in Fig. 7. The UI widgets are automatically placed following a list layout visualization. Next, the developer
s p o t i n f o . doBindView = f u n c t i o n ( ) { $ ( ’#map’ ) . b i n d ( ’click’ , f u n c t i o n ( ) { autoChange ( e v e n t ) ; }) ; ... }
Fig. 6: The definition of two states and the transition between them. //Definition of the states var s p o t i n f o = d e f i n e S t a t e ( ’Spot Info’ , ’info_view’ ) ; var p a t h m a p = d e f i n e S t a t e ( ’Path Map’ , ’map_view’ ) ;
s p o t in fo . doExecute = function ( ) { var e v e n t = t h i s . g e t E v e n t ( ) . t a r g e t ; switch ( event . id ) { c a s e ’map’ : t h i s . s e t M e s s a g e ( ’map’ ) ; break ; ... } };
978-1-4799-1608-5/13/$31.00 ©2013 IEEE
// The state are pushed into the State Machine addState ( spot info ) ; a d d S t a t e ( path map ) ; ... // Definition of the transition a d d T r a n s i t i o n ( ’map’ , s p o t i n f o , p a t h m a p ) ; ...
89
The developer chooses a specific platform (i.e., Android) to implement the application, and defines the State Transition Diagram. The application design is reported in Fig. 8.
Fig. 7: Examples of generated UIs.
When the user starts the application, he/she goes in the state List Path, showing the list of the available paths. Pressing the New button, a new path is created in the state Define Path. The information of a point of interest is displayed in the state Spot Info. When the path is complete, the user presses the Save button and the application goes in the state Save Path, which saves the path into the database. The user can activate a previously defined path pressing the activate button in the List Path state. In this state she can displays the map pressing the button Display, take a picture pressing the button Camera, save the Picture by clicking on the Save button. The picture is also associated to the Spot Info by automatically detecting the position through GPS. When the route is displayed on the map in the Path Map state, the user can display the information associated to a specific point of interest, including pictures previously taken in that place. The State Transition Diagram is implemented using Javascript and is embedded into a single HTML5 file. Finally, the deploy phase is performed by using the PhoneGap framework and installing the generated application on an Android Samsung Galaxy SII. Two screenshots of the generated mobile application are shown in the Fig. 7.
has to specify the events associated to the widgets (doBindView method) such as click, focus, and keyup. V.
AN
EXAMPLE : THE
T RAVEL G UIDE A PPLICATION
In this section, we describe an example of an application implemented using the proposed approach. Travel Guide is an application implementing a sightseeing navigation system described by the following scenario:
VI.
Starting from the consideration on the need of finding solutions to the problem of independence between mobile device characteristics and application implementation, this paper presents a development process supporting the implementation of portable web applications. The proposed approach is based on State Transition Diagram for modeling the behavior of a mobile application and on the MVVC architectural pattern for adapting the application to specific mobile devices.
Alice needs an application that helps her for selecting the point of interests of a travel on the Amalfi Coast. To this aim she has to search a list of the tourist places grouped by town in order to get information on a specific place. The application shows detailed information on the selected place, such as an image, telephone number, website, opening time and how to reach it. When Alice has selected the place to visit, the application proposes a trip considering the closeness among the places and their opening times. Moreover, during the trip Alice needs to associate to the place she is visiting the pictures she takes to compose a photo album.
R EFERENCES [1]
[2] Fig. 8: The State Transition Diagram of the application Travel Guide. [3]
[4]
[5]
[6]
[7]
978-1-4799-1608-5/13/$31.00 ©2013 IEEE
C ONCLUSION
90
S. Cuccurullo, R. Francese, M. Risi, and G. Tortora, “MicroApps Development on Mobile Phones,” in Intl. Symposium on End-User Development (IS-EUD), 2011, pp. 289–294. L. Corral, A. Janes, and T. Remencius, “Potential Advantages and Disadvantages of Multiplatform Development FrameworksA Vision on Mobile Environments,” Procedia Computer Science, vol. 10, pp. 1202– 1207, 2012. L. Corral, A. Sillitti, G. Succi, A. Garibbo, and P. Ramella, “Evolution of Mobile Software Development from Platform-Specific to Web-Based Multiplatform Paradigm,” in Onward!, 2011, pp. 181–183. H. Heitktter, S. Hanschke, and T. A. Majchrzak, “Comparing Crossplatform Development Approaches for Mobile Applications,” in Web Information Systems ans Technologies (WEBIST), K.-H. Krempels and J. Cordeiro, Eds. SciTePress, 2012, pp. 299–311. W. Viana and R. M. Andrade, “XMobile: A MB-UID environment for semi-automatic generation of adaptive applications for mobile devices,” Journal of Systems and Software, vol. 81, no. 3, pp. 382–394, 2008. Y. Choi, J.-S. Yang, and J. Jeong, “Application Framework for Multi Platform Mobile Application Software Development,” in Intl. Conference on Advanced Communication Technology (ICACT), 2009, pp. 208–213. M. Cimitile, M. Risi, and G. Tortora, “Automatic Generation of Multi Platform Web Map Mobile Applications,” in Intl. Conference on Distributed Multimedia Systems (DMS). Knowledge Systems Institute, 2011, pp. 84–89.
