Thomas Matzke XML & DYNAMIC USER INTERFACE DESIGN IN ...

joyfulfightΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

140 εμφανίσεις



Faculty of Computer Science, Institut
e

of System
s Architec
tur
e
,
Chair of Comput
er Networks

Technical University of Dresden, Thomas Matzke
Faculty of Computer Science, E-Mail: thomas.matzke@inf.tu-dresden.de
Institute of Systems Architecture,
Chair of Computer Networks



































Thomas Matzke
XDUDE
XML & DYNAMIC USER INTERFACE DESIGN
IN GOOGLE ANDROID

Großer Beleg
Dresden, 2009
2

TABLE OF CONTENTS
Table of Contents ............................................................................................................................. 2
1. Introduction .......................................................................................................................... 3
2. Google Android – An Overview ........................................................................................... 7
2.1. In general ...................................................................................................................... 7
2.2. Applications .................................................................................................................. 8
2.2.1. General Information ......................................................................................................... 8
2.2.2. Building Blocks .................................................................................................................. 9
2.2.3. Application Model........................................................................................................... 10
2.2.4. Application Lifecycle ...................................................................................................... 10
2.3. Developing .................................................................................................................. 11
3. Google Android User Interfaces ........................................................................................ 13
3.1. State-of-the-art ........................................................................................................... 13
3.1.1. Views and View Groups ................................................................................................ 13
3.1.2. XML-based Layouts ........................................................................................................ 14
3.2. Dynamic User Interface Design and XML – An open issue ....................................... 16
3.2.1. The Issue ........................................................................................................................... 16
3.2.2. Requirements analysis .................................................................................................. 17
3.2.3. Google Maps .................................................................................................................... 19
3.2.4. Conclusion ........................................................................................................................ 20
4. Concept and its Realisation ............................................................................................... 21
4.1. Overview ..................................................................................................................... 21
4.2. Web Service ................................................................................................................ 23
4.3. Interpreter ................................................................................................................... 26
5. Implementation .................................................................................................................. 31
5.1. xDUDE Web Service ................................................................................................... 31
5.2. xDUDE Interpreter ...................................................................................................... 34
6. Evaluation .......................................................................................................................... 40
6.1. Research Objectives ................................................................................................... 40
6.2. News Ticker Example ................................................................................................. 43
6.3. Goolge Maps .............................................................................................................. 46
6.4. Summary and Constraints ......................................................................................... 49
7. Summary and Future Work ............................................................................................... 52
7.1. Achieved Research Objectives ................................................................................... 52
7.2. Future Work ................................................................................................................ 52
References ...................................................................................................................................... 54
3






































4



ERKLÄRUNG




Hiermit erkläre ich, Thomas Matzke, die vorliegende Diplomarbeit zum Thema:


Analyse von Möglichkeiten und Umsetzung eines Verfahrens zur dynamischen User
Interface Generierung von Google Android


selbständig und ausschließlich unter Verwendung der im Quellenverzeichnis
aufgeführten Literatur- und sonstigen Informationsquellen verfasst zu haben.






Dresden, 30.6.2009












5





































6

1. INTRODUCTION
Google Android is a free, open source, and fully customisable platform
developed for mobile phones by the Open Handset Alliance. It includes an operating
system, middleware and mobile applications. [1] The term Android comes from the
Greek term androides (man + -like) and is used for ‘an automaton resembling a
human being.’
1

Android provides XML-based [2] layout descriptions, which are also separated
from code; an ideal possibility for static user interface design. But, due to the static,
at build time defined behaviour of these XML files reveal various drawbacks. First,
they only fit into the previously defined situation. Static UI design is totally inflexible
when it comes to variation of the circumstances. This might happen through
different end devices, user interactions or updating of the application. Furthermore,
modifications of the program involve another drawback. The implementation of a
user interface takes about half the time of the development of the whole project [3].
After changing the application, it might be necessary to invest the majority of this
time again on adapting the UI to the new requirements. Moreover, this concept is
not capable of handling user interfaces that are not determined before the
corresponding application is launched, without any question. As a result, static UI
design is inappropriate to be used in SOA approaches, which became popular and
essential in many companies over the last several years [4]. For instance, one
required feature in SOA is ad-hoc UI generation for Web Services to enable human-
machine interactions. The creation of the Web Services’ user interface descriptions
was already achieved. In the case of Android, an adequate format to provide a Web
Service UI is offered through the XML UI descriptions. They are supported widely
due to their XML syntax and furthermore, they are potent enough to describe the
various layout elements and attributes of Android. The missing part is the
interpretation and displaying of the user interface in Android at runtime. This is
because XML-based UIs require to be declared at build time. The research objective
of this assignment is not only the ad-hoc interpretation of XML UIs, but enabling full
dynamic user interface design, which also involves UI updates. The scope of this
research does not involve dynamic creation of the UI. Moreover, the major research
questions are:

/q1: What architecture enables a system to be capable of realising dynamic user
interface design in Android?
/q2: In which way must updates be broadcast to enable smooth processing at
client-side?
/q3: Is dynamic UI design at runtime too costly in Android?


1
The Oxford English Dictionary, 1991
7

2. GOOGLE ANDROID – AN OVERVIEW
2.1. IN GENERAL
The Open Handset Alliance (OHA) is a group of 47 companies
2
of all kinds of
the mobile ecosystem, e.g. Google, Sony Ericsson, T-Mobile and Intel. Along with
developing the initial version of Android under Google’s leadership, the members
also support the platform by the development of further software and hardware. The
big goal of the OHA is to accelerate innovation for mobile devices and provide more
comprehensive and cheaper mobile hardware and software. [5] The Alliance released
Android under the Apache v2 Open Source licence with a few exceptions, for
example the Linux kernel patches. Consequently, developers are free to sell their
programs for this completely open platform without any constraints to publicise their
source code. Additionally, mobile devices that are using Android, which is free of
charge, become more affordable than mobiles that use paid competitive products
like Windows Mobile or iPhone OS.
The base of Google Android is a Standard Linux Kernel; therefore, Android
benefits from advantages such as: mature memory and process management,
permissions based security model, proven driver model, and an open source status.
[6] Furthermore, the Dalvik Virtual Machine relies on the Linux kernel and is part of
the Android Runtime Environment. Google implemented an Android optimised
proprietary version of the Java libraries for its Runtime Environment. Due to this fact,
Google’s core libraries cover only a subset of the functionality of Sun’s Java libraries.
The Dalvik VM is CPU and memory optimised and was built to run Google’s
proprietary .dex byte code instead of java classes and jar files. As shown in Figure 1,
C/C++Libraries are lying on top of the Linux Kernel. They include among other things
a media library, 2D and 3D libraries and Apple’s WebKit. The aforementioned libraries
provide basic functionality, which are shipped to application developers through the
Application Framework. Since Android’s Application Framework is designed to
simplify reutilisation of application components, every application can publish its
abilities easily and is able to use the abilities of other applications at the same time.
Moreover, the framework includes various managers for service and system access,
including a set of Views, Content Providers, Resource Managers, Notification
Managers, and Activity Managers. A View represents the basic element of the
Android user interface; moreover, it is responsible for managing the layout and the
events assigned to it. [7] Additionally, the framework provides many Views, for
example controls (button, check box, and spinner) and layouts (table, grid, and list).
There are different Content Providers (e.g. audio, video, personal contact
information) to retrieve and store data of an application and make it accessible to
another one. This is the only way for applications of different packages to share data
directly one the device. The Resource Manager provides access to the individual
resource folder of an Android application and the Notification Manager is responsible
for the various notifications, which can be displayed. Finally, the Activity Manager is


2
Stand as at: 2009/1/16

one of the most important parts of t
single, focused thing that the user can do.”
the single things
by maintaining the navigation stack within an application and the
state of each activity.
There are optional APIs that may not be supported by a certain
mobile device. In spite of this fact, they are still present even if they cannot be used
on the device. Optional APIs are among others Wi
Media APIs
, and OpenGL. Reasons for unsupported devices might be no Wi
capability, no GPS, or unsupported media codecs.

2.2. APPLICATIONS
This subchapter
gives an overview about
software stack: A
pplications

2.2.1.
General Information
Android ships with certain
functionalities
to the user. Examples for
contacts applicat
ion, and
applications for Google Android is Java.
system, various applications can run
its individual process
, eac
application is given a unique ID
guarantee security. [7]
This
execution stack within Android. An application is not allowed to affect another one
8
one of the most important parts of t
he Application Framework.
single, focused thing that the user can do.”
[8]
The Activity Manager takes care
by maintaining the navigation stack within an application and the
There are optional APIs that may not be supported by a certain
mobile device. In spite of this fact, they are still present even if they cannot be used
on the device. Optional APIs are among others Wi
-
Fi APIs, Location
, and OpenGL. Reasons for unsupported devices might be no Wi
capability, no GPS, or unsupported media codecs.

FIGURE 1: ANDROID Architecture [8]
gives an overview about
the highest level of the Android
pplications
.
General Information

Android ships with certain
preinstalled applic
ations to provide basic
to the user. Examples for

these core applications are:
ion, and
a SMS program.
The programming language to develop
applications for Google Android is Java.
Because the Android OS is a multiprocess
system, various applications can run
simultaneously. In detail
, every application owns
, eac
h of which hosts its own virtual machine
application is given a unique ID
from the system
for its installation lifetime to
This
provides the application with
an associated and protect
execution stack within Android. An application is not allowed to affect another one
he Application Framework.
“An activity is a
The Activity Manager takes care
of all
by maintaining the navigation stack within an application and the
There are optional APIs that may not be supported by a certain
mobile device. In spite of this fact, they are still present even if they cannot be used
Fi APIs, Location
-Based-Services,
, and OpenGL. Reasons for unsupported devices might be no Wi
-Fi

the highest level of the Android
ations to provide basic
these core applications are:
a calendar, a
The programming language to develop
Because the Android OS is a multiprocess
, every application owns
h of which hosts its own virtual machine
. Once installed, an
for its installation lifetime to
an associated and protect
ed
execution stack within Android. An application is not allowed to affect another one
,
9

e.g. performing operations on data of other applications, unless it is not specified by
the developer. The security characteristics are enumerated in the
AndroidManifest.xml. This file is required in each Android application and resides in
its root folder. Besides security permissions the Building Blocks used by the
application are specified in the AndroidManifest.xml.

2.2.2. Building Blocks
An application for Google Android can be viewed as a collection of
components referred to as Building Blocks. Four different Building Blocks (1.
Activities, 2. Views, 3. Broadcast Receivers, 4. Services and 5. Content Providers)
serve various purposes and make up an application. Not all of them are required to
build an application, but they can be combined as necessary. During the following
paragraphs the different Building Blocks are described in detail.
As mentioned above, Activities are small steps within an application and
provide certain functionality to the user. Normally, an Activity is represented in an
application by a window. For example opening a new window is accomplished
through starting a new Activity. However, other possibilities to use Activities exist as
well, e.g. embedding them into another Activity. [8] Furthermore, Android manages
Activities as a stack. If a new Activity is started, it becomes the running Activity and
the system puts it on the top of the stack. As long as no other Activity is launched or
the current Activity is closed by the user, it remains the running Activity. Paused and
stopped Activities still retain all state and member information, but they will often be
killed by the system if more memory is needed. In addition, moving from one
Activity to another is done through Intents. “An Intent is an abstract description of an
operation to be performed.” [8] It requires an action that provides information about
the processing task and data to act upon, represented through a URI. Moreover,
IntentFilters describe what Intents an Activity or Broadcast Receiver is capable of.
Unlike Activities, Broadcast Receivers do not use a UI except for alerts they
publish by using the Notification Manager. Through Broadcast Receivers Applications
are capable of reacting to external events, including phone calls, time, and network
status. Additionally, applications can create their own broadcasts and send them to
others. [8]
Furthermore; services run completely without UI in the background. The other
components of an application can connect to a Service and invoke methods on it via
RPC. A good example for this is a media player. A service starts to play the music file
and keeps playing it even if the UI of the player is closed. When the user wants to
skip the actual song, the UI is opened again to invoke methods on the service. [8]
There are two kinds of Services. Whereas explicitly started Services run until they
are explicitly shut down or killed by the system, implicitly started Services run until
the last component unbinds. [9]
Usually, data of applications are stored in a SQLite database. In the case data
is shared by multiple applications, Content Providers are necessary. They handle the
data and provide methods to retrieve and store it.
10

2.2.3. Application Model
Code and resources of an application are stored in a file referred to as Android
Package (APK) [9]. Moreover, Android users would generally perceive Tasks in
Google Android as applications as they know from other systems. In contrast, from a
developer’s point of view Tasks are a collection of related Activities. If nothing
different is specified, each Activity of an APK runs in the same Task, which maintains
all its Activities in its own Activity stack. By default one Task runs per Process and
one Process runs per APK. An Android Process equates a Linux Process, i.e. it is a
kernel process in which the code of an application is running. Once started, an
Android Process remains until it is killed by the system. [9] Moreover, one or more
Threads run in a Process. All components of an application are created in the main
Thread of the same Process, unless otherwise specified. Consequently, it is not
common to start a new Thread for each single Activity, Broadcast Receiver, Service,
or Content Provider instance. If any component of an application performs long
operations, it will block all other components of the same Thread. Therefore, these
blocking components should run in their own Thread. Individual Threads are
especially useful for Services and Content Providers. Creating a new Process is very
uncommon in this case. Each Thread includes a class, referred to as a Looper, to
handle message queues and events for all components. [9]

2.2.4. Application Lifecycle
As previously mentioned, every application runs in its own Process in Android.
The lifecycle of the Process is not directly maintained by the application itself as
normally done in other systems; instead, Android manages the lifecycle. How the
system acts depends on the parts of the application that are running, the allocated
memory and how important it is to the user. [8] To decide which Process should be
killed first in the case of low memory, Processes are divided into five categories,
which are introduced in Table 1: Categories of Processes They are ordered in regards
of importance.


Name
Example
1)

Foreground Processes Running Activity and Broadcast Receiver, or a Service that
currently executes code
2)

Visible Processes Paused Activities
3)

Service Processes Service that has been started (Not visible to the users, but
important to them, due to its functions like playing music
and downloading data)
4)

Background Processes Stopped Activities
5)

Empty Processes No active component (Kept running to improve start up
time when they are needed again.)
TABLE 1: CATEGORIES OF PROCESSES

11

2.3. DEVELOPING
The Android SDK provides a large number of tools to satisfy the needs of
developers. This subsection contains a short review about the process of developing
an application for Google Android and how far-reaching the support is. To enjoy full
benefits for developing Eclipse is required. Other IDEs may be used to develop
applications for Android, but the current plugins are not as comprehensive and
technically mature as the Eclipse plugin.
3
Developing in Eclipse can be started after
unpacking the SDK and installing the Android Development Tools plugin (ADT).
With the ADT, Google affords a wide range of extensions for creating,
debugging and running applications more easily. First, a Wizard guides the developer
through creating a new Android project. Afterwards, appropriate folders and files are
generated automatically. The project can already be built after setting up the launch
configurations. Without anything changed, the final result is a simple Hello World
Application. To build a project, the ADT plugin resorts to the Android Asset
Packaging Tool (AAPT), which allows creating Zip-compatible archives (zip, jar, apk).
[8] Furthermore the ADT also includes a Launch Configuration Manager, which can
be used to specify the project to launch, the activity to start, multiple emulator
options and some additional settings. Further extensions of the ADT are special
views to edit the different XML files, for instance manifest and layout file, more
comfortably.
Once the project is built, it can be tested by using the Android Emulator,
which mimics all typical hardware and software features of a mobile device, except
that it cannot receive or place actual phone calls. [8] The Launch Configuration
Manager provides Eclipse developers with multiple parameters to handle the
Android Emulator. Main settings are display size, network latency and network
speed. Additionally, a command line is available to specify for example help options,
debugging or disk images in more detail. It provides access to the settings while the
emulator is already running as well. Every emulator instance provides a console and
a port to connect to the console via telnet. Along with changing settings, the console
can be used to simulate phone calls and SMS and to send data between different
emulator instances. The main settings are also available by using the Dalvik Debug
Monitor Service (DDMS) Tool, which is a part of the ADT plugin and provides a
graphical user interface in Eclipse. Moreover, the Android Emulator supports typical
mobile hardware characteristics, including: ARMv5 CPU, sound chip with out- and
input, emulated Flash Memory partitions, GSM Modem and simulated SIM Card. [8]
Nevertheless; there are more limitations than receiving and placing real phone calls.
For instance connections via USB and Bluetooth as well as camera input, battery
charge level and headphone support cannot be emulated.
Besides creating, building and testing an Android application, debugging is
also well supported by Google. The DDMS also covers debugging features. It is
integrated in Eclipse as an additional perspective and acts as a middleman to provide
the IDE with a connection to the applications running in the Android Emulator or on


3
Idea-android for IntelliJ IDEA, nbandroid for Netbeans

devices.
Furthermore, it can also be started separately.
all emulators and devices and their Virtual Machines (applications) currently running
I
nformation about threads and h
data,
network speed and
running. S
ystem messages of different levels, l
messages
of the developer
calls, SMS and data can be simulated as well.
Viewer are tools that present
information about the time, methods and threads spend, which
optimising and debugging an application.
debug and optimise user interfaces.
Application,
displayed by the Hierarchy View
relations between the different blocks of the user interface are presented. On the
right side,
properties of the currently selected block and its position in the display are
shown. In addition, the content of the current
window. However, the
Hierarchy Viewer does not work
set in code.
Additionally,

12
Furthermore, it can also be started separately.
The tool
gives an overview
all emulators and devices and their Virtual Machines (applications) currently running
nformation about threads and h
eap are provided. Furthermore,

network speed and
network
latency can be manipulated while the
ystem messages of different levels, l
ike errors or warnings, and
of the developer
are shown in the Logcat
of the DDMS
calls, SMS and data can be simulated as well.
Moreover,
Traceview and Hierarchy
Viewer are tools that present
complex
data graphically. Traceview
information about the time, methods and threads spend, which
optimising and debugging an application.
The
Hierarchy Viewer allows developers to
debug and optimise user interfaces.
In Figure 2
an example of a Hello World
displayed by the Hierarchy View
er, is shown.
On the left side
relations between the different blocks of the user interface are presented. On the
properties of the currently selected block and its position in the display are
shown. In addition, the content of the current
block
is displayed as well in an extra
Hierarchy Viewer does not work
if
the IDs of the Views are
Additionally,
the simple GUI editor
requires further development.
FIGURE 2: Hierarchy Viewer Example
gives an overview
of
all emulators and devices and their Virtual Machines (applications) currently running
.

radio state, location
latency can be manipulated while the
emulator is
ike errors or warnings, and
printed
of the DDMS
. Incoming phone
Traceview and Hierarchy
data graphically. Traceview
visualises
information about the time, methods and threads spend, which
is useful for
Hierarchy Viewer allows developers to
an example of a Hello World
On the left side
, the
relations between the different blocks of the user interface are presented. On the
properties of the currently selected block and its position in the display are
is displayed as well in an extra
the IDs of the Views are
requires further development.



3.
GOOGLE ANDROID
User interface
d
compared to other operating systems
Google developed an
XML
for Android is explained in detail before the constraint
dynamic UIs are
discussed.

3.1. STATE-OF-THE-
ART
This subchapter first introduces the structure of a
Android, before the XML layout file is explaine

3.1.1. Views and View
Groups
The basic
element
graphical equivalence
of an Activity
screen by itself, a View is necessary to close this gap and provide presen
screen to the Activity
.
responsible for
storing content, layout
Moreover; the widget

checkboxes
or scrollbars,

Combinations of
Groups. View Groups
are a spe
multiple Views and even other View

a tree structure. This
tree can be formed
Furthermore, all children of a View
When an Activity receives focus
measure and draw the tree. Next, all children of the roo
their children
et cetera.
children.
A child is able to specify its layout properties, for instance its size
borders, but these
might
Group owns a subclass of LayoutPara
D
espite a child may specify its own
defines the properties
that are appropriate
Besides cu
stom View types, predefined components can be used as well
example layouts (in
Figure
These widgets provide
predefined
ranges from simple layouts
rectangular part of
screen, to complex layouts


3.1.2. XML-based
Layouts
Each possible type of
are for instance a
whole layout,
design earn
s certain advantages from
separated UI code, c
ompared to programmatic
UI affords perfect shape to
related to Android UI
class
android.widget.TextView
certain methods. In addition to its own attributes, for instance
TextView in Figure 6
, a tag ha
respective L
ayoutParams subclass
access its own
and superclass att
LayoutParams attributes
14
tree can be formed
in regards of the

Furthermore, all children of a View
Group are ad
dressable through their parent.
When an Activity receives focus
, the root
node of the layout tree is requested to
measure and draw the tree. Next, all children of the roo
t
node are requested to draw
et cetera.
Therefore, each node is respons
ible to draw its direct
A child is able to specify its layout properties, for instance its size
might
be overwritten by its parent. [8]
Additionally, every
Group owns a subclass of LayoutPara
ms to define its
available
espite a child may specify its own

parameters, it is necessary that each child
that are appropriate
for its parent, as
shown
stom View types, predefined components can be used as well
Figure
3
: RelativeLayout and LinearLayout)
predefined
frequently used UI components.
ranges from simple layouts
such as the Frame
Layout, which is just a b
screen, to complex layouts
such as
the Gallery

FIGURE 4: Gallery Example [8]
Layouts

Each possible type of
a G
UI in Android can be designed in XML. These types
whole layout,
an options menu
, a context menu,
s certain advantages from
an XML-based UI
description
ompared to programmatic
ways
. In addition,
UI affords perfect shape to
be described in XML syntax.
The tags of the XML file
class
es, e.g. TextView in Figure 6
is related
android.widget.TextView
. Furthermore,
the attributes of the tags
certain methods. In addition to its own attributes, for instance
, a tag ha
s also access to attributes of its
superclass
ayoutParams subclass
(3.1.1.). As shown in
Table
and superclass att
ributes differs from the
; thus,
they are easy distinguishable in code.

developer’s needs.
dressable through their parent.
node of the layout tree is requested to
node are requested to draw
ible to draw its direct
A child is able to specify its layout properties, for instance its size
and
Additionally, every
View
available
layout parameters.
parameters, it is necessary that each child
shown
in Figure 3.
stom View types, predefined components can be used as well
. For
: RelativeLayout and LinearLayout)
and GUI widgets.
frequently used UI components.
The assortment
Layout, which is just a b
lank
the Gallery
(Figure 4).
UI in Android can be designed in XML. These types
, a context menu,
or dialogues. UI
description
, e.g. centred and
. In addition,
the tree structured
The tags of the XML file
are
is related
to the class
the attributes of the tags
corresponds to
certain methods. In addition to its own attributes, for instance
android:text of the
superclass
es and the
Table
2, the syntax to
ributes differs from the
syntax to access
they are easy distinguishable in code.


Sometimes UI elements may overlap each other on screen. The order,
Android draws elements, is from top of the XML file to its bottom. As a resu
last drawn element, from the bottom of the XML, appears on the top of all other
elements that reside in the same section of the screen.
necessary that every XML file contains a root element, for ins
Figure 6.

Type
class attributes
superclass attributes
LayoutPara
ms attributes
TABLE 2: HOW TO ACCESS
DIFFERENT TYPES OF
Android compiles each file and stores it in a special
Subsequently, shortcuts t
The result of the code in
referri
ng, IDs can be set for every element by using the special syntax
@+id/
someStringThatMakesSense
elements may
refer to this ID
Figure 6. Additionally,
developers can refer to these elements in Java with the help
of its ID by using
findViewById(R.id.









15
Sometimes UI elements may overlap each other on screen. The order,
Android draws elements, is from top of the XML file to its bottom. As a resu
last drawn element, from the bottom of the XML, appears on the top of all other
elements that reside in the same section of the screen.
[8]
necessary that every XML file contains a root element, for ins
tance
Syntax
android:attribute
android:attribute
ms attributes

android:layout_
l
ayoutParamsAttribute
DIFFERENT TYPES OF
TAG ATTRIBUTES FOR A TEXT
RELATIVELAYOUT
Android compiles each file and stores it in a special
Subsequently, shortcuts t
o these resources are provided through the class
The result of the code in
Figure 6 is shown in Figure 5
. To guarantee simple
ng, IDs can be set for every element by using the special syntax
someStringThatMakesSense
. Consequently, relative attributes of other
refer to this ID
, e.g.
android:layout_toLeftOf= "@id/ok"
developers can refer to these elements in Java with the help
findViewById(R.id.
someStringThatMakesSense
FIGURE 5: SCREEN OF CODE IN FIGURE 6 [8]

Sometimes UI elements may overlap each other on screen. The order,
Android draws elements, is from top of the XML file to its bottom. As a resu
lt, the
last drawn element, from the bottom of the XML, appears on the top of all other
[8]
Furthermore; it is
tance
RelativeLayout in
Example
android:text
android:background
android:layout_width
VIEW WITH THE PARENT
Android compiles each file and stores it in a special
resource file.
o these resources are provided through the class
R.java. [8]
. To guarantee simple
ng, IDs can be set for every element by using the special syntax
. Consequently, relative attributes of other
android:layout_toLeftOf= "@id/ok"
in
developers can refer to these elements in Java with the help
someStringThatMakesSense
).


16

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:background="@drawable/blue"
android:padding="10px">
<TextView id="@+id/label"
//attributes of RelativeLayout.LayoutParams
android:layout_width="fill_parent"
android:layout_height="wrap_content"
//attribute of TextView
android:text="Type here:"/>
<EditText id="@+id/entry"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:background="@android:drawable/editbox_background"
android:layout_below="@id/label"/>
<Button id="@+id/ok"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_below="@id/entry"
android:layout_alignParentRight="true"
android:layout_marginLeft="10px"
android:text="OK" />
<Button android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_toLeftOf="@id/ok"
android:layout_alignTop="@id/ok"
android:text="Cancel" />
</RelativeLayout>
FIGURE 6: CODE EXAMPLE, RELATIVE LAYOUT IN XML [8]

3.2. DYNAMIC USER INTERFACE DESIGN AND XML – AN OPEN ISSUE
3.2.1. The Issue
As mentioned above, XML-based user interfaces have certain advantages in
Android; nevertheless, one major drawback exists. Google did not enable dynamic
modifications of an XML-based UI; therefore, changes of any element of this UI are
not possible through modifying the respective XML file at runtime. Moreover, not
only modifications are essential, but also ad-hoc processing of complete new UIs, as
it is necessary after starting an application. In this case, the whole UI has to be
loaded ad-hoc during runtime. Due to this fact, once an application with an XML-
based layout is compiled, its user interface cannot be modified by changing the XML
code without compiling the whole application again. Despite the fact that XML layout
resources can be loaded and translated into visual elements at runtime by using the
LayoutInflater class, this does not solve the issue. The reason is that ‘for
performance reasons, view inflation relies heavily on pre-processing of XML files that
is done at build time. Therefore, it is not currently possible to use the LayoutInflater
with an XmlPullParser over a plain XML file at runtime; it only works with an
XmlPullParser returned from a compiled resource (R.something file)’. [8]

In today’s often service
determined before the application is
if necessary,
and adapted to satisfy user and system needs. An issue of this
approach is to
generate a UI out of the descriptions of the services.
syntax, the UI file provided by
the process of UI generation
currently not feasible in Google Android
not possible to modify an
XML code.
Consequently
aforementioned gap are analysed based on t
Google Maps is used as an
clarified.

3.2.2.
Requirements analysis
In order to solve the issue
of Android applications

applications are given in
Search.
Before the user can
necessary that the initial View is transmitted to the Android device and
by the interpreter. In
the
case ‘See News Overview’.
describing its UI. Because each use case in the diagram requires a further View,
including a further XML file, transmitting and processing
multiple times during this

F
IGURE

The previous
explanation
that overcomes the gap of dynamic user interface design.
due to the
goal of this research to provide synchronicity of the distri
17
In today’s often service
-oriented world (SOA) in some

determined before the application is
running
. Instead, they are generated at runtime
and adapted to satisfy user and system needs. An issue of this
generate a UI out of the descriptions of the services.
syntax, the UI file provided by
Google
for Android applications might be integrated in
the process of UI generation
without circumstance.
However, this procedure is
currently not feasible in Google Android
. Because of the
aforementioned
not possible to modify an
XML-based UI
at runtime through manipulations of the
Consequently
, the requirements for
an approach to overcome the
aforementioned gap are analysed based on t
wo use case diagrams.
Google Maps is used as an
example to show up further
questions that need to be
Requirements analysis

In order to solve the issue
(3.2.1)
, an interpreter that is able to process the UI

during runtime will be developed.
Examples of possible
applications are given in
Figure 7 and Figure 8
, News Ticker and Train Connection
Before the user can
start interacting
, as shown in bot
necessary that the initial View is transmitted to the Android device and
the
case of the news ticker example, the initial View is the use
case ‘See News Overview’.
Furthermore, this View
needs its own XM
describing its UI. Because each use case in the diagram requires a further View,
including a further XML file, transmitting and processing
of UIs has to be done
multiple times during this
small example.
IGURE
7: USE-CASE-DIAGRAM OF A NEWS TICKER

explanation

already clarifies some requirements
that overcomes the gap of dynamic user interface design.
Consistency
goal of this research to provide synchronicity of the distri

cases UIs are not
. Instead, they are generated at runtime
,
and adapted to satisfy user and system needs. An issue of this
generate a UI out of the descriptions of the services.
Due to its XML
for Android applications might be integrated in
However, this procedure is
aforementioned
fact, it is
at runtime through manipulations of the
an approach to overcome the
wo use case diagrams.
Afterwards,
questions that need to be
, an interpreter that is able to process the UI
s
Examples of possible
, News Ticker and Train Connection
, as shown in bot
h figures, it is
necessary that the initial View is transmitted to the Android device and
is processed
case of the news ticker example, the initial View is the use
needs its own XM
L file
describing its UI. Because each use case in the diagram requires a further View,
of UIs has to be done


already clarifies some requirements
of an approach
Consistency
is important
goal of this research to provide synchronicity of the distri
buted data.

Besides, it is also possible that modifications of the user interface appear
side
while the interpreter is running at
need to be broadcasted by the server to ensure consistency.
system
that is capable to broadcast the modified
necessary.
Moreover, because it is
information is
transferred and processed various times
furthermore, the
efficiency
of the cause, why Google did not enable
‘performance reasons’
consuming and how
computational expensive the approach in questions is.
second example,
illustrated
characteristics as the News Ticker example.
for Connections’, ‘See Connections’, and ‘See Detail of Connection’
own Views and with it,

and efficiency are
essential
requirements for software
it provides a good basement that can be extended by additional
done in Table 3. Furth
ermore, not all of the subcategories of the standard are
significant for this purpose. Within the scope of this research,
not considered. Additionally, since the interpreter will be implemented prototypical
the whole set of UI eleme
not be reached. Non-
goals of this research are summarised in
essential that the supported UI components are processed and pres
user correctly. This requirement meets the subcategory

FIGURE 8:
U
Moreover,
for the same reason as full interoperability is no goal of this
research, reliability
is no
work with incorrect XML files.
communication on the reliability are not focused in this assig
18
Besides, it is also possible that modifications of the user interface appear
while the interpreter is running at
client-side
. In this case, the modifications
need to be broadcasted by the server to ensure consistency.

that is capable to broadcast the modified

elements
Moreover, because it is
already required
that
transferred and processed various times
in a simple application
efficiency
of the interpreter is important.
In particular
of the cause, why Google did not enable
XML-based
UI processing at runtime:
‘performance reasons’
[8]. Efficiency contains
the subcategories
computational expensive the approach in questions is.
illustrated
in the use case diagram of
Figure
characteristics as the News Ticker example.
The three different us
for Connections’, ‘See Connections’, and ‘See Detail of Connection’

their own UI XML file. Therefore,
in this case
essential
as well.
The ISO 9126 standard
requirements for software
-
engineering. It is insufficient for distributed systems, but
it provides a good basement that can be extended by additional
ermore, not all of the subcategories of the standard are
significant for this purpose. Within the scope of this research,
security
not considered. Additionally, since the interpreter will be implemented prototypical
the whole set of UI eleme
nts will not be realised. Therefore, full
interoperability
goals of this research are summarised in
Table
essential that the supported UI components are processed and pres
user correctly. This requirement meets the subcategory
accuracy
U
SE-CASE-DIAGRAM OF A TRAIN CONNECTION S
EARCH
for the same reason as full interoperability is no goal of this
is no
aim as well (Table 4)
. For instance the interpreter will not
work with incorrect XML files.

Furthermore, the consequences of mobile
communication on the reliability are not focused in this assig
nment.
Besides, it is also possible that modifications of the user interface appear
at server-
. In this case, the modifications

Therefore an event
elements
of the XML file is
that
the user interface
in a simple application
:
In particular
in the context
UI processing at runtime:
the subcategories
how time
computational expensive the approach in questions is.
The
Figure
8, shows the same
The three different us
e cases ‘Search
for Connections’, ‘See Connections’, and ‘See Detail of Connection’
require their
in this case
consistency
The ISO 9126 standard
[10] defines
engineering. It is insufficient for distributed systems, but
it provides a good basement that can be extended by additional
requirements as
ermore, not all of the subcategories of the standard are
security
aspects are
not considered. Additionally, since the interpreter will be implemented prototypical
ly,
interoperability
will
Table
4. However, it is
essential that the supported UI components are processed and pres
ented to the
accuracy
of ISO 9126.

EARCH

for the same reason as full interoperability is no goal of this
. For instance the interpreter will not
Furthermore, the consequences of mobile
nment.
Due to the fact
19

that the interpreter will only translate the UI description into the final UI and does not
create new components by itself, it will not affect the usability aspects of the
aforementioned ISO standard. Nevertheless, transparency is important for the
usability of distributed systems. Consequently, it is necessary that the user does not
recognise the distributed parts of the system. These different components must
appear to the user as a normal centralized system. Because of the restrictions of a
prototype implementation (interoperability), it is indispensable to provide
maintainability for later completing of interoperability without any large barriers.
Due to the fact that the interpreter could be ported to different Android device the
last requirement is installability.

Category
Subcategory
Functionality + Accuracy
+ Consistency
Usability + Transparency
Efficiency
+ Time behaviour
+ Resources behaviour
Maintainability + Completing of Interoperability
Portability + Installability
TABLE 3: REQUIREMENTS FOR THE INTERPRETER (GOALS OF THIS RESEARCH)
Category
Subcategory
Functionality - No full interoperability
- No security aspects
Reliability - Not covered explicitely
TABLE 4: NON-REQUIREMENTS FOR THE INTERPRETER (NON-GOALS OF THIS RESEARCH)

3.2.3. Google Maps
A fully functional Google Maps version on a mobile device is a powerful
combination for location based services. Consequently, Google made sure to enable
full support for Google Maps in Android. Furthermore, embedding a Map in an
application requires only small efforts and the basic functionality works out of the
box. Google provides a whole package (com.google.android.maps), which allows
applications to display and control a Map. The complex communication in the
background is managed by an additional class, referred to as MapActivity, without
bothering the developer. Moreover, embedding is done by simply including a
MapView in the UI XML file of the application.
An interesting question is what happens, if the new UI component that has to
be processed and integrated into a running application is not only a simple element,
for instance a normal button, but a complex UI component, like a MapView including
20

a lot of complex functionality. Potentially the services of Google Maps will not work
at all or processing the MapView at runtime is too cost intensive.

3.2.4. Conclusion
In this subchapter the lack of dynamic XML-based user interface design in
Android was discussed. Afterwards, the requirements (Table 3) for an approach
resolving this lack were derived on the basis of two simple use case diagrams.
Additionally, the non-requirements of this research (Table 4) were disclosed as well.
Furthermore, two main parts need to be developed. First, at client-side it is
necessary to implement the missing capability of interpreting UI descriptions at
runtime. Second, it is essential at server-side to develop a method to recognise
modifications of the UI XML file and broadcast them. As previously mentioned
(3.2.1) a further requirement is the capability of sending completely new UI
descriptions to the client. Moreover, it was emphasised that efficiency is an
important aspect. Due to this fact, proving time and resource behaviour of
exceedingly complex UI elements, e.g. MapView, and determine their accuracy are
significant tasks of this research. In conclusion, the three main targets in compliance
with the aforementioned requirements (Table 3) and non-requirements (Table 4) are:

1. UI processing at runtime on client-side
2. Event system on server-side
3. Proving complex UI elements (efficiency, accuracy) in context of 1. and 2.















21

4. CONCEPT AND ITS REALISATION
4.1. OVERVIEW
In order to close the gap of dynamic user interface design, xDUDE (XML &
Dynamic User Interface Design) for Google Android has been developed. Moreover,
the goals of the xDUDE concept cover the requirements pointed out in the last
chapter. The xDUDE Architecture can be divided into two main parts: a Web Service
at server-side and an interpreter at client-side. It is necessary that both offer certain
functionalities to fulfil the aforementioned requirements. These functionalities are:

Web Service:
 Searching for UI XML files in predefined directory
 Recognition of UI updates
 Controlling of the application
 Providing application data
 Recognition of data updates
 Communication with interpreter to send information named above

Interpreter:
 Interpret UI XML definitions at runtime
 Create appropriate layout at runtime
 Modification of layout at runtime
 Reaction on server-side controlling (starting or finishing Activities)
 Integration of application data at runtime
 Modification of data at runtime
 Communication with Web Service to receive information named above

For the purpose of realising these functionalities, the Web Service provides
four operations used by the interpreter to get UI and data information, as shown in
Figure 9. When the client is started, it connects to the New UI Interface of the Web
Service to get the entire XML descriptions for all Views of the application. This is
done only once per running application. Afterwards, the update responses of the
Web Service must be integrated frequently at client-side. This is also necessary for
synchronising data between server and client. Moreover, it might be necessary to
offer more functions to handle data, e.g. removing and adding certain information.
Furthermore, the controlling of the interpreter is resided at server-side and is
provided by the Data Handler Interface.
An outline of the required UI processing at server and client-side is given in
Figure 10. The first line of the Web Service illustrates the handling of a New UI
description. This is necessary, if the interpreter was started at client-side and
requests the whole UI, because everything is new to it at this time. The second line
demonstrates the update handling. In addition to the first line, comparison to the old
22

data is required to find updates. In order to achieve this, the filenames and the time
of the last modification are checked. If a file was modified, its DOM tree will be
scanned for variations.



Finally, information about the modifications, e.g. parent name or child index,
will be added to alleviate the UI processing at client-side. Along with updated files,
xDUDE maintains new and removed files as well. The components of the interpreter
are arranged vice versa in the figure. If the whole UI was requested, it will be stored
first. Next, every UI description that belongs to a running Activity is filtered out for
processing it at runtime. The processing includes two steps, which alternate for each
element. The first step is parsing the UI description. If a UI component was found, it
will be interpreted to finally create its appropriate View on screen in the second step.
Maintaining updates is similar to this proceeding, but instead of handling the entire
UI description, only updated elements are processed.



FIGURE 9: COMMUNICATION BETWEEN INTERPRETER AND WEB SERVICE

xDUDE


once

frequently

on click

frequently
Interpreter

Get New UI


Get UI Update


Get Click Action


Get Data

Web Service

New UI Interface

Update UI Interface

Click Handler Interface

Data Handler Interface
23




4.2. WEB SERVICE
The xDUDE Web Service comprises five major parts. The central component
is the ServiceConnector Class. It provides the methods for clients to call and
transmit the client requests to the other components to handle them, as
demonstrated in Figure 11. Due to its uniform clients, which all need the same UI
and data at the same point in time, the Web Service session scope is on the entire
application. Consequently, only one instance of the ServiceConnector is created
during the application lifetime. This instance is shared by all clients and provides
exactly the same data to them. In detail, it holds among others the UI description
and the application data, which will be transmitted to the client. In order to minimise
computing power, the processing of these information is conducted centralised
instead of doing it multiple times for the various clients. After processing is finished,
UI and application data are present in the ServiceConnector Class. For the purpose of
computing the entire UI, an extra component is required. The NewUIProcessing
Component handles every call for the entire UI. It includes three classes. The
NewUISearch Class scans a predefined directory for XML files and passes the files
to the NewParser Class via the DataNewBean Class. Furthermore, the DOM trees
for each XML file are produced in the NewParser and transmitted back to the
ServiceConnector via the DataNewBean as well.

FIGURE 10: FLOW OF XDUDE UI PROCESSING

xDUDE UI Processing Flow


Web Service
Scan Directory
Produce DOMs
Scan
Directory

Compare
with

Old

Add
Infos

Produce
Update

DOMs

Interpreter
Store
entire UI

Allocate UIs to
running Activities

Update
entire UI

Allocate UI Updates
to

running
Act
ivities


Parse UI Updates
of running Act.
Interpret + Update
Layouts of run. Act.

Parse UI of
running Act.
Interpret + Create
Layouts of run. Act.

Similar to the
NewUIProcessi
bean to store its data.
ServiceConnector
, which also put
updates into the bean

starts the
UpdateLooperThread
and passing the results back to the
Update
UISearchThread
Additionally, comparison of
modified file
is transmitted to the
this class,
DOM trees are
versions of them. Each

the ServiceConnector.
Besi
is an element. For instance
element will be transmitted.
Component
is required. It includes two classes to manage data. The
Class
processes the whole data at start up. Furthermore, the
DataHandlerUpdateThread
data and maintains the updates.
of a controller in the
xDUDE
certain V
iew that was clicked,
describes how to react

closing Activities
for this concept

F
IGURE
24
NewUIProcessi
ng, the UpdateProcessing
Component
bean to store its data.
The DataUpdateBean
is instantiated from the
, which also put
s the data of the
NewUIProcessing

for later comparison. Furthermore,
the
UpdateLooperThread
. Its tasks are looping the
UpdateUISearchThread
and passing the results back to the
ServiceConnector. Like
the
UISearchThread
scans a certain predefined direct
ory for XML files.
Additionally, comparison of
the currently found files to prior
ones is necessary.
is transmitted to the
UpdateParser by using the
DataUpdateBean
DOM trees are
created
and its contents are compared to t

changed element is stored in the bean and passed back to
Besi
des, the most fine-grained level of
the
is an element. For instance
, if one attribute
of an element is changed, the enti
element will be transmitted.

In order to provide data to the clients, a
is required. It includes two classes to manage data. The
processes the whole data at start up. Furthermore, the
DataHandlerUpdateThread
Class
searches permanently for modifications of the
data and maintains the updates.
Finally, the
ClickHandling Component
xDUDE
Architecture.
After getting a request with the ID of a
iew that was clicked,
the ViewClickHandler
returns a command

on the click.
The range of actions is limited to start
for this concept
, but it can be extended easily.

IGURE
11: COMPONENT DIAGRAM OF THE XDUDE W
EB

Component
utilises a
is instantiated from the
NewUIProcessing
and previous
the
ServiceConnector
UpdateUISearchThread

the
NewUISearch, the
ory for XML files.

ones is necessary.
Every
DataUpdateBean
. In
and its contents are compared to t
he previous
changed element is stored in the bean and passed back to
the
update reporting
of an element is changed, the enti
re
In order to provide data to the clients, a
DataHandling
is required. It includes two classes to manage data. The
DataHandler
processes the whole data at start up. Furthermore, the
searches permanently for modifications of the
ClickHandling Component
fulfils the task
After getting a request with the ID of a
returns a command
, which
The range of actions is limited to start
ing and

EB
SERVICE

25



For the purpose of explaining the response of the update processing in more
detail, in Figure 12 an example of a server response including a simple UI is shown.
It contains the entire user interface definition of one file wrapped by an additional
tag, which consist of the name of the file and the timestamp of the last UI update.
Since no update happened in this example till the server response was send, the
timestamp is still zero. The user interface comprises a text element followed by a
button. Finally, the LinearLayout wraps both components into a top down linear
structured layout. If the TextView is deleted during an update, the server response
will look like the code in Figure 13. The first two tags contain additional information
and were added by the Web Service for better handling and integration of the UI
changes at client-side. Whereas the first tag includes information about the whole
file, the second one holds in particular information about the element that was
modified. In this case, the file startActivity.xml was updated; therefore, the name of
the first tag is file_updated. Other possible names are file_new and file_removed.
The attributes comprise the name of the file and the timestamp of the update. An
interpreter will use the name to identify the updated file at client-side. Furthermore,
the timestamp will be send back to the Web Service during UI update requests. As a
result, the time of the current update at server-side and the time of the last update at
client-side can be compared. If required, the Web Service sends back the content of
the current update. After identifying the file that was modified, the next step at
client-side is to detect the changed elements and integrate their modifications. For
that reason, the name of the second tag represents the action performed to the
certain UI element. Moreover, the tag contains the name of the element’s parent,
the element’s child index and the parent’s tag name. These attributes are necessary
to guarantee a fast integration of updates at client-side. Finally, the last tag is the
updated UI element. Due to the fact that the TextView has been removed in this
<?xml version="1.0" encoding="utf-8"?>
<startActivity.xml lastUpdate="0">
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:id="@+id/linLay">
<TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="This is a TextView"
android:id="@+id/titleID"/>
<Button
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="This is a Button"
android:id="@+id/buttonID"/>
</LinearLayout>
</startActivity.xml>
FIGURE 12: UI XML EXAMPLE (STARTACTIVITY.XML)

26

example, all of its attributes are deleted except the ID of the TextView. In case of
updated or new elements, all attributes are passed to the client.


This concept is capable to handle all different UI elements of Google Android,
including their attributes, and their possible combinations. Moreover, the
synchronisation of the user interface and the application data between interpreter
and Web Service is warranted. Particularly considering the required functionalities,
pointed out in 4.1, the xDUDE Web Service fulfils all mentioned requirements.
However, there is one constraint of the attributes. It is required that each element
owns an ID for identification purposes. An additional feature, which is not supported
at the moment, is dealing with cross file tags like <include> or <merge>. These
tags could be processed at server-side to unburden the interpreter.

4.3. INTERPRETER
In contrast to the xDUDE Web Service, a genuine symmetric architecture is
not feasible for the xDUDE client in respect of handling the entire UI at interpreter
start and handling its updates later. The reasons for this are a result of some
characteristics of Google Android. However, before the processing of the User
Interface is discussed, first the central parts of the interpreter and its main entry
point are explained. In Figure 14 a component diagram of the xDUDE Interpreter is
presented. The major parts of an Android Application are its Activities. The
interpreter consists of three different Activities. The entry point of the interpreter is
the PreferencesActivity. It has a static UI and is necessary to provide three settings
to the user: the address of the Web Service and the frequencies of the UI and data
polling. After the set-up is done the PreferencesActivity is finished, so it will not be
shown on screen again, and the InterpreterActivity is started. The
InterpreterActivity always assumes the role of the first Activity of an application.
Every other Activity will be processed by the NewActivity Class. Both classes act
the same way. First, they launch the NewUIProcessing Component to get their
personal UI. Next the UpdateUIProcessing Component is started to take care that
the Activities are aware of the updates of their UIs. Furthermore, because the
Activity Class offers via onCreateOptionsMenu the method to maintain its menu,
the InterpreterActivity and every NewActivity are in charge of creating their menu.
Additionally, it is required that menu interactions are handled in the corresponding
Activity. The NewUIProcessor Class is instantiated by the InterpreterActivity in
order to process the personal UI of the Activity. Only one NewUIProcessor is
FIGURE 13: EXAMPLE (STARTACTIVITY.XML) UPDATE RESPONSE

<file_updated name="startActivity.xml" timeStamp="1242382670500">
<removed parent="linLay" index="0" tagName="LinearLayout">
<TextView xmlns:android="http://schemas.android.com/apk/res/android"

android:id="@+id/textID"/>
</removed>
</file_updated>

necessary to take care of all Activities. For that reason
each NewActivity
to be reused there. The
takes care about the whole procedure of computing the
provide this functionality, four main tasks are accomplished. At the beginning, the
NewUIProcessor
connects to the Web Service via the
the entire user i
nterface of the application
response is passed to the
various Activities an
d Menus. There are some restrictions of the naming of the UI
XML files, which are discussed later in this chapter. After getting
Activities and Menus
, the
definition to its related Activity
responsible classes for that are the
Class
. Each element of the User Interface is generated and display
Moreover, the attributes of an elemen
Besides, some Views need special treatment to work correctly. For instance, it is
necessary to set a
handler for button
This is done in the
NewParser

F
IGURE

27
necessary to take care of all Activities. For that reason
,
the instance will be passed to
to be reused there. The
NewUIProcessor
is the basic class that
takes care about the whole procedure of computing the
user i
nterface. In order to
provide this functionality, four main tasks are accomplished. At the beginning, the
connects to the Web Service via the
HTTPConnector
nterface of the application
containing
its different Views. Next, the
response is passed to the
ActivityMapCreator Class
to find out the names of the
d Menus. There are some restrictions of the naming of the UI
XML files, which are discussed later in this chapter. After getting
, the
NewUIProcessor
is able to allocate the correct UI
definition to its related Activity
. T
he third task is launching the UI interpretation. The
responsible classes for that are the
NewParser Class
and the
. Each element of the User Interface is generated and display
Moreover, the attributes of an elemen
t are handled in the
Besides, some Views need special treatment to work correctly. For instance, it is
handler for button
clicks, or a
web site to open for WebViews.
NewParser
as well.
IGURE
14: COMPONENT DIAGRAM OF THE XDUDE I
NTERPRETER
the instance will be passed to
is the basic class that
nterface. In order to
provide this functionality, four main tasks are accomplished. At the beginning, the
HTTPConnector
Class to get
its different Views. Next, the
to find out the names of the
d Menus. There are some restrictions of the naming of the UI
XML files, which are discussed later in this chapter. After getting
the names of all
is able to allocate the correct UI
he third task is launching the UI interpretation. The
and the
ElementSwitcher
. Each element of the User Interface is generated and display
ed during parsing.
t are handled in the
ElementSwitcher.
Besides, some Views need special treatment to work correctly. For instance, it is
web site to open for WebViews.

NTERPRETER

28

For the purpose of maintaining clicks on Views or Items of a ListView, the
ClickHandler Component provides the required handler classes ClickHandler and
ItemClickHandler. Both classes connect to the Web Service via the HTTPConnector
Class to get the action that has to be performed. Beside the aforementioned handler
classes, other handlers may be necessary as well. One example is a handler that
manages long clicks. The fourth task of the NewUIProcessor is to save relevant data.
All information that needs to be stored is put into the SingletonHelperBean Class.
This bean is the central point for sharing data about the User Interface processing.
Among others, the names of all running Activities and of all initialised Menus are
stored here.
The structure of the UpdateUIProcessing Component is similar to the one of
the NewUIProcessing Component. However, there are significant differences. In
order to avoid blockage of other components, the base class of the
UpdateUIProcessing, the UpdateUIProcessor Class, starts a new thread. This
results in a problem, because the new thread is not allowed to manipulate the
layout. Consequently, generating, deleting and changing UI elements need to be
done in the main thread, which owns the Activities and their layouts. Furthermore,
another difference is the looping behaviour of the UpdateUIProcessor, which is
launching itself again after finishing an update process. As a result, occurring
updates are integrated continuously. Subsequently to an update response of the
server via the HTTPConnector, the next step in the UpdateUIProcessor Class is to
call the ResponseStringHandler. This handler provides two functionalities. Filtering
the UIs of currently running Activities out of the centrally stored UI definitions and
updating the parts of the entire UI definition where modifications have occurred. The
progress of the distribution of UI updates is explained in more detail later in this
chapter. The result of the filtering is used in the UpdateParser to handle UI updates
of already started Activities at runtime. As mentioned above, it is not possible to
manipulate the layout in the UpdateParser, because it runs in a new thread.
Therefore, the main task of this class is to fetch the additional information added by
the xDUDE Web Service, e.g. the first two tags in Figure 13. All information is sent
back in an Android Bundle
4
to the UpdateUIProcessor by using Messages. Before
the Bundle is sent, the UpdateElementsBundle Class inserts the attributes of the
element including their values. Finally, a message handler that is located in the
UpdateUIProcessor Class (in the main thread) receives the Messages and modifies
the layout.
The last component is the DataHandler Component, which consists of the
DataHandler and the DataUpdateHandler Class. The integration of the data takes
place immediately after the creation of the user interface element that displays the
data. This happens either in the NewParser Class or in the UpdateUIProcessor Class.
The DataHandler is responsible for the first processing of the application data,
whereas the DataUpdateHandler handles later updates. Besides, the
DataUpdateHandler launches a new thread, similar to all other classes that are


4
Special class to map various data types to string keys for fast execution
29

responsible for managing updates. Furthermore, after having finished an update
request and its processing, the DataUpdateHandler calls itself again to guarantee a
continuous integration of updates. The DataHandler Class and the
DataUpdateHandler Class connect to the Web Service via the HTTPConnector.
The sequence diagram in Figure 15 illustrates the process of the UI
distribution at client-side. One main central UI description is held by the Interpreter.
This description contains the entire User Interface consisting of the layouts of all
different Activities and their Menus. Since the InterpreterActivity adopt the part of
the first Activity of an application, it runs from the start up of the client (after the
PreferencesActivity is closed). Once the interpreter is launched, it requests the
entire UI. Next, all running Activities get their personal UI. In Figure 15 the only
Activity that is running from start is the InterpreterActivity. The NewActivity of the
example is not affected, because it was not started until this moment. The next
server response contains a UI update. The ResponseStringHandler Class filters out
the part of the update that involves the InterpreterActivity. Next, it is parsed by the
UpdateParser Class. Finally, the UpdateUIProcessor Class handles the UI update of
the InterpreterActivity for the purpose of modifying the layout of the
InterpreterActivity at runtime. Moreover, it is necessary that the entire update is
integrated in the central UI description of the interpreter to make it available to any
other Activity that is not running currently. Responsible for the integration is also the
ResponseStringHandler Class. The NewActivity in Figure 15 is an example for a
currently not running Activity that accesses the updated central user interface
definition. When the NewActivity is launched, it acts the same way as the
InterpreterActivity and asks for its personal UI. Due to the global user interface
update of the ResponseStringHandler, no special behaviour of the NewActivity is
needed. It uses its already updated personal UI and has not to be aware of recently
occurred updates.
The distribution of updates of the application data works in a similar way. After
getting the data of the application, the interpreter polls the Web Service to get
available updates. If an update occurs, the Web Service adds extra information,
which is done for UI updates as well. In the case of data updates, this information is
a timestamp for the whole response and per data item a hint whether it is new or
has to be removed.
Unlike the xDUDE Web Service, the interpreter is not capable of handling all
conceivable situations. In order to enable the interpreter to identify the UIs for
correct allocation, there are some rules for naming the UI XML files at server-side. In
order to identify the UI of the first Activity, a unique name is required that never
differs. As a result, the interpreter can apply the content of this file as layout of the
InterpreterActivity, which always take the part of the first Activity of an application.
Moreover, menu files require particular names. It is necessary that the system
recognises, whether the current file contains a layout or a menu and additionally, to
which Activity a menu belongs to. One constraint arises from Google Android itself.
This restriction is the gap between layouts defined in an XML file and coded layouts,
due to the fact that they do not coincide. More precisely, the XML-based way is

more powerful than defining layouts in code. This is an insuperable issue, since the
xDUDE Interpreter
realises
order to display it. This is ex
provided in XML, have no analogue method to be expressed in code. However,
these attributes are clearly less than the ones provided by coding and XML
declaration.

F
IGURE







30
more powerful than defining layouts in code. This is an insuperable issue, since the
realises

each element, declared in the XML,
order to display it. This is ex
plained in detail in chapter 5
. Some of the attributes,
provided in XML, have no analogue method to be expressed in code. However,
these attributes are clearly less than the ones provided by coding and XML
IGURE
15: SEQUENCE DIAGRAM OF UI DISTRIBUTION

more powerful than defining layouts in code. This is an insuperable issue, since the
each element, declared in the XML,
programmatically in
. Some of the attributes,
provided in XML, have no analogue method to be expressed in code. However,
these attributes are clearly less than the ones provided by coding and XML



5.
IMPLEMENTATION
5.1.
XDUDE WEB SERVICE
In order to implement the
engine Version 1.4.1
was
Eclipse Ganymede
(3.4.1) was chosen
generation of the AAR

Apache Software
Foundation
One major drawback of a We
messages. In order to avoid this,
Service. Additionally, using
at client-side
, since Google Android does not includ
SOAP
. There are frameworks developed by third parties that can be used to process
SOAP. Never
theless, using them will lead
computing time
and an increasing message overhead.
WSDL file are shown.
Interface
, including the definitions to set up the Axis 2 Web Service
first section, the in-
and output
client sends a long value. The response contains a string
uiOutputUpdate
operation
Web Service Interface. As a result, a c
Moreover, the HTTP
binding is defined. Because a
developed, no
SOAP
uiOutputUpdate
method
variable lastUpdate
refers to the input variable
last, the endpoint of the Web Service is defined as a
aforementioned interface and binding.
uiOutputUpdate
method cou
services/
xDUDEService/
representing the timestamp of the last update, the client is aware of.

32

The xDUDE Web Service consists of four packages (Figure 16). The main one
is the service package. It contains the ServiceConnector and the base classes for the
processing of new UIs and their updates. Any data related class is hold by the data
package. This involves the data beans and also the data handler classes. All parsers
are resided in the parser package. Finally, the logic package contains the
ViewClickHandler Class.



FIGURE 17: WSDL OF THE XDUDE WEB SERVICE

...
<wsdl2:types>
...
<xs:element name="uiOutputUpdate">
<xs:complexType><xs:sequence>
<xs:element minOccurs="0" name="lastUpdate" type="xs:long"/>
</xs:sequence></xs:complexType>
</xs:element>
<xs:element name="uiOutputUpdateResponse">
<xs:complexType><xs:sequence>
<xs:element minOccurs="0" name="return" type="xs:string"/>
</xs:sequence></xs:complexType>
</xs:element>
...
</wsdl2:types>
<wsdl2:interface name="ServiceInterface">
...
<wsdl2:operation name="uiOutputUpdate"
pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl2:input element="ns:uiOutputUpdate" wsaw:Action="urn:uiOutputUpdate"/>
<wsdl2:output element="ns:uiOutputUpdateResponse"
wsaw:Action="urn:uiOutputUpdateResponse"/>
</wsdl2:operation>
...
</wsdl2:interface>
<wsdl2:binding name="xDUDEServiceHttpBinding" whttp:methodDefault="GET"
interface="ns:ServiceInterface" type="http://www.w3.org/ns/wsdl/http">
...
<wsdl2:operation ref="ns:uiOutputUpdate"
whttp:location="uiOutputUpdate/{lastUpdate}"/>
...
</wsdl2:binding>
<wsdl2:service name="xDUDEService" interface="ns:ServiceInterface">
<wsdl2:endpoint name="xDUDEServiceHttpEndpoint"
binding="ns:xDUDEServiceHttpBinding"
address="http://localhost:8080/axis2/services/xDUDEService/"/>
</wsdl2:service>
...

The entire class diagram of the Web Service is illustrated in
includes the same classes as the component diagram in chapter
classes wer
e explained. In order to guarantee smooth progression of the Web
Service, threads are used to take care about the looping search for updates. This
involves the
UpdateLooperThread
PullParser is used for parsing the
resource allocation.






33
The entire class diagram of the Web Service is illustrated in
includes the same classes as the component diagram in chapter
e explained. In order to guarantee smooth progression of the Web
Service, threads are used to take care about the looping search for updates. This
UpdateLooperThread
and the
UpdateUISearchThread
PullParser is used for parsing the
XML files for the purpose of avoiding too costly
FIGURE 18: WEB SERVICE CLASS DIAGRAM
The entire class diagram of the Web Service is illustrated in
Figure 18. It
includes the same classes as the component diagram in chapter
4.2, where all
e explained. In order to guarantee smooth progression of the Web
Service, threads are used to take care about the looping search for updates. This
UpdateUISearchThread
. Moreover, a
XML files for the purpose of avoiding too costly


5.2. X
DUDE INTERPRETER
For the
development of the
was used as well.
During
Development Toolkit
were used.
The interpreter does
not benefit from the client support of the
is not possible to add
the
this reason, g
reat efforts
Android. Normally
, importing external libraries to Android
this operating system
is not possible
xDUDE
Interpreter was developed by usin

F

35
FIGURE 20: INTERPRETER CLASS DIAGRAM

36

The packages of the interpreter are pictured in Figure 19. The major part is the
interpreter package. It includes all Activities and the base classes for processing the
user interface. Furthermore, parsing and attribute handling classes are resided in the
parser package. In order to keep the necessary computing power low, an XML Pull
Parser is used to scan the UI descriptions. However, one exception exists. In the
ResponseStringHandler Class a DOM parser is needed to enable manipulation of the
UI description. Since it is necessary to insert, delete and change elements, using a
DOM parser to build the DOM trees is the best choice. Moreover, the
communication package is responsible for providing connection to the Web Service.
Due to the fact that frequently update checking is required, the interpreter requests
available updates of the UI by polling the Update UI Interface of the service.
Additionally, polling is also used for synchronizing data between server and client.
Any class that maintains application data or stores data needed for processing is
resided in the data package. Moreover, the application logic, which is composed of
the ClickHandler Classes, is arranged in the logic package. Finally, the helper
package contains classes that support others during computation.
The full class diagram of the xDUDE Interpreter in Figure 20 is mostly
composed of the classes already covered by the component diagram of the chapter
4.3. Additionally, the PossibleElementsAndAttributes Class and the standard R
Class were added. The R Class is automatically generated by the Android Toolkit and
provides fast access to user interface elements declared in a layout XML file. This is
done by allocating system-generated integer IDs for the UI components. Views that
are created in code can also be accessed after setting their ID with the method
setId. Moreover, PossibleElementsAndAttributes is a helper class to avoid the
costly computation of if-then-else statements. It includes an enumeration of possible
elements and attributes, e.g. TextView, Button or background, to enable a switch
statement that uses these elements and attributes. Furthermore, the
PossibleElementsAndAttributes Class implements the method valueOf of the
Enumeration Class to provide comparison of string values to the enumerated
elements and attributes. Besides, in order to keep the class diagram clearly
arranged, dependencies of the classes R, SingletonHelperBean, HTTPConnector and
PossibleElementsAndAttributes are not shown. These classes have multiple
dependencies to the other classes.
In the following paragraphs three code examples are given and discussed.
Among others, they cover two important questions of this thesis. First, whether it is
possible to create dynamically new Views at runtime on the base of a UI XML file.
And second, if it is feasible to create and start dynamically a new Activity at runtime.
Finally, the workaround in the update process to modify Views is explained.
The dynamic creation of a View at runtime is demonstrated exemplarily by
using a WebView in Figure 21 and Figure 22. The code of Figure 21 is part of the
NewUIParser Class. The switch statement is called during parsing the layout files.
The toElementString method tries to match the name of the current element to
name of the elements stored in the helper class PossibleElementsAndAttributes. In
37

case of the given example a new WebView is created. Besides, the respective
Activity including its Context is passed to the new WebView during creation.




Next, the attributes of the WebView are handled by the function switchIt of
the ElementSwitcher Class shown in Figure 22. This method requires the name of