Towards End-User Development of REST Client Applications on Smartphones
Total Page：16
File Type：pdf, Size：1020Kb
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, [email protected], Addis Ababa, Ethiopia bWesterdals Oslo ACT,Faculty of Technology, [email protected], Oslo, Norway cAddis Ababa University, [email protected], Addis Ababa, Ethiopia dBrunel University, [email protected], 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 experience, irrespective of the fact that their basic architecture and support of programming 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 development environments aiming at building platform independent applications. 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 architecture 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 mobile 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 smartphone 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 features and library set for devices with similar processing and memory limitations, 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 weaknesses 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 Windows 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 development 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 flourishing; 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 Xamarin 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 development tool developed by Adobe Systems Inc. under the Apache license. It provides 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 flexibility, 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 PhoneGap 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 environment) 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 Android and XCode for iOS. Thus far, PhoneGap permits the creation of applications 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 development environments.
3. 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 primarily built with the Windows Phone SDK together with Silverlight and XNA add-ons on Visual Studio. XNA is employed for 2D and 3D games development 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). 4. 5. 2.2. Android
Android is based on the Linux kernel and developed as an open source system platform. In addition to the operating system, Android provides a development 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 language 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). Recently 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 developers. However, achieving an identical look-and-feel as well as an identical 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. 6. REST-based Cross-platform Smartphone Applications
A REST web service, introduced by Fielding (2000), is a client-server architecture 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. 7. 8. 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 applications and mashups (Cesare, Olaf, and Frank, 2008; Chii, 2013). Like web pages, they support caching in proxies, and gateways. Since, JSON is a lightweight, directly supported inside JavaScript, and human readable data exchange 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 applications to be simple, and lightweight. Hence, the REST approach is considered to be a good alternative to build flexible, scalable and loosely- coupled service-oriented architecture systems, and is what we employ in the study underpinning this paper.
3.2. REST Services Composition
9. 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 updating 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 enhanced 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 capability 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 applications is dependent on the screen size of the smartphone (Zhang, 2005). Given the enhanced functionality of smartphones, it is thus not unreasonable 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.
10. 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 technologies, 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 system. The net increase in productivity (over the approach that the system replaces) measured when the system is used by someone who is moderately 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 design, 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 requirements 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/offline events management, and drag-and-drop. With a goal of enhancing usability, Marino et al. (2013) propose HTML5 as a visual programming environment for the composition of services based on a dataflow paradigm. The authors were oriented towards web technologies to offer developers an integrated 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 graphical 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 technical 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 challenges 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 system 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 suitability for the Web (Maleshkova, Pedrinaci, and Domingue, 2010), their use requires extensive manual effort, as will be described below.
11. 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 implemented in a smartphone environment.
12. 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 invocation 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 extensibility. 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 balance between the breadth and depth of the URI’s name space.
13. 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 principles. 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 significantly impact usability due to the fact that operations have varying configuration 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 parameters 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 enhancing 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 explored. 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. 14. Comparison of Usability of a Cross-platform Smartphone Application
In this study, the usability technique described in section 4 is used to evaluate 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 Frameworks
In addition, an Eclipse dynamic web project “WebContent/WEB-INF” folder contains the “web.xml” configuration file which provides a “
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 interfaces 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. Appendices 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 operations 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 implementation 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 discussed in sections 3 and 4 above); search result navigation; platform configuration; 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 parameters 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 Applications Development Platforms Feature Android Windows Phone iOS Development Language Java (Android SDK) C#, Visual Basic. Objective-C or NET Swift Packaging Android package XAP installation iOS App Package (APK) files files (IPA) files Learning curve Average Moderate Steep Developer community Large and fast- Relatively large Relatively large base growing IDE availability Eclipse, NetBeans, Visual Studio.NET Xcode for OS X, IntelliJ AppCode Emulator availability Bundled emulator Bundled with IDE Bundled iOS and GenyMotion Simulator
We explored these target platforms with the aim of finding common characteristics (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 developed 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 manifest 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, PhoneGap 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 deployment 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 applications 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, memorability, 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 individual 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 Appendix A.
15. 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 Cross-platform Application Feature Desktop browser Android Windows Phone iOS The ease to learn, Fonts of the URIs links Bigger font size as Smaller font size as Same as the and ease to are readable but they compared to the compared to the Windows version. remember of cannot be easily desktop version. Android version. URIs learned and remembered in business view. Ease to use of HTML5 drag/drop HTML5 drag/drop Swiping into the target Adaptation is made URIs(e.g. feature simplifies URIs works but dropping textbox drags and to avoid the manual entering into the dragging from a list does not copy the URIs drops the URIs. No entry (typing) of composition) and entry into textbox into the textbox. Thus, adaptation effort URIs into the during composition. adaptation is made to needed. composition tool. But, URIs entry into a avoid typing of URIs list is made manually. into the composition. Search result Search results are Search results are Search results are Search results are navigation viewable by scrolling viewed by swiping viewable by swiping viewable by across all sides on the across all sides on the with better swiping across all screen. screen. performance as sides. compared to the Android version. Platform No! But setting the cordova.js, cordova.jar PhoneGap-custom and PhoneGap for iOS configuration desktop browser. and config.xml files PhoneGap-starter are and other Mozilla Firefox was plugged in; the android used. Google’s JavaScript plug-ins used during the testing. manifest tweaked, and JavaScript plug-in, and are incorporated. JQuery is also added more. other custom plug-ins. into the app to use the getJSON function. SDK used Notepad++, Mozilla Eclipse IDE Visual Studio 2010 Xcode installed on Firefox Express for Win. Phone 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 composition, 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 manifest 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. However, 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 application 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 applications can be ported to other platforms with only limited SDK configuration efforts on the part of the developer. When considering the platform configuration 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 application 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 configure 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 analyzed 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 application 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 underscored 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 significant differences in scores between the three platforms were found. Our observation 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 converted 1 4 SUS scale. This reconfirms that the cross-platform application has an acceptable level of usability 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 Android Windows Phone iOS No SUS Question Mean Standard Mean Standard Mean Standard Deviation Deviation Deviation 1 I think that I would like to use 2.8750 1.1260 3.0000 0.7559 2.7500 1.1650 this system frequently. 2 I found the system unnecessarily 2.6250 1.0607 2.5000 0.9258 2.7500 1.0351 complex. 3 I thought the system was easy to 3.2500 1.1650 3.2500 0.8864 2.7500 0.8864 use. 4 I think that I would need the 3.5000 0.7559 2.6250 1.0607 3.1250 1.1260 support of a technical person to be able to use this system. 5 I found the various functions in 3.1250 0.6409 3.2500 0.8864 2.3750 1.1877 this system were well integrated. 6 I thought there was too much 2.8750 0.6409 2.7500 0.7071 2.8750 1.1260 inconsistency in this system. 7 I would imagine that most 3.1250 0.8345 2.7500 0.4629 3.0000 0.9258 people would learn to use this system very quickly. 8 I found the system very 3.2500 0.7071 2.5000 0.7559 3.2500 0.7071 cumbersome to use. 9 I felt very confident using the 3.2500 0.7071 3.1250 0.8345 2.3750 1.1877 system. 10 I needed to learn a lot of things 2.5000 1.6903 2.8750 0.8345 2.6250 1.0607 before I could get going with this system.
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 service 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
16. Conclusion
Cross-platform mobile application development frameworks provide support 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 developer, and that of the user of the developed REST-based application. The developer 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 questionnaire (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 development 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 understandability (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 addition, 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. Reading, UK. Bygstad, Bendik, Gheorghita Ghinea, and Eivind Brevik, 2008. Software development 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 applications, 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 Applications, 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 Advanced Information Networking and Applications (AINA), pp. 635 – 641. Guido, Moritz, Elmar Zeeb, Steffen Prüter, Frank Golatowski, Dirk Timmermann, 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. Evaluating 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 Application 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 development in SOA environments, pp. 29-34. Jackson, 2014. RESTful web service frameworks, http://jackson .codehaus.org/. Jacob, Nielsen, 1993. Usability Engineering, Orlando, FL, USA: Academic Press. Jeff, McWherter, and Scott Gowell, 2012. PROFESSIONAL Mobile Application Development, John Wiley & Sons, Inc. Jeff, Sauro, 2014. Quantitative Usability, Statistics, and Six Sigma: Measuring 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://cellphones.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. Exploring 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 Service 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 Izurieta, 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 Usable 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 Journal 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 iOS Question(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)
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 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 structure CREATE TABLE rest_demo.item ( code int(11) NOT NULL, name varchar(20), description varchar(25), qty int(11), price float, PRIMARY KEY (id) ); .