Towards end-user development of REST client applications on smartphones

Gebremariam Mesfina, Tor-Morten Grønlib, Dida Mideksoc, and Gheorghita Ghineab,d

aAddis Ababa University, mesfin.assres@gmail.com, Addis Ababa, EthiopiabWesterdals Oslo ACT,Faculty of Technology, tmg@westerdals.no, Oslo, Norway

cAddis Ababa University, mideksod@yahoo.com, Addis Ababa, Ethiopia dBrunel University, george.ghinea@brunel.ac.uk, London, UK

Abstract

Our previous work on the evaluation of a small cross-platform Smartphone application showed that its usability remains unaffected on the respective native platforms and the SDKs require only minimal configuration effort for adaptation. However, the evaluation process needs to be scaled up by incorporating higher level REST-based cross-platform application. The literature indicates that HTML5 can be used to develop client applications by composing REST web services within the context of Web 2.0. However, the possibility of implementing cross-platform Smartphone applications with REST services needs to be studied. In the study underlying this paper, we developed a REST-based cross-platform application with PhoneGap. The application was deployed on the Android, Windows Phone, and iOS platforms; subsequently we evaluated its usability. The evaluation was conducted focusing on the developer’s adaptation effort to native platforms as well as on the end users. Accordingly, we observed that REST-based cross-platform Smartphone applications can be implemented with HTML5 and PhoneGap, which can be scaled-up into a REST service composition (web mash-up) tool. In addition, the usability of the application remains unaffected on the native platforms and adaptation required only minimal effort, mainly for the configuration of the respective SDKs.

Keywords: REST service; Usability; PhoneGap; Android; Windows Phone; iOS; Service Composition; Smartphone; Cross-platform

1. Introduction

Smartphones play a very important role in life, being used in education, healthcare, and business, to name but a few application areas. smartphones may be described as mobile phones with increased capabilities, such as touch

screen, intelligence and alertness. For the purpose of this study, we consider smartphones to boast features as described in (Liane, 2013); hence we define smartphones as mobile phones that are capable of accessing the Internet and of running a variety of mobile operating systems such as Google’s Android, Microsoft’s Windows Phone, and Apple’s iOS.

On top of the operating system, smartphones are equipped with software development kits (SDKs) that enhance the characteristics of smartphone application software and configurations such as reusability, and interoperability. Smartphone applications themselves can broadly be categorized into native and cross-platform based on the software development environments they are produced from. Native applications belong to one category of smartphone applications that are written and developed for a specific operating system. They have unhindered access to device hardware and support all user interface and interactions available in the respective mobile operating environment (William, 2013). Cross-platform applications, on the other hand, can be dedicated mobile web applications, generic mobile web applications (also called mobile websites), and hybrid applications (William, 2013).

In this study, by cross-platform we understand those dedicated mobile web applications which are designed to mimic the native applications of the host operating system but actually execute on a web browser. Such applications are implemented based on a web browser, using fundamental web technologies - HTML5, JavaScript, and Cascading Style Sheets (CSS).

Cross-platform smartphone applications can also be REST-based applications implemented by composing (mashing-up) REST web services. The REST web service belongs to the family of service-oriented architecture (SOA) implementation technologies. It is a client-server architecture designed to make HTTP-based stateless communication between the components of a composite application using URIs (Fielding, 2000). In terms of productivity and time to market, cross-platform smartphone applications are preferred to native ones. However, cross-platform smartphone applications are challenged by limitations in the user experience when deployed on native platforms (William, 2013).

Usability is defined in (ISO, 1998) as the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Evaluating the usability of REST-based cross-platform smartphone applications is also of paramount importance. Accordingly, in this paper we evaluate the usability of REST-based cross-platform smartphone applications on their respective deployment operating platforms, which is an extension of our previous work (Gebremariam et al., 2014).

The paper is structured as follows. Cross-platform smartphone application development, REST-based application development, and issues related to

usability oriented implementations with HTML 5 are discussed in sections 2, 3 and 4 respectively. A concrete comparison of usability of a REST-based cross-platform application on different platforms is presented in section 5. In section 6 we discuss our findings; finally, we draw our conclusions in Section 7.

2. Cross-platform Smartphone Applications

Smartphone operating systems are rich in libraries and built-in features. However, they still have to match and create a consistently high user experi-ence, irrespective of the fact that their basic architecture and support of pro-gramming languages varies. Studies such as that of Henning, Sebastian, and Tim (2013) make the point that the proliferation of a fragmented smartphone market with multiple operating platforms makes the development of native mobile applications a challenging and costly endeavor. To improve this, the literature and industry envision cross-platform development approaches.

The essence of cross-platform environments is a subset of the software de-velopment environments aiming at building platform independent applica-tions. Cross-platform application development environments work based on the general principle of “write once, and run everywhere”. In the smartphone application development, Dalmasso et al. (2013) described the general archi-tecture available to cross-platform mobile application development tools. However, as pointed out by Henning, Sebastian, and Tim (2013), the diverse hardware and software platforms inevitably make portability a hassle for mo-bile application developers. Portability primarily depends on runtime support and the feasibility of achieving identical look-and-feel and functionality across platforms.

There are several attempts of implementations of cross-platform smart-phone application development environments. For example, Java ME supports cross-platform development through configurations and profiles. Damianos and Daphne (2011) describe a configuration as the minimum Java VM fea-tures and library set for devices with similar processing and memory limita-tions, user interface requirements, and connection capabilities, while a profile comprises libraries specialized in the unique characteristics of a particular device class.

In related work, Grønli et al. (2013) investigated the strengths and weak-nesses of the mobile application development ecosystem and pointed out that developer support has improved the performance of developer tools which provide a higher level abstraction of performance-critical third party libraries. However, cross-platform development environments are being challenged by the different implementations, immature platform support, as well as by the variety of devices and browsers; in contrast, platform-specific ones like Win-dows Phone, iOS, and Android benefit from being tightly integrated with their

respective operating system. Moreover, the work of Grønli et al. (2013) showed that there is better integration between the development environment and deployment devices on the platform-specific ones than that of the cross-platform environment. This indicates that the cross-platform application de-velopment is in its early stages.

Studies (Damianos and Daphne, 2011; Henning, Sebastian, and Tim, 2013; Isabelle et al., 2013) showed that cross-platform development tools are flour-ishing; they aim at addressing user experience, stability of framework, ease of updating, cost of development for multiple platforms, and the time to market of an application. When realized, the interests of many developers would be satisfied in terms of releasing applications for major mobile platforms and provide a consistent user experience across the platforms with minimal or no change to the original code. PhoneGap, Rhomobile, JQuery Mobile, and Xam-arin are some of the cross-platform mobile application development tools available.

In the work described in this paper, we employ PhoneGap because of its popularity (Isabelle et al., 2011; Manuel, Inderjeet, and Antonio, 2012). PhoneGap is an open source cross-platform smartphone application develop-ment tool developed by Adobe Systems Inc. under the Apache license. It pro-vides a toolbox for building native mobile applications using only HTML5, JavaScript and CSS (Isabelle et al., 2011; Manuel, Inderjeet, and Antonio, 2012). PhoneGap is quite popular among users mainly because of its flexibil-ity, straightforward architecture and ease of use. Its architecture is mainly composed of the Web application, PhoneGap, and the operating system, along with native Application Programming Interfaces (APIs - Fig. 1).

Fig. 1. Interfacing Layers of the PhoneGap Architecture

PhoneGap is a “wrapper” that allows developers to enclose applications written in known programming languages into native applications (Manuel, Inderjeet, and Antonio, 2012). That is, applications developed using Phone-

Gap are neither purely web-based and nor purely native and thus some layout rendering is done via web-view instead of the native language of the operating system; consequently there is a lack of support of HTML in some functions. PhoneGap does not provide its own IDE (integrated development environ-ment) to develop applications, but developers have to write the source code with an IDE and port their code into other IDEs such as the Eclipse for An-droid and XCode for iOS. Thus far, PhoneGap permits the creation of appli -cations for Windows Phone, Android, iOS, Bada, Symbian, and the WebOS operating systems.

In general, PhoneGap and other cross-platform development tools leverage device capabilities with the help of JavaScript APIs and generate the HTML code for presentation. However, the resulting code needs to be ported into specific operating systems like the Windows Phone, Android, and iOS so that they behave like native applications. In the following section, we provide an overview of these operating systems and their corresponding integrated devel-opment environments.

2.1. Windows Phone

Windows Phone is the smartphone operating systems advocated by Microsoft. In the latest versions of Windows Phone, smartphone applications are written in managed code by frameworks that support multiple languages such as C# from the Microsoft.NET environment. Windows Phone is primar-ily built with the Windows Phone SDK together with Silverlight and XNA add-ons on Visual Studio. XNA is employed for 2D and 3D games develop-ment while Silverlight is used to develop powerful and engaging interfaces. Programs created for Windows Phone are encapsulated into XAP files, which are packaged Silverlight applications (Grønli et al., 2013).

2.2. Android

Android is based on the Linux kernel and developed as an open source sys-tem platform. In addition to the operating system, Android provides a devel-opment environment to write managed code with Google’s Java libraries, and the Dalvik Virtual Machine for the smartphone applications to run on (eLinux, 2014).

The development environment enables rich multimedia, the use of 2D and 3D graphic libraries, a customized SQL engine for persistent storage, and 3G, 4G and WLAN network capabilities (Grønli et al., 2013). Eclipse and IntelliJ IDEA are two main vendors of software development tools for Android.

2.3. Apple iOS

iOS is an operating system for many of Apple’s devices including the iPhone. Its applications are written in an object-oriented programming lan-guage called Objective-C, which is an extension of the C language; they use a library called Cocoa Touch. Development for iOS requires a computer or a VMware running Mac OS. Xcode (Apple, 2013) is the most commonly used integrated development environment to write iOS applications. It includes an editor, analysis tool, iOS simulator, and the SDK (Grønli et al., 2013). Re-cently the release of a new programming language from Apple, Swift, may lead to changes in the platform, but for the time being both Objective-C and Swift are equally supported.

To summarize, the cross-platform applications development approach makes a significant contribution to the productivity of mobile application de-velopers. However, achieving an identical look-and-feel as well as an identi-cal functionality of applications (including REST-based ones) across target native platforms still needs to be clarified through further work - which we address in this paper.

3. REST-based Cross-platform Smartphone Applications

A REST web service, introduced by Fielding (2000), is a client-server ar-chitecture designed to make stateless communication with HTTP and includes the following set of principles: ─ Conceptual entities and functionalities are modeled as resources identified

by universal resource identifiers (URIs). ─ Resources are accessed and manipulated via standardized HTTP operations

(GET, POST, PUT and DELETE). ─ System components communicate with these standard interface operations

and exchange the representations of these resources. In REST, a single resource may have multiple representations; and the

communication is made through different states of resource representations by following the inter-links between resources.

3.1. Characteristics of REST Services

The REST web service views applications’ data and functionality from a resource perspective. They are declarative in that they focus on the description of the resources themselves, rather than describing how the operations are performed (Chii 2013; Cesare, Olaf, and Frank, 2008). REST web services are

easily accessible because the URIs representing the resources can be shared and reused by any application, and are self-descriptive.

Accordingly, REST web services are widely used to build Web 2.0 applica-tions and mashups (Cesare, Olaf, and Frank, 2008; Chii, 2013). Like web pages, they support caching in proxies, and gateways. Since, JSON is a light-weight, directly supported inside JavaScript, and human readable data ex-change language, we employ JSON for the client-server communication of the REST web services (Nurzhan et al., 2009; Mark 2011).

In general, the above mentioned set of principles encourages REST applica-tions to be simple, and lightweight. Hence, the REST approach is considered to be a good alternative to build flexible, scalable and loosely-coupled ser-vice-oriented architecture systems, and is what we employ in the study under-pinning this paper.

3.2. REST Services Composition

In the REST web service model, the system is seen from the perspective of resources. Thus, service composition focuses on web resources associated to Web 2.0 mashups and state transfer between candidate web services (Xinyang, Jianjing, and Ying, 2009). Zhao and Prashant (2009) describe a mash-up as a web application that combines data from multiple sources into a single integrated application, where the data could come from local databases or other sources from the Internet via different protocols such as HTTP, RSS, ATOM, and REST web services. Web mashups are limited to fetching data from remote sources while the REST web service composition involves up-dating or manipulating data sources.

3.3. REST Services Composition on smartphones

Modern smartphones are sensor-rich, boasting a high processing power, with larger storage capacity, and improved screen size, as well as having en-hanced connectivity and a variety of APIs; all these premises bode well for future smartphone applications development. Moreover, many of today’s smartphone applications are personalized (Jeff and Scott, 2012). However, they can do a useful job only if they communicate with one or more servers and access data. The best way to achieve this communication is through the composition (mash-up) of web services. To this end, the REST web service may be used to communicate and build other composite web services, mashups or applications for smartphones (Chen-Che, 2013; Narayana, 2006).

The above mentioned smartphone features in combination with the capabil-ity of REST services enable smartphones to capture and process large

amounts of information. For example, they can leverage the user community and software practitioners to expand the capabilities of smartphones so that they can host a number of state-of-the-art applications, such as peer-to-peer social networking, location-based services, collaborative environment, and data exchange (Chen-Che, 2013). However, the user experience of such ap-plications is dependent on the screen size of the smartphone (Zhang, 2005).

Given the enhanced functionality of smartphones, it is thus not unreason-able to anticipate that the smartphone screen real-estate will be used for the composition of REST web services (Chen-Che, 2013). That is, the possibility of developing applications with REST services on smartphones would turn the smartphone into a small development computer to ubiquitously browse and touch code. Nonetheless, consuming REST web services on the small screen real-estate requires an enhanced usability of the services; however, to the best of our knowledge, a real smartphone device has not been used as a software development, or REST-based service composition, environment.

Thus, in this paper, we illustrate the possibility of building a REST-based cross-platform smartphone application which would scale into an end-user cross-platform REST service composition (mash-up) tool for smartphones.

4. HTML 5 and Usability of REST Services

Previous work such as (Marino et al., 2013) indicates that HTML5 is used for a better user experience in the composition of REST services. Thus, in this section we describe fundamental issues related to usability, HTML5 technolo-gies, and the factors influencing the usability of REST web services.

4.1. Usability

Usability is one of the six quality characteristics of the ISO 9126 software quality model (ISO, 1998). It is defined as a set of attributes of software which bear on the effort needed for use and on the individual assessment of such use by a stated or implied set of users. Sommerville (2009) describes usability (user interaction) as the process of issuing commands and associated data to the computer system. User interaction has evolved from the command-line into a number of interaction styles which are easier to use, namely, direct manipulation with pointing devices, menu selection, form fill-in, command language, and natural language commands (Sommerville, 2009). Pressman (2001) also remarks that if a program is not user-friendly, it is often doomed to failure, even if the functions that it performs are valuable. Usability is thus an attempt to quantify user-friendliness and can be measured in terms of four characteristics:

The physical and or intellectual skill required to learn the system.

The time required to become moderately efficient in the use of the sys-tem.

The net increase in productivity (over the approach that the system replaces) measured when the system is used by someone who is moder-ately efficient.

A subjective assessment (sometimes obtained through a questionnaire) of users attitudes toward the system.

The usability engineering discipline, in general, is concerned with the de-sign, evaluation, and implementation of interactive computing systems for human use and the study of the major areas surrounding them (Eelke and Jan, 2001). API designs, on the other hand, are over-constrained by many require-ments that initially make satisfying all developers difficult; a few years of real-world use then flushes these mistakes out, leading to API evolution. Thus, an informed design of web service interfaces is important to ensure the effectiveness of developers (Beaton et al., 2008; Stylos, 2007) in terms of the levels of efficiency and rates of adoption. To this end, Beaton et al. (2008) emphasize the difficulty of meeting such API usability goals without having objective and empirical data to justify design decisions.

4.2. HTML 5

State-of-the-art web tools, namely, HTML5, JavaScript, and CSS3 have got considerable real world applications due to a number of new features such as application cache, local storage, web SQL and indexed database, online/off-line events management, and drag-and-drop. With a goal of enhancing usabil-ity, Marino et al. (2013) propose HTML5 as a visual programming environ-ment for the composition of services based on a dataflow paradigm. The au-thors were oriented towards web technologies to offer developers an inte-grated set of high-level tools to design and test new services via functional composition of available ones. Accordingly, Marino et al. (2013) proposed a tool called Visual Programming Service-Link (VisProSL), inspired by the user experience in HTML5, which is a mixture of:

Graphical actions and choices, for example the drag and drop of graphi-cal widgets and the connection of input-output links, and of

Interface coding, via the textual specification of the translation logic of data object types flowing through the input/output interfaces of the composed services.

Furthermore, the VisProSL environment capitalizes on a standardized JSON syntax of exchanged data objects and is oriented to REST web services (Marino et al., 2013).

4.3. Usability of REST Services on smartphones

Despite the demand for REST-based smartphone applications (Narayana, 2006), consumers have many usability challenges in understanding the techni-cal details of REST web services, connecting and setting the execution order during mash-up, and managing the manual operations (Fielding, 2000; Maleshkova, Pedrinaci, and Domingue, 2010). In addition, usability chal-lenges of REST web services due to the unique features of smartphones are also worth studying. Thus, an informed design decision of REST web services is important to ensure the effectiveness of developers (Beaton et al., 2008; Bygstad et al., 2008).

Previous studies (Beaton et al., 2008; Mandel, 1997; Pressman, 2001) show that usability engineering and associated principles can leverage usable sys-tem design, and many of the design techniques, and processes can be adapted to improve the usability of REST web services. However, although REST web services are characterized by their relative simplicity and natural suitabil -ity for the Web (Maleshkova, Pedrinaci, and Domingue, 2010), their use re-quires extensive manual effort, as will be described below.

4.3.1. Description of Web Resources

A web resource can be any physical object or an abstract concept that is important to be digitally represented, stored, referenced and exposed. It may have multiple different representations in a computer system due to the state of the resource itself and the path the client has taken through the application that uses the resource (Xinyang, Jianjing, and Ying, 2009). That is, each data item is handled as a resource, and each resource is an atomic data unit.

Roberto et al. (2010) also mention that the resource description framework (RDF) metadata can be used to describe and structure these web resources using domain ontologies. That is, their work is inspired by the possibility of enhancing usability through Web 2.0 concepts, but based on a semantic web data model.

However, there is a need for further investigation into how the lack of proper description of the web resources together with their representations and limitations impact upon the usability of the REST web services when imple-mented in a smartphone environment.

4.3.2. Uniform Resource Identifier (URI)

The URI is used to identify web resources, and to invoke HTTP commands (Roberto et al., 2010; Xinyang, Jianjing, and Ying, 2009). Almost all service descriptions (including the REST type) use URIs and HTTP methods for in-vocation and authentication (Maleshkova, Pedrinaci, and Domingue, 2010).

However, the diversity of services and actions observed in the SOAP web services must be mapped to resource representations in the REST web service counterpart with similar functionalities but offering more flexibility and ex-tensibility. This situation often results in REST applications using complex URI addressing schemes, thereby introducing usability challenges (Guido et al., 2010).

Thus, the impact of the URIs addressing scheme on the usability of REST web services during resource identification and invocation in the smartphone environment needs to be explored. This would include issues such as the need to design URIs with consistent naming schemes; aligning with the respective ontology of the target implementation domain, and setting an optimum bal-ance between the breadth and depth of the URI’s name space.

4.3.3. Uniform Interfaces

The use of standard HTTP methods for REST services has certain usability challenges (Maleshkova, Pedrinaci, and Domingue, 2010). Thus, developers prefer to define their own operations. This results in a larger portion of REST services being defined as conventional interfaces, disregarding REST princi-ples. This requires further study on the impact of limitations to incorporate domain ontologies in operation names on usability.

Similarly, parameters of the operations of REST services would signifi-cantly impact usability due to the fact that operations have varying configura-tion of their parameters. For example, many input parameters of web services, including the REST type, may be defined as optional values, default values, alternative values, and/or coded values. However, this variability of the pa-rameters together with the absence of data-types makes the transformation of inputs of one REST web service and outputs of the next in the invocation of mash-ups difficult for developers to predict (Maleshkova, Pedrinaci, and Domingue, 2010). Moreover, limiting the number of input parameters in an operation is of paramount importance in reducing complexity thereby enhanc-ing usability (Beaton et al., 2008).

Accordingly, addressing the limitations of current studies in failing to adopt a holistic view of usability of REST web services in general and particularly their suitability to be composed on the go with smartphones need to be ex-plored. This is the focus of the study at the heart of the research described in this paper, and which shall now be described in detail.

5. Comparison of Usability of a Cross-platform Smartphone Application

In this study, the usability technique described in section 4 is used to evalu-ate a REST-based smartphone application, with emphasis on the definition of usability in (ISO, 1998). Thus, our evaluation was focused on the extent to which the cross-platform application can be adapted and used by our sample end-users to achieve the specified goals with effectiveness, efficiency and satisfaction in the context of the target smartphone platforms.

The REST-based cross-platform smartphone application was developed with a design goal as described below and to meet expectations of common users (Carol, 2010). Accordingly, we applied convenience sampling to select our target group of users and evaluated the application’s usability.

5.1. A Description of the Application

As mentioned above, a REST-based application is developed using sample RESTful services on the server-side and a REST-based application on the client-side. RESTful services are developed in Java based on the Jersey and Jackson RESTful web service frameworks (Jackson, 2014; Jersey, 2014). These frameworks provide the “Path” annotation which enables to define the URI path of a resource. The Java construct in Fig. 2 shows use of the “Path” annotation at the class and method level which aggregates to define the URI of each service API.

Fig. 2. URIs Design using the Jersey and Jackson RESTful Service Frame-works

In addition, an Eclipse dynamic web project “WebContent/WEB-INF” folder contains the “web.xml” configuration file which provides a “<url-pat-tern>” XML element that allows defining the URL pattern of a REST web service. The complete URL of the REST service is therefore a concatenation of the host’s domain name, the URL pattern, and the URI of the specific re-source.

The client-side application, on the other hand, was initially developed to be tested on a desktop browser with JQuery and drag/drop plug-ins in HTML5 (See code listing on Appendix B).

Fig. 3. Architectural description of the Application

The application fetches a list of items from bid announcements floated by different organizations (see Appendix B.1) which is available as REST inter-faces in JSON format on their respective websites. Each item is described by name, description, quantity, unit price, and a link to the source of data. Ap-pendices B.2, B.3, B.4, and B.5 describe Java RESTful interfaces returning JSON data.

Fig. 4. User Interface of the REST-based Cross-platform Application

A full scale model of the application is intended to support CRUD opera-tions as shown in Fig. 3. However, given the time and resources available to us, and because it is sufficient for the purpose of this study, the current imple-mentation is partial. Hence, the application is designed to provide a data mash-up facility. In addition, it enables searching by taking item category and URIs as input; and presents query results (Fig. 4 and Fig.5).

Fig. 5. Query Results of the Application on Android Emulator

The basic features of the application used in the evaluation are the ease to learn, ease to use, and ease to remember of URIs in the composition (as dis-cussed in sections 3 and 4 above); search result navigation; platform configu-ration; and the SDK used. However, given that the scope of the implemented application is on data mash-up, the effect of other HTTP verbs and URIs pa-rameters with respect to usability is not included in the study.

5.2. Deployment of the Application on the Target Platforms

Initially, we developed the REST-based application for a desktop browser. It was tested against the required test cases and subsequently customized and adapted to the Android, Windows Phone, and iOS platforms.

Table 1 – Characteristics of the Android, Windows Phone, and iOS Applica-tions Development PlatformsFeature Android Windows Phone iOSDevelopment Language Java (Android SDK) C#, Visual Basic.

NETObjective-C or Swift

Packaging Android package (APK) files

XAP installation files

iOS App Package (IPA) files

Learning curve Average Moderate SteepDeveloper community base

Large and fast-grow-ing

Relatively large Relatively large

IDE availability Eclipse, NetBeans, IntelliJ

Visual Studio.NET Xcode for OS X, AppCode

Emulator availability Bundled emulator and GenyMotion

Bundled with IDE Bundled iOS Simu-lator

We explored these target platforms with the aim of finding common char-acteristics (Damianos and Daphne, 2011) as shown on Table 1. Accordingly, we found out that the platforms vary considerably between them, making it impossible to write a version of the application that ran on all of them - unless we applied the cross-platform approach described in section 2.

However, the process of getting a cross-platform version of the REST-based application was not straightforward. We used PhoneGap (Cordova) plug-ins and JavaScript APIs. The application was then adapted and deployed onto the Android, Windows Phone, and iOS platforms as follows:

As mentioned above, the REST-based application was initially devel-oped as a general web client application and tested with a desktop web browser (the Mozilla Firefox).

To deploy on the Android platform, we setup the Android SDK on the Eclipse IDE. In addition the PhoneGap plug-ins - cordova.js, cordova.-jar, and the config.xml files were incorporated; and the Android mani-fest was adapted.

Subsequently, the Windows Phone development environment was setup on Visual Studio 2010 Express for Windows Phone. We used PhoneGap plug-ins from Cordova for Windows Phone (namely, Phone-Gap Custom and PhoneGap Starter); Google’s JavaScript plug-in; and other custom plug-ins.

Finally, a development environment for Apple iOS was setup with Xcode running on VMware, PhoneGap-iOS and JavaScript plug-ins.

Accordingly, the usability evaluation of the application on the three deploy-ment platforms is conducted as presented in the next subsection.

5.3. Usability Evaluation

In this study, usability evaluation is conducted from the viewpoint of both the developer who does the REST service composition and adaptation to the native platforms, as well as the end users who actually use the application.

The developer viewpoint is framed under the developer-tools usability theme (Andrew et al., 2012), that is, the ease to use of the tool to develop ap-plications for multiple platforms. Specifically, we concentrate on the efforts exerted by the developer to adapt the application into Android, Windows Phone, and iOS platforms and a description of the results is shown in Table 2.

The end user viewpoint, on the other hand, is part of classical usability evaluation, essential attributes of which are learnability, efficiency, memora-bility, errors and satisfaction (Jacob, 1993). However, evaluating usability using these attributes is highly biased; this can be adjusted by employing the ten point system usability scale (SUS) shown in Appendix A (Brooke, 1986; Jeff, 2014). This is often referred to as an industry standard, is well tested and has been used for our previous work in (Gebremariam et al., 2014).

Thus, we employed this same tool in this study, where 24 smartphone users (16 male, 8 female) between the ages of 22-45 years old and self-reported basic IT skills were randomly allocated amongst three equal-sized groups to evaluate the usability of the application on each of the three platforms. Each user was introduced to the application; asked to use it by entering URIs of the component REST services; entering a search key; swiping over results of the query; finally, the user filled in the SUS questionnaire.

The mean overall SUS scores of each user group corresponding to the indi-vidual platforms are found to be 75.9, 71.6, and 69.7 for Android, Windows Phone, and iOS respectively. The summary of raw user responses to each

question and each scale of the respective group of users is also shown in Ap-pendix A.

6. Discussion

As described earlier in the previous section, our usability evaluation of the REST-based application and the corresponding discussion of results are based on both the developer’s adaptation effort as well as the end-user’s viewpoint

Table 2 - Developer Adaptation Effort of Cross-platform Application

Feature Desktop browser Cross-platform ApplicationAndroid Windows Phone iOS

The ease to learn, and ease to re-member of URIs

Fonts of the URIs links are readable but they cannot be easily learned and remem-bered in business view.

Bigger font size as compared to the desk-top version.

Smaller font size as compared to the An-droid version.

Same as the Win-dows version.

Ease to use of URIs(e.g. enter-ing into the com-position)

HTML5 drag/drop feature simplifies URIs dragging from a list and entry into textbox during composition. But, URIs entry into a list is made manually.

HTML5 drag/drop works but dropping does not copy the URIs into the textbox. Thus, adaptation is made to avoid typing of URIs into the composition.

Swiping into the target textbox drags and drops the URIs. No adaptation effort needed.

Adaptation is made to avoid the manual entry (typing) of URIs into the com-position tool.

Search result navigation

Search results are viewable by scrolling across all sides on the screen.

Search results are viewed by swiping across all sides on the screen.

Search results are viewable by swiping with better perfor-mance as compared to the Android version.

Search results are viewable by swip-ing across all sides.

Platform configu-ration

No! But setting the desktop browser. Mozilla Firefox was used during the testing. JQuery is also added into the app to use the getJSON function.

cordova.js, cordova.jar and config.xml files plugged in; the android manifest tweaked, and more.

PhoneGap-custom and PhoneGap-starter are used. Google’s JavaScript plug-in, and other custom plug-ins.

PhoneGap for iOS and other JavaScript plug-ins are incorporated.

SDK used Notepad++, Mozilla Firefox

Eclipse IDE Visual Studio 2010 Express for Win. Phone

Xcode installed on Mac OS X

.

6.1. Developer Adaptation Effort

With the developer viewpoint, we took into account the effort required by a developer (Andrew et al., 2012) to adapt the REST-based application to the Android, Windows Phone, and iOS platforms with respect to the ease to learn, ease to use (e.g. entering), and ease to remember of the URIs; search result navigation, platform configuration, and the SDK used.

Initially the application was developed with HTML5, CSS3, and JavaScript but targeting the desktop browser. The REST service APIs are invoked by a getJSON Ajax function in JQuery which was integrated into the application and then tested using Mozilla Firefox. As a result, HTML5’s drag and drop feature has simplified a URI’s entry from a list into textbox during composi-tion, as shown in Fig.6. However, since a URI’s entry into a list is either through web searching or typing-in, it needs to be well-designed so that users can learn and remember the URIs easily, thereby enhancing usability of the application.

Fig. 6. Drag/Drop of URIs on Mozilla Firefox

The source code has been deployed onto the Android platform as a cross-platform application. It has been debugged on the Android SDK, by applying a fairly large number of JavaScript lines of code, adapting the Android mani-fest and configuration files for HTTP access and by including Cordova

PhoneGap plug-ins, similar to the approach employed in (Gebremariam et al., 2014).

The above mentioned adaptation effort converted the application into a version for the Android platform and the drag and drop feature was tested. Initially, the drag and drop was unable to copy the URIs into the textbox, leaving the end-user with a cumbersome task of typing-in of the URIs. How-ever, this bug was fixed by applying a small modification on the HTML5, and JavaScript codes related to the mentioned feature.

The same source code that ran correctly on the Android platform has been deployed onto the Windows Phone and iOS platforms (Fig.7 and Fig.8) with the respective PhoneGap plug-ins. All the features of the REST-based appli-cation worked correctly without significant adaptation effort to maintain those features, with the possible exception of the fact that some SDK configurations had been made. Accordingly, the drag and drop feature worked correctly and URIs can be dragged from a list and dropped into a target textbox.

Fig. 7. Application on Windows Phone Emulator

Our findings highlighted that REST-based cross-platform smartphone ap-plications can be ported to other platforms with only limited SDK configura-tion efforts on the part of the developer. When considering the platform con-figuration effort as a feature, we observed the following:

─ The Android platform required adapting of the configuration elements such as the cordova.js, cordova.jar, config.xml, and the Android manifest. In addition, Google’s JavaScript plug-in, together with other custom plug-ins, are added to the source code.

─ The PhoneGap Custom and Starter, Google’s JavaScript plug-in, and other custom plug-ins are used to adapt the application to the Windows Phone platform; and

─ The application was adapted to the iOS platform by integrating PhoneGap-iOS, editing the configuration file, and adding JavaScript plug-ins.

Thus, we found out that adaptation of the cross-platform application into the target platforms is not so cumbersome, and that configuring SDKs of the target platforms took the largest share of the total effort exerted. In addition, we observed that the occurrence of REST services as part of the application did not require the same levels of adaptation effort as the non-REST applica-tion used in (Gebremariam et al., 2014), the only exception being that a JQuery library is included in each project to use the getJSON Ajax function and security settings of the respective platforms are configured for HTTP communications. We also found out that Windows Phone is easier to config-ure because the minimal configuration effort (see Table 2) required to run the REST-based application is less than that corresponding to the Android and iOS platforms.

Fig. 8. The Application on Apple iOS Emulator

6.2. Analysis of SUS Scores

The evaluation of usability from the end-user viewpoint has also been ana-lyzed using different approaches and the results of each are discussed next.

We began our analysis by focusing on the raw results in Appendix A. Here we can see high value user responses for odd numbered questions and low values for the even ones. This same response pattern is also observed under each column corresponding to the platforms, indicating that the REST-based appli-cation has an acceptable level of usability across the three platforms.

Subsequently, we continued our analysis based on the SUS scores. A study by Jeff (2014) pointed out that an SUS score of 68 and above is considered to portray above average levels of perceived usability. In addition, Jeff under-scored that an SUS score which is normalized into a percentile rank (Fig.9) provides a better interpretation of results. Thus, the SUS score and percentile rank of the REST-based cross-platform smartphone application on the three platforms is above 68 and grade “C” respectively, implying that the perceived usability of the application is generally above average.

Fig. 9. Percentile ranks, SUS scores and Letter grades (Jeff, 2014)

The variance of total SUS score means of each user groups was also tested for its statistical significance using analysis of variance (ANOVA), with the operating system as the independent variable, and the SUS items as dependent variables. The ANOVA single factor analysis result of the groups shows that, at the 5% significance level, there are no statistically significant differences in mean SUS scores between the three groups. Similarly, an ANOVA single factor analysis test was conducted for the variances of each SUS questions’ score means (Table 3) across the three groups. Again, no statistically signifi-cant differences in scores between the three platforms were found. Our obser-vation of the results in Table 3 also shows that the mean response of users of all groups to each question is above 2 on the converted1 4 SUS scale. This reconfirms that the cross-platform application has an acceptable level of us-ability across the platforms, as far as each SUS question is concerned.

1 SUS Scores coded as [response – 1] for odd questions, and [5 – response] for the even ones.

Table 3 – User Group’s SUS Score Means and Standard Deviations

No SUS QuestionAndroid Windows Phone iOS

Mean Standard Deviation

Mean Standard Deviation

Mean Standard Deviation

1 I think that I would like to use this system frequently.

2.8750 1.1260 3.0000 0.7559 2.7500 1.1650

2 I found the system unnecessarily complex.

2.6250 1.0607 2.5000 0.9258 2.7500 1.0351

3 I thought the system was easy to use.

3.2500 1.1650 3.2500 0.8864 2.7500 0.8864

4 I think that I would need the support of a technical person to be able to use this system.

3.5000 0.7559 2.6250 1.0607 3.1250 1.1260

5 I found the various functions in this system were well integrated.

3.1250 0.6409 3.2500 0.8864 2.3750 1.1877

6 I thought there was too much inconsistency in this system.

2.8750 0.6409 2.7500 0.7071 2.8750 1.1260

7 I would imagine that most peo-ple would learn to use this sys-tem very quickly.

3.1250 0.8345 2.7500 0.4629 3.0000 0.9258

8 I found the system very cumber-some to use.

3.2500 0.7071 2.5000 0.7559 3.2500 0.7071

9 I felt very confident using the system.

3.2500 0.7071 3.1250 0.8345 2.3750 1.1877

10 I needed to learn a lot of things before I could get going with this system.

2.5000 1.6903 2.8750 0.8345 2.6250 1.0607

In general, our discussion of results indicated that usability of the REST-based cross-platform smartphone application remains unaffected across the individual platforms when ignoring the impact of the form factor of the real devices. This implies that a cross-platform REST client application can be developed with consistent user experience irrespective of the target platforms; moreover, this bodes well for future development of an end-user REST ser-vice composition (mash-up) tool for smartphones that works across many different platforms.

However, the study has certain limitations that require further work. The primary limitation is that it fails to evaluate usability from the perspectives of the types of Web services, messaging and data serialization formats, service composition approaches, and mobile client application development platforms (Fig. 10). Moreover, our study is conducted on only three (albeit popular) mobile platforms - further generalization of findings is required by extending the study on more platforms.

Fig. 10. Perspectives for Usability Evaluation of Web Service Composition on Smartphones

7. Conclusion

Cross-platform mobile application development frameworks provide sup-port to developers to build applications for multiple platforms. However, there are unanswered questions as to the behavior of the resulting cross-platform applications (in terms of usability from the viewpoint of the developer as well as the end user) on the native platforms. Indeed, the deployment of REST-based cross-platform business applications on the respective platforms may even worsen usability problems.

In this study, usability was viewed from two perspectives: that of the devel-oper, and that of the user of the developed REST-based application. The de-veloper viewpoint is seen in terms of the configuration and coding effort (see Table 2) required to adapt the application to the respective native platforms.

For the end user, on the other hand, we employed the widely-used SUS ques-tionnaire (Jeff, 2014).

Our findings showed that the usability of REST-based cross-platform smartphone application remains unaffected when deployed on the respective native platforms. In addition, we observed that the cross-platform develop-ment tools such as PhoneGap require only minimal configuration effort to adapt the cross-platform application to the specific platforms.

JavaScript, HTML5, and the REST service web technologies together with the cross-platform tools would offer considerable opportunities to enhance the usability of developer tools, thereby fostering end-user development (REST service composition) of applications for smartphones. However, the under-standability (i.e. the ease to learn, and ease to remember) of URIs and the entry mechanisms into the composition area (ease to use) require further work.

Thus, our future work will consider design constraints, principles, and best practices for REST services with a goal of enhancing their usability in the composition (mashing-up) of cross-platform smartphone applications. In addi-tion, the prospect of HTML5 and related technologies will be explored to build an end-user cross-platform REST service composition (mash-up) tool for the smartphone, thereby realizing composition of REST services on the go.

REFERENCES

Andrew, Faulring, Brad A. Myers, Yaad Oren, Keren Rotenberg, 2012. A Case Study of Using HCI Methods to Improve Tools for Programmers, IEEE 5th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE), pp. 37-39.

Apple, 2013. Xcode, https://developer.apple.com/xcode/. Beaton, Jack, Sae Young Jeong, Yingou Xie, Jaffrey Stylos, Brad A. Myers,

2008. Usability challenges for Enterprise service oriented architecture APIs, IEEE Symposium on Visual Languages and Human-Centric Computing, pp. 193-196.

Brooke, J., 1986. System Usability Scale (SUS): A Quick-and-Dirty Method of System Evaluation User Information, Digital Equipment Co Ltd. Read-ing, UK.

Bygstad, Bendik, Gheorghita Ghinea, and Eivind Brevik, 2008. Software de-velopment methods and usability: Perspectives of a survey in the software industry in Norway, Elsevier Interacting with computers, 20(3), 375-385.

Carol, Barnum, 2010. Usability Testing Essentials: ready, set... test!, Elsevier.Cesare, Pautasso, Olaf Zimmermann, Frank Leymann, 2008. RESTful Web

Services vs. Big Web Services: Making the Right Architectural Decision,

ACM Proceedings of the 17th International World Wide Web Conference, pp. 805-814.

Chen-Che, Huang, Jiun-Long Huang, Chin-Liang Tsai, Guan-Zhong Wu, Chia-Min Chen, Wang-Chien Lee, 2013. Energy-efficient and cost-effective web API invocations with transfer size reduction for mobile mashup appli-cations, Springer in Wireless networks, 20(3), 361-378.

Chii Chang, 2013. Service-Oriented Mobile Social Network in Proximity, Doctoral Thesis.

Damianos, Gavalas and Daphne Economou, 2011. Development Platforms for Mobile Applications: Status and Trends, IEEE in Software, 28(1), 77-86.

Eelke, Folmer, Jan Bosch, 2001. Architecting for Usability: a survey, Journal of University of Groningen.

eLinux, 2014. Android Architecture, Embedded Linux Wiki http://elinux.org/Android_Architecture.

Fielding, R. T., 2000. Architectural Styles and the Design of Network-based Software Architecture, Doctoral Thesis.

Gebremariam, Mesfin, Gheorghita Ghinea, Dida Midekso, and Tor-Morten Grønli, 2014. Evaluating Usability of Cross-platform Smartphone Applica-tions, Springer in Mobile Web Information Systems, pp. 248-260.

Grønli, Tor-Morten, Jarle Hansen, Gheorghita Ghinea, Muhammad Younas, 2013. Mobile Application Platform Heterogeneity: Android vs Windows Phone vs iOS vs Firefox OS, IEEE 28th International Conference on Ad-vanced Information Networking and Applications (AINA), pp. 635 – 641.

Guido, Moritz, Elmar Zeeb, Steffen Prüter, Frank Golatowski, Dirk Timmer-mann, Regina Stoll, 2010. Devices Profile for Web Services and the REST, IEEE International Conference on Industrial Informatics, pp. 584-591.

Henning, Heitkotter, Sebastian Hanschkem, and Tim Majchrzak, 2013. Evalu-ating Cross-Platform Development Approaches for Mobile Applications, Springer in Web Information Systems and Technologies, pp. 120-138.

Isabelle, Dalmasso, Soumya Kanti Datta, Christian Bonnet, Navid Nikaein, 2013. Survey, Comparison and Evaluation of Cross Platform Mobile Appli-cation Development Tools, IEEE 9th International Conference in Wireless Communications and Mobile Computing, pp. 323-328.

ISO, 1998. Guidance on Usability 9241-1, International Organization for Standardization.

Jack, Beaton, Brad A. Myers, Jeffrey Stylos, Sae Young (Sophie) Jeong, Yingyu (Clare) Xie, 2008. Usability Evaluation for Enterprise SOA APIs, ACM Proceedings of the 2nd international workshop on Systems develop-ment in SOA environments, pp. 29-34.

Jackson, 2014. RESTful web service frameworks, http://jackson .code-haus.org/.

Jacob, Nielsen, 1993. Usability Engineering, Orlando, FL, USA: Academic Press.

Jeff, McWherter, and Scott Gowell, 2012. PROFESSIONAL Mobile Applica-tion Development, John Wiley & Sons, Inc.

Jeff, Sauro, 2014. Quantitative Usability, Statistics, and Six Sigma: Measur-ing Usability, http://www.measuringusability.com/sus.php.

Jersey, 2014. RESTful web service frameworks http://jersey.java .net/.Liane, Cassavoy, 2013. What Makes a Smartphone Smart? http://cell-

phones.about.com/od/ smartphonebasics/a/what_is_smart.htm.Maleshkova, Maria, Pedrinaci Carlos and Domingue John, 2010. Investigating

Web APIs on the World Wide Web, IEEE 8th European Conference on Web Services (ECOWS), pp. 107-114.

Mandel, T., 1997. The Elements of User Interface Design, Wiley.Palmieri, Manuel, Inderjeet Singh, and Antonio Cicchetti, 2012. Comparison

of Cross-Platform Mobile Development Tools, IEEE 16th International Conference on Intelligence in Next Generation Networks, pp. 179-186.

Marino, E., Federico Spini, Alberto Paoluzzi, Fabrizio Minuti, Maurizio Rosina, Antonio Bottaro, 2013. HTML5 Visual Composition of REST-like Web Services, IEEE 4th International Conference on Software Engineering and Service Science (ICSESS), pp. 49-55.

Mark, D. Syer, Bram Adams, Ying Zou, and Ahmed E. Hassan, 2011. Explor-ing the development of micro-apps: A case study on the blackberry and android platforms, IEEE 11th International Working Conference on Source Code Analysis and Manipulation (SCAM), pp. 55-64.

Narayana, Srirama, Matthias Jarke, Wolfgang Prinz, 2006. Mobile Web Ser-vice Provisioning, IEEE in Telecommunications, International Conference on Internet and Web Applications and Services/Advanced International Conference, pp. 120-120.

Nurzhan, Nurseitov, Michael Paulson, Randall Reynolds, and Clemente Izuri-eta, 2009. Comparison of JSON and XML Data Interchange Formats: A Case Study, Caine, 157-162.

Pressman, R., S., 2001. Software Engineering: A Practitioner’s Approach, Fifth Edition, McGraw-Hill.

Roberto, García, Juan Manuel Gimeno, Ferran Perdrix, Rosa Gil, Marta Oliva, Juan Miguel López, Afra Pascual, Montserrat Sendín, 2010. Building a Us-able and Accessible Semantic Web Interaction Platform, Springer in World Wide Web, 13(1-2), 143-167.

Sommerville, Ian, 2009. Software Engineering, Addison-Wesley.Stylos, J., Brad Myers, 2007. Mapping the Space of API Design Decisions,

IEEE Symposium in Visual Languages and Human-Centric Computing, pp. 50-60.

William, Jobe, 2013. Native Apps vs. Mobile Web Apps, International Jour-nal of Interactive Mobile Technologies (iJIM), 7(4), pp-27.

Xinyang, Feng, Jianjing Shen, and Ying Fan, 2009. REST：An Alternative to RPC for Web Services Architecture, IEEE First International Conference in Future Information Networks, pp. 7-10.

Zhang, D., B. Adipat, Challenges, methodologies, and issues in the usability testing of mobile applications, International Journal of Human-Computer Interaction, Volume 18, Issue 3, 2005.

Zhao, Haibo, Prashant Doshi, 2009. Towards automated restful web service composition, IEEE IEEE International Conference on ICWS, pp. 189-196.

Appendix A. The System Usability Scale and Users’ Responses

- Values in % represent users’ responses for each platform.- The “scale” column is used to signify Strongly agree(5), Agree(4), Neutral(3), Disagree(2), and

Strongly disagree(1).

Scale Android Windows Phone iOSQuestion(1) I think that I would like to use this system frequently.

5 37.5% 25.0% 37.5%4 25% 50.0% 12.5%3 25% 25.0% 37.5%2 12.5% 0.0% 12.5%1 0% 0.0% 0.0%

Question(2) I found the system unnecessarily complex.5 0.0% 0.0% 0.0%4 12.5% 12.5% 12.5%3 37.5% 37.5% 25.0%2 25.0% 37.5% 37.5%1 25.0% 12.5% 25.0%

Question(3) I thought the system was easy to use.5 62.5% 50.0% 12.5%4 12.5% 25.0% 62.5%3 12.5% 25.0% 12.5%2 12.5% 0.0% 12.5%1 0.0% 0.0% 0.0%

Question(4) I think that I would need the support of a technical person to be able to use this system.

5 0.0% 0.0% 0.0%4 0.0% 12.5% 12.5%3 12.5% 37.5% 12.5%2 25.0% 25.0% 25.0%1 62.5% 25.0% 50.0%

Question(5) I found the various functions in this system were well integrated.

5 25.0% 50.0% 25.0%4 62.5% 25.0% 12.5%3 12.5% 25.0% 37.5%2 0.0% 0.0% 25.0%1 0.0% 0.0% 0.0%

Question(6) I thought there was too much inconsistency in this system.

5 0.0% 0.0% 0.0%4 0.0% 0.0% 12.5%3 25.0% 37.5% 25.0%

2 62.5% 50.0% 25.0%1 12.5% 12.5% 37.5%

Question(7) I would imagine that most people would learn to use this system very quickly.

5 37.5% 0.0% 37.5%4 37.5% 75.0% 25.0%3 25.0% 25.0% 37.5%2 0.0% 0.0% 0.0%1 0.0% 0.0% 0.0%

Question(8) I found the system very cumbersome to use.5 0.0% 0.0% 0.0%4 0.0% 0.0% 0.0%3 12.5% 62.5% 12.5%2 50.0% 25.0% 50.0%1 37.5% 12.5% 37.5%

Question(9) I felt very confident using the system.5 37.5% 37.5% 25.0%4 50.0% 37.5% 12.5%3 12.5% 25.0% 37.5%2 0.0% 0.0% 25.0%1 0.0% 0.0% 0.0%

Question(10) I needed to learn a lot of things before I could get going with this system.

5 25.0% 0.0% 0.0%4 0.0% 0.0% 12.5%3 12.5% 37.5% 37.5%2 25.0% 37.5% 25.0%1 37.5% 25.0% 25.0%

Appendix B. Source Code Listing

B.1. Source code for REST client (index.html)<!DOCTYPE html><html><head><title>RESTful Client</title><!-- Use JQuery and Drag and Drop features --><script type="text/javascript" src="js/jquery-2.1.1.js"></script><script type="text/javascript" src="js/drag-drop-custom.js"></script><script type="text/javascript">var i=1;function addElement() { i = i + 1; var contentID = document.getElementById('content'); var newTBDiv = document.createElement('div'); newTBDiv.setAttribute('id','strText'+i); newTBDiv.innerHTML = "<input type='text' id='uri" + i + "' name='uri" + i + "' placeholder='Type https://... or http://....'/>"; contentID.appendChild(newTBDiv);}function removeElement() { if(i != 0){ var contentID = document.getElementById('content'); contentID.removeChild(document.getElementById('strText'+i)); i = i - 1; }}$(document).ready(function() { $("#myAjaxRequestForm").submit(function(e){ e.preventDefault();}); $("#myButton").click(function(e){ //get REST APIs & items item = document.forms['myAjaxRequestForm']['itemCategory'].value; uri1 = document.forms['myAjaxRequestForm']['uri1'].value; uri2 = document.forms['myAjaxRequestForm']['uri2'].value; $.getJSON(uri1, function(data1) { $.getJSON(uri2, function(data2) { data = data1.concat(data2); $("#ajaxResponse").html(""); htmlstr = "<table><thead><tr><td>Name</td>”+ “<td> Description</td>"<td>Qty</td><td>Price”+

“</td><td>Site</td></tr></thead>"; htmlstr += "<tr><td>-------</td><td>------------</td>"+ "<td>---</td><td>----</td><td>------</td></tr>"; i = 0; for(d in data){ if((data[i].name==item)||(item=="All")) {

htmlstr += “<tbody><tr><td>"+data[i].name+ "</td><td>"+ data[i].description+"</td><td>"+ data[i].qty+"</td><td>"+ data[i].price+

"</td><td>"+data[i].loc+"</td></tr>"; } i++; } $("#ajaxResponse").append(htmlstr+"</tbody></table>"); }); }); }); });</script></head><body><div id="allContent"><div id="myExample">

<form id="myAjaxRequestForm"> <fieldset> <legend>Please enter item category and the RESTful services you want to use.</legend> <p><label for="itemCategory">Category:</label> </p><p><input id="itemCategory" type="text" name= "itemCategory" placeholder="Enter Wheat, Banana, PC, ..."/> </p><label for="uri1">RESTful service APIs (URLs):</label> <div > <a id="site1" href="http://10.0.2.2:8080/rest/demo/item/loc1">Site 1</a>| <a id="site2" href="http://10.0.2.2:8080/rest/demo/item/loc2">Site 2</a>| ... </div> <input id="uri1" type="text" name="uri1" placeholder="Type http://.. or https://.."/> <p>More APIs? </p> <p>Please click <a href= "javascript:addElement();" >add</a> or <a href="javascript:removeElement();" >remove</a>.</p> <div id="content"></div> <p><input id="myButton" type="button" value="Search" /> </p></fieldset></form> <div id="anotherSection"> <fieldset> <legend>Query result from different sources:</legend><div id="ajaxResponse"></div> </fieldset></div></div></div> <script> //HTML5 Drag and Drop functionsfunction drop(idOfDraggedItem,targetId,x,y) { var html = document.getElementById(idOfDraggedItem).innerHTML; html = html + document.getElementById(idOfDraggedItem).innerHTML; document.getElementById(idOfDraggedItem).innerHTML = html;} var dragDropObj = new DHTMLgoodies_dragDrop();dragDropObj.addSource('site1',true); dragDropObj.addSource('site2',true);dragDropObj.addTarget('uri1','drop'); dragDropObj.addTarget('uri2','drop');dragDropObj.init();</script></body></html>

B.2. Source code for REST Services (item_api.java)package rest.demo;import javax.ws.rs.*;import javax.ws.rs.core.Response;import javax.ws.rs.core.MediaType;import org.codehaus.jettison.json.JSONArray;import java.sql.Connection;import java.sql.PreparedStatement;import java.sql.ResultSet;@Path("item")public class item_api {private PreparedStatement query = null;DBconnect connect=new DBconnect();@GET@Path("/loc1")@Produces(MediaType.APPLICATION_JSON)public Response returnItemsFromLoc1() throws Exception{ String returnString=null; Response rb = null; Connection conn= connect.open(); ResultSet rs; try { query = conn.prepareStatement("SELECT * " +

"FROM rest_demo.item WHERE loc='Site1'"); rs = query.executeQuery(); toJSON converter = new toJSON(); JSONArray json = new JSONArray(); json =converter.convert(rs); query.close(); returnString = json.toString(); rb = Response.ok(returnString).build(); } catch (Exception e) {throw e;} finally { connect.close();} return rb;}@GET@Path("/loc2")@Produces(MediaType.APPLICATION_JSON)

public Response returnItemsFromLoc2() throws Exception{String returnString=null; Response rb = null;Connection conn= connect.open(); ResultSet rs;try { query = conn.prepareStatement("SELECT * " +

"FROM rest_demo.item WHERE loc='Site2'"); rs = query.executeQuery(); toJSON converter = new toJSON(); JSONArray json = new JSONArray(); json=converter.convert(rs); query.close(); returnString = json.toString(); rb = Response.ok(returnString).build();} catch (Exception e) { throw e;} finally { connect.close();} return rb;}}

B.3. Source code for JSON convertor (toJSON.java)package rest.demo;import org.codehaus.jettison.json.JSONArray;import org.codehaus.jettison.json.JSONObject;import org.codehaus.jettison.json.JSONException;import java.sql.SQLException;import java.sql.ResultSet;import java.sql.ResultSetMetaData;public class toJSON {public JSONArray convert( ResultSet rs )throws SQLException, JSONException {JSONArray json = new JSONArray();ResultSetMetaData rsmd = rs.getMetaData();while(rs.next()) { int numColumns = rsmd.getColumnCount(); JSONObject obj = new JSONObject(); for (int i=1; i<numColumns+1; i++) { String column_name = rsmd.getColumnName(i); if(rsmd.getColumnType(i)==java.sql.Types.ARRAY){ obj.put(column_name, rs.getArray(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.BIGINT){ obj.put(column_name, rs.getInt(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.BOOLEAN){ obj.put(column_name, rs.getBoolean(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.BLOB){ obj.put(column_name, rs.getBlob(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.DOUBLE){ obj.put(column_name, rs.getDouble(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.FLOAT){ obj.put(column_name, rs.getFloat(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.INTEGER){ obj.put(column_name, rs.getInt(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.NVARCHAR){ obj.put(column_name, rs.getNString(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.VARCHAR){ obj.put(column_name, rs.getString(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.TINYINT){ obj.put(column_name, rs.getInt(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.SMALLINT){ obj.put(column_name, rs.getInt(column_name));

} else if(rsmd.getColumnType(i)==java.sql.Types.DATE){ obj.put(column_name, rs.getDate(column_name)); } else if(rsmd.getColumnType(i)==java.sql.Types.TIMESTAMP){ obj.put(column_name, rs.getTimestamp(column_name)); } else{

obj.put(column_name, rs.getObject(column_name)); } } json.put(obj); } return json; }}

B.4. Source code for database connector (DBConnect.java)package rest.demo;import java.sql.Connection;import java.sql.DriverManager;import java.sql.ResultSet;import java.sql.Statement;public class DBconnect {private Connection connect = null;private Statement statement = null;private ResultSet resultSet = null;String ConnDriver="com.mysql.jdbc.Driver";String ConnString="jdbc:mysql://localhost/rest_demo?user=root&password=root";public Connection open(){ Connection con= null; try{ Class.forName(ConnDriver); con= DriverManager.getConnection(ConnString); } catch (Exception e){System.out.println(e);} return con;}public void close() {try { if (resultSet != null) { resultSet.close();} if (statement != null) {statement.close(); } if (connect != null) { connect.close();}} catch (Exception e) {}}}

B.5. Database table structureCREATE TABLE rest_demo.item (

code int(11) NOT NULL, name varchar(20), description varchar(25), qty int(11), price float, PRIMARY KEY (id)

);

.