Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Master Thesis
A DOMAIN-SPECIFIC LANGUAGE FOR
UI-NAVIGATION IN MOBILE
APPLICATIONS
Peter Reuter
University of Kaiserslautern
Sep 25, 2013
First Examiner:Prof. Dr. Arnd Poetzsch-Heffter
Second Examiner:Dipl.-Inf. Axel Irriger
Advisor:Dipl.-Inf. (FH) Andy Scherzinger
STATEMENT OF AUTHORSHIP
Except where reference is made in the text of this thesis, this thesis contains no material published
elsewhere or extracted in whole or in part from a thesis presented by me for another degree or diploma. No
other person's work has been used without due acknowledgement in the main text of the thesis. This
thesis has not been submitted for the award of any other degree or thesis in any other tertiary institution.
Kaiserslautern, Sep 25, 2013
Peter Reuter
Abstract
Developing mobile applications for the major mobile operating systems Android, iOS and Windows Phone
7 often requires re-development of functional similar applications multiple times. Furthermore, applications
for similar business cases often use similar screens and screen flows. Software developers are therefore
faced by the challenge of minimizing this effort.
This master thesis presents a prototypical tool for the generation of native applications for mobile devices.
To this end, typical navigation structures and concepts of mobile applications are captured by an abstract
descriptions using a domain-specific language (DSL). This DSL supports developers while creating
platform-independent specifications of screens and screen flows. Furthermore, a prototypical code
generator is presented that is used to generate the concrete screens and the navigation between them.
Mobile user interface pattern are used to provide a basic implementation for the different screens. Finally,
the specification of a fictional application using the developed DSL is presented. The code generation
approach of this thesis is demonstrated and evaluated using this fictional application.
Kurzdarstellung
Die Entwicklung mobiler Anwendungen für die meistgenutzten Betriebssysteme Android, iOS und
Windows Phone 7 erfordert es, fachlich gleiche Anwendungen mehrfach zu entwickeln. Anwendungen für
ähnliche Geschäftsszenarios verfügen zudem oft über ähnliche Dialoge und Dialogflüsse.
Software-Entwickler stehen dabei vor der Herausforderung, den Aufwand an Neuentwicklung zu
minimieren.
Diese Masterarbeit präsentiert ein prototypisches Werkzeug zur Generierung von nativen Anwendungen
für mobile Geräte. Dazu werden die typischen Navigationsstrukturen und -konzepte mobiler Anwendungen
durch abstrakte Beschreibungen mittels einer Domänen-spezifischen Sprache (DSL) festgehalten. Diese
DSL erlaubt das Ableiten Plattform-unabhängiger Spezifikationen von Dialogen und Dialogflüssen.
Weiterhin wird ein prototypischer Generator präsentiert, der aus den abstrakten Dialog-Modellen alle
konkreten Dialoge und den Code für die Navigation zwischen diesen generiert. Um eine
Standard-Implementierung für Dialoge bereitzustellen werden Mobile User-Interface Pattern genutzt.
Abschließend wird die Spezifikation einer fiktive Anwendung mittels der entwickelten DSL präsentiert.
Anhand dieser Anwendung wird exemplarisch die Funktionsweise des vorgestellten Ansatzes
demonstriert und evaluiert.
Table Of Contents
1 Introduction......................................................................................................................................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.
4 Peter Reuter, University of Kaiserslautern
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
6 Peter Reuter, University of Kaiserslautern
framework highlights the different models and development steps from high-level
abstractions like user tasks to the final UI [CAL2003]. Existing MBUID
approaches can be mapped to the various levels of the CAMELEON Reference
Framework. As depicted in Fig. 1.1.1 the development life-cycle starts at the level
of tasks and concepts. This level specifies user activities that can be performed to
achieve certain goals. Temporal and causal dependencies can be used to restrict
the execution order of the different tasks. Next, the Abstract User Interface (AUI)
represents the available interaction elements and the navigation within the
application. The interaction elements are independent from their concrete
representation in the final UI. They are refined to platform-dependent interaction
elements at the Concrete User Interface (CUI) level. Furthermore, the CUI level
specifies properties that can be perceived by the user such as color or size. Last,
the platform-dependent Final User Interface (FUI) is represented at two
sub-levels: source code and the runtime UI.
Also the MobileUI DSL that is presented in Chapter 3 can be classified using the
CAMELEON Reference Framework. The DSL allows the specification of screens,
screen flows and relations between screens. It does not specify interaction
objects. Instead a common set of possible interactions of a screen is assumed
due to the restricted interaction possibilities of mobile applications that are
presented in Chapter 3.1.1. As depicted in Fig. 1.1.1, the MobileUI DSL can
therefore be seen as an AUI that is transformed to a platform-dependent CUI by
the code generator that is presented in Chapter 4. The platform's software
development kit (SDK) is then used to compile the CUI into a FUI that is
presented to the user as the final mobile application.
2.1.2 Domain-Specific Languages
The previously mentioned DSLs are used to capture the model.
Platform-independent and reusable descriptions of screens and screen flows are
provided as input data for for the UI generation process. This chapters provides a
definition of DSLs in order to clarify terms and categorizes the MobileUI DSL and
Pattern DSL.
Fowler [FOW10] defines DSLs as follows:
2 Methods, Techniques and Technologies 7
“A computer programming language of limited expressiveness
focused on a particular domain.”
Systematic studies on DSLs started only recently. Nonetheless, DSLs have been
widely used in the past [CZA05]. As we can find in [FOW10], DSLs can be
distinguished from other programming languages via the generality of the
problems they try to solve. DSLs do not provide general constructs and notations
that can be used to solve general problems. Instead, DSLs are more restrictive
with respect to the notations and constructs they provide. These often follow the
terms of the target domain. Thus domain-experts can easily “understand, validate,
modify, and often even develop DSL programs ” [DEU00]. Furthermore, domain
experts can use DSL to encapsulate their knowledge and thereby encourage
reuse.
Mernik et al. [MER05] provide various characteristic by which DSLs can be
distinguished from other programming languages. By the focus on a particular
domain DSLs offer an increased expressiveness with respect to their domain
despite their limited general expressiveness. In addition, executability can be used
as a distinguishing characteristic. While many programming languages are
executable in general DSLs are not necessarily executable. Fowler furthermore
mentions different scales of executability in [FOW10]:
• DSLs providing well-defined execution semantics
• DSLs that are used as input languages for application generators
• declarative DSLs that serve as domain-specific data structure
representations
The DSLs that are presented in Chapter 3.3 belong to the latter two categories.
They provide constructs and notations for the definition of screens, screen flows
and the relations between screens as well as for the definition of patterns. These
declarative descriptions of the UIs of mobile applications then serve as input for
the code generator that is presented in Chapter 4.
8 Peter Reuter, University of Kaiserslautern
2.1.3 Xtext
The DSL infrastructure like parsers or Eclipse plug-ins for editing that is presented
in chapter 4 is generated using the Xtext framework. As described by the Xtext
documentation, Xtext is a framework that supports the development of
programming languages as well as DSLs [XTE13].
Xtext features a rich grammar for language development. The grammar supports
references within instances of the same DSL or cross-references to other DSLs.
The MobileUI DSL grammar makes use of these cross-references. Screens and
screen flows can provide links to other screens and screen flows in order to reuse
them in new contexts. Furthermore, screen specify cross-references to patterns
specified by instances of the Pattern DSL. Thereby, available patterns providing
default implementations for frequently used screens can be easily referenced.
The editors that are generated from the DSL grammars are deeply embedded into
the Eclipse framework. Default implementations for syntax coloring, content
assists, validation of input and support for the correction of errors are generated
automatically. Thereby, users can rely on well-known views and functionality.
Although these default implementations are sufficient in most cases, the prototype
extends these as presented in Chapter 4.1.1 in order to cope with certain
peculiarities of the MobileUI DSL.
Developers can create new MobileUI specifications these editors. The prototype
presented in Chapter 4.2 then uses the generated parsers to parse the MobileUI
specifications and provide it as input data to the Freemarker library that processes
platform-dependent solutions of mobile UI patterns.
2.1.4 User-interface Patterns
In order to generate code from DSL instances the presented approach provides
reusable artifacts for common screens as UI patterns. The idea of patterns as
proven solutions for common design problems originates in the domain of urban
design [ALE77]. A pattern as Alexander defines as follows:
It is a “three-part rule, which expresses a relation between a certain
2 Methods, Techniques and Technologies 9
context, a problem and a solution” [ALE77].
Thereby, patterns “provide an effective way to transmit experience about
recurrent problems” [SIN04]. In 1994 patterns were introduced in the domain of
computer science by Gamma, Helm, Johnson, and Vlissides [GAM94]. Later, they
were also taken over in the field of UI development.
Today, pattern libraries like [TID13] or [WEL13] provide developers with a vast
amount of design patterns for traditional UIs. All these libraries have in common
that they utilize – to a certain extent – the pattern form that was initially proposed
by Alexander.
2.1.5 Patterns for mobile UIs
Since the first emergence of smart phones like the Apple iPhone and tablet
computers like the Apple iPad, a need for new UI patterns arose [NEI12]. These
patterns have to take into account the peculiarities of the new devices like their
reduced screen size or new interaction modalities such as touch and gestures.
Therefore, new pattern galleries were established. These galleries often are made
available on the Internet. As an example, the “Android Interaction Design
Patterns” gallery [AND13] offers a wide range of patterns for the Android platform.
Others like the “Pttrns” gallery [PTR13] or the “Inspired UI” gallery [INS13]
provide developers with patterns for the iOS platform. In addition, also
platform-independent pattern galleries like [NEI12] exist.
All these pattern galleries need to take into account the fact that the developers of
the different mobile platforms established different standards for UI design. The
platform-specific style guides induce that the same idea of a solution to a given
design problem often results in different implementations on different mobile
platforms. As an example the tab navigation pattern of [NEI12] can be considered.
As depicted in Fig. 2.1.1, some mobile platforms like iOS display tabs at the
bottom of the screen, while e.g. the Android style guide requires tabs to be
displayed at the top of the screen.
10 Peter Reuter, University of Kaiserslautern
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]
2 Methods, Techniques and Technologies 11
Platform-specific solutions for the already mentioned patterns are provided as
templates consisting of Java code and XML files. These files contain the
implementation of a frequently used screen and its layouts and other resources.
Pattern authors can use these templates to generate platform-dependent pattern
solutions that depend on the context the pattern is used in. As depicted in Fig.
2.1.2, Freemarker templates and input data in the form of Java objects are
passed to the Freemarker library. In case of the prototype, the MobileUI DSL
specification is parsed and provided as input to the Freemarker library. The
Freemarker library then processes both template and input data and afterwards
serves the generated text document. The generated text document then is saved
as a text files.
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]
12 Peter Reuter, University of Kaiserslautern
depicted in Fig. 2.2.1, the ADT supports the generation of common UI screens,
so-called “activities”.
To this end, it utilizes templates that can be instantiated. These templates consist
of a directory containing meta-information about the template and files containing
source code or other resources like XML layout definitions or configuration
information. The files of the template consist of static content and control
structures. As the meta-information includes parameters for the template the
control structures can be used to dynamically generate content. The control
structures allow conditional and repetitive parts since they are based on the
Freemarker Template Language. The ADT includes several general purpose
templates. Additional templates are provided by other authors [GIF13].
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 Methods, Techniques and Technologies 13
2.2.2 Sencha Touch and Adobe Phonegap
A common feature of modern smart phones is
the support of latest web technologies like
HTML5, JavaScript and CSS. Frameworks
like Sencha Touch take advantage of this fact
by providing UI toolkits based on these
technologies. The toolkits provide predefined
UI components. Websites utilizing such toolkits
can be accessed and used by smart phone
users almost like native applications. An
example of such an application is the Sencha
KitchenSink that is depicted in Fig. 2.2.2.
Although it is a basically a website, it looks and
behaves similarly to a mobile application that
was built using the native SDK.
Nonetheless, these websites cannot provide
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].
14 Peter Reuter, University of Kaiserslautern
such as Sencha Touch do not provide explicit support for reusing screens, screen
flows and the relations among them.
2.2.3 Cross-compilation
Puder [PUD10] presents an approach for cross-compiling Android applications for
the iOS platform. Thereby, instead of two code-bases only a single code-base
needs to be maintained. The Android platform was chosen as the code-base due
to the heterogeneity of available Android devices and a larger amount of tools for
the Java programming language.
The cross-compilation approach is depicted in
Fig. 2.2.3. After developing the Android
application the presented approach compiles
the Java source code to class files using a
regular Java compiler. Afterwards, an
XML-representation of the byte code is
generated. This stack-based
XML-representation is transformed into a
register-based format using instructions of
Android's Dalvik virtual machine. In contrast to
the Java programming language the
Objective-C programming language does not
provide garbage collection. Therefore,
instructions for correct memory management
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]
2 Methods, Techniques and Technologies 15
approach can be applied more easily to games as they are not widget-driven as
other applications.
The cross-compliation approach can be used to a certain extend to provide mobile
applications for both the Android and iOS platform. Nonetheless, it provides no
support for reusing existing screens, screen flows and the relations among them in
new mobile applications.
2.2.4 PhoneApps
In Mannadiar and Vangheluwe present an approach for generating Android
applications from domain-specific models [MAN10]. The authors suggest a
layered model transformation approach. Each transformation decreases the level
of abstraction and leads to an intermediate model.
The proposed PhoneApps DSL serves as the starting point. It allows developers
to specify visual structure and behavior of a mobile application. The visual
structure is comprised of container,
widgets and actions (platform-specific
features like dialing a number). The
behavior describes the flow between
containers via timed, conditional, and
user-prompted transitions. According to
the CAMELEON Reference
Framework, the PhoneApps DSL can
therefore be seen as a mixture of AUI
and CUI. As depicted in Fig. 2.2.4, this
initial instance of the DSL is afterwards
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
16 Peter Reuter, University of Kaiserslautern
actual files that can be compiled into an Android mobile application using the
Android SDK.
The PhoneApps approach has several advantages. It provides abstract
descriptions of mobile applications. These descriptions are then transformed into
platform-specific artifacts. Furthermore, the reuse of PhoneApps snippets and
therefore of partial specifications of mobile applications is possible. But also, the
PhoneApps approach relies on the Android platform and is not available for other
platforms. Furthermore, knowledge about style guides is hard-wired into the
model transformer and code generator. Additionally, it provides no explicit reuse
of screens, screen flows and relations among them.
2.3 Summary
In Chapter 2 the fundamental principles, the frameworks that are used by the
approach presented in this thesis and similar approaches that target the problems
mentioned in chapter 1.1 were presented.
First MBUID was introduced. It was said that MBUID has several advantages
such as the separation of concerns introduced by the various models. The
CAMELEON Reference Framework was introduced. The MobileUI DSL was
classified using the CAMELEON Reference Framework as an AUI model. Next,
the concept of DSLs was presented. Again, the DSL that are presented later-on
were classified. They were said to be declarative DSLs that furthermore serve as
input to a code generator. Next, the Xtext was presented. The framework offers a
a rich set of tools to DSL authors for developing new DSLs. Furthermore, patterns
were said to be well-known in the field of UI design. Pattern galleries already exist
for traditional desktop interfaces, but mobile UI pattern are still an emerging field.
Afterwards, the Freemarker template framework was introduced. The Freemarker
library is used by the later-on presented code generator to adapt the available
pattern solutions according to the context these patterns are used in. Lastly,
approaches for platform-independent mobile UIs and mobile UI generation were
presented and basically analyzed for the applicability to the given problems.
Though each of these approaches offers a rich set of features, none of them
2 Methods, Techniques and Technologies 17
explicitly provides the possibility to reuse screens, screens flows and the relations
among them.
3 The Mobile UI DSL 19
3 The Mobile UI DSL
In Chapter 2.2 it was shown, that none of the presented approaches solves all
problems mention in Chapter 1.1. While all approaches aim to solve certain
problems, especially the problem of reusing screens, screen flows and the
relations between them remains unsolved. This chapter presents a solution to this
problem that still considers the multitude of different platforms.
The relations between screens are mostly defined by inter-screen navigation and
hierarchical structures in which screens are embedded. Therefore, Chapter 3.1
presents navigation concepts of the major mobile operating systems Android,
Apple iOS and Microsoft Windows Phone 7. As explained in Chapter 2.1.4,
patterns are a way to support reuse when creating user interfaces. Therefore,
commonly used patterns from various pattern libraries are presented. These
patterns are used by the code generator prototype presented in Chapter 4. The
analysis is then turned into requirements in chapter 3.2. Finally, Chapter 3.3
presents the implementation of the requirements in form of two DSLs. The main
DSL provides concepts for defining mobile user interfaces and especially
supports the reuse of screens flows. Furthermore, an auxiliary DSL that captures
patterns is used by the main DSL in order to support reuse on a screen level.
3.1 Analysis of Mobile Applications
Following, common navigation concepts are presented in platform-independently.
Furthermore, the platform-dependent implementation of these concepts is
presented by platform and finally summarized in an overview.
In addition, screens that are often used in mobile applications are presented in
their abstract form as UI patterns in Chapter 3.1.2. The patterns are derived from
several pattern galleries. They present a platform-independent solution as well as
an example from a real mobile application.
20 Peter Reuter, University of Kaiserslautern
3.1.1 Navigation Concepts
The differences between traditional desktop computers and smart phones such as
screen size and input methods require new navigation concepts. The following
concepts can be found commonly:
• Hierarchical navigation: The screens of a mobile application can be
ordered hierarchically. Hierarchical navigation leads from one screen to its
parent.
• Temporal navigation: Moving backwards through the list of most recent
screens.
• Content navigation: Touching content elements such as list entries leads
to a different screen.
• Navigation via toolbars: A toolbar is provided that contains e.g. the title
of the current screen and menu items. These toolbar items provide options
to interact with content elements (e.g. “delete”, “edit”) or can trigger
navigation to another screen.
These navigation concepts are implemented differently by the different platforms.
Platform-independent Concept Implementations
Common to all of the analyzed mobile operating systems is the navigation via
content elements. As depicted in Fig. 3.1.2, clicking on an element (1) can trigger
navigation to a (sub-) screen e.g. representing details of the element (2).
Furthermore, toolbars with toolbar items
provide options to interact with content
elements and can trigger navigation to
another screen. Although the
appearance differs between platforms,
the Android “Actionbar”, iOS “Toolbar”
and Windows Phone 7 “Application
Bar” provide the same functionality. An
example of a toolbar is depicted in fig.Fig. 3.1.1: Android Action Bar of the AndroidGallery mobile application
3 The Mobile UI DSL 21
3.1.1. The Android “Actionbar” (1) contains entries for e.g. sharing images (2) or
deleting (3) them from the mobile device.
Android-specific Concept Implementations
Hierarchical implementation is implemented via an “Up” button. The “Up” button
is available since Android version 3.0 and enables hierarchical navigation within a
mobile application. An example is shown in Fig. 3.1.2: selecting an entry in the
Google Currents application leads to a detail screen presenting the details of an
article of a magazine. Clicking the “Up” button (2) leads back to the previous
overview. Often, as in this example clicking “Up” has the same effect as clicking
the “Back” button.
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.
22 Peter Reuter, University of Kaiserslautern
application. Clicking the “Back” button will bring the user back to the browser.
This default behavior is provided by the Android platform but can be overridden by
developers. Overriding the default behavior can lead to a inconsistent user
experience and should therefore be used carefully.
“Windows Phone 7”-specific Concept Implementations
The Microsoft Windows Phone 7 platform does not provide hierarchical
navigation. Nonetheless, it provides temporal navigation via a “Back” button that
is similar to the “Back” button of the Android platform. As with the Android
platform the button is system-wide which means that temporal navigation
encompasses the screens of the current application as well as screens of other
applications. This standard behavior is provided by the platform but developers
can decide to override the default behavior. Again, overriding the default behavior
can lead to a inconsistent user experience and should therefore be used carefully.
iOS-specific Concept Implementations
The Apple iOS operating system provides a dedicated navigation bar. This toolbar
commonly contains a “Back” button for hierarchical navigation. Furthermore, it
can also contain content specific controls such as filters to manage contents of
screen.
Temporal navigation as it is provided by the Android or Microsoft Windows Phone
7 platform is not available on the Apple iOS platform.
Summary
Android WP7 iOS
Hierarchical Navigation X X
Temporal Navigation X X
Content Navigation X X X
Navigation via Toolbars X X X
Table 3.1: Summary of navigation concepts in Android, Microsoft Windows Phone 7 and Apple iOS
3.1.2 Frequently Used Screens
Following, frequently used screens of mobile applications are presented in the
abstract form of mobile UI patterns. In the later-on presented code generation
approach these patterns serve as default implementations for screens. The
3 The Mobile UI DSL 23
default implementations can be used after code generation by developers as a
starting point for creating customized implementations. The context section of the
patterns describe that context a pattern should be used in. The pattern solutions
takes into account this general context information, but needs to be adapted to the
concrete context a pattern is used in.
Confirmation
The “Confirmation” pattern can be
found in the 4ourth pattern gallery
[4OUa].
Problem: A process for collecting
information comes to an end. The user
might not remember all information that
she entered.
Context: Long lasting processes
involving multiple screens and large
data sets.
Solution: The user needs to be
presented with a summary of the data
that was entered. She needs to confirm
the presented information in order to
make sure that she made no mistakes.
Example: Fig. 3.1.3 shows the
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.
24 Peter Reuter, University of Kaiserslautern
Grouped Rows
The “Grouped Rows” pattern can be
found the Neil's pattern gallery [NEI12].
Problem: A large dataset needs to be
displayed in a list. The user needs
support while digesting the data.
Context: Large datasets with entries
that differ in one or more criteria.
Solution: Group the entries by the
criteria in which they differ.
Example: Fig. 3.1.4 shows the
Grouped Rows view of the the Google
Contacts Android application. Entries
are grouped by the first letter of a
contact's forename.
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.
3 The Mobile UI DSL 25
Example: Fig. 3.1.5 shows the Login view of the Sixt Car/Truck Reservation
Android application. After login the user is able to access, modify or cancel current
and previous reservations.
Master Detail (Nokia)
The “Master Detail” pattern can be found in the Nokia pattern gallery [NOK13].
Problem: Displaying detailed information for many entries of a large dataset can
distract the user.
Context: A dataset with entries that contain detailed information.
Solution: Display a list with all entries and reduced information along with a
separate view that shows detailed information for the currently selected list item.
Example: Fig. 3.1.6 shows the MasterDetail view of the Google Contacts Android
application. The details of the contact the was selected last from the list of all
contacts are displayed on the right. The list only provides information about the
name of the contact whereas the details view provides all information such as
telephone numbers and e-mail addresses.
Fig. 3.1.6: MasterDetail view of the Google Contacts Android application.
26 Peter Reuter, University of Kaiserslautern
Search
The “Search” pattern can be found in various galleries using different names
[4OUb, AND13, NEI12].
Problem: Seeking a single entry within
a dataset with many entries can take
long.
Context: Large dataset with many
entries.
Solution: Provide a search field that
allows the user to enter search term.
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.
3 The Mobile UI DSL 27
broadcasting are displayed. The videos title is shown in bold print as the main
information. Additional data such as broadcasting date and length of the video are
presented in light print.
3.2 Derived Requirements
The following requirements were derived from the previous analysis of navigation
concepts as well as the problems and general challenge presented in Chapter 1.
The requirements are used as a basis for the DSLs that are presented in Chapter
3.3.
3.2.1 General
As a general premise, the following requirements have to be met by an approach
that solves the initially presented challenge and problems:
1. The approach supports the specification of a mobile application's meta
information consisting of application name, name space and vendor/author.
2. The approach supports the generation of executable mobile applications
that provide a basic, pattern-based UI and full navigation between the
different screens.
3. The approach supports the generation of code stubs for manual
implementation. Manual changes of these stubs must not be reverted by
code re-generation.
3.2.2 Navigation
The navigation concepts presented in Chapter 3.1.1 can be summarized by the
following main requirements. Additional requirements were added in order to
increase practicality.
Main
1. The approach supports the concept of hierarchical navigation between
screens.
28 Peter Reuter, University of Kaiserslautern
2. The approach supports the concept of linear navigation between screens
(screen flows). Thereby, e.g. a process or steps of a user task can be
represented.
3. The approach supports the concept of non-linear navigation via content
elements.
4. The approach supports the concept of non-linear navigation via toolbars.
5. The approach provides the possibility to reuse existing screen flows by
integrating references to them into other flows.
Additional
1. The approach supports nested screen flows, i.e. the decomposition into
sub-flows. Screen flows can represent user tasks which might have
subtasks that can be represented by sub-flows.
2. The approach supports the composition of complex or often used flows in
separate files.
3. The previous requirements also requires the possibility to import such
external flow definitions
3.2.3 Screens
1. The approach supports the integration of UI patterns in order to provide a
default implementation for screens.
1. The approach supports developers while accessing the available
patterns.
2. A referenced pattern can be adapted to the given context. The context
consist of the hierarchical structure a screen resides in as well as
user-defined values for pattern parameters that are required to
instantiate a pattern's solution.
2. A single screen can be marked as as the entry point to the mobile
application.
1. Additional entries for toolbars can be specified that support custom
implementations of the toolbar items.
3 The Mobile UI DSL 29
3.3 The MobileUI DSL
This chapter presents the MobileUI DSL in detail. The DSL was developed in
order to meet the requirements presented before.
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
30 Peter Reuter, University of Kaiserslautern
3.3.1 MobileUI DSL Grammar
MobileUI
The “MobileUI” rule is the starting point for either the definition of a mobile
application or list of flows. The rule allows developers to make “import”
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
3 The Mobile UI DSL 31
The second part of the remainder of the rule allows the definition of a list of flows.
Files matching this part of the grammar rule can be imported by those files, that
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
32 Peter Reuter, University of Kaiserslautern
Finally, the “FlowReference” statement provides support to reuse existing flows at
several points of the mobile application. A further description of the
“FlowReference” statement can be found in the description of the
“FlowReference“ rule.
All three options can be represented in the grammar by referencing rule “Flow”
which enables rudimentary polymorphism.
FlowReference
“FlowReference” statements refer to an existing flow defined in the main file or
any imported file. They provide support for reusing flows definition and their
integration as a sub-flow into the current flow. The explicit semantics of flow
references are presented in Chapter 3.3.4.
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
3 The Mobile UI DSL 33
Action
“Action” statements provide definitions for toolbar items that are available in the
toolbar of the screen. An actions “name” statement represents the label of the
toolbar item.
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
34 Peter Reuter, University of Kaiserslautern
Additional Types
Special parameters can be used to override the implicit “parent”, “next” and
“previous” relation for a given screen. These relations are presented in detail in
Chapter 3.3.4.
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
3 The Mobile UI DSL 35
Pattern
Each “Pattern” statement specifies the interface of a pattern solution via its
“parameters” statement. As mentioned earlier, “Screen” statements can reference
patterns via their “name” attribute which results in a new instance of the pattern
solution created wrt. the context of the screen.
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
36 Peter Reuter, University of Kaiserslautern
3.3.3 Context Conditions
Some restrictions of the MobileUI DSL cannot be expressed by the presented
grammar. Therefore, the following context conditions have to be satisfied in order
to ensure processability of a MobileUI DSL instance:
1. Within a “Screen” statement only simple parameters of the referenced
pattern as well as special parameters may be used.
2. All parameters of a pattern that are not optional have to be provided with
values.
3. The types of the provided values and the parameter type that was specified
in the Pattern DSL file have to match.
4. Each of the special parameters “parent”, “next” and “previous” may only
occur once within a single “Screen” statement.
5. The “target” attribute of an “Action” statement may only refer to screens
and flows that are defined by the “Screen” statement that defines the
“Action” statement.
3.3.4 Semantics of Nested Flows and Screens
The MobileUI DSL does not use an explicit description of navigation between
screens. Instead, nesting of screens and flows creates implicit relations.
The “parent” relation can be derived directly from the hierarchy. It expresses
hierarchical navigation between screens. The parent screen of each screen can
be determined by the algorithm that is depicted in Fig. 3.3.1.
3 The Mobile UI DSL 37
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.
38 Peter Reuter, University of Kaiserslautern
relation can be determined by applying the algorithm that is depicted in Fig. 3.3.2.
The “previous” relation can be determined similarly.
As can be seen from this algorithm, screens encapsulate flows. Separate “next”
and “previous” relations for flows defined as children of a screen are created.
These child flows and screens do not occur in the “next” relation of the flow in
which the parent screen is defined.
Fig. 3.3.3 presents the visualization of an examplary MobileUI specification. The
“parent” and “next” relation were determined using the above algorithms an
highlighted in the figure. For screen S1, S2, S3 and S4 screen Sstart is
determined as the parent screen by evaluating the hierarchical structure. In order
to determine the “next” relation, it might be necessary to evaluate sub-flows
(S1→S2) or to evaluate the hierarchical structure (S4→SStart).
Although the relations are defined implicitly developers can modify them for single
screens by using the special parameters “parent”, “next”, “previous”. Values for
these parameters include the referenced screen or flow into the relation that was
determined by applying and executing the above rules and algorithm.
Fig. 3.3.3: Example for the “parent” and “next” relation
3 The Mobile UI DSL 39
3.4 Summary
In the last chapters, the foundations and concepts of the MobileUI and Pattern
DSL were presented. First, an overview of navigation concepts and frequently
used screens of the three major mobile platforms Android, Microsoft Windows
Phone 7 and Apple iOS was given. It was shown that several navigational
concepts are common to all platforms, while others such as as temporal
navigation concept using a “Back” button are only available on certain platforms.
Also, patterns such as the “Login” pattern were presented with an example
application. The platform-dependent solutions provide a basic screen
implementation that can be refined by developers after code generation. Then,
requirements for a platform-independent DSL that faces the problems of Chapter
1.1 were derived from this basic analysis. Finally, the MobileUI DSL grammar and
the Pattern DSL grammar were presented. The grammars were further restricted
by context conditions that are required to ensure processability. The semantics of
nesting flows and screens and the derivation of the implicit navigation relations
were presented finally. It was shown that the “parent” relation can be derived quite
simply, while in order to derive the “next” and “previous” relation more effort and a
more complex algorithm are required.
4 Tool Support 41
4 Tool Support
In the previous chapter the MobileUI DSL for defining mobile user interfaces and
the auxiliary Pattern DSL were introduced. The DSLs were developed according
to the requirements that were presented in Chapter 3.2. This chapter presents the
code generation approach that implements these requirements. The prototype
allows developers to generate executable mobile application stubs that provide a
basic, pattern-based UI and full navigation between the different screens.
The major tasks a developer has to perform when using this solution are creating
and editing of new descriptions of mobile applications using the MobileUI DSL
and generating executable stubs from these descriptions. The prototype provides
tool support for these tasks. It is implemented as a set of Eclipse IDE plug-ins
since until 05/2013 the major development platform for Android mobile
applications was the Eclipse IDE [ADB13]. The different tasks are supported by
separate plug-ins. A basic parser and editor for both MobileUI DSL and Pattern
DSL is provided via the Eclipse Xtext framework. The editors feature e.g. Eclipse
content assist and outline view. New MobileUI DSL files can be edited easily
using the editors. Furthermore, a code generator is provided as a separate
plug-in. Developers can use this code generator to generate fully functional
Android mobile applications.
4.1 Eclipse Editors for DSL instances
4.1.1 DSL Text Editors
The Eclipse grammars for the MobileUI DSL and the Pattern DSL are specified
using the Xtext grammar language. Therefore, editors for both can be generated
automatically by the Xtext framework. The generation process results in separate
Eclipse plug-ins providing an text editor implementation. The editors provide many
features instead of simple text editing functionality. The editor's default
functionality encompasses among other features auto-completion for specific
values and cross-references, syntax highlighting, syntactic validation, linking
errors and an outline view.
42 Peter Reuter, University of Kaiserslautern
Despite this rich set of feature the
standard behavior of the default
implementation is not sufficient in some
cases. Especially the coverage of the
context conditions that were presented
in Chapter 3.3.3 has to be guaranteed.
As it was mentioned earlier, these
context conditions put further
restrictions on the grammar. Therefore,
checks for the context conditions can
not be generated but must be
implemented manually.
As depicted in Fig. 4.1.1, this can be
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.
44 Peter Reuter, University of Kaiserslautern
Proposal Provider
As no syntactic indicator is available that distinguishes the “SimpleParameter”
rule from the “SpecialParameter” rule, the editor's default auto-completion does
not suggest values for the “type” parameter of the “SpecialParameter” rule. The
absence of the previously mentioned indicator provides a more transparent view
of the DSL to the user. Nonetheless, the developer also has to be informed about
the available “SpecialParameter” rule. Therefore, the auto-completion has to
suggest the values “next”, “previous”, “parent” while specifying a
“PatternParameterRule” instance. The missing values are provided by
implementing a custom ProposalProvider that adds these values to the
auto-completion list (see Fig. 4.1.3).
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.
46 Peter Reuter, University of Kaiserslautern
is already known from e.g. the Eclipse Java development tools is provided also for
the MobileUI DSL editor.
4.1.2 Visualization of DSL Instances
Working with large textual descriptions of a mobile application specified via the
MobileUI DSL does not provide a comprehensive view of the different screens
and their relations. The possibility to decompose these descriptions into several
files makes them even less comprehensible.
A visualization of a complete mobile application description can provide
developers with an overview on the different screens and their relations. The
prototype presented in this thesis represents MobileUI DSL instances as a
graphs. While nodes represent Screens and Flows, the implicit relations “next”,
“previous”, “parent” as well as Actions are represented explicitly by edges.
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
48 Peter Reuter, University of Kaiserslautern
allows the prototype to reference parameters as well as to check whether all
necessary parameters were specified (cf. Chapter 4.1). The data that was
retrieved from the MobileUI DSL instance is then passed to the Freemarker library
which instantiates the dynamic content. The output of the Freemarker library as
well as static content are then added to the already existing Android project.
In contrast to layout or menu descriptions the files “AndroidManifest.xml” and
“values/strings.xml” are shared by several activities. Therefore, they cannot be
simply copied but need to be merged with already existing versions of them.
More about the structure of meta templates is explained in chapters 4.2.1 and
4.2.2. As can be seen easily their structure is resulting from the project structure of
Android Eclipse IDE projects.
4.2.1 Base Meta Template
The Base Meta Template presented in Fig. 4.2.2 is used to generate a basic
Android project for the Eclipse IDE.
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
50 Peter Reuter, University of Kaiserslautern
mentioned earlier, the Screen Meta Template's “AndroidManifest.xml” file has to
be merge into the main “AndroidManifest.xml” file.
The “res” folder contains among other files layout descriptions of the resulting
activity and additional layout descriptions for e.g. list items or dialogs.
Furthermore, menu descriptions that list items of the menus used within the
activity are provided by the “res” folder. Most commonly, the menu descriptions
encompass a toolbar menu. Additional resource files can vary between templates,
but most common comprise additional String resources.
The “src” folder commonly contains source code that implements the behavior of
the activity, but it can also contain library or helper code. Source code files ending
with “Impl.java.ftl” are processed different from others. They provide code
skeletons for which an implementation can be provided by the developer. This
allows the developer to separate generated code for navigation or demo UIs from
code that is to be implemented manually such as business logic. During
re-generation these special files are not modified. In contrast, all other content is
overwritten.
4.2.3 Navigation Controller Architecture
While generating the code that is necessary for navigating the final mobile
application, a considering all relations is not possible. Referencing existing flows
increases complexity, as “next”/”previous” and “parent” relations depend on
context in which a flow is included or specified. In order to cope with this
complexity the navigation task can be decomposed. During code generation, the
children, i.e. screens, flows and flow references, of each flow are known. The
Navigation Controller Architecture makes use of this fact.
Basically, a central instance that knows about flows and one component per flow
called Navigation Controller are provided. Each Navigation Controller handles the
navigation within its respective flow. The Navigation Controllers provides methods
for navigating via the “next”/”previous” and “parent” relations. If navigation via
one of the relations is request by a screen, navigation control is delegated to the
Navigation Controller for the flow that contains the screen. The Navigation
Controller then determines the next screen. If the sibling of the requesting screen
4 Tool Support 51
is a flow or flow reference control is delegated to the respective Navigation
Controller and returned after the last screen of the child flow.
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
52 Peter Reuter, University of Kaiserslautern
The interaction of all of these
components is highlighted using the
exemplary screen/flow structure
depicted Fig. 4.2.5. During code
generation, an Android activity
SXActivity that represents screen “SX”
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”.
54 Peter Reuter, University of Kaiserslautern
Next, the final contents are copied to their respective locations in the target
Android project. As mentioned in 4.2.2, the files “AndroidManifest.xml” and
“values/strings.xml” are treated separately. Finally, the Navigation Controller
Architecture is established as presented in Chapter 4.2.3.
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
56 Peter Reuter, University of Kaiserslautern
Template which represents the default Andrdoi project structure. The new mobile
application's specification can then be modified via dedicated text editors. The
specification is then turned into executable stubs via Screen Meta Templates
which presented platform-specific solutions to the patterns of Chapter 3.1.2.
Last, a graph-based visualization for MobileUI DSL instances was presented as
the textual representation of large or even decomposed mobile application
specifications does not provide a comprehensive overview. Also the implicit
navigation relations are sometimes not easy to understand. The visualization
provides an overview on the complete mobile application specification as well as
an explicit representation of these relations. Therefore, screens and flows as well
as the implicit relations are represented as nodes and edges of the graph,
respectively.
5 Evaluation 57
5 Evaluation
The previous chapters presented an approach that aims to solve the problems
mentioned in Chapter 1. In this chapter an example application is presented and
used as a basis for comparing the traditional development and development of
mobile applications using the MobileUI DSL.
First an overview and informal description of a mobile application for managing
business trips called “BusinessTrips” is presented. The informal description is
then turned into a UI specification using the MobileUI DSL grammar presented in
3.3. Next, the artifacts resulting from the code generation process are presented.
A special focus is put on the generation of a DemoUI in contrast to the final
application. Finally, the approach is compared to traditional development in terms
of initial and long-term effort.
5.1 Description and Specification
Following a fictional, informal description of a mobile application as a customer
could give it to developers can be found.
“The 'BusinessTrips' mobile application provides a UI for viewing
future and past business trips. Additionally, the possibility to add new
business trips has to be provided. When creating a new business trip,
basic data consisting of the trips designation and date, possible night
stops, in detail hotel, room and duration of night stops, and means of
transportation need to be provided. Additionally, a cost center for night
stops and means of transportation is mandatory which should be
chosen via a single UI. In order order to protect the private data of
business trips from unauthorized persons, a possibility for user
authentication has to be provided by the mobile application.”
A developer can create a specification of screens and screen flows using the
MobileUI DSL in turn. Fig. 5.1.1 presents possible screens and flows of resulting
from the informal specification as well as visual representation of the implicit
58 Peter Reuter, University of Kaiserslautern
relations between the different screens. A complete textual specification can
found found in Chapter 10.3. As can be seen, access to the application is
restricted via a “Login” screen. Current and past business trips can be viewed via
the “BusinessTrips_Overview” screen providing a list grouping business trips into
the categories “BusinessTrips – current” and “BusinessTrips – past”. Additional
information on single business trips can be viewed via the
“BusinessTrips_Details” screens. The “Businesstrips_Overview” screen
furthermore provides a toolbar action "New_BusinessTrip” that starts the
“New_BusinessTrip” flow for adding new business trips. The data for new
business trips is acquired via the subflows “BaseData”, “Night_Stops” and
“Means of Travel”. As required by the informal specification, the
“Choose_CostCenter” flow is reused within “Night_Stops” and
“Means_of_Travel” flow via flow references. As it is defined separately, it can be
easily reused within other mobile applications.
Fig. 5.1.1: Specification of the “BusinessTrips” mobile application with implicit relation “next”(purple) and action “New_BusinessTrip” (green) of screen “Businesstrips_Overview”
5 Evaluation 59
5.2 Code Generation
After the specifying screens and flows of the “BusinessTrips” mobile application
via the MobileUI DSL, the source code for Android mobile application can be
generated easily. As presented in Chapter 4.2, during code generation, the screen
meta templates of the referenced patterns are instantiated. Source code for
screens, layout and menu descriptions is generated. Furthermore, instances and
library code is copied to the Android project. Finally, the Navigation Controller
Architecture that is depicted in Fig. 5.2.1 is established as described in Chapter
4.2.3. As presented in Chapter 4.2.3, a subclass of the “AbstractNavController”
class is created for each Flow, additionally one navigation controller for the whole
mobile application. The implicit navigation relations were turned into code
statements of “setup()” method of the NCRegistry class that is presented in
Chapter 10.4.
After code generation, the mobile application can be executed directly.
Screenshots of the "BusinessTrips”, “BusinessTrips_Overview” and
“BusinessTrips_Details” screen are presented in Fig. 5.2.2.
60 Peter Reuter, University of Kaiserslautern
As the “Generate Demo UI” key phrase is used in the specification, only dummy
content is generated, but no implementation for e.g. authentication or retrieving
data is provided. Manual implementations are required for the application logic.
Examples for such application logic are: ListAdapters for retrieving data from data
sources and providing them to Android ListViews, authentication methods, or
methods for searching in and filtering of ListViews. Furthermore, if required,
layouts need to be adapted. These layouts can include: the layout of ListView
items that should display more than a simple string, or the branding for customers
via icons or colors. When the key phrase “Generate Demo UI” is removed from
DSL instances, stubs for manual implementation of this business logic are created
during code generation. Following, the exemplary implementation of the
“BusinessTrips” screen that utilizes the “Login” pattern is presented. After
removing the “Generate Demo UI” key phrase and code re-generation in addition
to “BusinessTrips.java” the file “BusinessTripsImpl.java” exists. The default
content of “BusinessTripsImpl.java” is presented in Listing 4.1. Now, a
meaningfull authentication mechanism can be implemented within
“BusinessTripsImpl.java”. The manual implementation presented in Listing 4.2
uses a fictional authentication service that could for example utilize a web service
After the implementations for all generated stubs are created by the developer,
the final application can be executed and tested on an Android device or the
Android Emulator again. It has to be noted that no need to implement or modify
code for navigation exists, as navigation is encapsulated by Navigation
5 Evaluation 61
Controllers and the “AbstractMobileUIActivity” class. Additionally, all other
template specific code is encapsulated by implementation of screen meta
template.
5.3 Comparison with Traditional Development
In the previous chapters, the informal and formal specification of a fictional mobile
application for managing business trips as well as code generation based on the
formal specification were presented. Following, the effort for creating an
application using the MobileUI approach is compared to the required effort using
the traditional development approach for the Android platform.
At first, the initial effort when creating a single new mobile application is analyzed.
Next, the long-term effort when maintaining existing applications or creating new
applications based upon already existing applications is analyzed. Finally, a
summary of the presented effort analysis is given.
5.3.1 Initial Effort
When starting the development of a new application, it is required for both
approaches to derive a specification of the required screens and screen flows.
Whether an unspecific approach like informal graphical or textual notations or a
specification using the MobileUI DSL is created does not alter the required effort.
Next, in traditional development an implementation for each screen is created
manually. Furthermore, navigation code, that is hard-coded into the
implementation of the screen needs to be implemented. In contrast, the MobileUI
approach requires a set of templates that needs to be created first. As experience
from the templates for the patterns presented in Chapter 3.1.2 shows, the creating
of a template requires approximately ½ to 1 day per template. Subsequently, the
first draft for the new mobile application can be generated and afterwards tested
easily. As a next step business logic and custom layouts need to be implemented,
which is common to both, the traditional and the MobileUI development approach.
In addition, using the MobileUI development approach, new templates can be
derived from custom implementations which in turn can be reused in future mobile
applications.
62 Peter Reuter, University of Kaiserslautern
5.3.2 Long-term Effort
In traditional development new applications need to be created manually. Also
when adding new screens to an existing mobile application each screen manually.
Furthermore, altering screen flows requires to manually change the hard-coded
statements for navigation. Although the possibility to reuse existing layouts and
implementations exists, additional code that handles navigation needs to be
implemented manually and changes to navigational structure require probably
many manual changes. In contrast, the altering existing mobile applications using
the MobileUI approach requires much less effort. Adding new screens simply
requires the integration of them into an already existing MobileUI DSL file. When
altering the screen flows, of already existing mobile applications, only the order of
screens in the MobileUI DSL file needs to be changed and the code has to be
re-generated. Furthermore, new mobile applications can be easily derived from
already existing ones be using the already existing templates and reusing flows.
5.4 Summary
In the previous chapters, first, an informal description and formal specification of
an exemplary mobile application presented. The code generation process and
resulting artifacts of the MobileUI approach were presented. The transition from
the generated UI to the final UI including business logic was highlighted using a
screen referencing the “Login” pattern. Manual adaptation and implementation of
application logic and Android layout specifications is required, but
implementations the provided a basis for manual refinement are available. Finally,
a comparison to traditional development showed that the initial effort is higher
when using the MobileUI approach as the effort for setting up templates is high. In
contrast, the long-term effort for traditionally developed applications is much
higher. Altering the application or deriving new applications using the MobileUI
approach can take advantage of already existing artifacts such as screen flow
specifications or templates and thereby reduces effort.
6 Conclusion 63
6 Conclusion
6.1 Summary
In Chapter 1 the following challenge for developers of mobile applications was
presented: “Minimize the amount of re-development while creating new mobile
applications for similar business cases and porting existing mobile applications to
new configurations”. As an additional problem, adherence to the style guides of
the target platforms was mentioned. In order to achieve style guide conformity,
developers need to be experts for the target platform of the mobile application.
The approach that is suggested in this thesis targets the initial challenge and
overcomes issues of existing approaches that were presented in Chapter 2.2.
The basic idea of the presented approach is to reuse and combine existing
technologies. Model-based development is used to provide platform-independent
description of mobile applications. Mobile UI pattern for frequently used screens
featuring platform-dependent pattern solutions enable adherence to style guides.
Finally, code generation is used to transform the platform-independent model into
platform-dependent artifacts by using platform-dependent pattern solutions.
The presented prototype uses a DSL as the notation form for the model. The DSL
provides the possibility for screens to refer to patterns such as the “Login” pattern.
Tool support for creating and editing DSL instances and code generator for
Android platform is implemented prototypically via the Xtext framework.
In order to evaluate the approach, an exemplary mobile application for managing
business trips is presented. A comparison of traditional development and
presented approach shows, that the initial effort when using the presented
approach is higher. Nonetheless, the long term effort can be considered
significantly less. Thereby, the approach solves the initial challenge. Screens and
screen flows of existing applications can be easily integrated into new mobile
applications.
64 Peter Reuter, University of Kaiserslautern
6.2 Future Work
The code generator for the Android platform presented in this thesis already
shows the general feasibility of this approach. As a next step, additional code
generators for the iOS and Windows Phone 7 platform need to be develped.
When additional code generators for the iOS and Windows Phone 7 platform are
provided, the effort of providing mobile applications for the major mobile platforms
is reduced. In order to further decrease the initial effort of developing new mobile
applications, additional templates need to be provided. To this end, screens of
existing mobile applications can be transformed into new pattern solutions by
following the structure of the screen meta templates that were presented in
Chapter 4.2.2. As the initial development of these screen meta templates showed,
this task is time consuming and tedious without tool support. Therefore,
appropriate tools for converting existing screens into screen meta templates need
to be developed in order to reduce the effort that is required for conducting this
task.
Further improvements could for example include an extended code generator that
support partial code re-generation for regenerating only navigation code or a
distinct set of screens. Additionally, embedding custom layout into generated
layouts could be supported. Extensions to the MobileUI DSL could include
additional abstractions via flow templates. Thereby, parameterized flows that can
be adapted to the context they are used in could be provided. In addition, existing
applications should be examined for flow patterns. It has to be checked whether
flow patterns exist and how they can be formalized.
7 Bibliography 65
7 Bibliography
[4OUa] "Confirmation - 4ourth Mobile Design Pattern Library", 2013,
http://4ourth.com/wiki/Confirmation, accessed 05.06.2013
[4OUb] "Search Within - 4ourth Mobile Design Pattern Library", 2013,
http://4ourth.com/wiki/Search%20Within, accessed 05.06.2013
[4OUc] "Vertical List - 4ourth Mobile Design Pattern Library", 2013,
http://4ourth.com/wiki/Vertical%20List, accessed 05.06.2013
[ADB13] "Android Studio: An IDE built for Android | Android Developers Blog",
2013,
http://android-developers.blogspot.de/2013/05/android-studio-ide-built
-for-android.html, accessed 08.07.2013
[ADT13] "ADT Plugin | Android Developers", 2013,
http://developer.android.com/tools/sdk/eclipse-adt.html, accessed
07.02.2013
[ALE77] Alexander, C., "A pattern language: towns, buildings, construction",
1977
[AND13] "Android Interaction Design Patterns", 2013,
http://www.androidpatterns.com/,
[BIT13] "Tablet Computer drängen in die Berufswelt", 2013,
http://www.bitkom.org/de/presse/8477_75913.aspx, accessed
13.05.2013
[CAL2003] Calvary, G., Coutaz, J., et al., "A unifying reference framework for
multi-target user interfaces", 2003
[CZA05] Czarnecki, K., "Overview of generative software development", 2005
[DEU00] van Deursen, A., Klint, P., Visser, J., "Domain-specific languages: An
annotated bibliography", 2000
66 Peter Reuter, University of Kaiserslautern
[DEV13] "The AndroidManifest.xml File | Android Developers", 2013,
http://developer.android.com/guide/topics/manifest/manifest-intro.html,
accessed 15.08.2013
[FOW10] Fowler, M., "Domain-specific languages", 2010
[FRE13] "Freemarker: Java Template Engine Library", 2013,
http://freemarker.sourceforge.net/index.html, accessed 01.03.2013
[GAM94] Gamma, E., Helm, R., Johnson, R., Vlissides, J., "Design patterns:
elements of reusable object-oriented software", 1994
[GIF13] "jgilfelt/android-adt-templates", 2013,
http://developer.android.com/tools/sdk/eclipse-adt.html, accessed
07.02.2013
[INS13] "Inspirred UI - mobile ui patterns", 2013, http://inspired-ui.com/,
accessed 01.03.2013
[LIM04] Limbourg, Q., Vanderdonckt, J., Michotte, B., Bouillon, L., Florins, M.,
"USIXML: A User Interface Description Language Supporting Multiple
Levels of Independence.", 2004
[MAN10] Mannadiar, R., Vangehluwe H., "Modular synthesis of mobile device
applications from domain-specific models", 2010
[MER05] Mernik, M., Heering, J., Sloane, A.M., "When and how to develop
domain-specific languages", 2005
[NEI12] Neil, T., "Mobile Design Pattern Gallery", 2012
[NOK13] "Mobile Design Pattern: Master Detail - Nokia Developer Wiki", 2013,
http://developer.nokia.com/Community/Wiki/Mobile_Design_Pattern:_
Master_Detail, accessed 06.06.2013
[PER07] Perez-Medina, J. L., Dupuy-Chessa, S., et al., "A survey of model
driven engineering tools for user interface design", 2007
[PTR13] "iOS Mobile Patterns Library", 2013, http://pttrns.com/, accessed
08.02.2013
[PUD10] Puder, A., "Cross-compiling Android applications to the iPhone", 2010
7 Bibliography 67
[PUE97] Puerta, A. R., Maulsby, D., "Management of interface design
knowledge with MOBI-D", 1997
[SEN13] "HTML5 Mobile App Development Framework.", 2013,
http://www.sencha.com/products/touch/, accessed 01.03.2013
[SIN04] Sinnig, D., "Enhancing Re-Use: Towards a Pattern- and
Component-Based UI Development", 2004
[TID13] "Patterns: Designing Interfaces", 2013,
http://designinginterfaces.com/patterns/, accessed 08.02.2012
[W3C] "Model-based UI XG Final Report", 2013,
http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui/#mbui,
accessed 19.08.2013
[WEL13] "Interaction Design Pattern Library", 2013,
http://www.welie.com/patterns/, accessed 08.02.2013
[XTD13] "Xtext - Language Development Made Easy!", 2013,
http://www.eclipse.org/Xtext/, accessed 07.02.2013
[XTE13] "Xtext - Language Development Made Easy!", 2013,
http://www.eclipse.org/Xtext/, accessed 07.02.2013
8 List of Figures 69
8 List Of Figures
Fig. 1.1.1: Simplified CAMELEON Reference Framework [LIM04] And
Classification Of The MobileUI DSL.............................................................................2
Fig. 1.2.1: Sketch Of The Approach Presented By This Thesis................................4
Fig. 2.1.1: Tab Orientation For Various OSs [NEI12, Fig. 1-12]..............................10
Fig. 2.1.2: Freemarker Text Generation Process, Adapted From [FRE13]............11
Fig. 2.2.1: “New Activity” Wizard Of The Eclipse ADT.............................................12
Fig. 2.2.2: Sencha KitchenSink Application [SEN13]...............................................13
Fig. 2.2.3: Cross-compilation Process, Adapted From [PUD10, Figure 2].............14
Fig. 2.2.4: PhoneApps Layered Model Transformation Approach..........................15
Fig. 3.1.1: Android Action Bar Of The Android Gallery Mobile Application............20
Fig. 3.1.2: Google Current Mobile Applications, Hierarchical Navigation And
Navigation Via Content.................................................................................................21
Fig. 3.1.3: Confirmation View Of The Sixt Car/Truck Reservation Android
Application.....................................................................................................................23
Fig. 3.1.4: Grouped Rows View Of The The Google Contacts Android Application.
.........................................................................................................................................24
Fig. 3.1.5: Login View Of The Sixt Car/Truck Reservation Android Application.. .24
Fig. 3.1.6: MasterDetail View Of The Google Contacts Android Application.........25
Fig. 3.1.7: Search View Of The Google Contacts Android Application...................26
Fig. 3.1.8: Simple List View Of The “Theke” Android Application...........................26
Fig. 3.3.1: Algorithm For Determining The “next” Relation.......................................33
Fig. 3.3.2: Algorithm For Determining The “parent” Relation...................................37
Fig. 3.4.1: Example For The “parent” And “next” Relation.......................................38
Fig. 4.1.1: Generation And Customization Of DSL Editors......................................42
Fig. 4.1.2: Wrong (default) And Correct Scoping Of References To Pattern
Parameters.....................................................................................................................43
Fig. 4.1.3: Additional Proposals For The Explicit “next”, “previous” And “parent”
Provided By The Custom Proposal Provider.............................................................44
Fig. 4.1.4: Using The HyperlinkHelper To Navigate From Specification To
Implementation..............................................................................................................45
70 Peter Reuter, University of Kaiserslautern
Fig. 4.1.5: Visualization Of A MobileUI DSL Instance...............................................46
Fig. 4.2.1: Structure Of Meta Templates....................................................................47
Fig. 4.2.2: Structure And Content Of The Base Meta Template..............................48
Fig. 4.2.3: Structure And Common Files Of A Screen Meta Template...................49
Fig. 4.2.4: Classes Of The Navigation Controller Architecture................................51
Fig. 4.2.5: Example Screen/flow Structure.................................................................52
Fig. 4.2.6: Retrieving The Navigation Controller And Using It Within A Concrete
Android Activity That Represents A Screen..............................................................52
Fig. 4.2.7: Executing A “navigateNext” Call...............................................................52
Fig. 4.2.8: Generation Process For A Single Screen................................................54
Fig. 5.1.1: Specification Of The “BusinessTrips” Mobile Application With Implicit
Relation “next” (purple) And Action “New_BusinessTrip” (green) Of Screen
“Businesstrips_Overview”...........................................................................................58
Fig. 5.2.1: Navigation Controller Architecture For “BusinessTrips” Mobile
Application.....................................................................................................................59
Fig. 5.2.2: Exemplary Screenshots Of The “BusinessTrips” Mobile Application. .60
9 List Of Tables 71
9 List Of Tables
Table 3.1: Summary Of Navigation Concepts In Android, Microsoft Windows
Phone 7 And Apple IOS...............................................................................................22
10 Appendices 73
10 Appendices
10.1 MobileUIDSL – Xtext Grammar
1 grammar de.tukl.cs.softech.mobileui.Dsl with org.eclipse.xtext.common.Terminals
2 generate dsl "http://www.tukl.de/cs/softech/mobileui/Dsl"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
74 Peter Reuter, University of Kaiserslautern
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 ;
76 Peter Reuter, University of Kaiserslautern
10.3 Main screens for the “Business Trips”
mobile application
10.3.1 BusinessTrips.mobileui
1 import "patterns.ptncat"2 import "CostCenter.mobileui"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 {
78 Peter Reuter, University of Kaiserslautern
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 }