Keywords

1 Introduction

Applications running on mobile devices are becoming so popular that they are representing a revolution in the IT sector [1]. A mobile platform consists of various source codes to control a microprocessor and hardware. Mobile applications include various software that uses APIs supported by a mobile platform [2]. This paper presents a development method to help software engineers to improve productivity and quality of mobile applications.

In Sect. 2, we present general background information regarding mobile applications development approaches. In Sect. 3, we introduce the characteristics of mobile applications. Then we present a development method in Sect. 4. We apply our method to an application example in Sect. 5. Finally we come to a conclusion in Sect. 6.

2 Related Methodologies and Development Approaches

There are many preexisting approaches to developing mobile applications, in this section we are going to discuss some of the more notable ones and compare them to our approach.

Kraemer [3] details his approach which focuses on limiting complexity and development time. To that end he suggests the use of libraries and tools that are highly extensible. These tools successfully reduce development time and complexity, especially for novice programmers or those new to mobile development. However, third party tools carry inherent risks in addition to their benefits. They sacrifice reliability because they are not supported and can break easily. As Kramer notes, mobile platforms release new versions often. Even with careful consideration this can lead to instability, especially in tools that are extensible. Because of this we suggest a method that does not rely on third party tools or libraries.

Dehlen and Aagedal [4] propose a unique mobile deveolpment method that focuses on mobility. Their proposition is that mobile applications should be aware of the devices movement at the physical, logical, and network level. Many applications would benefit from such an architecture, however not all applications would. Self-contained application, those not requiring network access at all, as well as applications that require little location awareness such as solely GPS, would see little, if any, benefit from such an approach. Thus, this method will add unnecessary complexity to many mobile applications. Whereas our approach is heavily focused on simplicity, and universal applicability. Finally in most modern mobile platforms the operating system handles all location information. Applications need only query the operating system to acquire the necessary information. Rarely if ever do applications need to manipulate such information since it’s handled by the OS.

Another useful approach given by Parada and Brisolara [5] provides specifications for developing Android applications. This approach use models to solve the problems of code efficiency and development time. Similar to the approach of Kraemer [3] this method uses code generation and tools. Which, while extremely useful, can lead to issues with reliability. Also this approach focuses solely on the Android operating system and is not an adequate approach for all mobile platforms.

A fourth approach presented by Balagtas-Ferrnandez and Hussman [6] explains how novice programmers may be put off by development because of the inherent level of difficulty. To solve this problem they have created a tool called the MobiA modeler [6]. A cross-platform tool which is excellent for beginning developers, the MobiA however has the same pitfalls as previously tools, specifically with Kraemer as well as Parada and Brisolara’s approach. Because the tools are platform agnostic however, they prevent the user from having a native experience on their device, something which even web applications struggle with [7].

Given the rapid nature of mobile platform evolution and the lack of formal research into mobile engineering technologies, it should be no surprise that new and varied approaches to development are necessary [8]. Our approach is unique in that it focuses on simplicity without sacrificing reliability, and universal applicability without sacrificing a native user experience. We also expect our approach to have more longevity than other methods due to the high level nature.

3 Characteristics of Mobile Applications

There are two kind of traditional mobile applications: web-based applications and native applications. Web-based applications consist of web pages optimized for mobile devices and can be developed by using HTML, JavaScript and CSS. They usually run on a server. Native applications are developed for specific mobile devices. They can access the functionalities of mobile devices, such as GPS, file storage, databases, SMS, mail box and etc. They can be downloaded, installed, and sold in applications store [9]. In this paper, mobile applications refer to native mobile applications.

Mobile devices, in particular smart phones, have been popular in our life. Mobile applications are different from the desktop applications because smart phone devices are resource-limited embedded systems and are developed separately on different development platforms with different operating systems such as RIM of Blackberry, Windows Phone, iOS, Symbian, and Android [10]. In addition, mobile applications are developed in small-scale, fast-paced projects to meet competitive market demand [11].

Development of mobile applications with Android requires Java programming language using the Android SDK which provides the tools and APIs necessary for development [12]. An application is packaged as an Android application. Figure 1 shows the Android applications architecture.

Fig. 1
figure 1

Android system architecture

Full size image
Fig. 2
figure 2

A development phases for mobile applications

Full size image

4 A Development Method for Mobile Applications

We propose a development method for mobile applications, which includes five phases: requirements analysis, architecture design, navigation design, page design, and implementation and testing. Figure 2 shows the entire development cycle. This process model is iterative between phases to support feedback.

4.1 Development Phases

Requirements Analysis. Developers define the goals and functions of the mobile applications. The purpose of the requirements analysis phase is to analyze the application domain through the viewpoint of users. In this phase, developers define the target users who will use the application. They also analyze the contents and functions, constraints, and who is going to provide the new content. The product of this phase is requirements specification.

Architecture Design. Developers determine the most suitable architecture according to the result of the requirements analysis phase. Developers divide the application domains into sub-applications. Well-defined architecture can reduce the complexity of the system and provide the work boundaries for developers. The product of this phase is the architecture design diagram.

Navigation Design. Developers define navigation relationships between pages (screens of smart phones) of the mobile applications. The navigation relationship includes the link relationship and data migration between the pages and makes the mobile applications different from general applications. The mobile applications program generally consists of more than one page. Users of applications navigate the pages to retrieve some information or to accomplish what they want to do. The product of this phase is the navigation design diagram.

Page Design. Developers design the screen layouts and functions for all of the pages. The pages can be classified into static pages and dynamic pages according to their functions. The function of static pages is to show their contents. The function of dynamic pages is to accomplish tasks such as data processing or accessing databases. The products of this phase are the page detail design diagrams.

Implementation and Testing. The analysis and design specifications can be implemented in a straightforward manner by programming all of the page detail design diagrams. The behavior of the mobile applications must be tested on the emulator and on the mobile device because the applications on an emulator may perform differently from them running on a mobile device with various hardware and software versions [13].

4.2 Graphic Notations

Our method provides program developers with two main notations, the component and the connector. Components represent the functional modules of the system while connectors represent the interactions between components. Figure 3 represents the notations of the diagrams for modeling mobile applications

Components in the diagrams are classified into the architecture component, the page component, the passive component, the active component, the database component, the group component, and the condition component.

The architecture component is used to represent the structure of applications in the architecture diagram and represents a function of an application. The page component represents a page in the navigation design diagram. The passive component represents a static functional module. The active component represents a dynamic module. The database component represents a data repository. The group component can be used to combine a set of components into one group of functions. The condition component is used to specify a condition. All of these components are used in the page detail design diagram.

Fig. 3
figure 3

Graphic notations for design diagrams

Full size image

Connectors in the diagrams are classified into the general link, the indirect link, the direct link, the data link, the DB link, and the sequence link.

The general link represents the existence of any relationships between two components in the architecture design diagram. The indirect link and the data link represent the transitions occurred by a user’s clicking on a button. The indirect link does not contain a data transmission between two components. But the data link contains a data transmission between two components. The direct link represents an automatic page link in the applications program. The Database link represents a data transmission between a functional module and a database. The sequence link represents the sequence of the activation of components. The Database link and the sequence link are used in the page detail design diagram.

4.3 Diagrams

The following three kinds of diagrams are produced after we analyze and design an application:

  • The architecture design diagram

  • The navigation design diagram

  • The page detail design diagram

The Architecture Design Diagram. The architecture of software is defined by computational components and interactions among components. The well-defined structure makes it easy to integrate and maintain the parts of a large application. The architecture design diagram shows the vertical and horizontal structure between functions of applications and does not include the information about the detail algorithms.

The Navigation Design Diagram. The most important characteristic of mobile applications is the navigation feature. Because mobile applications consist of pages (for example, one screen form of a smart phone), users of the applications have to explore pages to search for information or accomplish what they want to do.

The navigation design diagram represents the navigation relationships among pages. It shows the link relationships and data transformation among pages.

The Page Detail Design Diagram. The page detail design diagram represents each page in detail. The pages are classified into static pages or dynamic pages according to their tasks. Some pages may include the characteristics of both.

The static pages display their contents and are described by the design patterns. On the other hand, the dynamic pages perform some tasks and are described by the functional flows to represent the algorithms for the tasks.

5 Mobile Application Example: Location a classroom

We apply our method to developing a mobile application that provides the information about the locations of classrooms. It requires a classroom number as an input from users, and then shows the information about the location of the classroom. Figure 4 shows the application development environment supported by Android and Eclipse.

Fig. 4
figure 4

Application program development environment

Full size image

Figure 5 shows the architecture design diagram for the main starting page. Here you can see the simplicity and high level nature of our method. The application includes two computational components: Search and Exit. The component Search is processed by the two components, Success and Failure, checking the validation of the input from users. The architecture design diagram includes architecture components and general links.

Fig. 5
figure 5

The architecture design diagram

Full size image

If users enter a correct classroom number, the information system prints its location. If they don’t, it prints failure message. The component Exit includes the procedures for users’ exiting the information system.

Figure 6 shows the navigation design diagram for the architecture design diagram in Fig. 5. Figure 6 represents the navigation relationships between pages for the application by using the page component, the direct link, the data link, and the database link. The component in this diagram is concretized in the page detail design diagram.

Fig. 6
figure 6

The navigation design diagram

Full size image

Figure 7 shows the page detail design diagram for Fig. 6. Figure 7a is the screen layout of the start page of the application. It shows users two button types, Search and Exit, at bottom. These can be implemented differently for different OS allowing for a native user experience while maintaining a simple design diagram. The position of input that users enter a classroom number is above two buttons. The result of users’ query is printed at top. A graphic image is displayed between the result and the input. Figure 7b represents the functional flows of the function “Search”. It is operated by pressing the button Search.

Fig. 7
figure 7

The page detail design diagram. a The design patterns b The functional flows

Full size image

Comparison of our approach with other mobile development models shows advantages in the areas of simplicity and elegance as outlined by the above figures and explanations. Also see Sect. 2 for more detailed information about the differences between our proposed method and preexisting methods.

6 Conclusions

Mobile devices, in particular smart phones, have been popular in our life. So, mobile applications are necessary for providing smart phone devices with functionalities for mobile data services. We present a development method to help software engineers to improve productivity and quality of mobile applications. It consists of five phases: requirements analysis, architecture design, navigation design, page design, and implementation and testing. We applied our method to an application example, and the results were found to be promising.

Further research should consist or analytics measuring the appropriate quality attributes for mobile development using our method compared to established methods. We expect to find improvements in the areas of simplicity, reliability, performance, and the native user experience . We further hypothesize that there is significant overhead created by using general purpose development models, specifically UML and third party tools, which may negatively impact performance.