Master Thesis
A DOMAIN-SPECIFIC LANGUAGE FOR UI-NAVIGATION IN MOBILE APPLICATIONS
Peter Reuter University of Kaiserslautern [email protected]
Sep 25, 2013
First Examiner: Prof. Dr. Arnd Poetzsch-Heffter
Second Examiner: Dipl.-Inf. Axel Irriger
Advisor: Dipl.-Inf. (FH) Andy Scherzinger
STATEMENT OF AUTHORSHIP
Except where reference is made in the text of this thesis, this thesis contains no material published elsewhere or extracted in whole or in part from a thesis presented by me for another degree or diploma. No other person's work has been used without due acknowledgement in the main text of the thesis. This thesis has not been submitted for the award of any other degree or thesis in any other tertiary institution.
Kaiserslautern, Sep 25, 2013
Peter Reuter
Abstract
Developing mobile applications for the major mobile operating systems Android, iOS and Windows Phone 7 often requires re-development of functional similar applications multiple times. Furthermore, applications for similar business cases often use similar screens and screen flows. Software developers are therefore faced by the challenge of minimizing this effort.
This master thesis presents a prototypical tool for the generation of native applications for mobile devices. To this end, typical navigation structures and concepts of mobile applications are captured by an abstract descriptions using a domain-specific language (DSL). This DSL supports developers while creating platform-independent specifications of screens and screen flows. Furthermore, a prototypical code generator is presented that is used to generate the concrete screens and the navigation between them. Mobile user interface pattern are used to provide a basic implementation for the different screens. Finally, the specification of a fictional application using the developed DSL is presented. The code generation approach of this thesis is demonstrated and evaluated using this fictional application.
Kurzdarstellung
Die Entwicklung mobiler Anwendungen für die meistgenutzten Betriebssysteme Android, iOS und Windows Phone 7 erfordert es, fachlich gleiche Anwendungen mehrfach zu entwickeln. Anwendungen für ähnliche Geschäftsszenarios verfügen zudem oft über ähnliche Dialoge und Dialogflüsse. Software-Entwickler stehen dabei vor der Herausforderung, den Aufwand an Neuentwicklung zu minimieren.
Diese Masterarbeit präsentiert ein prototypisches Werkzeug zur Generierung von nativen Anwendungen für mobile Geräte. Dazu werden die typischen Navigationsstrukturen und -konzepte mobiler Anwendungen durch abstrakte Beschreibungen mittels einer Domänen-spezifischen Sprache (DSL) festgehalten. Diese DSL erlaubt das Ableiten Plattform-unabhängiger Spezifikationen von Dialogen und Dialogflüssen. Weiterhin wird ein prototypischer Generator präsentiert, der aus den abstrakten Dialog-Modellen alle konkreten Dialoge und den Code für die Navigation zwischen diesen generiert. Um eine Standard-Implementierung für Dialoge bereitzustellen werden Mobile User-Interface Pattern genutzt. Abschließend wird die Spezifikation einer fiktive Anwendung mittels der entwickelten DSL präsentiert. Anhand dieser Anwendung wird exemplarisch die Funktionsweise des vorgestellten Ansatzes demonstriert und evaluiert.
Table Of Contents
1 Introduction...... 1 1.1 Motivation...... 1 1.2 Goals And Structure...... 2 2 Methods, Techniques And Technologies...... 5 2.1 Foundations...... 5 2.1.1 Model-Based User Interface Development...... 5 2.1.2 Domain-Specific Languages...... 6 2.1.3 Xtext...... 8 2.1.4 User-interface Patterns...... 8 2.1.5 Patterns For Mobile UIs...... 9 2.1.6 Freemarker...... 10 2.2 Existing Approaches...... 11 2.2.1 Eclipse Android Development Tools...... 11 2.2.2 Sencha Touch And Adobe Phonegap...... 13 2.2.3 Cross-compilation...... 14 2.2.4 PhoneApps...... 15 2.3 Summary...... 16 3 The Mobile UI DSL...... 19 3.1 Analysis Of Mobile Applications...... 19 3.1.1 Navigation Concepts...... 20 3.1.2 Frequently Used Screens...... 22 3.2 Derived Requirements...... 27 3.2.1 General...... 27 3.2.2 Navigation...... 27 3.2.3 Screens...... 28 3.3 The MobileUI DSL...... 29 3.3.1 MobileUI DSL Grammar...... 29 3.3.2 Pattern DSL Grammar...... 34 3.3.3 Context Conditions...... 36 3.3.4 Semantics Of Nested Flows And Screens...... 36 3.4 Summary...... 38 4 Tool Support...... 41 4.1 Eclipse Editors For DSL Instances...... 41 4.1.1 DSL Text Editors...... 41 4.1.2 Visualization Of DSL Instances...... 46 4.2 Code Generator For Android...... 47 4.2.1 Base Meta Template...... 48 4.2.2 Screen Templates...... 49 4.2.3 Navigation Controller Architecture...... 50 4.2.4 Generation Process...... 53 4.3 Summary...... 54 5 Evaluation...... 57 5.1 Description And Specification...... 57 5.2 Code Generation...... 59
5.3 Comparison With Traditional Development...... 61 5.3.1 Initial Effort...... 61 5.3.2 Long-term Effort...... 62 5.4 Summary...... 62 6 Conclusion And Future Work...... 63 7 Appendices...... 71 7.1 MobileUIDSL – Xtext Grammar...... 71 7.2 Pattern DSL – Xtext Grammar...... 73 7.3 Main Screens For The “Business Trips” Mobile Application...... 74 7.3.1 BusinessTrips.mobileui...... 74 7.3.2 CostCenter.mobileui...... 75 7.4 “BusinessTrips” Mobile Application “NCRegistry.java”...... 76
1 Introduction 1
1 Introduction
1.1 Motivation
Tablet computers like the Apple iPad or corresponding devices of other manufacturers provide simple access to data of all kinds. Whether one wants to get the latest weather forecast, book a flight or simply check e-mails, mobile applications provide access to almost any online resource. Tablet computers are even more portable than traditional laptops and have a longer battery service life of around 10h. These devices along with smart phones are steadily gaining popularity compared to conventional devices like personal computers or laptops. Also in the business environment a growing demand for tablet computers and applications for these devices is recognized [BIT13]. A major requirement for these applications is the availability of the mobile application for common configurations of operating systems, operating system versions and devices.
Providing mobile applications for all these configurations can require much re-development. Different mobile platforms use different technologies and pose different restrictions to UIs of mobile applications via their respective style guides, but only experts know about the details. In addition, a single mobile application should look an behave similarly on different platforms. Furthermore, mobile applications for similar business cases often feature similar user interfaces (UIs) in terms of screens1. Also, navigation between screens and screen flows – screens that are presented subsequently to the user – are often similar. Thereby, a high potential for reducing the amount of re-development exists. Developers are therefore faced with the following challenge:
Minimize the amount of re-development while creating new mobile applications for similar business cases and porting existing mobile applications to new configurations.
1 cf. renting a car using the Sixt and Hertz Android mobile application 2 Peter Reuter, University of Kaiserslautern
At present, several approaches exist that approach this challenge. These range from approaches based on web technologies like JavaScript, HTML5 or CSS to cross-compilation approaches. Still, they suffer from certain issues. They can break style guides when offering one UI for multiple platforms. Technologies like JavaScript have a decreased performance compared to the platforms' native programming languages. Furthermore, these approaches neither provide options for re-using screen flows nor support for non-expert developers when creating screen for mobile applications.
Techniques that solve the latter problems already exist. Non-expert developers can be supported by providing reusable artifacts for UI development. UI pattern were adapted in the field of UI development in order to easily transmit design knowledge [SIN04]. Furthermore, reusable descriptions of UIs can be provided by abstracting from a concrete platform. In current practice, descriptions of UIs range from formal descriptions to mock-ups using Microsoft PowerPoint to wire frames to simple paper mock-ups. These descriptions are later implemented by developers. Current research suggest model-based user interface development
Fig. 1.1.1: Simplified CAMELEON Reference Framework [LIM04] and classification of the MobileUI DSL 1 Introduction 3
(MBUID) as a formal approach. MBUID can reduce the gap between requirements and the developed user interface [W3C]. Models are used to specify the UI and refine it stepwise. The UI is developed subsequently or even generated according to the models. Still, these approaches are rather heavyweight as they often try to specify all aspects of a UI. In contrast, the approach suggested by this thesis focuses on screen flows and the relations between screens.
1.2 Goals and Structure
This thesis presents an approach for the generation of basic UIs for mobile applications featuring fully functional navigation. The approach is based on platform-independent and reusable descriptions of screens and screen flows.
As Fig. 1.2.1 depicts, in order to achieve this goal, already existing technologies are combined. Referring to MBUID, a model is used as an abstract description of the mobile application's UI and UI navigation. The model captures information about screens, screen flows and relations between screens. A custom domain-specific language (DSL) called “MobileUI DSL” is presented that provides a notation form for the model. Furthermore, mobile UI patterns are used that provide frequently used screens as reusable artifacts. The pattern's solutions are provided platform-dependently. Conformity with style guides can therefore be easily ensured if the pattern solutions are created by expert developers. Furthermore, as the pattern solutions are implemented platform-specifically, no performance issues are introduced. A second DSL called “Pattern DSL” that lists available patterns was developed in order to be able to validate instances of the first DSL. Finally, a code generation approach is used to transform the abstract UI description into a platform-specific implementation of the mobile application. The basis for the code generation process are the knowledge about the required screens, screen flows and relations that is captured in the model as well as the platform-dependent solutions of the patterns. In order to show the feasibility of the presented approach a code generator for the Android platform was developed as a prototype. 4 Peter Reuter, University of Kaiserslautern
Fig. 1.2.1: Sketch of the approach presented by this thesis.
The rest of this thesis is structured as follows. First, an overview of the foundations of the developed approach is presented. In addition, existing approaches that try to solve the problems mentioned in chapter 1.1 are presented and their applicability to the given challenge is highlighted. Afterwards, the developed DSLs and their fundamental constructs are introduced in detail. Thereafter, tools for editing, visualization of DSL instances and code generation are presented. Special emphasis lies on the code generator for the Android platform that was implemented prototypically. Finally, exemplary DSL instances serve as input to the developed code generator. These instances specify an existing reference application. The outcome of the generation, namely source code and other resources, is then compiled to an executable application. In the last chapter this generated application is then compared to the traditionally developed reference application. The capabilities of the presented DSLs and the generation approach are highlighted and benefits as well as drawbacks are pointed out last. 2 Methods, Techniques and Technologies 5
2 Methods, Techniques And Technologies
This chapter describes the fundamental principles and frameworks that are used in the developed approach. The foundations of the approach that is presented in chapter 3 and 4 are introduced in chapter 2.1. Chapter 2.2 presents already existing approaches that cope with platform independence or that provide support to developers while developing new mobile applications. The benefits and drawbacks of each approach are highlighted.
2.1 Foundations
The following chapters present the technological and methodical foundations of the later on presented code generation approach. Furthermore, it is presented in brief how these methods, techniques and technologies are used within the approach.
2.1.1 Model-Based User Interface Development
In order to solve the problems presented in Chapter 1 the UI generation approach of this thesis follows the principle idea of MBUID. Model-Based User Interface Development (MBUID) uses a set of declarative models to capture the different aspects of UIs [W3C]. These models can be manually or (semi-) automatically transformed into a concrete UI [PUE97].
MBUID has several advantages. The different aspects of UIs are captured in separate models. Thereby, developers can handle the increasing complexity of UIs more easily [W3C]. Furthermore, the different models and thus the UI can be analyzed at early development stages. UIs for different devices, regarding both form factor and vendors, can be created more easily if the models are defined platform independent.
The idea of MBUID has evolved in more than a decade [W3C], but there is no consensus about the models and model notations to be used [PER07]. Nonetheless, most MBUID approaches capture the different aspects of UIs similarly and can be classified using the CAMELEON Reference Framework. This 6 Peter Reuter, University of Kaiserslautern
framework highlights the different models and development steps from high-level abstractions like user tasks to the final UI [CAL2003]. Existing MBUID approaches can be mapped to the various levels of the CAMELEON Reference Framework. As depicted in Fig. 1.1.1 the development life-cycle starts at the level of tasks and concepts. This level specifies user activities that can be performed to achieve certain goals. Temporal and causal dependencies can be used to restrict the execution order of the different tasks. Next, the Abstract User Interface (AUI) represents the available interaction elements and the navigation within the application. The interaction elements are independent from their concrete representation in the final UI. They are refined to platform-dependent interaction elements at the Concrete User Interface (CUI) level. Furthermore, the CUI level specifies properties that can be perceived by the user such as color or size. Last, the platform-dependent Final User Interface (FUI) is represented at two sub-levels: source code and the runtime UI.
Also the MobileUI DSL that is presented in Chapter 3 can be classified using the CAMELEON Reference Framework. The DSL allows the specification of screens, screen flows and relations between screens. It does not specify interaction objects. Instead a common set of possible interactions of a screen is assumed due to the restricted interaction possibilities of mobile applications that are presented in Chapter 3.1.1. As depicted in Fig. 1.1.1, the MobileUI DSL can therefore be seen as an AUI that is transformed to a platform-dependent CUI by the code generator that is presented in Chapter 4. The platform's software development kit (SDK) is then used to compile the CUI into a FUI that is presented to the user as the final mobile application.
2.1.2 Domain-Specific Languages
The previously mentioned DSLs are used to capture the model. Platform-independent and reusable descriptions of screens and screen flows are provided as input data for for the UI generation process. This chapters provides a definition of DSLs in order to clarify terms and categorizes the MobileUI DSL and Pattern DSL.
Fowler [FOW10] defines DSLs as follows: 2 Methods, Techniques and Technologies 7
“A computer programming language of limited expressiveness focused on a particular domain.”
Systematic studies on DSLs started only recently. Nonetheless, DSLs have been widely used in the past [CZA05]. As we can find in [FOW10], DSLs can be distinguished from other programming languages via the generality of the problems they try to solve. DSLs do not provide general constructs and notations that can be used to solve general problems. Instead, DSLs are more restrictive with respect to the notations and constructs they provide. These often follow the terms of the target domain. Thus domain-experts can easily “understand, validate, modify, and often even develop DSL programs ” [DEU00]. Furthermore, domain experts can use DSL to encapsulate their knowledge and thereby encourage reuse.
Mernik et al. [MER05] provide various characteristic by which DSLs can be distinguished from other programming languages. By the focus on a particular domain DSLs offer an increased expressiveness with respect to their domain despite their limited general expressiveness. In addition, executability can be used as a distinguishing characteristic. While many programming languages are executable in general DSLs are not necessarily executable. Fowler furthermore mentions different scales of executability in [FOW10]:
• DSLs providing well-defined execution semantics
• DSLs that are used as input languages for application generators
• declarative DSLs that serve as domain-specific data structure representations
The DSLs that are presented in Chapter 3.3 belong to the latter two categories. They provide constructs and notations for the definition of screens, screen flows and the relations between screens as well as for the definition of patterns. These declarative descriptions of the UIs of mobile applications then serve as input for the code generator that is presented in Chapter 4. 8 Peter Reuter, University of Kaiserslautern
2.1.3 Xtext
The DSL infrastructure like parsers or Eclipse plug-ins for editing that is presented in chapter 4 is generated using the Xtext framework. As described by the Xtext documentation, Xtext is a framework that supports the development of programming languages as well as DSLs [XTE13].
Xtext features a rich grammar for language development. The grammar supports references within instances of the same DSL or cross-references to other DSLs. The MobileUI DSL grammar makes use of these cross-references. Screens and screen flows can provide links to other screens and screen flows in order to reuse them in new contexts. Furthermore, screen specify cross-references to patterns specified by instances of the Pattern DSL. Thereby, available patterns providing default implementations for frequently used screens can be easily referenced.
The editors that are generated from the DSL grammars are deeply embedded into the Eclipse framework. Default implementations for syntax coloring, content assists, validation of input and support for the correction of errors are generated automatically. Thereby, users can rely on well-known views and functionality. Although these default implementations are sufficient in most cases, the prototype extends these as presented in Chapter 4.1.1 in order to cope with certain peculiarities of the MobileUI DSL.
Developers can create new MobileUI specifications these editors. The prototype presented in Chapter 4.2 then uses the generated parsers to parse the MobileUI specifications and provide it as input data to the Freemarker library that processes platform-dependent solutions of mobile UI patterns.
2.1.4 User-interface Patterns
In order to generate code from DSL instances the presented approach provides reusable artifacts for common screens as UI patterns. The idea of patterns as proven solutions for common design problems originates in the domain of urban design [ALE77]. A pattern as Alexander defines as follows:
It is a “three-part rule, which expresses a relation between a certain 2 Methods, Techniques and Technologies 9
context, a problem and a solution” [ALE77].
Thereby, patterns “provide an effective way to transmit experience about recurrent problems” [SIN04]. In 1994 patterns were introduced in the domain of computer science by Gamma, Helm, Johnson, and Vlissides [GAM94]. Later, they were also taken over in the field of UI development.
Today, pattern libraries like [TID13] or [WEL13] provide developers with a vast amount of design patterns for traditional UIs. All these libraries have in common that they utilize – to a certain extent – the pattern form that was initially proposed by Alexander.
2.1.5 Patterns for mobile UIs
Since the first emergence of smart phones like the Apple iPhone and tablet computers like the Apple iPad, a need for new UI patterns arose [NEI12]. These patterns have to take into account the peculiarities of the new devices like their reduced screen size or new interaction modalities such as touch and gestures.
Therefore, new pattern galleries were established. These galleries often are made available on the Internet. As an example, the “Android Interaction Design Patterns” gallery [AND13] offers a wide range of patterns for the Android platform. Others like the “Pttrns” gallery [PTR13] or the “Inspired UI” gallery [INS13] provide developers with patterns for the iOS platform. In addition, also platform-independent pattern galleries like [NEI12] exist.
All these pattern galleries need to take into account the fact that the developers of the different mobile platforms established different standards for UI design. The platform-specific style guides induce that the same idea of a solution to a given design problem often results in different implementations on different mobile platforms. As an example the tab navigation pattern of [NEI12] can be considered. As depicted in Fig. 2.1.1, some mobile platforms like iOS display tabs at the bottom of the screen, while e.g. the Android style guide requires tabs to be displayed at the top of the screen. 10 Peter Reuter, University of Kaiserslautern
Fig. 2.1.1: Tab orientation for various OSs [NEI12, fig. 1-12]
The later-on presented approach provides these platform-dependent pattern solutions as sets of template files that are processed by the Freemarker library in order to adapt them to the context they are used in.
2.1.6 Freemarker
The Freemarker documentation describes the Freemarker programming library as a “generic tool to generate text output (anything from HTML to auto-generated source code) based on templates” [FRE13]. The Fremarker library provide a custom template language called Freemarker Template Language (FTL). The FTL provides template authors with constructs like if/then/else, loops or definition and manipulation of variables by using e.g. string operations like concatenation or sub-strings. 2 Methods, Techniques and Technologies 11
Platform-specific solutions for the already mentioned patterns are provided as templates consisting of Java code and XML files. These files contain the implementation of a frequently used screen and its layouts and other resources. Pattern authors can use these templates to generate platform-dependent pattern solutions that depend on the context the pattern is used in. As depicted in Fig. 2.1.2, Freemarker templates and input data in the form of Java objects are passed to the Freemarker library. In case of the prototype, the MobileUI DSL specification is parsed and provided as input to the Freemarker library. The Freemarker library then processes both template and input data and afterwards serves the generated text document. The generated text document then is saved as a text files.
Fig. 2.1.2: Freemarker text generation process, adapted from [FRE13]
2.2 Existing Approaches
Next, already existing approaches that cope with platform independence or that provide support to developers while creating new mobile applications for different platforms are presented. The benefits and drawbacks of each approach are highlighted.
2.2.1 Eclipse Android Development Tools
For the Android platform the most commonly used development tool is the Eclipse Android Developer Tools Plugin (ADT) [ADT13]. The ADT includes support for creating new Android projects, debugging or exporting the application. As 12 Peter Reuter, University of Kaiserslautern
depicted in Fig. 2.2.1, the ADT supports the generation of common UI screens, so-called “activities”.
To this end, it utilizes templates that can be instantiated. These templates consist of a directory containing meta-information about the template and files containing source code or other resources like XML layout definitions or configuration information. The files of the template consist of static content and control structures. As the meta-information includes parameters for the template the control structures can be used to dynamically generate content. The control structures allow conditional and repetitive parts since they are based on the Freemarker Template Language. The ADT includes several general purpose templates. Additional templates are provided by other authors [GIF13].
Fig. 2.2.1: “New Activity” wizard of the Eclipse ADT
These templates provide a good foundation for novice Android developers and are developed and designed by Android experts. Thereby, conformity with the Android platform's style guide is ensured when using these templates. Nonetheless, only a few templates exist.
Furthermore, the wizards provide only restricted support for instantiating an interconnected set of mobile application screens. When creating a new screen, only a link to the parent screen can be specified. This link is used in the final mobile application for navigation. Additional concepts for the specification of reusable screens, screen flows and relations among them are not supported. Furthermore, as the ADT is specifically tailored to the Android platform, code and other artifacts for other platforms cannot be generated. 2 Methods, Techniques and Technologies 13
2.2.2 Sencha Touch and Adobe Phonegap
A common feature of modern smart phones is the support of latest web technologies like HTML5, JavaScript and CSS. Frameworks like Sencha Touch take advantage of this fact by providing UI toolkits based on these technologies. The toolkits provide predefined UI components. Websites utilizing such toolkits can be accessed and used by smart phone users almost like native applications. An example of such an application is the Sencha KitchenSink that is depicted in Fig. 2.2.2. Although it is a basically a website, it looks and behaves similarly to a mobile application that was built using the native SDK.
Nonetheless, these websites cannot provide Fig. 2.2.2: Sencha KitchenSink access to resources of the smart phone such application [SEN13]. as GPS or acceleration sensors. The Phonegap framework of Adobe adresses this issue by providing a JavaScript API to access native operating system functionality. The Phonegap framework is available for all major mobile platforms. In addition to providing access to resources of smart phones, Phonegap also allows developers to package web technology based applications into installable applications. These applications then can be used almost like native mobile applications. Thus, platform-independent applications can be easily developed by using Sencha Touch and Phonegap in combination.
Although common UI components are provided such applications might not comply with the style guides of one or more platforms since they provide a single interface for multiple different platforms. Even when style guide conformity can be achieved, it requires a much effort to build up and maintain the conformity of the UI. Additionally, the performance of JavaScript compared to applications written in a platform's native programming language is inferior. Furthermore, frameworks 14 Peter Reuter, University of Kaiserslautern
such as Sencha Touch do not provide explicit support for reusing screens, screen flows and the relations among them.
2.2.3 Cross-compilation
Puder [PUD10] presents an approach for cross-compiling Android applications for the iOS platform. Thereby, instead of two code-bases only a single code-base needs to be maintained. The Android platform was chosen as the code-base due to the heterogeneity of available Android devices and a larger amount of tools for the Java programming language.
The cross-compilation approach is depicted in Fig. 2.2.3. After developing the Android application the presented approach compiles the Java source code to class files using a regular Java compiler. Afterwards, an XML-representation of the byte code is generated. This stack-based XML-representation is transformed into a register-based format using instructions of Android's Dalvik virtual machine. In contrast to the Java programming language the Objective-C programming language does not provide garbage collection. Therefore, instructions for correct memory management Fig. 2.2.3: Cross-compilation are injected in the next step. The XMLVMDEX-MEM process, adapted from [PUD10, format is then used to generate the final Figure 2] Objective-C code.
According to the author the main problem areas are the aforementioned memory management and the mapping of APIs. The API mappings are achieved via a compatibilty library that maps widgets, resources such as media files and layouts to the Objective-C target platform. In a prototypical implementation the general feasibility of the approach was shown. Nonetheless, Puder states that the 2 Methods, Techniques and Technologies 15 approach can be applied more easily to games as they are not widget-driven as other applications.
The cross-compliation approach can be used to a certain extend to provide mobile applications for both the Android and iOS platform. Nonetheless, it provides no support for reusing existing screens, screen flows and the relations among them in new mobile applications.
2.2.4 PhoneApps
In Mannadiar and Vangheluwe present an approach for generating Android applications from domain-specific models [MAN10]. The authors suggest a layered model transformation approach. Each transformation decreases the level of abstraction and leads to an intermediate model.
The proposed PhoneApps DSL serves as the starting point. It allows developers to specify visual structure and behavior of a mobile application. The visual structure is comprised of container, widgets and actions (platform-specific features like dialing a number). The behavior describes the flow between containers via timed, conditional, and user-prompted transitions. According to the CAMELEON Reference Framework, the PhoneApps DSL can therefore be seen as a mixture of AUI and CUI. As depicted in Fig. 2.2.4, this initial instance of the DSL is afterwards Fig. 2.2.4: PhoneApps layered model transformation approach transformed to a state chart in order to extract the behavioral components. Additionally, the containers and actions of the visual structure get related to Android-specific artifacts like Java source code or XML source code by a second transformation. The next transformation assembles the two generated intermediate models into an abstract AndroidAppFiles model. According to [MAN10], the AndroidAppFiles model simplifies debugging and can later be output to real files. Finally, the AndroidAppFiles model is transformed into 16 Peter Reuter, University of Kaiserslautern
actual files that can be compiled into an Android mobile application using the Android SDK.
The PhoneApps approach has several advantages. It provides abstract descriptions of mobile applications. These descriptions are then transformed into platform-specific artifacts. Furthermore, the reuse of PhoneApps snippets and therefore of partial specifications of mobile applications is possible. But also, the PhoneApps approach relies on the Android platform and is not available for other platforms. Furthermore, knowledge about style guides is hard-wired into the model transformer and code generator. Additionally, it provides no explicit reuse of screens, screen flows and relations among them.
2.3 Summary
In Chapter 2 the fundamental principles, the frameworks that are used by the approach presented in this thesis and similar approaches that target the problems mentioned in chapter 1.1 were presented.
First MBUID was introduced. It was said that MBUID has several advantages such as the separation of concerns introduced by the various models. The CAMELEON Reference Framework was introduced. The MobileUI DSL was classified using the CAMELEON Reference Framework as an AUI model. Next, the concept of DSLs was presented. Again, the DSL that are presented later-on were classified. They were said to be declarative DSLs that furthermore serve as input to a code generator. Next, the Xtext was presented. The framework offers a a rich set of tools to DSL authors for developing new DSLs. Furthermore, patterns were said to be well-known in the field of UI design. Pattern galleries already exist for traditional desktop interfaces, but mobile UI pattern are still an emerging field. Afterwards, the Freemarker template framework was introduced. The Freemarker library is used by the later-on presented code generator to adapt the available pattern solutions according to the context these patterns are used in. Lastly, approaches for platform-independent mobile UIs and mobile UI generation were presented and basically analyzed for the applicability to the given problems. Though each of these approaches offers a rich set of features, none of them 2 Methods, Techniques and Technologies 17 explicitly provides the possibility to reuse screens, screens flows and the relations among them.
3 The Mobile UI DSL 19
3 The Mobile UI DSL
In Chapter 2.2 it was shown, that none of the presented approaches solves all problems mention in Chapter 1.1. While all approaches aim to solve certain problems, especially the problem of reusing screens, screen flows and the relations between them remains unsolved. This chapter presents a solution to this problem that still considers the multitude of different platforms.
The relations between screens are mostly defined by inter-screen navigation and hierarchical structures in which screens are embedded. Therefore, Chapter 3.1 presents navigation concepts of the major mobile operating systems Android, Apple iOS and Microsoft Windows Phone 7. As explained in Chapter 2.1.4, patterns are a way to support reuse when creating user interfaces. Therefore, commonly used patterns from various pattern libraries are presented. These patterns are used by the code generator prototype presented in Chapter 4. The analysis is then turned into requirements in chapter 3.2. Finally, Chapter 3.3 presents the implementation of the requirements in form of two DSLs. The main DSL provides concepts for defining mobile user interfaces and especially supports the reuse of screens flows. Furthermore, an auxiliary DSL that captures patterns is used by the main DSL in order to support reuse on a screen level.
3.1 Analysis of Mobile Applications
Following, common navigation concepts are presented in platform-independently. Furthermore, the platform-dependent implementation of these concepts is presented by platform and finally summarized in an overview.
In addition, screens that are often used in mobile applications are presented in their abstract form as UI patterns in Chapter 3.1.2. The patterns are derived from several pattern galleries. They present a platform-independent solution as well as an example from a real mobile application. 20 Peter Reuter, University of Kaiserslautern
3.1.1 Navigation Concepts
The differences between traditional desktop computers and smart phones such as screen size and input methods require new navigation concepts. The following concepts can be found commonly:
• Hierarchical navigation: The screens of a mobile application can be ordered hierarchically. Hierarchical navigation leads from one screen to its parent.
• Temporal navigation: Moving backwards through the list of most recent screens.
• Content navigation: Touching content elements such as list entries leads to a different screen.
• Navigation via toolbars: A toolbar is provided that contains e.g. the title of the current screen and menu items. These toolbar items provide options to interact with content elements (e.g. “delete”, “edit”) or can trigger navigation to another screen.
These navigation concepts are implemented differently by the different platforms.
Platform-independent Concept Implementations Common to all of the analyzed mobile operating systems is the navigation via content elements. As depicted in Fig. 3.1.2, clicking on an element (1) can trigger navigation to a (sub-) screen e.g. representing details of the element (2).
Furthermore, toolbars with toolbar items provide options to interact with content elements and can trigger navigation to another screen. Although the appearance differs between platforms, the Android “Actionbar”, iOS “Toolbar” and Windows Phone 7 “Application
Bar” provide the same functionality. An Fig. 3.1.1: Android Action Bar of the Android example of a toolbar is depicted in fig. Gallery mobile application 3 The Mobile UI DSL 21
3.1.1. The Android “Actionbar” (1) contains entries for e.g. sharing images (2) or deleting (3) them from the mobile device.
Android-specific Concept Implementations Hierarchical implementation is implemented via an “Up” button. The “Up” button is available since Android version 3.0 and enables hierarchical navigation within a mobile application. An example is shown in Fig. 3.1.2: selecting an entry in the Google Currents application leads to a detail screen presenting the details of an article of a magazine. Clicking the “Up” button (2) leads back to the previous overview. Often, as in this example clicking “Up” has the same effect as clicking the “Back” button.
Fig. 3.1.2: Google Current mobile applications, hierarchical navigation and navigation via content.
The Android platform provides temporal navigation via a system-wide “Back” button that navigates through history of previous screens. As the “Back” button is system-wide available it does not only take into account previous screens of the current application but also those of other applications. For example clicking on a YouTube link in the browser application commonly opens the YouTube 22 Peter Reuter, University of Kaiserslautern
application. Clicking the “Back” button will bring the user back to the browser. This default behavior is provided by the Android platform but can be overridden by developers. Overriding the default behavior can lead to a inconsistent user experience and should therefore be used carefully.
“Windows Phone 7”-specific Concept Implementations The Microsoft Windows Phone 7 platform does not provide hierarchical navigation. Nonetheless, it provides temporal navigation via a “Back” button that is similar to the “Back” button of the Android platform. As with the Android platform the button is system-wide which means that temporal navigation encompasses the screens of the current application as well as screens of other applications. This standard behavior is provided by the platform but developers can decide to override the default behavior. Again, overriding the default behavior can lead to a inconsistent user experience and should therefore be used carefully.
iOS-specific Concept Implementations The Apple iOS operating system provides a dedicated navigation bar. This toolbar commonly contains a “Back” button for hierarchical navigation. Furthermore, it can also contain content specific controls such as filters to manage contents of screen.
Temporal navigation as it is provided by the Android or Microsoft Windows Phone 7 platform is not available on the Apple iOS platform.
Summary
Android WP7 iOS Hierarchical Navigation X X Temporal Navigation X X Content Navigation X X X Navigation via Toolbars X X X
Table 3.1: Summary of navigation concepts in Android, Microsoft Windows Phone 7 and Apple iOS
3.1.2 Frequently Used Screens
Following, frequently used screens of mobile applications are presented in the abstract form of mobile UI patterns. In the later-on presented code generation approach these patterns serve as default implementations for screens. The 3 The Mobile UI DSL 23 default implementations can be used after code generation by developers as a starting point for creating customized implementations. The context section of the patterns describe that context a pattern should be used in. The pattern solutions takes into account this general context information, but needs to be adapted to the concrete context a pattern is used in.
Confirmation The “Confirmation” pattern can be found in the 4ourth pattern gallery [4OUa].
Problem: A process for collecting information comes to an end. The user might not remember all information that she entered.
Context: Long lasting processes involving multiple screens and large data sets. Solution: The user needs to be presented with a summary of the data that was entered. She needs to confirm the presented information in order to make sure that she made no mistakes.
Example: Fig. 3.1.3 shows the Fig. 3.1.3: Confirmation view of the Sixt Confirmation view of the Sixt Car/Truck Car/Truck Reservation Android application. Reservation Android application. Collection data, return data, vehicle type and total price have to be confirmed by the user via the “Reservieren” button. 24 Peter Reuter, University of Kaiserslautern
Grouped Rows The “Grouped Rows” pattern can be found the Neil's pattern gallery [NEI12].
Problem: A large dataset needs to be displayed in a list. The user needs support while digesting the data.
Context: Large datasets with entries that differ in one or more criteria.
Solution: Group the entries by the criteria in which they differ.
Example: Fig. 3.1.4 shows the Grouped Rows view of the the Google Contacts Android application. Entries are grouped by the first letter of a contact's forename.
Fig. 3.1.4: Grouped Rows view of the the Google Contacts Android application.
Login The “Login” pattern can be found in Neil's pattern gallery as the “Sign In” pattern [NEI12] and in the Android Interaction Design Patterns gallery as the “Login” pattern [AND13].
Problem: Access to a mobile application or parts of it must be restricted.
Context: Personal or sensitive data stored by a mobile application needs to be protected.
Solution: Let the user authenticate by a user name and password. Fig. 3.1.5: Login view of the Sixt Car/Truck Reservation Android application. 3 The Mobile UI DSL 25
Example: Fig. 3.1.5 shows the Login view of the Sixt Car/Truck Reservation Android application. After login the user is able to access, modify or cancel current and previous reservations.
Master Detail (Nokia) The “Master Detail” pattern can be found in the Nokia pattern gallery [NOK13].
Problem: Displaying detailed information for many entries of a large dataset can distract the user.
Context: A dataset with entries that contain detailed information.
Solution: Display a list with all entries and reduced information along with a separate view that shows detailed information for the currently selected list item.
Example: Fig. 3.1.6 shows the MasterDetail view of the Google Contacts Android application. The details of the contact the was selected last from the list of all contacts are displayed on the right. The list only provides information about the name of the contact whereas the details view provides all information such as telephone numbers and e-mail addresses.
Fig. 3.1.6: MasterDetail view of the Google Contacts Android application. 26 Peter Reuter, University of Kaiserslautern
Search The “Search” pattern can be found in various galleries using different names [4OUb, AND13, NEI12].
Problem: Seeking a single entry within a dataset with many entries can take long.
Context: Large dataset with many entries.
Solution: Provide a search field that
allows the user to enter search term. Fig. 3.1.7: Search view of the Google Only entries matching the search term Contacts Android application. will be displayed.
Example: Fig. 3.1.7 shows the Search view of the Google Contacts Android application. The search term in the search field (1) restricts the list of displayed contacts (2) to those that match the search term.
Simple List The “Simple List” pattern can be found in Neil's as well as the 4ourth pattern gallery [4OUc, NEI12]
Problem: A simple dataset needs to be displayed.
Context: -/- Solution: Show the entries in a list. Display the most important information in bold print. Add additional information in light print if necessary.
Example: Fig. 3.1.8 shows the Simple List view of the Theke Android application. Popular videos of the Fig. 3.1.8: Simple List view of the “Theke” second channel of German television Android application. 3 The Mobile UI DSL 27 broadcasting are displayed. The videos title is shown in bold print as the main information. Additional data such as broadcasting date and length of the video are presented in light print.
3.2 Derived Requirements
The following requirements were derived from the previous analysis of navigation concepts as well as the problems and general challenge presented in Chapter 1. The requirements are used as a basis for the DSLs that are presented in Chapter 3.3.
3.2.1 General
As a general premise, the following requirements have to be met by an approach that solves the initially presented challenge and problems:
1. The approach supports the specification of a mobile application's meta information consisting of application name, name space and vendor/author.
2. The approach supports the generation of executable mobile applications that provide a basic, pattern-based UI and full navigation between the different screens.
3. The approach supports the generation of code stubs for manual implementation. Manual changes of these stubs must not be reverted by code re-generation.
3.2.2 Navigation
The navigation concepts presented in Chapter 3.1.1 can be summarized by the following main requirements. Additional requirements were added in order to increase practicality.
Main 1. The approach supports the concept of hierarchical navigation between screens. 28 Peter Reuter, University of Kaiserslautern
2. The approach supports the concept of linear navigation between screens (screen flows). Thereby, e.g. a process or steps of a user task can be represented.
3. The approach supports the concept of non-linear navigation via content elements.
4. The approach supports the concept of non-linear navigation via toolbars.
5. The approach provides the possibility to reuse existing screen flows by integrating references to them into other flows.
Additional 1. The approach supports nested screen flows, i.e. the decomposition into sub-flows. Screen flows can represent user tasks which might have subtasks that can be represented by sub-flows.
2. The approach supports the composition of complex or often used flows in separate files.
3. The previous requirements also requires the possibility to import such external flow definitions
3.2.3 Screens
1. The approach supports the integration of UI patterns in order to provide a default implementation for screens.
1. The approach supports developers while accessing the available patterns.
2. A referenced pattern can be adapted to the given context. The context consist of the hierarchical structure a screen resides in as well as user-defined values for pattern parameters that are required to instantiate a pattern's solution.
2. A single screen can be marked as as the entry point to the mobile application.
1. Additional entries for toolbars can be specified that support custom implementations of the toolbar items. 3 The Mobile UI DSL 29
3.3 The MobileUI DSL
This chapter presents the MobileUI DSL in detail. The DSL was developed in order to meet the requirements presented before.
1 PatternParameterInstance: 2 3 SimpleParameter | SpecialParameter 4 5 ; Listing 3.1: The “PatternParameterInstance” grammar rule
1 SpecialParameter: 2 type=SpecialParameterType '=' 3 ( screen=[Flow|FQN] | 4 '['screens+=[Flow|FQN](','screens+=[Flow|FQN])*']' ) 5 ; Listing 3.2: The “SpecialParameter” grammar rule
1 SimpleParameter: 2 patternParameter=[Pattern DSL::Parameter|FQN] '=' 3 ( value=STRING | 4 screen=[Flow|FQN] | 5 '['values+=STRING(','values+=STRING)*']' | 6 '['screens+=[Flow|FQN](','screens+=[Flow|FQN])*']' ) 7 ; Listing 3.3: The “SimpleParameter” grammar rule First, the grammar rules of the MobileUI DSL as well as those of the auxiliary Pattern DSL are presented. The meaning of the rules and relations among them are highlighted. Second, context conditions are presented that add further restrictions to the DSL and could not be expressed by the grammar. Nesting flows and screens is the key to the implicit description of hierarchical and linear navigation concepts represented by the DSL. Its semantics are presented in Chapter 3.3.4. 30 Peter Reuter, University of Kaiserslautern
3.3.1 MobileUI DSL Grammar
MobileUI The “MobileUI” rule is the starting point for either the definition of a mobile application or list of flows. The rule allows developers to make “import”
1 MobileUI: 2 3 imports += Import* 4 5 ('MobileUI' '{' 6 7 'AppName' '=' appName = ID 8 9 'NameSpace' '=' nameSpace = FQN 10 11 'Author' '=' author = STRING 12 13 'Path to PatternRepository' '=' patternRepositoryPath = STRING 14 15 (demoUI ?= 'Generate Demo UI')? 16 17 (screens += Screen)+ 18 19 20 '}' | 21 22 (flows += Flow)* 23 24 ) 25 26 ; Listing 3.4: The “MobileUI” grammar rule statements. These statements specify files from which elements of external flow definitions.
The first part of the remainder of the rule can be used to define a new application. The self-explanatory statements “appName”, “nameSpace”, “author” provide meta-data that is commonly required when creating a new mobile application. The “patternRepositoryPath” statements indicates where the pattern solutions are located on the local storage. The “demoUI” statement indicates whether a rudimentary but executable application or code stubs for further refinement should be generated. The “startScreen” statement specifies the hierarchical topmost screen. This screen is used as the main application screen and displayed when the mobile application is started. 3 The Mobile UI DSL 31
The second part of the remainder of the rule allows the definition of a list of flows. Files matching this part of the grammar rule can be imported by those files, that 1 Parameter: 2 'Parameter' '{' 3 'ParameterName' '=' name = ID 4 'ParameterType' '=' (parameterType = Type) 5 (optional ?= 'optional')? 6 '}' 7 ; Listing 3.5: The “Parameter” grammar rule match the first part of the rule. This makes it possible to divide a single large application description up into several smaller sub-descriptions. Furthermore, it allows developers to reuse flow definitions as they can integrate them into any other MobileUI instance via “import” statements.
Import “Import” statements specify names of files containing external flow definitions. 1 Import: 'import' importURI=STRING; Listing 3.6: The “Import” grammar rule
Flow The “Flow” rule is a three-part rule consisting of screens, flows and flow references.
“Screen” statements specify atomic flows. They define a screen of the application which users of a mobile application can interact with. Additional information on screens can be found in the description of the “Screen“ rule.
The second option can be used to specify a flow. This provides support for hierarchical decomposition and allows developers to split a flow into several sub-flows each containing screens or further sub-flows. The explicit semantics of nesting flows is presented in Chapter 3.3.4. In addition, flows provide a unique name that can be used for referencing e.g. via “FlowReference” statements.
1 Flow: 2 Screen | 3 'Flow' '{' 4 'id' '=' name = ID 5 (flows+=Flow)* 6 '}' 7 | 8 FlowReference 9 ; Listing 3.7: The “Flow” grammar rule 32 Peter Reuter, University of Kaiserslautern
Finally, the “FlowReference” statement provides support to reuse existing flows at several points of the mobile application. A further description of the “FlowReference” statement can be found in the description of the “FlowReference“ rule.
All three options can be represented in the grammar by referencing rule “Flow” which enables rudimentary polymorphism.
FlowReference “FlowReference” statements refer to an existing flow defined in the main file or any imported file. They provide support for reusing flows definition and their integration as a sub-flow into the current flow. The explicit semantics of flow references are presented in Chapter 3.3.4. 1 FlowReference: 2 'FlowReference' '=' refFlow=[Flow|FQN] 3 ; Listing 3.8: The “FlowReference” grammar rule
Screen The “Screen” statement defines a screen of the application. Each screen has a unique name defined via “name” statement. In addition, each screen references a pattern via the “PatternInstance” rule. Patterns representing frequently used screens and therefore encouraging reuse are made available via the Pattern DSL that is presented in Chapter 3.3.2. 1 Screen: 2 'Screen' '{' 3 'id' '=' name = ID 4 pattern = PatternInstance 5 (flows+=Flow)* 6 (actions+=Action)* 7 '}' 8 ; Listing 3.9: The “Screen” grammar rule
Subsidiary screens, flows and flow references are encapsulated within a screen. Thereby, the user interface of a mobile application can be further decomposed into flows that can be started in this screen.
“Action” statements provide definitions of toolbar items that are available in the toolbar of the screen. They are described in detail in the explanation of the “Action“ rule. 3 The Mobile UI DSL 33
Action “Action” statements provide definitions for toolbar items that are available in the toolbar of the screen. An actions “name” statement represents the label of the toolbar item. 1 Action: 2 'Action' '{' 3 'id' '=' name = ID 4 ('target' '=' target = [Flow|FQN] | 'custom') 5 '}' 6 ; Listing 3.10: The “Action” grammar rule
Developers can choose between “custom” actions that indicate the generation of a code stub that has to be implemented by developer and a “target” statement that triggers navigation to a certain screen, flow or flow reference.
PatternInstance Available patterns are defined in a separate file using the Pattern DSL. The file is imported via “import” statement. The instantiation of a pattern by a screen provides a standard implementation for the code generator. The “Parameters” statement provides values for parameters specified by patterns. The pattern parameters are explained in detail in the description of the PatternParameterInstance rule. 1 PatternInstance: 2 'Pattern' '=' patternRef = [Pattern DSL::Pattern|FQN] '{' 3 parameters+=PatternParameterInstance* 4 '}' 5 ; Listing 3.11: The “PatternInstance” grammar rule
PatternParameterInstance “PatternParameterInstance” elements specify values for parameters defined by a pattern solution. They are used during code generation as input for instantiation these solutions. Authors can specify simple parameters consisting of a reference to a parameter of a pattern and a value. Values can be simple string literals, references to existing “Flow” elements or lists of both. Furthermore, special parameters can be specified. Instead of referring to the parameter of a pattern, they specify a value from the “SpecialParameterType” rule. 34 Peter Reuter, University of Kaiserslautern
Additional Types Special parameters can be used to override the implicit “parent”, “next” and “previous” relation for a given screen. These relations are presented in detail in Chapter 3.3.4. 1 SpecialParameterType: 2 'next' | 'previous' | 'parent' 3 ; Listing 3.12: The “SpecialParameterType” type
The “FQN” type makes it possible to reference elements not only by ID but by a fully qualified name. That means that a FQN then contains also all names of parent elements separated by dots such as “ParentScreen.Flow.ChildScreen”.
1 FQN: 2 ID('.'ID)* 3 ; Listing 3.13: The “FQN” type
3.3.2 Pattern DSL Grammar
The code generator presented in Chapter 4.2 uses Freemarker templates for the specification of platform-dependent solutions of patterns. These templates templates contain variables that are replaced during instantiation of the templates. Thereby, they declare an instantiation interface. In order to assigning a pattern to a screen knowledge about existing patterns and how their solutions are adapted to the context a pattern is used in is required. To this end, the Pattern DSL was created. This DSL allows the description of pattern catalogs, contained patterns and their interface/signature. As it is included by the MobileUI DSL grammar, elements of the Pattern DSL can be referenced from those of the MobileUI DSL.
PatternCatalog The “PatternCatalog” statement consists of a list of patterns. This list represents a mapping to existing pattern solutions. 1 PatternCatalog: 2 'PatternCatalog' '{' 3 (patterns+= Pattern)+ 4 '}' 5 ; Listing 3.14: The “PatternCatalog” grammar rule 3 The Mobile UI DSL 35
Pattern Each “Pattern” statement specifies the interface of a pattern solution via its “parameters” statement. As mentioned earlier, “Screen” statements can reference patterns via their “name” attribute which results in a new instance of the pattern solution created wrt. the context of the screen. 1 Pattern: 2 'Pattern' '{' 3 'PatternName' '=' name = ID 4 parameters+=Parameter* 5 '}' 6 ; Listing 3.15: The “Pattern” grammar rule
Parameter The context for pattern instantiation is not only represented by the hierarchical architecture but also by parameter references. Screens reference parameters via their “name” statement when providing concrete values for pattern instantiation. In addtion, the “parameterType” statement is used to ensure compatibility of concrete value and expected type. Finally, the “optional” statements indicates whether a value for a certain parameter has to be specified or can be omitted.
Type The “Type” rule used within “parameterType” statements of the “Parameter” rule provide developers with a set of commonly used types for parameters. It consists of a basic set of types as well as lists which can be parameterized with other types. 7 Type: 8 {Type} 'String' | 9 {Type} 'Integer' | 10 {Type} 'Boolean' | 11 {Type} 'Screen' | 12 List 13 ; 14 15 List returns Type: 16 'List<'type=Type'>' 17 ; Listing 3.16: The “Type” and “List” grammar rule 36 Peter Reuter, University of Kaiserslautern
3.3.3 Context Conditions
Some restrictions of the MobileUI DSL cannot be expressed by the presented grammar. Therefore, the following context conditions have to be satisfied in order to ensure processability of a MobileUI DSL instance:
1. Within a “Screen” statement only simple parameters of the referenced pattern as well as special parameters may be used.
2. All parameters of a pattern that are not optional have to be provided with values.
3. The types of the provided values and the parameter type that was specified in the Pattern DSL file have to match.
4. Each of the special parameters “parent”, “next” and “previous” may only occur once within a single “Screen” statement.
5. The “target” attribute of an “Action” statement may only refer to screens and flows that are defined by the “Screen” statement that defines the “Action” statement.
3.3.4 Semantics of Nested Flows and Screens
The MobileUI DSL does not use an explicit description of navigation between screens. Instead, nesting of screens and flows creates implicit relations.
The “parent” relation can be derived directly from the hierarchy. It expresses hierarchical navigation between screens. The parent screen of each screen can be determined by the algorithm that is depicted in Fig. 3.3.1. 3 The Mobile UI DSL 37
Fig. 3.3.1: Algorithm for determining the “parent” relation.
The “next” and “previous” relation express linear and inverse linear navigation between screens, respectively. Their derivation requires more effort. The “next”
Fig. 3.3.2: Algorithm for determining the “next” relation. 38 Peter Reuter, University of Kaiserslautern
relation can be determined by applying the algorithm that is depicted in Fig. 3.3.2. The “previous” relation can be determined similarly.
As can be seen from this algorithm, screens encapsulate flows. Separate “next” and “previous” relations for flows defined as children of a screen are created. These child flows and screens do not occur in the “next” relation of the flow in which the parent screen is defined.
Fig. 3.3.3 presents the visualization of an examplary MobileUI specification. The “parent” and “next” relation were determined using the above algorithms an highlighted in the figure. For screen S1, S2, S3 and S4 screen Sstart is determined as the parent screen by evaluating the hierarchical structure. In order to determine the “next” relation, it might be necessary to evaluate sub-flows (S1→S2) or to evaluate the hierarchical structure (S4→SStart).
Although the relations are defined implicitly developers can modify them for single screens by using the special parameters “parent”, “next”, “previous”. Values for these parameters include the referenced screen or flow into the relation that was determined by applying and executing the above rules and algorithm.
Fig. 3.3.3: Example for the “parent” and “next” relation 3 The Mobile UI DSL 39
3.4 Summary
In the last chapters, the foundations and concepts of the MobileUI and Pattern DSL were presented. First, an overview of navigation concepts and frequently used screens of the three major mobile platforms Android, Microsoft Windows Phone 7 and Apple iOS was given. It was shown that several navigational concepts are common to all platforms, while others such as as temporal navigation concept using a “Back” button are only available on certain platforms. Also, patterns such as the “Login” pattern were presented with an example application. The platform-dependent solutions provide a basic screen implementation that can be refined by developers after code generation. Then, requirements for a platform-independent DSL that faces the problems of Chapter 1.1 were derived from this basic analysis. Finally, the MobileUI DSL grammar and the Pattern DSL grammar were presented. The grammars were further restricted by context conditions that are required to ensure processability. The semantics of nesting flows and screens and the derivation of the implicit navigation relations were presented finally. It was shown that the “parent” relation can be derived quite simply, while in order to derive the “next” and “previous” relation more effort and a more complex algorithm are required.
4 Tool Support 41
4 Tool Support
In the previous chapter the MobileUI DSL for defining mobile user interfaces and the auxiliary Pattern DSL were introduced. The DSLs were developed according to the requirements that were presented in Chapter 3.2. This chapter presents the code generation approach that implements these requirements. The prototype allows developers to generate executable mobile application stubs that provide a basic, pattern-based UI and full navigation between the different screens.
The major tasks a developer has to perform when using this solution are creating and editing of new descriptions of mobile applications using the MobileUI DSL and generating executable stubs from these descriptions. The prototype provides tool support for these tasks. It is implemented as a set of Eclipse IDE plug-ins since until 05/2013 the major development platform for Android mobile applications was the Eclipse IDE [ADB13]. The different tasks are supported by separate plug-ins. A basic parser and editor for both MobileUI DSL and Pattern DSL is provided via the Eclipse Xtext framework. The editors feature e.g. Eclipse content assist and outline view. New MobileUI DSL files can be edited easily using the editors. Furthermore, a code generator is provided as a separate plug-in. Developers can use this code generator to generate fully functional Android mobile applications.
4.1 Eclipse Editors for DSL instances
4.1.1 DSL Text Editors
The Eclipse grammars for the MobileUI DSL and the Pattern DSL are specified using the Xtext grammar language. Therefore, editors for both can be generated automatically by the Xtext framework. The generation process results in separate Eclipse plug-ins providing an text editor implementation. The editors provide many features instead of simple text editing functionality. The editor's default functionality encompasses among other features auto-completion for specific values and cross-references, syntax highlighting, syntactic validation, linking errors and an outline view. 42 Peter Reuter, University of Kaiserslautern
Despite this rich set of feature the standard behavior of the default implementation is not sufficient in some cases. Especially the coverage of the context conditions that were presented in Chapter 3.3.3 has to be guaranteed. As it was mentioned earlier, these context conditions put further restrictions on the grammar. Therefore, checks for the context conditions can not be generated but must be implemented manually.
As depicted in Fig. 4.1.1, this can be Fig. 4.1.1: Generation and achieved by the Scope and Proposal customization of DSL Editors Providers presented following.
Also further drawbacks of grammar constructs need to be compensated by custom validity checks. The Custom Validation component checks whether the specified values for the “patternRepositoryPath” statement of the “MobileUI” rule as well as parameters and parameter values of instances of the “Screen” rule are valid.
Finally, a custom HyperlinkHelper was implemented, that links the screens with their resulting implementation. Thereby, developers can easily switch between the specification and the resulting implementation by the default Eclipse navigation mechanisms. 4 Tool Support 43
Scope Providers As presented in Chapter 3.3.2, the parameters of a pattern are specified in a Pattern DSL file. In the MobileUI DSL these parameters are referenced by the parameter “patternParameter” of the “SimpleParameter” grammar rule. The grammar does not allow developers to restrict the possible values any further (cf. Fig. 4.1.2, red arrows). Therefore, any parameter from any pattern can be selected. Instead of this default behavior the possible parameters should be restricted to the parameters of the pattern that is referenced by the subordinate instance of the “PatternInstance” grammar rule (cf. Fig. 4.1.2, green arrow).
Fig. 4.1.2: Wrong (default) and correct scoping of references to Pattern parameters.
The available pattern parameters are provided via scoping. By default, the Xtext framework generates a general scope that is only limited by the “Parameter” rule of the Pattern DSL. A more restrictive scope can be implemented by providing a custom Scope Provider that provide a scope for a given context. The scope restricts access to the compatible elements for a given reference[cf. XTD13, p. 97]. Here, the context is defined by the “PatternInstance” rule. A scope for the available pattern parameters can be created by a lookup of the referenced pattern. After the lookup, all parameters of the referenced pattern can be added to the new (and more restrictive) scope. 44 Peter Reuter, University of Kaiserslautern
Proposal Provider As no syntactic indicator is available that distinguishes the “SimpleParameter” rule from the “SpecialParameter” rule, the editor's default auto-completion does not suggest values for the “type” parameter of the “SpecialParameter” rule. The absence of the previously mentioned indicator provides a more transparent view of the DSL to the user. Nonetheless, the developer also has to be informed about the available “SpecialParameter” rule. Therefore, the auto-completion has to suggest the values “next”, “previous”, “parent” while specifying a “PatternParameterRule” instance. The missing values are provided by implementing a custom ProposalProvider that adds these values to the auto-completion list (see Fig. 4.1.3).
Fig. 4.1.3: Additional proposals for the explicit “next”, “previous” and “parent” provided by the custom Proposal Provider
Custom Validation The “patternRepositoryPath” statement of the “MobileUI” cannot be restricted to valid paths by default. Therefore, the Custom Validation checks whether the specified path points to an existing directory.
As is was already said, “SimpleParameter” rule instances simply point to parameters of the “Pattern” rule of the Pattern DSL. In addition to the restrictions implemented by the Scope Provider, the Custom Validation checks whether all required parameters are specified and whether they are specified not more than once. 4 Tool Support 45
In addition the Custom Validation checks whether the values specified by “SimpleParameter” rule instances can be converted to the type specified by the “PatternParameter” rule of the PatternDSL. The grammar rule for “SimpleParameter” restricts values to strings, flows and lists of both. This restriction reduces the complexity of the grammar. While the conversion checks are easy for screens and lists of screens other types require more effort. First of all it has to be checked if a list or a single value is required and whether it is also provided. Afterwards, it has to be checked if the type of all list values or the single value matches the type specified by the pattern parameter.
HyperlinkHelper The many tools for the Eclipse IDE provide several mechanisms for navigating within text editors via their content. Most common, pressing the 'CTRL' key and left mouse button leads to linked resources. For example pressing 'CTRL' + clicking on the name of a method in a Java source code file opens the implementation of the method. The same mechanism was implemented for the MobileUI DSL editor. As depicted in Fig. 4.1.4, pressing the 'CTRL' key+ clicking on a screen's name leads to the resulting implementation of the screen if already source code was generated. This is convenient for developers as functionality that
Fig. 4.1.4: Using the HyperlinkHelper to navigate from specification to implementation. 46 Peter Reuter, University of Kaiserslautern
is already known from e.g. the Eclipse Java development tools is provided also for the MobileUI DSL editor.
4.1.2 Visualization of DSL Instances
Working with large textual descriptions of a mobile application specified via the MobileUI DSL does not provide a comprehensive view of the different screens and their relations. The possibility to decompose these descriptions into several files makes them even less comprehensible.
A visualization of a complete mobile application description can provide developers with an overview on the different screens and their relations. The prototype presented in this thesis represents MobileUI DSL instances as a graphs. While nodes represent Screens and Flows, the implicit relations “next”, “previous”, “parent” as well as Actions are represented explicitly by edges.
Fig. 4.1.5: Visualization of a MobileUI DSL instance
As depicted in Fig. 4.1.5 (1), the graph is displayed in form of a tree. The tree layout is created via the hierarchical “parent” relation. Fig. 4.1.5 furthermore presents the implementation of the visualization which is integrated within the text editor for MobileUI DSL instances. Changes in the textual representation are immediately reflected in the graphical representation. As an additional feature, filters and layout options which are depicted by Fig. 4.1.5 (2) can be used to gain more overview by reducing the represented relations and resetting the layout, respectively. 4 Tool Support 47
Last, it has to be checked if values for all parameters of the referenced pattern that are not marked as being “optional” are specified. Although the ScopeProvider restricts parameters only to those of the referenced pattern, no further checks for illicit omission or duplicate specification of parameters are performed by the ScopeProviders implementation. Also for specification of “SpecialParameter” instances checks for illicit omission or duplicate specification have to be performed.
4.2 Code Generator for Android
As well as the DSL editors also the generator was realized as a separate Eclipse plug-in. The code generation approach used by the prototype is similar to ADT approach. It is based on meta templates that encompass dynamic as well as static content. Dynamic content denotes files containing Freemarker templates. The templates suffixed by “ftl” and are instantiated during the code generation process. Static content denotes all other content that is not processed. Examples are images or Fig. 4.2.1: Structure of Meta Templates library code.
As a starting point, the prototype provides an Eclipse wizard for creating new Android project based on the MobileUI DSL. The wizard uses a Base Meta Template to set up an Eclipse project. The generator provides developers with code stubs for UIs featuring complete navigation after the specification of a new mobile application via the MobileUI DSL editor. During the generation process, screens described by the MobileUI DSL instance are transformed into the Android equivalent “activities” via Screen Meta Templates. To this end, the generator uses data from the DSL instances and Screen Meta Templates that provide platform-specific solution to patterns. As it was said in Chapter 3.3.2, the parameters of the dynamic content are specified in a Pattern DSL instance. This instance provides the interface between the meta templates and the DSL. This 48 Peter Reuter, University of Kaiserslautern
allows the prototype to reference parameters as well as to check whether all necessary parameters were specified (cf. Chapter 4.1). The data that was retrieved from the MobileUI DSL instance is then passed to the Freemarker library which instantiates the dynamic content. The output of the Freemarker library as well as static content are then added to the already existing Android project.
In contrast to layout or menu descriptions the files “AndroidManifest.xml” and “values/strings.xml” are shared by several activities. Therefore, they cannot be simply copied but need to be merged with already existing versions of them.
More about the structure of meta templates is explained in chapters 4.2.1 and 4.2.2. As can be seen easily their structure is resulting from the project structure of Android Eclipse IDE projects.
4.2.1 Base Meta Template
The Base Meta Template presented in Fig. 4.2.2 is used to generate a basic Android project for the Eclipse IDE.
Fig. 4.2.2: Structure and content of the Base Meta Template
On the top level it contains the Eclipse project descriptor file “.project” with Eclipse specific configuration data. Furthermore, the “AndroidManfiest.xml” provides a declarative description of the Android application. According to [DEV13] it “presents essential information about the application to the Android 4 Tool Support 49 system”. It most importantly – in the context of this code generator – describes activities of the mobile application.
The “dsl” folder contains a basic MobileUI DSL file and a Pattern DSL file with the default pattern catalog. The screens presented in Chapter 3.1.2 are represented in the Pattern DSL file.
Finally the “libs” folder contains a library providing utility APIs and APIs that are not available for older platform versions while the “res” folder encompasses general resource files for e.g. String resources as well as images or icons.
4.2.2 Screen Templates
Screen Meta Templates provide platform specific solutions to the pattern presented in Chapter 3.1.2. They provide layout descriptions as well as implementation for the behavior of screens.
Fig. 4.2.3: Structure and common files of a Screen Meta Template
Just like the Base Meta Template, Screen Meta Templates contain an “AndroidManifest.xml” file. The file provides Information about the activity that is created from the MobileUI screen referencing the pattern. The information encompasses name, label and parent activity of the resulting activity. As 50 Peter Reuter, University of Kaiserslautern
mentioned earlier, the Screen Meta Template's “AndroidManifest.xml” file has to be merge into the main “AndroidManifest.xml” file.
The “res” folder contains among other files layout descriptions of the resulting activity and additional layout descriptions for e.g. list items or dialogs. Furthermore, menu descriptions that list items of the menus used within the activity are provided by the “res” folder. Most commonly, the menu descriptions encompass a toolbar menu. Additional resource files can vary between templates, but most common comprise additional String resources.
The “src” folder commonly contains source code that implements the behavior of the activity, but it can also contain library or helper code. Source code files ending with “Impl.java.ftl” are processed different from others. They provide code skeletons for which an implementation can be provided by the developer. This allows the developer to separate generated code for navigation or demo UIs from code that is to be implemented manually such as business logic. During re-generation these special files are not modified. In contrast, all other content is overwritten.
4.2.3 Navigation Controller Architecture
While generating the code that is necessary for navigating the final mobile application, a considering all relations is not possible. Referencing existing flows increases complexity, as “next”/”previous” and “parent” relations depend on context in which a flow is included or specified. In order to cope with this complexity the navigation task can be decomposed. During code generation, the children, i.e. screens, flows and flow references, of each flow are known. The Navigation Controller Architecture makes use of this fact.
Basically, a central instance that knows about flows and one component per flow called Navigation Controller are provided. Each Navigation Controller handles the navigation within its respective flow. The Navigation Controllers provides methods for navigating via the “next”/”previous” and “parent” relations. If navigation via one of the relations is request by a screen, navigation control is delegated to the Navigation Controller for the flow that contains the screen. The Navigation Controller then determines the next screen. If the sibling of the requesting screen 4 Tool Support 51 is a flow or flow reference control is delegated to the respective Navigation Controller and returned after the last screen of the child flow.
Fig. 4.2.4: Classes of the Navigation Controller Architecture
Besides the Navigation Controllers for flows, an additional Application Navigation Controller that handles initial navigation for top-level screens is provided.
The implementation of the Navigation Controller Architecture is depicted in Fig. 4.2.4. The NCRegistry serves as a central instance that knows about the specified flows and their respective Navigation Controllers. A Navigation Controller can be retrieved from the NCRegistry via its Java class name. The code for evaluating the “next”/”previous” and “parent” navigation calls from screens does not depend on a specific flow. Therefore, the Navigation Controller implementations are split up into an abstract class the handles the default navigation resulting from the relations and a flow-specific class for handling navigation via toolbar action. The AbstractMobileUIActivity extends the default Android Activity class and provides code to get the responsible Navigation Controller from NCRegistry, Activities provided by screen meta templates should subclass AbstractMobileUIActivity, as the retrieved Navigation Controller can be used by subclasses. Thereby, developers do not need to retrieve the responsible Navigation Controller but can simply use it. 52 Peter Reuter, University of Kaiserslautern
The interaction of all of these components is highlighted using the exemplary screen/flow structure depicted Fig. 4.2.5. During code generation, an Android activity SXActivity that represents screen “SX” Fig. 4.2.5: Example screen/flow structure is created. The activity extends the AbstractMobileUIActivity class. When SXActivity is instantiated, its responsible Navigation Controller “FCNavController” representing flow “FC” is retrieved from NCRegistry via code provided by its superclass AbstractMobileUIActivity. As Fig. 4.2.6 depicts, SXActivity can call navigation methods on this Navigation Controller. An exemplary executing of a “navigateNext” call is presented in Fig.
Fig. 4.2.6: Retrieving the Navigation Controller and using it within a concrete Android Activity that represents a screen
Fig. 4.2.7: Executing a “navigateNext” call 4 Tool Support 53
4.2.7. According to the “next” relation, either the next screen is presented. If there is no next screen, control is delegated to the parent Navigation Controller or the parent screen is presented. Furthermore, if the next element of the flow is a flow itself, navigation control is delegated to the flow's respective Navigation Controller and returned after the last element of this subflow.
4.2.4 Generation Process
In the previous chapters, the artifacts that are generated during the generation process were presented. A base template for MobileUI DSL projects, Screen templates and the Navigation Controller architecture were highlighted. The generation process uses these artifacts as follows.
At first, a new MobileUI DSL Project needs to be created by the developer. This can be achieved easily using the Eclipse “New Project” wizard that was mentioned in 4.2. The project that is generated by using the base meta template. After all necessary data such as screens and flows is specified in the main MobileUI DSL file, the code generation process can be started.
At first the activities resulting from the specified screens are generated as depicted in Fig. 4.2.8. The MobuileUI DSL data is parsed from its textual representation into a representation the can be process by the Freemarker library.
Next, each file of the dynamic content of the required meta template is processed by the Freemarker library which uses the DSL data as input. In addition to this all occurrences of parameter names occurring in the DSL data are replaced in the final file paths. Consider the following exemplary meta data:
• appName=“ExampleApp”
• nameSpace=“com.example”
• screenName=“StartScreen”
Given this data, the templates file path
• “src/nameSpace/appName/screenName.java.ftl” results in the actual file path
• “src/com/example/exampleapp/StartScreen.java”. 54 Peter Reuter, University of Kaiserslautern
Next, the final contents are copied to their respective locations in the target Android project. As mentioned in 4.2.2, the files “AndroidManifest.xml” and “values/strings.xml” are treated separately. Finally, the Navigation Controller Architecture is established as presented in Chapter 4.2.3.
Fig. 4.2.8: Generation process for a single Screen
4.3 Summary
In the previous chapters, a prototypical code generator that implements the requirements of Chapter 3.2 was presented. The prototype It was realized as a set of Eclipse IDE plug-ins. The different plug-ins support developers while conducting the major tasks of editing DSL instances and generating code stubs.
First, text editors for both DSLs were presented. The editors were generated using the DSL grammar and Xtext framework. The standard implementation provided by the Xtext framework already provides advanced features such as auto-completion and syntax highlighting. Nonetheless, the implementation was 4 Tool Support 55 adapted in order to guarantee satisfaction of the context conditions presented in Chapter 3.3.3. The custom adaptations were provided by Scope and Proposal Providers as well as custom validity checks.
1 package com.example.BusinessTrips; 2 3 public final class BusinessTripsImpl extends BusinessTrips { 4 5 protected boolean login(String userName, String password) { 6 // TODO implement login method 7 return false; 8 } 9 10 } Listing 4.1: Default content of “BusinessTripsImpl.java”, resulting from “Login” pattern
1 package com.example.BusinessTrips; 2 3 import android.net.ConnectivityManager; 4 import com.example.logic.services.AuthenticationService; 5 6 public final class BusinessTripsImpl extends BusinessTrips { 7 8 protected boolean login(String userName, String password) { 9 10 ConnectivityManager conMan = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE); 11 if (conMan.getActiveNetworkInfo() != null && conMan.getActiveNetworkInfo().isConnected()) { 12 13 AuthenticationService authService = new AuthenticationService(); 14 return authService.checkCredentials(userName, password); 15 16 } 17 18 return false; 19 } 20 21 } Listing 4.2: Examplary implementation of the “BusinessTrips” screen Second, the actual code generator was presented. Meta templates consisting content that is dynamically adapted to given contexts as well as static content provided the basis for the code generation approach. The structure of the presented meta templates results from the Eclipse Android project structure. In order to specify a new mobile application at first an Eclipse Android project is generated via an Eclipse “New Project” wizard that utilizes the Base Meta 56 Peter Reuter, University of Kaiserslautern
Template which represents the default Andrdoi project structure. The new mobile application's specification can then be modified via dedicated text editors. The specification is then turned into executable stubs via Screen Meta Templates which presented platform-specific solutions to the patterns of Chapter 3.1.2.
Last, a graph-based visualization for MobileUI DSL instances was presented as the textual representation of large or even decomposed mobile application specifications does not provide a comprehensive overview. Also the implicit navigation relations are sometimes not easy to understand. The visualization provides an overview on the complete mobile application specification as well as an explicit representation of these relations. Therefore, screens and flows as well as the implicit relations are represented as nodes and edges of the graph, respectively. 5 Evaluation 57
5 Evaluation
The previous chapters presented an approach that aims to solve the problems mentioned in Chapter 1. In this chapter an example application is presented and used as a basis for comparing the traditional development and development of mobile applications using the MobileUI DSL.
First an overview and informal description of a mobile application for managing business trips called “BusinessTrips” is presented. The informal description is then turned into a UI specification using the MobileUI DSL grammar presented in 3.3. Next, the artifacts resulting from the code generation process are presented. A special focus is put on the generation of a DemoUI in contrast to the final application. Finally, the approach is compared to traditional development in terms of initial and long-term effort.
5.1 Description and Specification
Following a fictional, informal description of a mobile application as a customer could give it to developers can be found.
“The 'BusinessTrips' mobile application provides a UI for viewing future and past business trips. Additionally, the possibility to add new business trips has to be provided. When creating a new business trip, basic data consisting of the trips designation and date, possible night stops, in detail hotel, room and duration of night stops, and means of transportation need to be provided. Additionally, a cost center for night stops and means of transportation is mandatory which should be chosen via a single UI. In order order to protect the private data of business trips from unauthorized persons, a possibility for user authentication has to be provided by the mobile application.”
A developer can create a specification of screens and screen flows using the MobileUI DSL in turn. Fig. 5.1.1 presents possible screens and flows of resulting from the informal specification as well as visual representation of the implicit 58 Peter Reuter, University of Kaiserslautern
relations between the different screens. A complete textual specification can found found in Chapter 10.3. As can be seen, access to the application is restricted via a “Login” screen. Current and past business trips can be viewed via the “BusinessTrips_Overview” screen providing a list grouping business trips into the categories “BusinessTrips – current” and “BusinessTrips – past”. Additional information on single business trips can be viewed via the “BusinessTrips_Details” screens. The “Businesstrips_Overview” screen furthermore provides a toolbar action "New_BusinessTrip” that starts the “New_BusinessTrip” flow for adding new business trips. The data for new business trips is acquired via the subflows “BaseData”, “Night_Stops” and “Means of Travel”. As required by the informal specification, the “Choose_CostCenter” flow is reused within “Night_Stops” and “Means_of_Travel” flow via flow references. As it is defined separately, it can be easily reused within other mobile applications.
Fig. 5.1.1: Specification of the “BusinessTrips” mobile application with implicit relation “next” (purple) and action “New_BusinessTrip” (green) of screen “Businesstrips_Overview” 5 Evaluation 59
5.2 Code Generation
After the specifying screens and flows of the “BusinessTrips” mobile application via the MobileUI DSL, the source code for Android mobile application can be generated easily. As presented in Chapter 4.2, during code generation, the screen meta templates of the referenced patterns are instantiated. Source code for screens, layout and menu descriptions is generated. Furthermore, instances and library code is copied to the Android project. Finally, the Navigation Controller Architecture that is depicted in Fig. 5.2.1 is established as described in Chapter 4.2.3. As presented in Chapter 4.2.3, a subclass of the “AbstractNavController” class is created for each Flow, additionally one navigation controller for the whole mobile application. The implicit navigation relations were turned into code statements of “setup()” method of the NCRegistry class that is presented in Chapter 10.4.
After code generation, the mobile application can be executed directly. Screenshots of the "BusinessTrips”, “BusinessTrips_Overview” and “BusinessTrips_Details” screen are presented in Fig. 5.2.2. 60 Peter Reuter, University of Kaiserslautern
As the “Generate Demo UI” key phrase is used in the specification, only dummy content is generated, but no implementation for e.g. authentication or retrieving data is provided. Manual implementations are required for the application logic. Examples for such application logic are: ListAdapters for retrieving data from data sources and providing them to Android ListViews, authentication methods, or methods for searching in and filtering of ListViews. Furthermore, if required, layouts need to be adapted. These layouts can include: the layout of ListView items that should display more than a simple string, or the branding for customers via icons or colors. When the key phrase “Generate Demo UI” is removed from DSL instances, stubs for manual implementation of this business logic are created during code generation. Following, the exemplary implementation of the “BusinessTrips” screen that utilizes the “Login” pattern is presented. After removing the “Generate Demo UI” key phrase and code re-generation in addition to “BusinessTrips.java” the file “BusinessTripsImpl.java” exists. The default content of “BusinessTripsImpl.java” is presented in Listing 4.1. Now, a meaningfull authentication mechanism can be implemented within “BusinessTripsImpl.java”. The manual implementation presented in Listing 4.2 uses a fictional authentication service that could for example utilize a web service After the implementations for all generated stubs are created by the developer, the final application can be executed and tested on an Android device or the Android Emulator again. It has to be noted that no need to implement or modify code for navigation exists, as navigation is encapsulated by Navigation 5 Evaluation 61
Controllers and the “AbstractMobileUIActivity” class. Additionally, all other template specific code is encapsulated by implementation of screen meta template.
5.3 Comparison with Traditional Development
In the previous chapters, the informal and formal specification of a fictional mobile application for managing business trips as well as code generation based on the formal specification were presented. Following, the effort for creating an application using the MobileUI approach is compared to the required effort using the traditional development approach for the Android platform.
At first, the initial effort when creating a single new mobile application is analyzed. Next, the long-term effort when maintaining existing applications or creating new applications based upon already existing applications is analyzed. Finally, a summary of the presented effort analysis is given.
5.3.1 Initial Effort
When starting the development of a new application, it is required for both approaches to derive a specification of the required screens and screen flows. Whether an unspecific approach like informal graphical or textual notations or a specification using the MobileUI DSL is created does not alter the required effort. Next, in traditional development an implementation for each screen is created manually. Furthermore, navigation code, that is hard-coded into the implementation of the screen needs to be implemented. In contrast, the MobileUI approach requires a set of templates that needs to be created first. As experience from the templates for the patterns presented in Chapter 3.1.2 shows, the creating of a template requires approximately ½ to 1 day per template. Subsequently, the first draft for the new mobile application can be generated and afterwards tested easily. As a next step business logic and custom layouts need to be implemented, which is common to both, the traditional and the MobileUI development approach. In addition, using the MobileUI development approach, new templates can be derived from custom implementations which in turn can be reused in future mobile applications. 62 Peter Reuter, University of Kaiserslautern
5.3.2 Long-term Effort
In traditional development new applications need to be created manually. Also when adding new screens to an existing mobile application each screen manually. Furthermore, altering screen flows requires to manually change the hard-coded statements for navigation. Although the possibility to reuse existing layouts and implementations exists, additional code that handles navigation needs to be implemented manually and changes to navigational structure require probably many manual changes. In contrast, the altering existing mobile applications using the MobileUI approach requires much less effort. Adding new screens simply requires the integration of them into an already existing MobileUI DSL file. When altering the screen flows, of already existing mobile applications, only the order of screens in the MobileUI DSL file needs to be changed and the code has to be re-generated. Furthermore, new mobile applications can be easily derived from already existing ones be using the already existing templates and reusing flows.
5.4 Summary
In the previous chapters, first, an informal description and formal specification of an exemplary mobile application presented. The code generation process and resulting artifacts of the MobileUI approach were presented. The transition from the generated UI to the final UI including business logic was highlighted using a screen referencing the “Login” pattern. Manual adaptation and implementation of application logic and Android layout specifications is required, but implementations the provided a basis for manual refinement are available. Finally, a comparison to traditional development showed that the initial effort is higher when using the MobileUI approach as the effort for setting up templates is high. In contrast, the long-term effort for traditionally developed applications is much higher. Altering the application or deriving new applications using the MobileUI approach can take advantage of already existing artifacts such as screen flow specifications or templates and thereby reduces effort. 6 Conclusion 63
6 Conclusion
6.1 Summary
In Chapter 1 the following challenge for developers of mobile applications was presented: “Minimize the amount of re-development while creating new mobile applications for similar business cases and porting existing mobile applications to new configurations”. As an additional problem, adherence to the style guides of the target platforms was mentioned. In order to achieve style guide conformity, developers need to be experts for the target platform of the mobile application. The approach that is suggested in this thesis targets the initial challenge and overcomes issues of existing approaches that were presented in Chapter 2.2.
The basic idea of the presented approach is to reuse and combine existing technologies. Model-based development is used to provide platform-independent description of mobile applications. Mobile UI pattern for frequently used screens featuring platform-dependent pattern solutions enable adherence to style guides. Finally, code generation is used to transform the platform-independent model into platform-dependent artifacts by using platform-dependent pattern solutions.
The presented prototype uses a DSL as the notation form for the model. The DSL provides the possibility for screens to refer to patterns such as the “Login” pattern. Tool support for creating and editing DSL instances and code generator for Android platform is implemented prototypically via the Xtext framework.
In order to evaluate the approach, an exemplary mobile application for managing business trips is presented. A comparison of traditional development and presented approach shows, that the initial effort when using the presented approach is higher. Nonetheless, the long term effort can be considered significantly less. Thereby, the approach solves the initial challenge. Screens and screen flows of existing applications can be easily integrated into new mobile applications. 64 Peter Reuter, University of Kaiserslautern
6.2 Future Work
The code generator for the Android platform presented in this thesis already shows the general feasibility of this approach. As a next step, additional code generators for the iOS and Windows Phone 7 platform need to be develped.
When additional code generators for the iOS and Windows Phone 7 platform are provided, the effort of providing mobile applications for the major mobile platforms is reduced. In order to further decrease the initial effort of developing new mobile applications, additional templates need to be provided. To this end, screens of existing mobile applications can be transformed into new pattern solutions by following the structure of the screen meta templates that were presented in Chapter 4.2.2. As the initial development of these screen meta templates showed, this task is time consuming and tedious without tool support. Therefore, appropriate tools for converting existing screens into screen meta templates need to be developed in order to reduce the effort that is required for conducting this task.
Further improvements could for example include an extended code generator that support partial code re-generation for regenerating only navigation code or a distinct set of screens. Additionally, embedding custom layout into generated layouts could be supported. Extensions to the MobileUI DSL could include additional abstractions via flow templates. Thereby, parameterized flows that can be adapted to the context they are used in could be provided. In addition, existing applications should be examined for flow patterns. It has to be checked whether flow patterns exist and how they can be formalized. 7 Bibliography 65
7 Bibliography
[4OUa] "Confirmation - 4ourth Mobile Design Pattern Library", 2013, http://4ourth.com/wiki/Confirmation, accessed 05.06.2013
[4OUb] "Search Within - 4ourth Mobile Design Pattern Library", 2013, http://4ourth.com/wiki/Search%20Within, accessed 05.06.2013
[4OUc] "Vertical List - 4ourth Mobile Design Pattern Library", 2013, http://4ourth.com/wiki/Vertical%20List, accessed 05.06.2013
[ADB13] "Android Studio: An IDE built for Android | Android Developers Blog", 2013, http://android-developers.blogspot.de/2013/05/android-studio-ide-built -for-android.html, accessed 08.07.2013
[ADT13] "ADT Plugin | Android Developers", 2013, http://developer.android.com/tools/sdk/eclipse-adt.html, accessed 07.02.2013
[ALE77] Alexander, C., "A pattern language: towns, buildings, construction", 1977
[AND13] "Android Interaction Design Patterns", 2013, http://www.androidpatterns.com/,
[BIT13] "Tablet Computer drängen in die Berufswelt", 2013, http://www.bitkom.org/de/presse/8477_75913.aspx, accessed 13.05.2013
[CAL2003] Calvary, G., Coutaz, J., et al., "A unifying reference framework for multi-target user interfaces", 2003
[CZA05] Czarnecki, K., "Overview of generative software development", 2005
[DEU00] van Deursen, A., Klint, P., Visser, J., "Domain-specific languages: An annotated bibliography", 2000 66 Peter Reuter, University of Kaiserslautern
[DEV13] "The AndroidManifest.xml File | Android Developers", 2013, http://developer.android.com/guide/topics/manifest/manifest-intro.html, accessed 15.08.2013
[FOW10] Fowler, M., "Domain-specific languages", 2010
[FRE13] "Freemarker: Java Template Engine Library", 2013, http://freemarker.sourceforge.net/index.html, accessed 01.03.2013
[GAM94] Gamma, E., Helm, R., Johnson, R., Vlissides, J., "Design patterns: elements of reusable object-oriented software", 1994
[GIF13] "jgilfelt/android-adt-templates", 2013, http://developer.android.com/tools/sdk/eclipse-adt.html, accessed 07.02.2013
[INS13] "Inspirred UI - mobile ui patterns", 2013, http://inspired-ui.com/, accessed 01.03.2013
[LIM04] Limbourg, Q., Vanderdonckt, J., Michotte, B., Bouillon, L., Florins, M., "USIXML: A User Interface Description Language Supporting Multiple Levels of Independence.", 2004
[MAN10] Mannadiar, R., Vangehluwe H., "Modular synthesis of mobile device applications from domain-specific models", 2010
[MER05] Mernik, M., Heering, J., Sloane, A.M., "When and how to develop domain-specific languages", 2005
[NEI12] Neil, T., "Mobile Design Pattern Gallery", 2012
[NOK13] "Mobile Design Pattern: Master Detail - Nokia Developer Wiki", 2013, http://developer.nokia.com/Community/Wiki/Mobile_Design_Pattern:_ Master_Detail, accessed 06.06.2013
[PER07] Perez-Medina, J. L., Dupuy-Chessa, S., et al., "A survey of model driven engineering tools for user interface design", 2007
[PTR13] "iOS Mobile Patterns Library", 2013, http://pttrns.com/, accessed 08.02.2013
[PUD10] Puder, A., "Cross-compiling Android applications to the iPhone", 2010 7 Bibliography 67
[PUE97] Puerta, A. R., Maulsby, D., "Management of interface design knowledge with MOBI-D", 1997
[SEN13] "HTML5 Mobile App Development Framework.", 2013, http://www.sencha.com/products/touch/, accessed 01.03.2013
[SIN04] Sinnig, D., "Enhancing Re-Use: Towards a Pattern- and Component-Based UI Development", 2004
[TID13] "Patterns: Designing Interfaces", 2013, http://designinginterfaces.com/patterns/, accessed 08.02.2012
[W3C] "Model-based UI XG Final Report", 2013, http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui/#mbui, accessed 19.08.2013
[WEL13] "Interaction Design Pattern Library", 2013, http://www.welie.com/patterns/, accessed 08.02.2013
[XTD13] "Xtext - Language Development Made Easy!", 2013, http://www.eclipse.org/Xtext/, accessed 07.02.2013
[XTE13] "Xtext - Language Development Made Easy!", 2013, http://www.eclipse.org/Xtext/, accessed 07.02.2013
8 List of Figures 69
8 List Of Figures
Fig. 1.1.1: Simplified CAMELEON Reference Framework [LIM04] And Classification Of The MobileUI DSL...... 2 Fig. 1.2.1: Sketch Of The Approach Presented By This Thesis...... 4 Fig. 2.1.1: Tab Orientation For Various OSs [NEI12, Fig. 1-12]...... 10 Fig. 2.1.2: Freemarker Text Generation Process, Adapted From [FRE13]...... 11 Fig. 2.2.1: “New Activity” Wizard Of The Eclipse ADT...... 12 Fig. 2.2.2: Sencha KitchenSink Application [SEN13]...... 13 Fig. 2.2.3: Cross-compilation Process, Adapted From [PUD10, Figure 2]...... 14 Fig. 2.2.4: PhoneApps Layered Model Transformation Approach...... 15 Fig. 3.1.1: Android Action Bar Of The Android Gallery Mobile Application...... 20 Fig. 3.1.2: Google Current Mobile Applications, Hierarchical Navigation And Navigation Via Content...... 21 Fig. 3.1.3: Confirmation View Of The Sixt Car/Truck Reservation Android Application...... 23 Fig. 3.1.4: Grouped Rows View Of The The Google Contacts Android Application...... 24 Fig. 3.1.5: Login View Of The Sixt Car/Truck Reservation Android Application...24 Fig. 3.1.6: MasterDetail View Of The Google Contacts Android Application...... 25 Fig. 3.1.7: Search View Of The Google Contacts Android Application...... 26 Fig. 3.1.8: Simple List View Of The “Theke” Android Application...... 26 Fig. 3.3.1: Algorithm For Determining The “next” Relation...... 33 Fig. 3.3.2: Algorithm For Determining The “parent” Relation...... 37 Fig. 3.4.1: Example For The “parent” And “next” Relation...... 38 Fig. 4.1.1: Generation And Customization Of DSL Editors...... 42 Fig. 4.1.2: Wrong (default) And Correct Scoping Of References To Pattern Parameters...... 43 Fig. 4.1.3: Additional Proposals For The Explicit “next”, “previous” And “parent” Provided By The Custom Proposal Provider...... 44 Fig. 4.1.4: Using The HyperlinkHelper To Navigate From Specification To Implementation...... 45 70 Peter Reuter, University of Kaiserslautern
Fig. 4.1.5: Visualization Of A MobileUI DSL Instance...... 46 Fig. 4.2.1: Structure Of Meta Templates...... 47 Fig. 4.2.2: Structure And Content Of The Base Meta Template...... 48 Fig. 4.2.3: Structure And Common Files Of A Screen Meta Template...... 49 Fig. 4.2.4: Classes Of The Navigation Controller Architecture...... 51 Fig. 4.2.5: Example Screen/flow Structure...... 52 Fig. 4.2.6: Retrieving The Navigation Controller And Using It Within A Concrete Android Activity That Represents A Screen...... 52 Fig. 4.2.7: Executing A “navigateNext” Call...... 52 Fig. 4.2.8: Generation Process For A Single Screen...... 54 Fig. 5.1.1: Specification Of The “BusinessTrips” Mobile Application With Implicit Relation “next” (purple) And Action “New_BusinessTrip” (green) Of Screen “Businesstrips_Overview”...... 58 Fig. 5.2.1: Navigation Controller Architecture For “BusinessTrips” Mobile Application...... 59 Fig. 5.2.2: Exemplary Screenshots Of The “BusinessTrips” Mobile Application..60 9 List Of Tables 71
9 List Of Tables
Table 3.1: Summary Of Navigation Concepts In Android, Microsoft Windows Phone 7 And Apple IOS...... 22
10 Appendices 73
10 Appendices
10.1 MobileUIDSL – Xtext Grammar
1 grammar de.tukl.cs.softech.mobileui.Dsl with org.eclipse.xtext.common.Terminals 2 generate dsl "http://www.tukl.de/cs/softech/mobileui/Dsl" 3 4 import "http://www.tukl.de/cs/softech/mobileui/Pattern DSL" as Pattern DSL 5 6 MobileUI: 7 8 imports += Import* 9 10 ('MobileUI' '{' 11 12 'AppName' '=' appName = ID 13 14 'NameSpace' '=' nameSpace = FQN 15 16 'Author' '=' author = STRING 17 18 'Path to PatternRepository' '=' patternRepositoryPath = STRING 19 20 (demoUI ?= 'Generate Demo UI')? 21 22 (screens += Screen)+ 23 24 25 '}' | 26 27 (flows += Flow)* 28 29 ) 30 31 ; 32 33 Import: 'import' importURI=STRING; 34 35 Flow: 36 Screen | 37 'Flow' '{' 38 'id' '=' name = ID 39 (flows+=Flow)* 40 '}' 41 | 42 FlowReference 43 ; 44 45 FlowReference: 46 'FlowReference' '=' refFlow=[Flow|FQN] 47 ; 48 74 Peter Reuter, University of Kaiserslautern
49 Screen: 50 'Screen' '{' 51 'id' '=' name = ID 52 pattern = PatternInstance 53 (flows+=Flow)* 54 (actions+=Action)* 55 '}' 56 ; 57 58 Action: 59 'Action' '{' 60 'id' '=' name = ID 61 ('target' '=' target = [Flow|FQN] | 'custom') 62 '}' 63 ; 64 65 PatternInstance: 66 'Pattern' '=' patternRef = [Pattern DSL::Pattern|FQN] '{' 67 parameters+=PatternParameterInstance* 68 '}' 69 ; 70 71 PatternParameterInstance: 72 73 SimpleParameter | SpecialParameter 74 75 ; 76 77 SimpleParameter: 78 patternParameter=[Pattern DSL::Parameter|FQN] '=' 79 ( value=STRING | 80 screen=[Flow|FQN] | 81 '['values+=STRING(','values+=STRING)*']' | 82 '['screens+=[Flow|FQN](','screens+=[Flow|FQN])*']' ) 83 ; 84 85 SpecialParameter: 86 type=SpecialParameterType '=' 87 ( screen=[Flow|FQN] | 88 '['screens+=[Flow|FQN](','screens+=[Flow|FQN])*']' ) 89 ; 90 91 SpecialParameterType: 92 'next' | 'previous' | 'parent' 93 ; 94 95 FQN: 96 ID('.'ID)* 97 ; 10 Appendices 75
10.2 Pattern DSL – Xtext Grammar
1 grammar de.tukl.cs.softech.mobileui.Pattern DSL with org.eclipse.xtext.common.Terminals 2 3 generate Pattern DSL "http://www.tukl.de/cs/softech/mobileui/Pattern DSL" 4 5 PatternCatalog: 6 'PatternCatalog' '{' 7 (patterns+= Pattern)+ 8 '}' 9 ; 10 11 Pattern: 12 'Pattern' '{' 13 'PatternName' '=' name = ID 14 parameters+=Parameter* 15 '}' 16 ; 17 18 Parameter: 19 'Parameter' '{' 20 'ParameterName' '=' name = ID 21 'ParameterType' '=' (parameterType = Type) 22 (optional ?= 'optional')? 23 '}' 24 ; 25 26 Type: 27 {Type} 'String' | 28 {Type} 'Integer' | 29 {Type} 'Boolean' | 30 {Type} 'Screen' | 31 List 32 ; 33 34 List returns Type: 35 'List<'type=Type'>' 36 ; 37 38 Boolean: 39 'true' | 'false' 40 ; 76 Peter Reuter, University of Kaiserslautern
10.3 Main screens for the “Business Trips” mobile application
10.3.1 BusinessTrips.mobileui
1 import "patterns.ptncat" 2 import "CostCenter.mobileui" 3 4 MobileUI { 5 AppName = BusinessTrips 6 NameSpace = com.example 7 Author = "Reuter" 8 Path to PatternRepository = "/home/reuter/Ubuntu One/WS1213/Masterarbeit/Templates" 9 Generate Demo UI 10 11 Screen { 12 id = BusinessTrips 13 Pattern = Login {} 14 } 15 Screen { 16 id = BusinessTrips_Overview 17 Pattern = GroupedRows { 18 Headings = ["BusinessTrips - current", "BusinessTrips - past"] 19 ItemLabels = ["BusinessTrip", "BusinessTrip"] 20 next = [BusinessTrips_Overview.BusinessTrips_Details, BusinessTrips_Overview.BusinessTrips_Details] 21 } 22 Screen { 23 id = BusinessTrips_Details 24 Pattern = Confirmation {} 25 } 26 Flow { 27 id = New_BusinessTrip 28 Flow { 29 id = Basedata 30 Screen { 31 id = Search_Target 32 Pattern = Search {} 33 } 34 Screen { 35 id = Choose_Date 36 Pattern = Confirmation {} 37 } 38 Screen { 39 id = Confirm_BaseData 40 Pattern = Confirmation {} 41 } 42 } 43 Flow { 44 id = Night_Stops 10 Appendices 77
45 Screen { 46 id = Search_Hotel 47 Pattern = Search {} 48 } 49 Screen { 50 id = Choose_Room 51 Pattern = SimpleList { 52 ItemLabel = "Room" 53 ItemsLabel = "Rooms" 54 } 55 } 56 Screen { 57 id = Number_of_Night_Stops 58 Pattern = SimpleList { 59 ItemLabel = "Night Stop" 60 ItemsLabel = "Night Stops" 61 } 62 } 63 FlowReference = Choose_CostCenter 64 Screen { 65 id = Confirm_Reservation 66 Pattern = Confirmation {} 67 } 68 } 69 Flow { 70 id = Means_of_Travel 71 Screen { 72 id = Choose 73 Pattern = SimpleList { 74 ItemLabel = "Means of Travel" 75 ItemsLabel = "Means of Travel" 76 } 77 } 78 FlowReference = Choose_CostCenter 79 Screen { 80 id = Confirm_Means_of_Transportation 81 Pattern = Confirmation {} 82 } 83 } 84 } 85 Action { 86 id = New_BusinessTrip 87 target = BusinessTrips_Overview.New_BusinessTrip 88 } 89 } 90 }
10.3.2 CostCenter.mobileui
1 import "patterns.ptncat" 2 3 Flow { 4 id = Choose_CostCenter 5 Screen { 78 Peter Reuter, University of Kaiserslautern
6 id = CostCenter_Overview 7 Pattern = SimpleList { 8 ItemLabel = "CostCenter" 9 ItemsLabel = "CostCenters" 10 } 11 } 12 Screen { 13 id = CostCenter_Details 14 Pattern = Confirmation {} 15 } 16 } 10.4 “BusinessTrips” mobile application “NCRegistry.java”
1 package com.example.BusinessTrips.navigation; 2 3 import java.util.HashMap; 4 5 import com.example.BusinessTrips.BusinessTrips; 6 import com.example.BusinessTrips.BusinessTrips_Details; 7 import com.example.BusinessTrips.BusinessTrips_Overview; 8 import com.example.BusinessTrips.Choose; 9 import com.example.BusinessTrips.Choose_Date; 10 import com.example.BusinessTrips.Choose_Room; 11 import com.example.BusinessTrips.Confirm_BaseData; 12 import com.example.BusinessTrips.Confirm_Means_of_Transportation; 13 import com.example.BusinessTrips.Confirm_Reservation; 14 import com.example.BusinessTrips.CostCenter_Details; 15 import com.example.BusinessTrips.CostCenter_Overview; 16 import com.example.BusinessTrips.Number_of_Night_Stops; 17 import com.example.BusinessTrips.Search_Hotel; 18 import com.example.BusinessTrips.Search_Target; 19 20 public class NCRegistry { 21 22 @SuppressWarnings("rawtypes") 23 private HashMap
39 40 /*********************** 41 * method to be used by 42 * Activites and other 43 * NavControllers 44 ***********************/ 45 public AbstractNavController getNavController(@SuppressWarnings("rawtypes") Class navController) { 46 if (navController != null) { 47 return navControllers.get(navController); 48 } else { 49 return navControllers.get(AppNavController.class); 50 } 51 52 } 53 54 /*********************** 55 * create all necessary 56 * NavController 57 ***********************/ 58 private void setup() { 59 navControllers.put(AppNavController.class, new AppNavController(new Class[][] {new Class[] {BusinessTrips.class}, new Class[] {BusinessTrips_Overview.class}, new Class[] {BusinessTrips_Details.class, BusinessTrips_Details.class} }, new Integer[] {}, BusinessTrips.class, AppNavController.class)); 60 navControllers.put(Choose_CostCenterNavController.cl ass, new Choose_CostCenterNavController(new Class[][] {new Class[] {CostCenter_Overview.class}, new Class[] {CostCenter_Details.class} }, new Integer[] {}, BusinessTrips.class, AppNavController.class)); 61 navControllers.put(BaseDataNavController.class, new BaseDataNavController(new Class[][] {new Class[] {Search_Target.class}, new Class[] {Choose_Date.class}, new Class[] {Confirm_BaseData.class} }, new Integer[] {}, New_BusinessTripNavController.class, AppNavController.class)); 62 navControllers.put(Night_StopsNavController.class, new Night_StopsNavController(new Class[][] {new Class[] {Search_Hotel.class}, new Class[] {Choose_Room.class}, new Class[] {Number_of_Night_Stops.class}, new Class[] {Choose_CostCenterNavController.class}, new Class[] {Confirm_Reservation.class} }, new Integer[] {3}, New_BusinessTripNavController.class, AppNavController.class)); 63 navControllers.put(Means_of_TravelNavController.clas s, new Means_of_TravelNavController(new Class[][] {new Class[] {Choose.class}, new Class[] {Choose_CostCenterNavController.class}, new Class[] {Confirm_Means_of_Transportation.class} }, new Integer[] {1}, New_BusinessTripNavController.class, AppNavController.class)); 64 navControllers.put(New_BusinessTripNavController.cla ss, new New_BusinessTripNavController(new Class[][] {new Class[] {BaseDataNavController.class}, new Class[] {Night_StopsNavController.class}, new Class[] {Means_of_TravelNavController.class} }, new Integer[] {}, BusinessTrips_Overview.class, AppNavController.class)); 65 } 66 }