Considerations on developing mobile applications based on the ...

Considerations on developing mobile applications based on the Capuchin project ∗ Marcio E. F. Maia, Claysson Celes, Rute Castro, Rossana M. C. Andrade Group of Computer Network, Software Engineering and Systems Universidade Federal do Ceara Campus do Pici S/N, Bloco 942-A, Fortaleza CE, Brasil. 60.455-760. Phone: +55 85 3366 9797

{marcio,claysson,rute,rossana}@great.ufc.br ABSTRACT

forward development of mobile applications, Java Micro Edition (JME) [5] is a natural solution. JME has innumerous benefits, such as a vast range of extensions on the language through the use of JSRs, solid runtime debugger and considerable development tools support. Although JME is a mature language for developing mobile applications, it offers limited support for user interface (UI) development. On a different path, Adobe’s Flash Lite [3] is tailored to develop rich UI for mobile applications. Flash Lite animations are created using standardized and intuitive tools, primarily directed towards designers. Using a Flash scripting language called ActionScript [1], user interface can interact with services present on the device. However, compared with JME, ActionScript access to phone services is limited and inefficient. To bring together the advantages of both JME and Flash Lite, Sony Ericsson’s Capuchin project [4] permits the creation of interactive mobile applications, using Flash Lite to implement the user interface and JME to implement application core. Since each language has specific characteristics, the use of Flash Lite and JME in a single application has risen design issues that must be dealt by software engineers. One important decision is how to divide application functionalities between Flash Lite and JME, considering non-functional requirements such as performance or security. Other issues like maintainability and reusability may influence the way Capuchin-based applications are designed. To guide software engineers design mobile applications, this paper presents a development process for interactive Capuchin-based mobile applications. The goal is to specify predefined steps that considers the benefits of both Flash Lite and JME, as well as non-functional requirements of these applications. The remainder of the paper is divided as follows. Section 2 presents an overview of the Capuchin project, and section 3 describes the characteristics of both Flash Lite and JME, highlighting their benefits and disadvantages. Whereas section 4 details the development process for Capuchin-based mobile applications, followed by a case study in section 5. On section 6 is presented some conclusions and future work.

The development of applications for mobile devices is becoming increasingly popular, with manufacturers struggling to support different programming environments and embedding libraries on their devices. In this pursuit for a straightforward development of mobile applications, Java Micro Edition (JME) is a natural solution. Although JME has innumerous benefits, it offers limited support for user interface (UI) development. On a different path, Adobe’s Flash Lite is tailored to develop rich UI for mobile applications. To bring together the advantages of both JME and Flash Lite, Sony Ericsson’s Capuchin project permits the creation of interactive mobile applications, using Flash Lite to implement the user interface and JME to implement application core. The use of Flash Lite and JME in a single application has rised design issues that must be dealt by software engineers, such as performance, maintainability and reusability of both Flash Lite and JME programming languages. To guide software engineers design mobile applications, this paper presents a development process for interactive mobile applications based on Capuchin project. To validate it, a mobile application is developed based on this process, and relevant topics of the process are discussed.

Categories and Subject Descriptors D.2.13 [Reusable Software]: Reuse Models

Keywords Mobile application development, Flash Lite, JME, Capuchin

1.

INTRODUCTION

The development of applications for mobile devices is becoming increasingly popular, with manufacturers struggling to support different programming environments and embedding libraries on their devices. In this pursuit for a straight9∗Capuchin project is a property of Sony Ericsson

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’10 March 22-26, 2010, Sierre, Switzerland. Copyright 2010 ACM 978-1-60558-638-0/10/03 ...$10.00.

2.

CAPUCHIN PROJECT OVERVIEW

The Capuchin project permits the development of mobile applications, using Flash Lite to implement user interface and JME to develop application core. To implement applications using both technologies is possible because Capuchin offers mechanisms to exchange information between Flash

575

Lite and JME [4]. Information is exchanged between Flash Lite and JME using two data transfer mechanisms, namely DataRequest and ExtendedEvent. The former permits Flash Lite UI to request information from JME, and the response is sent asynchronously. To execute this request, JME can use any service available on the phone, such as JSRs. Additionally, the ExtendedEvent mechanism allows JME to notify Flash UI of events occurring on the phone.

Algorithm 3 Flash ExtendedEvents subscription [4]

2.1

On the JME side, a F lashEventM anager interface must be implemented. It has a method called addEventListener, invoked when an Flash event is detected (see algorithm 3, procedure f lashExtendedEvents). Algorithm 4 has the addEventListener implementation and the Flash UI notification of an event by JME.

procedure f lashExtendedEvents() var eventListener : Object = newObject(); ExtendedEvents.CapuchinEvent.addListener(eventListener); end procedure procedure f lashExtendedEvents listener() myEventListener.onEvent = f unction(receivedT ext){ myM ovieClip.textBox = receivedT ext; } end procedure

DataRequest

The DataRequest mechanism is useful when Flash UI proactively requests JME execution. Using this approach, information can be sent in both directions, from Flash user interface to JME application core, and in the opposite direction. Algorithm 1 shows the Action Script code to access JME services and to receive the execution response. In this algorithm, the f lashDataRequest procedure initializes a DataRequest class with a parameter called greeting.

Algorithm 4 Flash ExtendedEvents notification [4] procedure addF lashEventListener(name, eventContent) if (name.equals(”CapuchinEvent”)) capuchinEventListener = eventContent; endif end procedure procedure jmeExtendedEvents notif ication() String[]str = newString[]{”HelloW orld again!”}; capuchinEventListener.handleEvent(str); end procedure

Algorithm 1 Flash Lite DataRequest invocation [4] procedure f lashDataRequest() var myDataRequest = new DataRequest(”greeting”); myDataRequest.request(); end procedure procedure f lashDataRequest result() myDataRequest.onLoad = f unction(success : Boolean){ myM ovieClip.textBox = myDataRequest.greetingT ext; }; end procedure

The FlashEventListener object in JME has a handleEvent method, which is responsible for notifying the Flash UI of an event. jmeExtendedEvents notif ication procedure shows JME notifying Flash UI of an event of type CapuchinEvent.

The myDataRequest.request(); line is responsible for sending the request to JME. The response is accessed using the f lashDataRequest result procedure. On the JME side, algorithm 2 shows the dataRequested procedure, which is executed when a request method from a DataRequest class is executed on the Flash side. The dataRequested procedure shows JME handling the Flash request. JME programmers must handle different requests in this same dataRequested method. To do so, the name of the DataRequest must be known by the programmer. In this case, myDataRequest parameter from f lashDataRequest procedure is called ”greeting”. The dataRequested procedure sets ”HelloW orld!” to the ”greeting” DataRequest. Then, it calls the ”dr.complete()” method to notify the Flash UI that the execution is finished.

2.3

3.

Algorithm 2 JME DataRequest execution [4]

FLASH LITE/JME DIVISION

To help software engineers decide what should be implemented in Flash and JME, it is important to understand the strengths and weaknesses of each programming language. Additionally, issues such as performance constraints and quality requirements may also influence this decision.

procedure dataRequested(F lashDataRequest dr) dr.setP roperty(”greetingT ext”, ”HelloW orld!”); dr.complete(); end procedure

2.2

Considerations on data transfer mechanisms

Using DataRequest and ExtendedEvent approaches, Flash Lite and JME developers must agree on the name of the parameters, their types and format, and the number of variables that is shared between these two technologies. This agreement must be incorporated into the development process of Capuchin applications. For example, one of the arguments in favor of the Flash/JME division is to facilitate the reuse of Flash UI and application core [4]. This is only true when information about the syntax and semantics of Capuchin data and events is available along with the code that is going to be reused.

ExtendedEvents

3.1

The ExtendedEvents mechanism permits JME to notify Flash Lite UI of events occurring on the phone. In order to receive these events, Flash UI defines one listener object for each type of event. When an event is detected on JME, the correct listener is chosen to notify the Flash UI. Algorithm 3 shows the Flash UI subscription on an event called CapuchinEvent (procedure f lashExtendedEvents). The onEvent method in f lashExtendedEvents listener procedure is invoked by JME when the CapuchinEvent is generated.

Flash strengths and weaknesses

Flash was initially designed to permit the development of rich user interfaces for web applications. When a lighter version, called Flash Lite, was ported to mobile devices, it gave to developers the benefits of using Flash to create rich UI. The use of Flash Lite in mobile devices permitted web designers, experienced in the Flash programming language, to develop rich user, interfaces for mobile applications. Capuchin API support the development of flash interfaces using Adobe CS3 [2], which increases considerably the devel-

576

oper productivity. Other advantages are the low complexity to create animations using Flash, and the support for vector graphics. The use of Flash, however, has also its weaknesses. The use of Adobe CS3 increases developer productivity, but at a cost to the enterprise associated with its license. Another drawback of CS3 is the lack of developer customization. Flash Lite also lacks runtime debug support. It is not possible to monitor memory allocation and execution performance on the device as the application is executing. Perhaps the most serious problem that Flash Lite developers face is performance. Flash Lite code executes much slower and consumes more resources than other programming language for mobile devices. Thus, software designers must consider carefully non-functional requirements when defining what should be implemented in Flash. Another drawback of Flash Lite is that it lacks dynamic library deploy and undeployment support, and all libraries must be loaded at development time.

the application. The benefits are the improvement of development productivity and application quality, since these components have already been tested and used in real applications, and most of the errors have been identified and corrected.

3.2

The quality attributes of an application may help decide what parts should be implemented in JME and Flash. The quality of an application can be analyzed according to three attributes, namely maintainability, reusability and readability [7]. The readability attribute is more dependent on the coding style used by the developer, than exactly an attribute of the language itself [12]. The development paradigm used by the Flash and Actionscript languages is a little different from the traditional programming languages like JME or C/C++. The Flash language has concepts such as Movie clips and Frames that are not common to other programming languages, and developers that are not familiar with the Flash paradigm may not feel comfortable. One construct that must be used with special care is the goto statement, since it could considerably increase the complexity to understand and maintain the code, and difficult its reuse. The overall quality of an application, considering the maintainability and reusability attributes, is strongly influenced by the entire development process. However, one good indicator is to analyze characteristics of the Flash and JME languages themselves to identify differences that may result in gain or loss of quality in the application. Sant’anna [10] presents a framework to analyze the maintainability and reusability of an application. According to this framework, quality of an application is more influenced by its design, than the programming language itself. Nevertheless, the coupling metric, that measures the strength of the connections between components, might present higher values in Flash than in JME, since the visibility of inherited class variables and methods is higher. In Flash, by default, all attributes are public and all inherited methods and class variable are always visible. Whereas in JME, methods and variables are visible, by default, only inside the same package, and inherited members are only visible if declared as protected.

3.3.3

3.3.4

JME strengths and weaknesses

Most of Flash weaknesses are JME strengths. JME introduces a considerable performance gain, mainly in floating point operations, and has stronger security guarantees. Thus, it is up to the software engineer to identify parts of the application with performance requirements or security issues and design it to be implemented in JME. JME also has a solid runtime debugger, where it is possible to developers and testers to monitor memory allocation and processor load at runtime. Another advantage of JME is its the number of extensions permitted on the language through the use of JSRs. JME also permits runtime library deployment and undeployment to create adaptable applications. Most of the development tools for JME are free. However, the drawback of developing user interfaces using JME is what motivated the migration of Flash from the web to mobile devices.

3.3

Influencing factors

Although it is not possible to create a classification of the functionalities that should be implemented in Flash and JME, analyzing the strengths and weaknesses of each technology gives a starting point to make that division. Clearly, it is reasonable to implement the UI using Flash, since that is the its main advantage over JME. Additionally, any service provided by the JSRs should be implemented in JME.

3.3.1

Performance and security issues

The functional and non-functional requirements shall define the Flash/JME division. Performance is the first issue that should be considered, and JME is considerably more efficient in terms of performance and resource consumption. Therefore, any functionality with performance restrictions should be implemented in JME. All security measures should be implemented centralized in a single component using JME, since centralization increases security guarantees and JME implements more reliable security mechanisms.

3.3.2

Runtime deployment

Context-aware and adaptable applications require a mechanism to describe and dynamically discover and deploy libraries from the environment. Depending on the adaptation level required by the application, the functionalities are divided into Flash Lite/JME components. Thus, the first step is to identify what is subject of change during the execution and implement it using JME. Functionalities that are not subject to runtime change, and do not face performance constraints, must consider other aspects such as maintainability, reusability or readability.

3.3.5

Flash/JME application quality attributes

Organizational relevant issues

Organizational issues may influence the decision between Flash and JME as well. For example, an organization with a long history of projects developed in Flash, with designers and developers experienced in this technology, may decide

Reuse existing components

Existing Flash and JME components can be reused in

577

to continue developing applications mainly in Flash, and minimizing the use of JME. Other important issues like cost and time to market should be considered.

4.

DEVELOPMENT PROCESS OF CAPUCHIN APPLICATIONS

The main characteristic of Capuchin applications is user interaction. Thus, it is a natural step to design these applications using the MVC architectural pattern [11]. According to this pattern, The View component is responsible for displaying information to the user, whereas the Controller component handles user input and the Model component encapsulates business logic and data handling actions. The question that remains is how to divide the Model, View and Controller components between Flash/Actionscript and JME programming languages. To start with, the developer should consider three key points, namely the strengths and weaknesses of each technology, described in sections 3.1 and 3.2, the Flash/JME influencing factors, detailed in section 3.3, along with the non-functional requirements of the application. With these points in mind, the software engineer can now consider the properties of developing regular MVC applications, together with specific characteristics of the Capuchin development process.

4.1

4.3

Flash/JME division and data transfer format specification

With the core functionality fully specified, and all nonfunctional requirements well understood, it is time to define what should be implemented in JME and Flash. This definition is guided by the factors discussed in section 3. Once the division is clearly defined, the Flash/JME interfaces are identified. The next step is to define the communication mechanism to exchange information between Flash and JME. Regardless of which data transfer mechanism is to be used, Flash and JME developers must agree on the exact name, type and number of parameters being exchanged. To minimize communication problems between designers and developers, a mechanism to describe these data formats can be used [8].

4.4

Application requirements elicitation and user interface draft

Implement the controller and model components

Once the Flash and JME interface is delimited, the Controller and Model components can be implemented. The Controller components, responsible for handling user input and output, should implement the interfaces that are accessed by the View components. Each View must have one Controller component associated to it. Additionally, the Model component is responsible for the application core functionality and data handling actions. One of the advantages of implementing the core functionalities of mobile applications using JME is that any middleware available can be used [9].

As any conventional application, the development process starts by gathering, understanding and documenting the application requirements. Hence, with the functional and non-functional requirements clearly defined, the architecture design process starts. Considering these requirements, the software engineer must separate human-computer interaction from core functionality. Once the human-computer interface is defined, the UI draft can be developed and user input and output is identified. At this point, Flash UI implementation and test, and Controller/Model development can be performed in parallel.

4.2

the Controller, without any impact on the Views. If the View component directly interacts with JME, it would increase the complexity to maintain and reuse these user interfaces (Views). The reuse is compromised since it would only be possible when the JME core receives and responds using the same data transfer and extended events format. Additionaly, any maintenance modification in the data transfer mechanism would impact on the View component.

5.

CASE STUDY

In order do validate the development process proposed in this paper, a Capuchin application was implemented. It basically informs to the user the weather in a given city. The fonts and executables can be downloaded from http://www.great.ufc.br/marcio/weatherInfo.tar.gz. ˜ The user interacts with the application by typing in the name and country of the city. Weather information is retrieved by accessing a web service at www.webservicex.net/WCF/ServiceDetails.aspx?SID=48. This web service is called Global Weather. It receives as input parameter city information and returns an XML file containing information about temperature, wind velocity and direction, pressure, humidity, date and time. The information about the weather is then presented to the user. Depending on this information, the layout of the UI is adapted. For instance, if the temperature is bellow 0 ◦ C, the background of the application shows a snowy day image. If the temperature is above 35 ◦ C, it shows an image of a sunny day. Once the functionality is defined, Flash UI can be developed. Clearly, two views can be identified. One to inform the city and country to obtain weather information from, and another to present this information.

Implement and test the View component based on Flash UI

The View component, based on Flash user interface, can now be developed using all tools offered by Adobe CS3. Additionally, the testing process can be performed by reading dummy values from an external file using Actionscript. To test interactive mobile applications should consider the constraints and characteristics of the mobile devices [6] At this phase, the input and output actions are already defined. To minimize the coupling between the View and Controller components, and facilitate the reuse and portability of the Flash UI, the View component should interact exclusively with interfaces from the Controller component implemented in Actionscript. The actual implementation of these interfaces is left to be defined later, either using Actionscript or JME. This approach has a couple of benefits. Firstly, it permits the entire interface to be reused in other applications or devices, even on applications developed entirely using Flash, permitting the creation of UI components. Secondly, it minimizes the coupling between Views and Controllers. It permits an easy maintenance and replacement of input/output response in

578

Each view has one controller associated to it. One to obtain weather information and another to deactivate the second view and activate the first one. At this point, it is known that the application requires an invocation to a remote web service. Independently of how this invocation should be implemented, the UI can be implemented and tested. To do so, the view receives weather information in a specific format. Algorithm 5 shows the Action Script code to implement the controller responsible for handling user interaction, in this case, requesting weather information. This interface is important because it separates the UI components (View) from the controller and model components, and facilitates UI reuse and maintenance. Now, an important design-time decision must be made. The interface implementation to invoke the web service should use either JME or Action Script. This decision is made based on the issues highlighted in section 3. The application implemented for this study case chose to invoke the web service using JME. Firstly, JME has a programming environment that supports web service invocation more easily. Secondly, XML parsing is executed more efficiently in JME. The actual implementation of the model component is shown in the requestService procedure from algorithm 5. This procedure calls a method named weatherDataRequest. In this method, the DataRequest mechanism is used to access JME. In another situation, where the JME service might not be available, this interface could be implemented using Action Script.

development of mobile applications is the Capuchin project. This project permits the creation of these applications using Flash Lite to improve the development of rich user interfaces and JME to implement efficient application core. This paper presented an overview of the Capuchin project and discussed issues that drive the division of functional requirements between Flash Lite and JME. Additionally, it showed an initial development process for mobile applications based on the Capuchin project. As future work, this development process is going to be extended and detailed, introducing testing requirements for mobile applications, presenting a performance comparison between Flash Lite and JME, analyzing the differences between these programming languages that affect quality attributes like maintainability and reusability. The goal is create a development process that considers all phases of the development of applications using the Capuchin API.

7.

REFERENCES

[1] Adobe actionscript. http://www.adobe.com/devnet/actionscript. Accessed in June 18th 2009. [2] Adobe creative suite. http://www.adobe.com/products/creativesuite/. Accessed in June 18th 2009. [3] Adobe flash lite. http://www.adobe.com/products/flashlite/. Accessed in June 18th 2009. [4] Sony ericsson, project capuchin information document. http://developer.sonyericsson.com/getDocument.do?docId=100351.

Accessed in June 18th 2009. [5] Sun java. http://java.sun.com/. Accessed in June 18th 2009. procedure requestService(country, city) [6] Testing requirements for mobile applications. In weatherDataRequest(country, city); end procedure Proceedings of the Special Session on Software procedure weatherDataRequest(country, city) Validation & Verification (V&V), 24th International var myDataRequest = newDataRequest(country, city); Symposium on Computer and Information Sciences myDataRequest.request(); end procedure 2009. [7] D. Coleman, D. Ash, B. Lowther, and P. Oman. Using metrics to evaluate software system maintainability. The myDataRequest.request() command triggers an JME Computer, 27(8):44–49, Aug 1994. method called dataRequested. This method is shown in [8] K. Fisher, Y. Mandelbaum, and D. Walker. The next algorithm 6. It invokes the web service, parses the XML 700 data description languages. SIGPLAN Not., with the response, sets the weather information into the 41(1):2–15, 2006. DataRequest variable to be accessed under the name ”infor[9] M. E. Maia, L. S. Rocha, and R. M. Andrade. mations” and notifies the FLash UI using the dr.complete(); Requirements and challenges for building command. It is important to mention that the weatherInf o service-oriented pervasive middleware. In ICPS ’09: message sent from JME to Flash Lite has an specific format Proceedings of the 2009 international conference on that it is understood by the Flash UI. Pervasive services, pages 93–102, New York, NY, USA, 2009. ACM. Algorithm 6 JME handling DataRequest for web service [10] C. Sant’anna, A. Garcia, C. Chavez, C. Lucena, and invocation A. v. von Staa. On the reuse and maintenance of procedure dataRequested(F lashDataRequestdr) aspect-oriented software: An assessment framework. String[]is = dr.getArgs(); weatherInf o = webService.invoke(is) In Proceedings XVII Brazilian Symposium on Software dr.setP roperty(”inf ormations”, weatherInf o); Engineering, 2003. dr.complete(); [11] D. C. Schmidt, H. Rohnert, M. Stal, and D. Schultz. end procedure Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects. John Wiley & Sons, Inc., New York, NY, USA, 2000. 6. CONCLUSIONS AND FUTURE WORK [12] D. Spinellis. Reading, writing, and code. Queue, 1(7):84–89, The development of mobile applications has gained spe2003. cial attention lately. One initiative to allow a more efficient Algorithm 5 Flash request to JME

579