Faculty of Computer Science, Institute of Systems Architecture, Chair of Computer Networks XML & DYNAMIC USER INTERFACE DESIGN IN GOOGLE ANDROID

(1)

Faculty of Computer Science, 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)

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.

(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

(7)

2. GOOGLE ANDROID – AN OVERVIEW

2.1. IN GENERAL

The Open Handset Alliance (OHA) is a group of 47 companies2_{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

(8)

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: Applications

2.2.1. General Information

Android ships with certain functionalities to the user. Examples for contacts application, 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 one of the most important parts of the 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 applications 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

, each 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 protected 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.)

(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

(12)

devices. Furthermore, it can also be started separately.

all emulators and devices and their Virtual Machines (applications) currently running Information about threads and h

data, network speed and

running. System 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,

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 heap are provided. Furthermore,

network speed and network latency can be manipulated while the ystem messages of different levels, like 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 Viewer, 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.

(13)

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

GOOGLE ANDROID USER INTERFACES

design in Google Android shows some

compared to other operating systems. Besides the classic programmatic XML-based layout model. In this chapter the structure of for Android is explained in detail before the constraints of XML

discussed.

ART

This subchapter first introduces the structure of a user Android, before the XML layout file is explained.

Groups

element of a user interface in Android is the

of an Activity. Since an Activity has no attendance on the screen by itself, a View is necessary to close this gap and provide presen

. A View claims a rectangular area of the screen and is storing content, layout drawing, and handling

package contains various UI components or scrollbars, to simplify and accelerate the design of UIs

FIGURE 3:Example for LayoutParams [8] Combinations of Views to complex hierarchies are possible

are a special type of View that can contain a

multiple Views and even other View Groups. As a result, UIs in Google Android have some special shades classic programmatic way, the structure of a UI XML-based layouts for

ser interface of Google

View, which is the . Since an Activity has no attendance on the screen by itself, a View is necessary to close this gap and provide presence on the A View claims a rectangular area of the screen and is events in its area. various UI components, e.g. buttons,

the design of UIs.

[8]

are possible by using View contain and manage As a result, UIs in Google Android have

(14)

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 Despite a child may specify its own defines the properties that are appropriate

Besides custom 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 earns certain advantages from

separated UI code, compared 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 LayoutParams subclass access its own and superclass att LayoutParams attributes

tree can be formed in regards of the

Furthermore, all children of a View Group are addressable 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 root node are requested to draw et cetera. Therefore, each node is responsible 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 LayoutParams 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 GUI 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 classes, 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 has also access to attributes of its superclass ayoutParams subclass (3.1.1.). As shown in Table

and superclass attributes 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 blank

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 superclasses and the Table 2, the syntax to ributes differs from the syntax to access they are easy distinguishable in code.

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

necessary that every XML file contains a root element, for ins Figure 6.

Type

class attributes superclass attributes LayoutParams 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

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

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 instance

Syntax

android:attribute android:attribute

ms attributes android:layout_layoutParamsAttribute DIFFERENT TYPES OF TAG ATTRIBUTES FOR A TEXT

RELATIVELAYOUT

Android compiles each file and stores it in a special

Subsequently, shortcuts to 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 result, 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

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

(17)

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

FIGURE 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 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 two 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 UIs Examples of possible , News Ticker and Train Connection , as shown in both 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 XML 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 distributed data.

(18)

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

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

USE-CASE-DIAGRAM OF A TRAIN CONNECTION SEARCH

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

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 use 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 prototypically, interoperability will Table 4. However, it is essential that the supported UI components are processed and presented 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

(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 XDUDEUIPROCESSING 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 Activities Parse UI Updates of running Act. Interpret + Update

Layouts of run. Act.

Parse UI of running Act. Interpret + Create

(24)

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 UpdateUISearchThread

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 View that was clicked, describes how to react

closing Activities for this concept

FIGURE

NewUIProcessing, the UpdateProcessing Component

bean to store its data. The DataUpdateBean is instantiated from the , which also puts 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 directory 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 Besides, 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 XDUDEWEB

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 the previous changed element is stored in the bean and passed back to the update reporting of an element is changed, the entire 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 starting and

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

(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">

</removed> </file_updated>

(27)

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 interface of the application response is passed to the

various Activities and 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

FIGURE

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 interface. 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. The 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 element 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 XDUDEINTERPRETER

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

(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 Bundle4_{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

Faculty of Computer Science, Institute of Systems Architecture, Chair of Computer Networks XML & DYNAMIC USER INTERFACE DESIGN IN GOOGLE ANDROID

Thomas Matzke

XDUDE

XML & DYNAMIC USER INTERFACE DESIGN

IN GOOGLE ANDROID

Großer Beleg

Dresden, 2009

TABLE OF CONTENTS

ERKLÄRUNG

1.

INTRODUCTION

2.

GOOGLE ANDROID – AN OVERVIEW

3.

GOOGLE ANDROID

GOOGLE ANDROID USER INTERFACES

4.

CONCEPT AND ITS REALISATION