a domain-specific language for ui-navigation in …...2.1.1 model-based user interface development...

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

mailto:[email protected]

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......................................................................................................................................11.1 Motivation.................................................................................................................................11.2 Goals And Structure...............................................................................................................2

2 Methods, Techniques And Technologies.....................................................................................52.1 Foundations.............................................................................................................................5

2.1.1 Model-Based User Interface Development..................................................................52.1.2 Domain-Specific Languages..........................................................................................62.1.3 Xtext..................................................................................................................................82.1.4 User-interface Patterns..................................................................................................82.1.5 Patterns For Mobile UIs..................................................................................................92.1.6 Freemarker....................................................................................................................10

2.2 Existing Approaches.............................................................................................................112.2.1 Eclipse Android Development Tools...........................................................................112.2.2 Sencha Touch And Adobe Phonegap........................................................................132.2.3 Cross-compilation.........................................................................................................142.2.4 PhoneApps....................................................................................................................15

2.3 Summary................................................................................................................................16

3 The Mobile UI DSL.......................................................................................................................193.1 Analysis Of Mobile Applications..........................................................................................19

3.1.1 Navigation Concepts....................................................................................................203.1.2 Frequently Used Screens.............................................................................................22

3.2 Derived Requirements..........................................................................................................273.2.1 General...........................................................................................................................273.2.2 Navigation......................................................................................................................273.2.3 Screens..........................................................................................................................28

3.3 The MobileUI DSL................................................................................................................293.3.1 MobileUI DSL Grammar...............................................................................................293.3.2 Pattern DSL Grammar..................................................................................................343.3.3 Context Conditions........................................................................................................363.3.4 Semantics Of Nested Flows And Screens.................................................................36

3.4 Summary................................................................................................................................38

4 Tool Support..................................................................................................................................414.1 Eclipse Editors For DSL Instances.....................................................................................41

4.1.1 DSL Text Editors...........................................................................................................414.1.2 Visualization Of DSL Instances...................................................................................46

4.2 Code Generator For Android...............................................................................................474.2.1 Base Meta Template....................................................................................................484.2.2 Screen Templates.........................................................................................................494.2.3 Navigation Controller Architecture..............................................................................504.2.4 Generation Process......................................................................................................53

4.3 Summary................................................................................................................................54

5 Evaluation......................................................................................................................................575.1 Description And Specification.............................................................................................575.2 Code Generation...................................................................................................................59

5.3 Comparison With Traditional Development.......................................................................615.3.1 Initial Effort.....................................................................................................................615.3.2 Long-term Effort............................................................................................................62

5.4 Summary................................................................................................................................62

6 Conclusion And Future Work.......................................................................................................63

7 Appendices....................................................................................................................................717.1 MobileUIDSL – Xtext Grammar...........................................................................................717.2 Pattern DSL – Xtext Grammar.............................................................................................737.3 Main Screens For The “Business Trips” Mobile Application...........................................74

7.3.1 BusinessTrips.mobileui................................................................................................747.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.


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.

Fig. 1.2.1: Sketch of the approach presented by this thesis.

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


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:


“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.


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


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.


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.

Fig. 2.1.1: Tab orientation for various OSs [NEI12, fig. 1-12]


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.

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

Fig. 2.1.2: Freemarker text generation process, adapted from [FRE13]


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].

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.

Fig. 2.2.1: “New Activity” wizard of the Eclipse ADT


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

access to resources of the smart phone such

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

Fig. 2.2.2: Sencha KitchenSinkapplication [SEN13].


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

are injected in the next step. The XMLVMDEX-MEM

format is then used to generate the final

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

Fig. 2.2.3: Cross-compilationprocess, adapted from [PUD10,Figure 2]


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

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

Fig. 2.2.4: PhoneApps layered modeltransformation approach


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


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.


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

example of a toolbar is depicted in fig.Fig. 3.1.1: Android Action Bar of the AndroidGallery mobile application


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.

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

Fig. 3.1.2: Google Current mobile applications, hierarchical navigation and navigation viacontent.


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


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

Confirmation view of the Sixt Car/Truck

Reservation Android application.

Collection data, return data, vehicle type and total price have to be confirmed by

the user via the “Reservieren” button.

Fig. 3.1.3: Confirmation view of the SixtCar/Truck Reservation Android application.


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.

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/TruckReservation Android application.

Fig. 3.1.4: Grouped Rows view of the theGoogle Contacts Android application.


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.


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.

Only entries matching the search term

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

second channel of German television

Fig. 3.1.7: Search view of the GoogleContacts Android application.

Fig. 3.1.8: Simple List view of the “Theke”Android application.


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.


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.3 The MobileUI DSL

This chapter presents the MobileUI DSL in detail. The DSL was developed in

order to meet the requirements presented before.

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.

1 PatternParameterInstance:23 SimpleParameter | SpecialParameter 45 ;

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


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”

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.

1 MobileUI:2 3 imports += Import*4 5 ('MobileUI' '{'67 'AppName' '=' appName = ID89 'NameSpace' '=' nameSpace = FQN10 11 'Author' '=' author = STRING1213 'Path to PatternRepository' '='

patternRepositoryPath = STRING14 15 (demoUI ?= 'Generate Demo UI')?1617 (screens += Screen)+181920 '}' |2122 (flows += Flow)*2324 )2526 ;

Listing 3.4: The “MobileUI” grammar rule


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

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.

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 Import: 'import' importURI=STRING;

Listing 3.6: The “Import” grammar rule

1 Parameter:2 'Parameter' '{'3 'ParameterName' '=' name = ID4 'ParameterType' '=' (parameterType = Type)5 (optional ?= 'optional')?6 '}'7 ;

Listing 3.5: The “Parameter” grammar rule

1 Flow:2 Screen |3 'Flow' '{'4 'id' '=' name = ID5 (flows+=Flow)*6 '}'7 |8 FlowReference9 ;

Listing 3.7: The “Flow” grammar rule


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.

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.

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.

1 FlowReference:2 'FlowReference' '=' refFlow=[Flow|FQN]3 ;

Listing 3.8: The “FlowReference” grammar rule

1 Screen:2 'Screen' '{'3 'id' '=' name = ID4 pattern = PatternInstance5 (flows+=Flow)*6 (actions+=Action)*7 '}'8 ;

Listing 3.9: The “Screen” grammar rule


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.

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.

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.

1 Action:2 'Action' '{'3 'id' '=' name = ID4 ('target' '=' target = [Flow|FQN] | 'custom')5 '}'6 ;

Listing 3.10: The “Action” grammar rule

1 PatternInstance:2 'Pattern' '=' patternRef = [Pattern DSL::Pattern|FQN] '{'3 parameters+=PatternParameterInstance*4 '}'5 ;

Listing 3.11: The “PatternInstance” grammar rule


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.

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”.

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

1 SpecialParameterType:2 'next' | 'previous' | 'parent'3 ;

Listing 3.12: The “SpecialParameterType” type

1 FQN:2 ID('.'ID)*3 ;

Listing 3.13: The “FQN” type


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.

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.

1 Pattern:2 'Pattern' '{'3 'PatternName' '=' name = ID4 parameters+=Parameter*5 '}'6 ;

Listing 3.15: The “Pattern” grammar rule

7 Type:8 {Type} 'String' |9 {Type} 'Integer' |10 {Type} 'Boolean' |11 {Type} 'Screen' |12 List13 ;1415 List returns Type:16 'List<'type=Type'>'17 ;

Listing 3.16: The “Type” and “List” grammar rule


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.


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.

Fig. 3.3.1: Algorithm for determining the “parent” relation.


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.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.


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

achieved by the Scope and Proposal

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.

Fig. 4.1.1: Generation andcustomization of DSL Editors

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).

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.

Fig. 4.1.2: Wrong (default) and correct scoping of references to Pattern parameters.


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).

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.

Fig. 4.1.3: Additional proposals for the explicit “next”,“previous” and “parent” provided by the custom ProposalProvider

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.


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.

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.

Fig. 4.1.5: Visualization of a MobileUI DSL instance

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

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

Fig. 4.2.1: Structure of Meta Templates


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.

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

Fig. 4.2.2: Structure and content of the Base Meta Template

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.

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

Fig. 4.2.3: Structure and common files of a Screen Meta Template


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.

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.

Fig. 4.2.4: Classes of the Navigation Controller Architecture


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”

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.7: Executing a “navigateNext” call

Fig. 4.2.6: Retrieving the Navigation Controller and using it within a concrete Android Activitythat represents a screen

Fig. 4.2.5: Example screen/flow structure

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”.


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.

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

Fig. 4.2.8: Generation process for a single Screen

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.

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

1 package com.example.BusinessTrips;23 public final class BusinessTripsImpl extends BusinessTrips {45 protected boolean login(String userName, String password)

{6 // TODO implement login method7 return false;8 }910 }

Listing 4.1: Default content of “BusinessTripsImpl.java”, resulting from “Login” pattern

1 package com.example.BusinessTrips;23 import android.net.ConnectivityManager;4 import com.example.logic.services.AuthenticationService;56 public final class BusinessTripsImpl extends BusinessTrips {78 protected boolean login(String userName, String password)

{910 ConnectivityManager conMan = (ConnectivityManager)

getSystemService(CONNECTIVITY_SERVICE);11 if (conMan.getActiveNetworkInfo() != null &&

conMan.getActiveNetworkInfo().isConnected()) {1213 AuthenticationService authService = new

AuthenticationService();14 return authService.checkCredentials(userName,

password);1516 }1718 return false;19 }2021 }

Listing 4.2: Examplary implementation of the “BusinessTrips” screen


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


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.


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.


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.


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


[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


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"34 import "http://www.tukl.de/cs/softech/mobileui/Pattern DSL" as

Pattern DSL56 MobileUI:7 8 imports += Import*9 10 ('MobileUI' '{'1112 'AppName' '=' appName = ID1314 'NameSpace' '=' nameSpace = FQN15 16 'Author' '=' author = STRING1718 'Path to PatternRepository' '='

patternRepositoryPath = STRING19 20 (demoUI ?= 'Generate Demo UI')?2122 (screens += Screen)+232425 '}' |2627 (flows += Flow)*2829 )3031 ;3233 Import: 'import' importURI=STRING;3435 Flow:36 Screen |37 'Flow' '{'38 'id' '=' name = ID39 (flows+=Flow)*40 '}'41 |42 FlowReference43 ;4445 FlowReference:46 'FlowReference' '=' refFlow=[Flow|FQN]47 ;48


49 Screen:50 'Screen' '{'51 'id' '=' name = ID52 pattern = PatternInstance53 (flows+=Flow)*54 (actions+=Action)*55 '}'56 ;5758 Action:59 'Action' '{'60 'id' '=' name = ID61 ('target' '=' target = [Flow|FQN] | 'custom')62 '}'63 ;6465 PatternInstance:66 'Pattern' '=' patternRef = [Pattern DSL::Pattern|FQN] '{'67 parameters+=PatternParameterInstance*68 '}'69 ;7071 PatternParameterInstance:7273 SimpleParameter | SpecialParameter 7475 ;7677 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 ;8485 SpecialParameter:86 type=SpecialParameterType '='87 ( screen=[Flow|FQN] |88 '['screens+=[Flow|FQN](','screens+=[Flow|FQN])*']' )89 ;9091 SpecialParameterType:92 'next' | 'previous' | 'parent'93 ;9495 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

23 generate Pattern DSL

"http://www.tukl.de/cs/softech/mobileui/Pattern DSL"45 PatternCatalog:6 'PatternCatalog' '{'7 (patterns+= Pattern)+8 '}'9 ;

1011 Pattern:12 'Pattern' '{'13 'PatternName' '=' name = ID14 parameters+=Parameter*15 '}'16 ;1718 Parameter:19 'Parameter' '{'20 'ParameterName' '=' name = ID21 'ParameterType' '=' (parameterType = Type)22 (optional ?= 'optional')?23 '}'24 ;2526 Type:27 {Type} 'String' |28 {Type} 'Integer' |29 {Type} 'Boolean' |30 {Type} 'Screen' |31 List32 ;3334 List returns Type:35 'List<'type=Type'>'36 ;3738 Boolean:39 'true' | 'false'40 ;


10.3 Main screens for the “Business Trips”

mobile application

10.3.1 BusinessTrips.mobileui

1 import "patterns.ptncat"2 import "CostCenter.mobileui"34 MobileUI {5 AppName = BusinessTrips6 NameSpace = com.example7 Author = "Reuter"8 Path to PatternRepository = "/home/reuter/Ubuntu

One/WS1213/Masterarbeit/Templates"9 Generate Demo UI1011 Screen {12 id = BusinessTrips13 Pattern = Login {}14 }15 Screen {16 id = BusinessTrips_Overview17 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_Details24 Pattern = Confirmation {}25 }26 Flow {27 id = New_BusinessTrip28 Flow {29 id = Basedata30 Screen {31 id = Search_Target32 Pattern = Search {}33 }34 Screen {35 id = Choose_Date36 Pattern = Confirmation {}37 }38 Screen {39 id = Confirm_BaseData40 Pattern = Confirmation {}41 }42 }43 Flow {44 id = Night_Stops

10 Appendices 77

45 Screen {46 id = Search_Hotel47 Pattern = Search {}48 }49 Screen {50 id = Choose_Room51 Pattern = SimpleList {52 ItemLabel = "Room"53 ItemsLabel = "Rooms"54 }55 }56 Screen {57 id = Number_of_Night_Stops58 Pattern = SimpleList {59 ItemLabel = "Night Stop"60 ItemsLabel = "Night Stops"61 }62 }63 FlowReference = Choose_CostCenter64 Screen {65 id = Confirm_Reservation66 Pattern = Confirmation {}67 }68 }69 Flow {70 id = Means_of_Travel71 Screen {72 id = Choose73 Pattern = SimpleList {74 ItemLabel = "Means of

Travel"75 ItemsLabel = "Means of

Travel"76 }77 }78 FlowReference = Choose_CostCenter79 Screen {80 id =

Confirm_Means_of_Transportation81 Pattern = Confirmation {}82 }83 }84 }85 Action {86 id = New_BusinessTrip87 target =

BusinessTrips_Overview.New_BusinessTrip88 }89 }90 }

10.3.2 CostCenter.mobileui

1 import "patterns.ptncat"23 Flow {4 id = Choose_CostCenter5 Screen {


6 id = CostCenter_Overview7 Pattern = SimpleList {8 ItemLabel = "CostCenter"9 ItemsLabel = "CostCenters"10 }11 }12 Screen {13 id = CostCenter_Details14 Pattern = Confirmation {}15 }16 }

10.4 “BusinessTrips” mobile application

“NCRegistry.java”

1 package com.example.BusinessTrips.navigation;23 import java.util.HashMap;45 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;1920 public class NCRegistry {2122 @SuppressWarnings("rawtypes")23 private HashMap<Class, AbstractNavController>

navControllers = new HashMap<Class, AbstractNavController>();2425 public static final String NAV_CONTROLLER =

"NavController";2627 /******************28 * singleton *29 ******************/30 private static NCRegistry instance = new NCRegistry();3132 private NCRegistry() {33 setup();34 }3536 public static NCRegistry getInstance() {37 return instance;38 }

10 Appendices 79

3940 /***********************41 * method to be used by42 * Activites and other43 * 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 }5152 }5354 /***********************55 * create all necessary56 * NavController57 ***********************/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.class, 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.class, 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.class, 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 }

a domain-specific language for ui-navigation in …...2.1.1 model-based user interface development...

Documents