Research Objectives

In this chapter the issues of the first two research questions, posed at the beginning of this assignment (chapter 0), are addressed. Afterwards the quality requirements pointed out in 3.2.2 are highlighted again. /q3 is discussed in the next chapter. The first research question has been the following:

/q1: What architecture enables a system to be capable of realising dynamic user interface design in Android?

As mentioned previously in chapter 3.2.1, Google did not enable the ad-hoc interpretation of XML layout files at runtime. It is necessary to pre-process the XML files, which is done during compilation, to make them accessible for Android. In contrast, the alternative way of maintaining layouts in Android is not as limited as the XML-based approach, when it comes to dynamically changing UIs. This alternative is to create and handle Views in code. As a result, in code declared layouts are capable of dynamic manipulation at runtime. The xDUDE approach implements the obvious solution of realising XML-based UIs programmatically at runtime. Furthermore, an additional necessity is maintaining Activities dynamically. Generally, an Activity can be started easily by using an Intent and declaring a class that is responsible for managing the new Activity.

Figure 28 contains the architecture of the xDUDE Web Service. Each of the required functionalities is handled by an extra component, except of the user interface, which is managed by two components. The reason is the complex process of handling UIs. Consequently, the task of managing the whole UI at beginning and handling its updates later are split into two components. However, one component for the user interface processing could be an alternative. The data is managed by the DataHandling Component and the ClickHandling takes care about the controlling.

Additionally, one central component (Service Connector) maintains the communication with the client and allocates its requests to the respective component. The benefit of these five separated parts is manageable, clearly separated code that can be better adapted and upgraded.

The client architecture contains, analogue to the server, two components to handle the layouts and each

(ClickHandler), as shown in

responsible for connecting to the server. In the by the Communication

advantage of fast access and updating data without passing multiple variables around the various classes. Due to the fact that the

maintaining its layout and its content, it is necessary to implement it as well. An Activity can be filled dynamically, but it must be declared in the manifest file. Along with that, one special Activity

for instance UI handling. The fulfils takes the role of the first is necessary to handle the other

processes again. Generally, every other Activity is handled by the though, there are some exceptions, which are discussed in

/q2: In which way, updates must be broadcasted t client-side?

During this research some special tags and attributes were introduced to enable correct processing of updates at client

about the XML files and about certain UI elements, e.g.

removed or newly created. Without these added information, integration of updates would not be possible at client

simple, polling is used. The major drawback of polling, the mess be avoided if a server push would be realised.

FIGURE 28:SERVER-SIDE COMPONENTS

The client architecture contains, analogue to the server, two components to handle the layouts and each with one for data handling (DataHandling

), as shown in Figure 29. Moreover, one component is required that is responsible for connecting to the server. In the xDUDE architecture this

Communication component. Furthermore, a central data storage has the advantage of fast access and updating data without passing multiple variables around the various classes. Due to the fact that the Activity Class

aintaining its layout and its content, it is necessary to implement it as well. An Activity can be filled dynamically, but it must be declared in the manifest file. Along

Activity is required to instantiate all processes that are nee for instance UI handling. The InterpreterActivity is in charge of this and additionally,

takes the role of the first Activity of an application. Furthermore, another class is necessary to handle the other Activities of an application without i

processes again. Generally, every other Activity is handled by the though, there are some exceptions, which are discussed in chapt

In which way, updates must be broadcasted to enable smooth processing at

During this research some special tags and attributes were introduced to enable correct processing of updates at client-side. These tags contain information about the XML files and about certain UI elements, e.g. if they were updated, removed or newly created. Without these added information, integration of updates would not be possible at client-side. In order to keep the broadcasting of the updates simple, polling is used. The major drawback of polling, the mess

be avoided if a server push would be realised.

The client architecture contains, analogue to the server, two components to DataHandling) and controlling . Moreover, one component is required that is architecture this task is done component. Furthermore, a central data storage has the advantage of fast access and updating data without passing multiple variables Class is responsible for aintaining its layout and its content, it is necessary to implement it as well. An Activity can be filled dynamically, but it must be declared in the manifest file. Along is required to instantiate all processes that are needed, is in charge of this and additionally, of an application. Furthermore, another class of an application without instantiating all processes again. Generally, every other Activity is handled by the NewActivity Class;

ter 6.3.

o enable smooth processing at

During this research some special tags and attributes were introduced to side. These tags contain information if they were updated, removed or newly created. Without these added information, integration of updates side. In order to keep the broadcasting of the updates simple, polling is used. The major drawback of polling, the message overhead, could

During the requirement analysis ( with regard to its quality

6 covers the non-goals.

next two chapters focuses on these requirements and the research

Category Subcategory Functionality + Accuracy

+ Consistency Usability + Transparency Efficiency + Time

+ Resources Maintainability + Completing Portability + Installability

TABLE

FIGURE 29:CLIENT-SIDE COMPONENTS

During the requirement analysis (3.2.2) the goals and non

rd to its quality are developed. Table 5 contains these goals, whereas goals. The analysis of the News Ticker and Google Maps in the s focuses on these requirements and the research

Subcategory + Accuracy + Consistency + Transparency + Time behaviour + Resources behaviour

Completing of Interoperability + Installability

ABLE 5:REQUIREMENTS FOR THE INTERPRETER

the goals and non-goals of xDUDE contains these goals, whereas Table The analysis of the News Ticker and Google Maps in the s focuses on these requirements and the research questions.

Shortcuts /r1a /r1b /r2 /r3a /r3b /r4 /r5

Category Subcategory met, the News Ticker example of

different Views and Activities, which are the News Ticker uses a RSS

The analysis in this chapter only focuses application data when the

updates is not determined. This is done in the following chapter PreferenceActivity is shown

beginning, because this

loaded dynamically and will not work without a server providing layout. After finishing the development and setting up the

Service, it is not longer necessary to change the URL of the polling frequencies

PreferencesActivity could be

FIGURE

Subsequent to pressing one of the buttons the In the case of this News Ticker Example, the screen, displayed. The left side of the figure contains the at server-side and is interpreted

Subcategory

No full interoperability security aspects

ABLE 6:NON-REQUIREMENTS FOR THE INTERPRETER

NEWS TICKER EXAMPLE

In order to evaluate to which extend the aforementioned requirements are met, the News Ticker example of Figure 7 was implemented for

different Views and Activities, which are loaded and handled dynamically. Moreover uses a RSS-Feed [13] and contains data that changes fre

s chapter only focuses on the ad-hoc interpreting of the layout and when the Activities are launched. Furthermore, the behaviour during updates is not determined. This is done in the following chapter

is shown in Figure 30. It is important to specify the beginning, because this Activity is the only static part of xDUDE

and will not work without a server providing

After finishing the development and setting up the final version of the Service, it is not longer necessary to change the URL rapidly. Additionally, the set up

cies may also be dispensable. Consequently, the whole could be disregarded.

IGURE 30:SCREEN OF PREFERENCESACTIVITY

Subsequent to pressing one of the buttons the InterpreterActivity f this News Ticker Example, the screen, indicated

The left side of the figure contains the XML code of the

and is interpreted ad-hoc during the launch of the Activity contains data that changes frequently.

interpreting of the layout and . Furthermore, the behaviour during updates is not determined. This is done in the following chapter. The screen of the It is important to specify the URL at XML code of the layout, which lies nch of the Activity. The first