Innovative Use of Mobile Applications Supporting Learning and

WIRTSCHAFTSUNIVERSITÄT WIEN

Institute for Management Information Systems

Projektseminar aus Wirtschaftsinformatik

ao.Univ.Prof. Dr. Rony G. Flatscher

Sommersemester 2011

Bachelorarbeit

Innovative Use of Mobile Applications Supporting

Learning and Teaching Activities at the New WU

vorgelegt von:

Studenten: Stefan Belk

Dennis Robert Stöhr

Studiengang: Bachelorstudium Wirtschafts- und Sozialwissenschaften

Matrikelnummer: h0750926

h0453244

Geburtsdatum: 15.09.1989

29.08.1983

Adresse: Linke Wienzeile 56/19, A-1060 Wien

Torfwerk 16, D-83075 Bad Feilnbach

Telefon-Nr.: +43 (660) 65 08 784

+49 (160) 58 59 447

E-Mail: [email protected]

[email protected]

Wien, den 15.07.2011

Erklärung

Hiermit erkläre ich, dass ich meinen Teil der vorliegenden Arbeit selbstständig und ohne Benut-

zung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder

sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommen wurden, sind als

solche kenntlich gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im

Rahmen einer anderen Prüfung noch nicht vorgelegt worden.

Wien, den 15.07.2011

Dennis Robert Stöhr

Belk/Stöhr, June 2011 II

Erklärung

Hiermit erkläre ich, dass ich meinen Teil der vorliegenden Arbeit selbstständig und ohne Benut-

zung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder

sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommen wurden, sind als

solche kenntlich gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im

Rahmen einer anderen Prüfung noch nicht vorgelegt worden.

Wien, den 15.07.2011

Stefan Belk

Belk/Stöhr, June 2011 III

Abstract

This bachelor thesis provides an overview about exemplary mobile applications for the new WU.

It can be divided into three main parts.

The first part covers the basics which are necessary for understanding the paper. Relevant wireless

technologies and mobile operating systems are explained. Furthermore, the planned IT

deployments at the university's new site are briefly presented.

The second part gives details on the different application examples. These are described as use

cases. Sixteen use cases are described in detail, and additional twelve use cases are listed and

briefly described.

In the third part, two use case examples are selected and implemented as applications. The first

shows how a reservation system for learning places at the library could look like. It states that

while using HTML5 a tradeoff between new features, maintainability and compatibility had to be

made. The second implementation allows students to ask questions digitally in large lectures. It

can improve teaching quality, but in its form, it requires that students and lecturers use Android

powered devices, putting those who haven't at a disadvantage.

Belk/Stöhr, June 2011 IV

Table of Contents

1 INTRODUCTION....................................................................................................................1

1.1 RESEARCH QUESTION.............................................................................................................................1

1.2 METHODOLOGY......................................................................................................................................1

2 MOBILE DEVICES AND WIRELESS TECHNOLOGY...................................................2

2.1 AVAILABLE TECHNOLOGIES.......................................................................................................................22.1.1 Data Connection......................................................................................................................2

2.1.1.1 Wireless LAN..............................................................................................................................................22.1.1.2 Wireless PAN..............................................................................................................................................32.1.1.3 Near Field Communication (NFC)..............................................................................................................32.1.1.4 2(.5)G, 3(.5)G, 4G (GPRS/EDGE, UMTS/HSPA, LTE).............................................................................5

2.1.2 Voice Communication..............................................................................................................52.1.3 Identification............................................................................................................................52.1.4 Location Systems......................................................................................................................6

2.2 OPERATING SYSTEMS..............................................................................................................................8

3 FUTURE IT INFRASTRUCTURE OF THE NEW WU....................................................10

3.1 WU CAMPUS......................................................................................................................................103.1.1 NFC at the Campus................................................................................................................103.1.2 User Interaction and Notification at the Campus..................................................................12

3.2 LECTURE ROOMS.................................................................................................................................13

3.3 EXISTING SOFTWARE.............................................................................................................................163.3.1 Learn@WU............................................................................................................................163.3.2 WUdoo....................................................................................................................................173.3.3 WUdroid.................................................................................................................................18

3.4 PLANNED DEVELOPMENTS.....................................................................................................................193.4.1 WUdoo in HTML....................................................................................................................19

4 USE CASES............................................................................................................................20

4.1 AT THE CAMPUS...................................................................................................................................21

4.2 IN THE LECTURE..................................................................................................................................28

4.3 WU-ADMINISTRATION..........................................................................................................................41

4.4 ADDITIONAL USE CASES.......................................................................................................................43

5 IMPLEMENTED PROJECTS.............................................................................................45

5.1 MOBILE LIBRARY RESERVATION SYSTEM..................................................................................................465.1.1 Introduction............................................................................................................................465.1.2 Modelling...............................................................................................................................48

5.1.2.1 Use Case Diagram.....................................................................................................................................485.1.2.2 Sequence Diagram....................................................................................................................................495.1.2.3 Entity Relationship Model........................................................................................................................52

5.1.3 Implementation.......................................................................................................................545.1.3.1 Database....................................................................................................................................................545.1.3.2 Server .......................................................................................................................................................55

V

5.1.3.3 Mobile Application...................................................................................................................................565.1.3.4 Learning places.........................................................................................................................................74

5.1.4 Project Conclusion.................................................................................................................76

5.2 AUDIMAX QUERY TOOL........................................................................................................................785.2.1 Introduction............................................................................................................................785.2.2 “Look and Feel” of the Query Tool.......................................................................................795.2.3 Modeling................................................................................................................................84

5.2.3.1 Use case diagram.......................................................................................................................................855.2.3.2 Class diagram............................................................................................................................................865.2.3.3 Sequence Diagram....................................................................................................................................885.2.3.4 Entity Relationship Model........................................................................................................................90

5.2.4 Implementation.......................................................................................................................915.2.4.1 AndroidManifest.xml................................................................................................................................925.2.4.2 Queries.java..............................................................................................................................................945.2.4.3 Config.java................................................................................................................................................985.2.4.4 DbHelper.java and DbConst.java............................................................................................................1005.2.4.5 Asking.java..............................................................................................................................................1025.2.4.6 Listing.java.............................................................................................................................................1055.2.4.7 About.java...............................................................................................................................................108

5.2.5 Project Conclusion...............................................................................................................110

6 CONCLUSION.....................................................................................................................111

7 REFERENCES.....................................................................................................................112

8 APPENDIX – SOURCE CODE...........................................................................................116

8.1 PROJECT 1: MOBILE LIBRARY RESERVATION SYSTEM...............................................................................116

8.2 PROJECT 2: QUERY TOOL (XML DATA FILES)........................................................................................132

VI

List of FiguresFigure 2.1: Location systems and accuracy [HaSK04]....................................................................6

Figure 2.2: WLAN fingerprinting visual radio map [Linn10].........................................................7

Figure 2.3: WLAN fingerprinting operation modes [Linn10].........................................................7

Figure 2.4: Mobile operating systems by market share [Niel11].....................................................8

Figure 2.5: Mobile operating system distribution by age groups [Niel11]......................................9

Figure 3.1: DRAG-AND-DROP (A-C) AND DRAG-AND-POP (D) ACROSS MULTIPLE

GRAPHICAL INTERFACES [Baudisch, et al.]...........................................................................13

Figure 3.2: Interactive Whiteboard [WUOfficeMedia11].............................................................14

Figure 3.3: Mobile Learn@WU [LEARNWU].............................................................................16

Figure 3.4: WUdoo Application [WUdoo Facebook]...................................................................17

Figure 3.5: Wudroid [androidzoom.com]......................................................................................18

Figure 4.1: Use Cases at the campus.............................................................................................21

Figure 4.2: Use Cases in the lecture..............................................................................................29

Figure 5.1: LLC [CAMPWU].......................................................................................................46

Figure 5.2: Use Case Diagram.......................................................................................................48

Figure 5.3: Sequence Diagram......................................................................................................49

Figure 5.4: Entity Relationship Diagram.......................................................................................52

Figure 5.5: Entry Point..................................................................................................................58

Figure 5.6: WU Applications [WUAPPS11].................................................................................60

Figure 5.7: Reservation List..........................................................................................................62

Figure 5.8: LLC 5th floor..............................................................................................................63

Figure 5.9: Reservation Detail.......................................................................................................64

Figure 5.10: Application Drop Down Menu..................................................................................65

Figure 5.11: Day & Time Selection...............................................................................................66

Figure 5.12: HTML 5 Video working............................................................................................67

Figure 5.13: HTML 5 Video not working......................................................................................68

Figure 5.14: Floor Overview.........................................................................................................69

Figure 5.15: Area Selection...........................................................................................................71

Figure 5.16: Reservation Done......................................................................................................73

Figure 5.17: HTML5 Support [caniuse.com]................................................................................76

Figure 5.18: Opening screen..........................................................................................................79

Figure 5.19: Asking questions.......................................................................................................80

VII

Figure 5.20: Listing and voting for questions................................................................................81

Figure 5.21: Configuration screen.................................................................................................82

Figure 5.22: Selecting a lecture hall..............................................................................................82

Figure 5.23: Setting a nickname....................................................................................................83

Figure 5.24: Prompt to configurate...............................................................................................83

Figure 5.25: About screen..............................................................................................................84

Figure 5.26: UML Use Case Diagram...........................................................................................85

Figure 5.27: UML Class Diagram.................................................................................................87

Figure 5.28: UML Sequence Diagram...........................................................................................88

Figure 5.29: E-R Diagram of the database....................................................................................90

Figure 5.30: Revised E-R Diagram of the database......................................................................91

Figure 5.31: Project skeleton.........................................................................................................92

Figure 5.32: AndroidManifest.xml................................................................................................93

Figure 5.33: Queries.java..............................................................................................................96

Figure 5.34: Config.java................................................................................................................98

Figure 5.35: Shared preferences....................................................................................................99

Figure 5.36: DbConst.java...........................................................................................................100

Figure 5.37: DbHelper.java.........................................................................................................101

Figure 5.38: Asking.java..............................................................................................................103

Figure 5.39: Listing.java..............................................................................................................106

Figure 5.40: About.java...............................................................................................................109

VIII

List of AbbreviationsADB Android Debug Bridge

ADT Android Development Tools

API Application Programming Interface

APK Android Package

AVD Android Virtual Device

BACH An Administrative Website/Service of the WU

BSD Berkeley Software Distribution

CSS Cascading Style Sheet

DBMS Database Management System

DDMS Dalvik Debug Monitor Server

EDGE Enhanced Data Rates for GSM Evolution

ER / E-R Entity Relationship

GPRS General Packet Radio Service

ID Identity Document

IDE Integrated Development Environment

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

JDK Java Development Kit

JSP Java Server Pages

Learn@WU E-Learning Platform of the WU

ÖH Österreichische Hochschülerschaft (Austrian National Students Association)

PDA Personal Digital Assistent

PID Process Identifier

RFID Radio-Frequency Identification

SDK Software Development Kit

SMS Short Message Service

SQL Structured Query Language

TCP Transmission Control Protocol

UI User Interface

UML Unified Modeling Language

UMTS Universal Mobile Telecommunications System

URI Uniform Resource Identifier

VM Virtual Machine

VoIP Voice over IP

WLAN Wireless Local Area Network

WPAN Wireless Personal Area Network

WU Wirtschaftsuniversität Wien (Vienna University of Economics)

XML Extensible Markup Language

IX

1. Introduction

1 Introduction

1.1 Research Question

The authors motivation for this paper is the finding of possible fields of applica-

tions for mobile devices such as smart-phones and tablet PCs at the new campus of

the WU.

Derived from those findings, two exemplary mobile applications shall be selected

and developed in order to determine their implementation feasibility and to demon-

strate a possibility of their technical realisation.

1.2 Methodology

Interviews have been performed with the employees of the WU who are responsible

for the development of mobile applications. The main goal of these interviews was

to get an overview of the currently existing technologies at the WU and to gather in-

formation about the technologies which will be used in the future.

Scenarios were developed which show the possible applicability of future technolo-

gies available at the WU. These scenarios are focused on the possible use of mobile

phones at the new WU to support students, lecturers, visitors and employees in or-

ganizational and social matters and to facilitate e-learning at the university and dur-

ing the courses.

Furthermore Use Cases of the Unified Modeling Language (UML) were defined.

These use cases will help to specify the technological and organizational require-

ments needed for the implementation of the scenarios.

Two Use Cases were selected and they have been implemented either in Java for the

Android operating system or in HTML.

Belk/Stöhr, June 2011 1

2. Mobile Devices and Wireless Technology

2 Mobile Devices and Wireless Technology

When thinking of developing creative mobile applications for the new WU, a look

at the available technologies and operating systems – as of the date of this writing –

is needed. This section describes where the mobile world stands as of mid 2011.

Regarding the implementation of two projects which will be derived from our use

case findings (see chapters 4 and 5), we look for a target operating system that

• has software-side support for modern technologies,

• has a positive tendency regarding its widespread usage,

• is rapidly developed going forward,

• is free of charge to develop for as well as

• friendly to novices.

As we go forward, we will see that the mobile operating system “Android”, which

is developed by Google Inc., best fits our prerequisites.

2.1 Available Technologies

This chapter describes some functional characteristics of widespread technologies

from the perspective of a mobile application. Learning about these capabilities and re-

strictions enabled the authors to think of possibilities to use or combine these technolo-

gies (see chapter 4).

2.1.1 Data Connection

Mobile devices can connect to data networks or other devices by using certain of

the following standardized technologies.

2.1.1.1 Wireless LAN

A IEEE 802.11 WLAN connection supports the transmission of classic network

protocols like the Internet protocol (TCP/IP, UDP) [IEEE11]. Therefore a mobile

device's application could address existent intra-/internet services like

• classic network services (eMail and web services, etc.),

• communication services (SIP, proprietary instant messaging protocols, etc.),

• (room) equipment control via control protocols transmitted over IP.

A wireless LAN device operates in one of two modes:



• An ad-hoc network allows devices to directly connect to one another and no in-

frastructure is needed (allowing only peer-to-peer connections between

devices).

• In infrastructure mode, the WLAN is bridged to a wired network (allowing ac-

cess to intra-/internet services).

2.1.1.2 Wireless PAN

A IEEE 802.15 WPAN connects devices and peripherals in immediate vicinity. The

reach is typically only a few meters and data rates are lower than in WLAN networks.

Several implementations exist.

The “Bluetooth technology is a short-range communications technology […]. You

can find it in billions of devices like mobile phones and computers […]. It is intended

to replace the cables connecting devices, while maintaining high levels of security.”

[Blue11]

It is defined in the IEEE 802.15.1 standard.

Mobile applications can utilize a Bluetooth API (e.g. [ADev11]) to

• discover other nearby bluetooth-enabled devices and making itself identifiable,

• interact with the same or other application running on nearby devices,

• access remote data like contact details, dates and schedules of other users,

• integrate functions provided by peripheral devices (e.g. headsets).

ZigBee is a low-rate WPAN (LR-WPAN) technology which is built on top of the

IEEE 802.15.4 standard. The range is even shorter and power consumption of the chips

so low that a battery charge would suffice for 1-3 years. Its purpose is to enable control

and automation by spontaneous linking and data exchange. ZigBee and other 802.15.4

based technologies (e.g. WirelessHART, 6LoWPAN and ISA100.11a) are built rather

into sensors and control systems than mobile devices like smart-phone or tablets up to

mid 2011 [Frau11].

2.1.1.3 Near Field Communication (NFC)

NFC also is a short-range wireless technology with a range of only a few centi-

meters. Its data rate is slower than Bluetooth's while far less power is consumed, pair-



ing is not required and connections are established quickly (in about 10 milliseconds).

Furthermore, NFC is able to communicate with already existing passive RFID chips

[Ambr11]. It has not yet been implemented in many mobile devices until mid 2011.

Two modes of operation are possible:

• Passive communication mode: An initiator generates a radio-frequency field

and therefore allows that (passive) targets do not require an own power supply.

• Active communication mode: The initiator and the targets generate their own

RF fields. A connection can be initiated by each of both devices (peer-to-peer).

Wikipedia authors had collected several scenarios for possible mobile applications

[Wiki11]:

• “Social Networking

◦ File sharing: Tap one NFC device to another to instantly share a contact,

photo, song, application, video, or website link.

◦ Electronic business card: Tap one NFC device to another to instantly share

electronic business cards or resumes

◦ Electronic money: To pay a friend, you could tap the devices and enter the

amount of the payment.

◦ Mobile gaming: Tap one NFC device to another to enter a multiplayer

game.

◦ Friend-to-friend: You could touch NFC devices together to Facebook friend

each other or share a resume or to "check-in" at a location.

• Connections

◦ Bluetooth: Instant Bluetooth Pairing can save searching, waiting, and enter-

ing codes. Touch the NFC devices together for instant pairing.

◦ WiFi: Instant WiFi Configuration can configure a device to a WiFi network

automatically. Tap an NFC device to an NFC enabled router.

• Identification

◦ ID card: An NFC enabled device can also act as an encrypted student, em-

ployee, or personal ID card or medical ID card.

◦ Keycard: An NFC enabled device may serve as car, house, and office keys.

◦ Rental Car and hotel keys: NFC rental car or hotel room keys may allow

fast VIP check-in and reduce staffing requirements.”



2.1.1.4 2(.5)G, 3(.5)G, 4G (GPRS/EDGE, UMTS/HSPA, LTE)

Like wireless LAN, the cellular mobile (data) network and its evolutions allow to

encapsulate the Internet protocol. For mobile applications, the same capabilities apply.

Differences are

• higher latencies, which may have a negative influence on real-time applications

like those using voice communication via VoIP, and

• lower data rates, which may be problematic for streaming applications with

high-definition content.

2.1.2 Voice Communication

Apart from the telephony service agreement most users entered with their providers,

another form of voice communications is available for mobile devices. Voice over IP

relays calls via SIP servers over IP-based networks and establishes direct links in order

to transmit the binary encoded conversions.

Fixed line numbers and dialing extensions are no longer location-dependent be-

cause in a VoIP environment, they can be routed via Asterisk servers to IP-addressable

devices with a VoIP client running [Aste11]. This could be a VoIP mobile application

running on a smart-phone, which can connect to an Asterisk server via the WLAN or

3G connection of the phone.

2.1.3 Identification

Mobile devices and therefore mostly their users can be identified in various ways:

• The WLAN chip has an identifier (MAC address), which is unique worldwide.

This address is broadcasted and access points, network nodes as well as other

active users and passive eavesdroppers on the wireless network can identify the

device and thus (if it is known who cares it) its user(s).

• Bluetooth does also have such an unique device address, which is programmed

into the Bluetooth radio. Even the manufacturer can be determined (in case of

WLAN too) by looking at the first three bytes of this address [HeMu04].

• Authentication mechanisms implemented in software on a mobile device allow

users to make themselves identifiable (e.g. via sending authentication tokens

over a network to an authentication server).



2.1.4 Location Systems

Location systems can help mobile devices to identify their current position. This is

critical for location-based services like navigation. But it can also facilitate the use of

certain mobile applications where input of the current location is required by retrieving

and updating the position automatically.

Figure 2.1 shows various technologies ordered by their rate of dissemination in as-

sociation with their respective location accuracy.

Note that widespread technologies like Wi-Fi (WLAN), GPS and Bluetooth deliver

the most inaccurate results. This is important to know as these technologies are imple-

mented in mobile devices.

Furthermore, a distinction must be drawn between indoor and outdoor location sys-

tems. The GPS satellite signals are, for example, not available for uses inside build-

ings. Possible alternatives for such uses are methods like WLAN fingerprinting or

RFID tagging.


Figure 2.1: Location systems and accuracy [HaSK04]


WLAN fingerprinting has two stages: In the record phase, a radio map (see figure

2.2) is created by measuring the received signal strength (for each access point) for

each reference point. Note that several measurements for each reference point may be

required to get averages. In the operating phase, a mobile device (located somewhere)

measures the RSS for each available access point. The point on the reference map with

minimal difference represents the current location of the mobile device [Linn10].

Depending where the signal measurements and the position calculation happen,

three operation modes can be distinguished (see figure 2.3).

(a) Terminal-assisted mode: Measurements happen at the mobile device, while cal-

culation is done at a server (privacy is not protected)

(b) Terminal-based mode: Measurements and calculation happen at the mobile

device (privacy is protected)

(c) Network-based mode: Beacon is emitted by the mobile device and measure-

ments happen at the access points, calculation is done at a server (privacy is not

protected)


Figure 2.3: WLAN fingerprinting operation modes [Linn10]

Figure 2.2: WLAN fingerprinting visual radio map [Linn10]


2.2 Operating Systems

On the one side, some mobile operating systems (OS) are exclusively pre-installed

on the manufacturer's own devices and no licenses are distributed to third-parties –

examples are the iOS from Apple which powers the iPhone and iPad and the Black-

Berry operating system from Research In Motion (RIM) powering the BlackBerry

product line.

Another form of distribution is that of Google's Android or Microsoft's Windows

Mobile. These OSes are available to manufacturers to drive their devices. For ex-

ample, Samsung installs Android on various smart phones and tablets inside their

product lines.

As of March 3rd, 2011, the Nielsen Company found that “Android (29%) appears to

be pulling ahead of RIM Blackberry (27%) and Apple iOS (27%)” regarding the

market share of operating system in the United States [Niel11]. A graphical repres-

entation is given by figure 2.4.


Figure 2.4: Mobile operating systems by market share [Niel11]


According to figure 2.5, which shows the distribution of operating systems among

age groups, Android has gained an edge in distribution among young people with 6

percent versus the iOS with 4 percent. One main reason for this may be that iPhone

devices are expensive and, due to budget constrains, young people go for Android

phones which generally have comparable functionality.

Before application (“app”) development can begin, a developer has to choose a tar-

get platform which to write code for. Apps, which were programmed for the iOS for

example, do not run on mobile devices powered by other mobile operating systems

– e.g. Android.

HTML5 will break through this restrictiveness. Websites, programmed in HTML5,

do have a much wider multimedia component and are displayed and interacted with

via the browser. The difference between apps and websites may vanish. Once pro-

grammed, HTML content can be accessed from classic desktop computers, tablets,

smart phones and other terminals. The disadvantage is that no direct access to the

hardware layer is available, making position location via a GPS sensor or detection

of movements via an accelerometer limited or even impossible.


Figure 2.5: Mobile operating system distribution by age groups [Niel11]

3. Future IT Infrastructure of the New WU

3 Future IT Infrastructure of the New WU

This chapter is principally concerned with the technologies which will be available

in the future. These future technologies have to be taken into account during the

construction of the new WU. For this purpose interviews were conducted by the au-

thors with Stefan Jester, Kathrin Wembacher and Matthias Frey. The goal was to de-

termine the capabilities and issues of the currently most well-known systems of the

WU which are used by students, lecturers and employees. Furthermore it was at-

tempted to gather information about the future developments of the WU applica-

tions. These interviews were performed during February and March 2011.

3.1 WU Campus

The construction of the new WU in the second district offers the possibility to in-

clude modern technology into the design of the campus from the very beginning.

3.1.1 NFC at the Campus

NFC will play an essential role for the new WU. Students, lecturers and especially

visitors who will be unfamiliar with the campus during their first visit will have to

find their ways to the points of interest on a area of 90.000 m². Localization via

NFC offers more accuracy than other localization methods like triangulation with

wireless local area network signals or the mobile communications network. To

guide people through the WU campus high accuracy is needed. This accuracy is of

even more importance when it comes to indoor navigation.

The range of NFC signals is limited. Nevertheless this technology can be used for

location-based services by installing terminals equipped with NFC readers in the

campus buildings or by placing readers at bottlenecks like door frames where the

users have to pass.

Likewise a NFC chip in a mobile phone can be used as an ID card which grants

entry to rooms or denied it when the user does not have the required rights of ac-

cess. The input possibilities like the numeric key pad which mobile phones provide



extend these applications considerably. Key pads at doors would be obsolete. The

user who wants to enter a locked room simply holds his mobile phone to the NFC

reader. Additionally he can enter a pin code if it is needed.

As for the first quarter of 2011 there are only a few mobile phones available with

built-in NFC chips. The some main mobile phone manufacturers and some minor

ones already offer some models. [NFCWORLD] The most prominent of them are:

• Samsung Galaxy S II

• Samsung S5230 NFC

• Samsung SHW-A170K

• Google Nexus S / Google Nexus S 4G

• Sagem Wireless Cosyphone

• NOKIA C7

• Motorola MC75A HF

It can be expected that this number will rise during the next years. At the earliest the

new campus will be used in October 2013 [CAMPWU]. The major producers of

mobile phones such as SAMSUNG, Toschiba, Sony Ericsson, LG and APPLE all

announced to launch a series of new mobile phones equipped with NFC. A built-in

NFC chip will become a standard feature for mobile devices comparable to

Bluetooth chips which can be found in nearly every phone today. Once a significant

number of phones is equipped with NFC chips manufacturers will have to equip all

of their new models with this feature to stay competitive.

It is planned that the NFC readers will be installed in facades, shear walls or they

are directly plugged into computers at the new WU. The NCF chips will store as

less information as needed. This information will only be the unique chip's identi-

fication number and necessary security certificates. The number is assigned to the

users data which is stored at the WU’s database. [CAMPWU]



3.1.2 User Interaction and Notification at the Campus

As described in the working paper [WUIT00] displays and terminals will be placed

at important locations at the campus area.

Displays will provide general information, information about current lectures and

important news. These displays are not primarily designed for user interaction, but

they can be equipped with NFC readers to enhance their functionality. Students can

view their next courses or assignments by placing their mobile phone or their stu-

dent identification card next to the display.

Terminals with whom the users will be able to interact will be available at the cam-

pus. These terminals will offer information such as the users current location or

lectures of the day. They will be equipped with touch screens to offer an additional

way of input.

Terminals equipped with video cameras can serve as information desks or emer-

gency terminals which connect the user to a WU employee. [CAMPWU]



3.2 Lecture Rooms

Interactive teaching should be an essential part of the new WU. Therefore lecture

rooms should meet the technological requirements to support students and lecturers

during their courses.

Interactive whiteboards will support the teaching activities. These boards can be

controlled using a pen. This device would allow new input methods such as drag

and drop.

“Drag-and-Pop and Drag-and-Pick are techniques for users of pen and touch oper-

ated display systems. These concepts should enable users to interact with devices,

including PDA's (Personal Digital Assistant), tablet PC's and other touch screen sys-

tems by providing innovative ways to access screen content more easily.”

[Baudisch, et al.]

Figure 3.1: DRAG-AND-DROP (A-C) AND DRAG-AND-POP (D) ACROSS MULTIPLE GRAPHICAL INTERFACES [Baudisch, et al.]



Lecturers will be able to use the whiteboards to display interactive content such as

videos or include content from the internet during their lessons. In lecture rooms of

the old WU multimedia content which is normally presented over a video projector

and hand-written content at whiteboards are separated. Interactive boards will com-

bine these two worlds. Currently information flows mostly from the lecturer to the

students during lectures since the computer which is connected to the video

projector and the whiteboard can only be accessed by the person in front of the oth-

ers. An interactive whiteboard would be accessible from anywhere in the lecturing

room and it could be controlled by multiple persons. This would allow new con-

cepts of room usage where students and lecturers can use the available space as they

wish.

Figure 3.2: Interactive Whiteboard [WUOfficeMedia11]

Additionally the information flow will no longer be in one direction only. Interact-

ive paper can be used to display the student's writing on the digital whiteboard.

Thus student's writing can be displayed at the interactive whiteboard it can be dis-



cussed by the whole class. It can even be corrected by the lecturer using an interact-

ive pen to write at the whiteboard.

Room settings should adapt to the current lecture. “Different lecturers have differ-

ent demands to IT infrastructure, and not everyone uses the same applications, as

not every lecture has the same requirements to the environment.” [Zeitler09/10]

NFC readers can receive the signal of the lecturers mobile phone at the rooms en-

trance. The lecture room's interactive table will boot up and programs or web pages

which are needed for the lecture will start up automatically. Additionally the light

settings and the room temperature will be set to the preferred preferences of the lec-

turer.



3.3 Existing Software

At the old WU there are currently multiple software solutions in use for the differ-

ent requirements of the students and lecturers. These applications base on BACH

which is the interface to the main database of the WU containing the basic informa-

tion about courses, grades, etc.

Learn@WU is the university's e-learning platform which is accessible through the

internet and offers information about courses and e-learning material. Concerning

the mobile access there exists the WUdoo application for Apple iPhones.

3.3.1 Learn@WU

In 2011 a mobile version of Learn@WU was introduced. This mobile version was

designed after a study described in the term paper by Bayat, Cendik, Durmus, Föls,

Mühlbacher, Tacetdin [BCDF11].

Figure 3.3: Mobile Learn@WU [LEARNWU]

Implementing the application in different platform dependent languages was taken

in consideration. This would have meant that Learn@WU would have only become

accessible for the users of the most popular smart-phone operating systems which

are Android and Apples' iOS. Other users would have been excluded from the use

of a mobile Learn@WU. This would have created a situation similar to the one of

the currently available WU mobile application WUdoo.



3.3.2 WUdoo

In 2009 WUdoo was introduced as Austria's first mobile application developed by

an university. It offers general information about the WU like a campus map, in-

formation about courses, a news feed and user specific information.

This application was very successful among WU students and employees. However

WUdoo is only available for iPhones due to its platform dependency, therefore it

can only be obtained by a small portion of the possible users who possess a smart-

phone.

Figure 3.4: WUdoo Application [WUdoo Facebook]

WUdoo offers features such as a news feed, a course overview and a campus map

for orientation. The idea of an mobile application developed for educational means

was also adapted by the University of Applied Science in Carinthia. [fh-kaernten.at]

More information and news about the WU's iPhone application WUdoo can be

found at “http://www.facebook.com/wudoo.mobile”. [WUdoo Facebook]



3.3.3 WUdroid

WUdroid is the equivalent to WUdoo for Android smart phones. It features “Helps

to keep track of the courses which you are registered at the WU Wien[sic]. View per

day or month, of your entries and a day view of all the courses on, on a specific

day.” [androidzoom.com]

Figure 3.5: Wudroid [androidzoom.com]

It offers some basic information about the courses in which a student is enrolled and

it serves as a calendar to manage the courses. However it is not an as highly de-

veloped application such as the iPhone application WUdoo. Due to the fact that it is

not developed any further on a regular basis problems arise in case of software

bugs. Additionally the functionality of this program remains limited.



3.4 Planned Developments

Future developments of the WU will try to avoid platform dependencies by making

use of web technologies such as HTML. The developers of the Learn@WU chose

this path of development for their mobile application. This decision was facilitated

by the already existing Learn@WU HTML pages for desktops which made the con-

version to a mobile platform easy. According to Matthias Frey, future versions of

WUdoo and similar software will also be developed in HTML.

3.4.1 WUdoo in HTML

Due to the platform dependency of the current mobile application WUdoo, which is

only available for the iPhone, iPod touch and iPad with iOS 3.0 or higher, the

amount of people who have access to this service is limited. The existence of a sim-

ilar application for Android phones increases the amount of reachable people but it

also doubles the amount of time which is needed for support, development, soft-

ware changes and error elimination.

Therefore it will be necessary to develop future mobile applications with platform

independent technologies. HTML and Java offer these possibilities. Java is a plat-

form independent technology, but for Java applications it is necessary that the user

downloads the Java file first and additionally memory is needed to save it at the

user's mobile phone.

HTML has the crucial advantage that no application has to be downloaded an in-

stalled on the user's phone since every mobile phone comes with a built in web

browser which can display HTML sites.

If we compare the recently launched mobile website for Learn@WU and the iPhone

application WUdoo it becomes clear that it easier to maintain a HTML page than a

platform dependent code. Due to the design of HTML browsers are able to display

old websites as well as new ones which are written in the most modern HTML lan-

guage specification. On the other hand platform dependent code may have to be re-

written if the operating system is updated by the manufacturer. It may also occur

that some users do not update their systems.

This reasons motivate the developers of the WUdoo application to implement future

applications in system independent HTML code.


4. Use Cases

4 Use Cases

Each use case presented in this thesis consists of a textual description, a use case

diagram and additional graphical representations if needed. Since the Unified Mod-

eling Language Specification does not specify mandatory guidelines for a textual

description of a use case the template of Hansen and Neumann [HaNe09] is used

and it is extended by some elements of Derek Coleman's template [Cole98] for this

purpose. Additionally the template is extended for the attribute 'Stakeholders' by the

authors. This was considered necessary because in Information Systems the is not

only the user (actor) who has an interest in an application, but also other people

(stakeholders) who may not use the application and are affected by it in one or an-

other way. The diagrams are geared to the UML notation guide of the Object Man-

agement Group [OMG05].

In this thesis examples for use cases of possible future applications at the new WU

are examined in detail. For the classification of these use cases three categories are

used which basically represent their main fields of application. The categories are

'At the Campus', 'In the Lecture' and 'WU-Administration'.

The category 'At the Campus' comprises use cases which are not especially bound

to a specific lecture and which are designed to be used at the whole campus by the

students.

Uses cases which focus on the lecturing activities are combined to the category 'In

the Lecture'. Their main goal is to improve the quality of lecturing and learning for

tutors and students.

The last category is called 'WU-Administration', which consists of applications to

support the administrative personal of the WU in their daily work.

In their work about the conversion of the e-learning platform “Learn@WU” for mo-

bile devices Bayat, Cendik, Durmus, Föls, Tacetdin and Mühlbacher already define

some use cases, which although they were not specially designed for the new WU,

can be applied for it as well [BCDF11].


4. Use Cases

4.1 At the Campus

Use Cases which do not affect the teaching activities are grouped in the category

“At the Campus”. These Use Cases comprise social and organizational activities

outside the lecturing halls.

These actives are not only restricted to students. They will be useful for the stu-

dents, as well as for the Wu’s staff and for guests. Some services such as getting

routed over the campus offer basic functionality which will be important for the

people on the WU area. These services can later be used to create new applications

which enhance the daily live of the people at the WU.


Figure 4.1: Use Cases at the campus

4. Use Cases

Use Case Reserving books via a mobile device

Goal Improvement of library services

Description Students will be able to interact with the database of the lib-

rary via their mobile phones. It is possible to view the current

availability of books and to reserve them. If a book is not on

stock than the date of return has to be displayed.

Actors Students, library (server)

Stakeholders Students, WU staff

Trigger Events • Student wants to reserve a book

Scenario Steps 1. Log in to the library book reservation system

2. Search for a book

3. Check the availability of the book

IF available THEN

4a. Reserve book

ELSE not available

4b. Display return date of the book

Preconditions • The library at the old WU already manages its invent-

ory via an electronic database. It is also possible to

look up the availability of a book through the libraries

website. Therefore the use case can be realized

without much effort. It will only be necessary to im-

plement a mobile web interface to access the library's

services with mobie devices.

Additional Inform-

ation

• If the WU's library does not possess a requested book,

the system should suggest alternative sources such as

other libraries where the book is available or online

resources.


4. Use Cases

Use Case Reserving learning stations via mobile devices

Goal Improvement of library services

Description Learning stations can be reserved for predetermined periods

of time. Therefore students can check with their mobile

devices if a station is free at the desired time and they do not

have to spend their time on going to the library and searching

for a free learning station.

Actors Students, library (server)


Trigger Events • Student wants to reserve a learning station

Scenario Steps 1. Log in to the library learning station reservation system

2. Check if learning stations are unoccupied

IF unoccupied THEN

3a. Display free stations (a graphical presentation

would be possible where the student can choose

the station or a group of stations by its location to re-

duce unnecessarily long ways to bookshelves etc.)

4a. Student chooses suitable station and desired period

of time

ELSE occupied

3b. Suggest free stations and time slots for the next

days

Issues • The reservation server could be overloaded on special

occasions like the week before the exams when there

is a high demand for learning stations at the library.

Additional Inform-

ation

• Additionally the WU will be able to monitor the aver-

age and the peak utilization of the library's learning

stations.

• The current proposed use case favors a system where

learning stations can only be used if the student has re-

served one. This would eliminate the possibility to use

a learning station spontaneously. If desired the possib-

ility to use a learning station spontaneously could be


4. Use Cases

sustained by using a method (which one has so be

chosen later, for example a small warning light) to in-

dicate weather or not a station is occupied.

• Further on stations should be equipped with card read-

ers of NFC readers which help to detect if a person is

currently using this station, or if the student who re-

served the station has shown up, so that it can be used

by spontaneous users after a specified time.


4. Use Cases

Use Case Getting routed over the campus area

Goal Improvement of navigation at the campus area

Description Routing people over the campus area is an important task

considering its net floor space of 100.000 m² and its six com-

plexes of buildings (campuswu.at, 2011). People may search

for a specific room on the campus and need guidance to find

it fast and easily. Popular routing applications such as

Google's “Google Maps” can not find single rooms in build-

ings and they also can not guide people through various floors

of a building. Therefore a special solution is needed which

communicates with sensors in the building to determine the

users location properly and which is aware of the buildings

room layout. Wireless LAN signals and NFC stations can be

used for indoor localization.

The routing can either be achieved through a web interface

similar to Google Maps or the campus could be equipped

with terminals where the user can choose the destination and

the information is then displayed at the users mobile device

via a 2D-BARCODE or a NFC connection.

Actors University members, guests, web server

Stakeholders Students, WU staff, guests

Trigger Events • A person needs help finding a room at the campus.

Scenario Steps 1. The user is accessing an specific application or web

page

2. Retrieve location of the user

3. Enter destination

4. Compute route to destination

5. Guide user though the campus based on GPS, WLAN or

mobile phone triangulation

Alternative Scen-

ario Steps

1. The user is accessing a terminal

2. Retrieve location of the terminal

3. User enters destination into the terminal

4. Compute route to destination


4. Use Cases

5. Display 2D-BARCODE with a link to a navigation web

page or transfer with NFC

6. Guide user though the campus based on GPS, WLAN,

etc

Preconditions Indoor localization has to be available.

Post-conditions User is guided to the right room.

Issues • GPS does not work inside buildings so therefore wire-

less LAN signals or NFC stations have to be used.

Wireless LAN is not as accurate as GPS and NFC sta-

tions have to be placed in large numbers at strategic

points all over the campus.

• Software may be platform dependent if it is designed

to use NFC.

Additional Inform-

ation

• The streams of people (visitors, students, lecturers,

employees, etc.) can be channeled through selected

parts of the campus area.


4. Use Cases

Use Case Finding friends on the campus area

Goal Supporting social interactions at the university

Description As mentioned in the use case for routing people, the campus

of the new WU will extend over a large area.

Actors WU members, web server


Trigger Events • Friends are in close range to each other.

Scenario Steps REPEAT

1. Retrieve own position

2. Check position of friends

IF friend is close THEN

3. Alert user

4. Guide user to friend

UNTIL application is turned off

Preconditions The users have to be logged in into the system.

Post-conditions Users have found each other.

Issues • Users have to be localized at the campus area.

• People may not always want their friends to know

where they are.

• Friends may move quickly through the campus. The

localization has to keep up with the speed.

Additional Inform-

ation

• This use case can be extended with the use case for

routing people over the campus.


4. Use Cases

Use Case Offering and demanding private lessons

Goal Students have found partners for private lessons.

Description Students may access a web interface where they can search

for private lessons or post a request for a specific course. The

difference to the forum of the ÖH which is currently the most

used platform would be that students offer their private les-

sons in specified categories which resemble the courses at the

WU. Students who search for private lessons for a special

subject would be presented a list of available partners in a

matter of seconds instead of searching through all posts of a

forum.

Actors Students, e-learning server

Stakeholders Students

Trigger Events • Student needs or offers private lessons.

Scenario Steps 1. Student accesses the platform

SWITCH

CASE offering private lessons:

2a. Student enters information about the type of

offered lessons

CASE searching for private lessons:

2b. Student enters search parameters (course type, etc)

3b. List possible matches

4b. Student chooses an offer

5b. A notification with contact information is sent to

the partner

Issues • There has to be the possibility to recall an offer for

private lessons.

• A critical mass of offers has to be reached for the plat-

form to be attractive for users.

Additional Inform-

ation

• This use case can be extended with the use cases for

finding friends and for routing people over the cam-

pus.

4.2 In the Lecture


4. Use Cases

There are basically two actors during lectures – students and lecturers. Lecturers

have an interest in teaching activities and in organizational activities during the lec-

tures. Students may have additional tasks such as organizing groups which are ne-

cessary for some courses.


Figure 4.2: Use Cases in the lecture

4. Use Cases

Use Case Evaluating courses

Goal Improvement of lecture quality

Description Immediate students' feedback regarding lecturer's teaching

quality during/after a course. Evaluations are presented to the

lecturer(s) so that the teaching can be improved subsequently.

Actors Students of a lecture, lecturer(s), administration server

Stakeholders Students, WU administration

Trigger Events • Student is attending a lecture

Scenario Steps 1. Student logs in to the evaluation application

2. Conditions check

2.1. Student is registered for the course

2.2. Time has not elapsed (see preconditions)

2.3. Student is physically present in the course premises

(positioning)

3. Evaluation

4. Submitting evaluation

5. Analysis

6. Presentation of results to lecturer(s)

Preconditions • Student must be registered for the course.

• The student must have attended the course for at least

30 minutes and the lecture must have finished not

longer than 30 minutes ago.

Postconditions • Submitted evaluation

Issues • Lecturer(s) may not want permanent feedback.

• The amount of assessment items should be minimal.

• Detecting if a student is present at the course may be a

technical difficulty. Possible solutions are NFC,

WLAN localization or the handing out of a access

code for the evaluation page by the lecturer(s).

• Students must not vote more than once per lesson.


4. Use Cases

Use Case Acquire course literature

Goal Reduction of time and costs for the acquisition of literature

Description Lecturer(s) provide a digital list of the required literature for

the course. Students can choose which books they need to get

and check those which they already have (the application may

remember those). Availability at the WU library (for borrow-

ing) as well as at online and near-by book stores (for buying)

is checked and presented. An internal book market facilitates

mutual lending as well as brings buyers and sellers of used

books together.

Actors Student of a lecture, lecturer(s), e-learning server


Trigger Events • Student is registering for a course or viewing the

course information without registration.

Scenario Steps 1. Lecturer(s) provide a digital bibliographical reference

for a course

2. Student logs in, accesses the list and selects the literat-

ure

3. Application checks the availability at predetermined

sources

3.1. WU library

3.2. (Internal) book market

3.3. Near-by stores

3.4. Online stores

4. Application presents the results

5. Student is forwarded to library's or retailer's site

Preconditions Lecturer(s) must provide a literature list.

Issues • Persons responsible for a course's administration have

to take care of updating the respective literature list

regularly. Antiquated editions of textbooks are usually

out-of-stock soon which would impair the functional-

ity and benefit of the application.

• Connection to a store (or the library) via APIs may be


4. Use Cases

complex and change overtime. This could be resolved

by allowing only stores which use standardized data

formats like XML.

Additional Inform-

ation

• The WU Library can estimate the demand for text-

books easily using the data of the application and ex-

pand its stock respectively. This use case can be exten-

ded by the functionality described in the use case “Re-

serving books via a mobile device”.

• Additionally the use case “Routing people over the

campus area” can be included to guide the students to

the next nearby store.


4. Use Cases

Use Case Organizing groups

Goal Facilitating the organization of groups and subsequent group

processes

Description Students set up groups by digitally forming them. This hap-

pens either spontaneously with the aim of forming loose

“learning groups” or within a course for “working groups”.

Forming groups can either be achieved by a registration pro-

cess on an mobile web page where a student enters his num-

ber and password to join a group or the formation could be

achieved automatically by placing the phones of the group

members near to each other. An application could detect the

NFC chips in the phones and the group will be created auto-

matically. Group processes are digitally supported (messages,

chat, coordination of physical appointments, retrieving group

assignments, contact to the lecturer). Lecturer(s) can see the

groups and maybe allowed to have full insight to their pro-

gresses.

Actors Students, e-learning server

Stakeholders Students, lecturer(s)

Trigger Events • Lecturer calls on students to form groups, student

want to form or join a learning group

Scenario Steps 1. Student logs in to the application

2. Student sees categories and existing groups with their

status (“full” / “place free”) which may be joined or

can create a new group

IF new group THEN

3a. Student enters the topic the group will focus on

with a description, the number of maximum group

members, a time-line, deadlines (those may be set

dynamically by a lecturer), the preliminary dates

and places of physical meetings

ELSE joining a group

3b. Student can view group details provided by the


4. Use Cases

group leader and request admission

4. Anytime: Group leader can reduce or extend the number

of members or close the group

Preconditions • In case of forming a working group: Student must be

registered for a course

Postconditions • Student joined a group or formed one.

Issues • (Automatic) purging of groups is necessary so that the

virtual groups always represent real ones (for example

by regularly “pinging” the group members). Other-

wise, if there are relics, the respective groups are no

longer really existent and there will be lot of uncer-

tainty which

Additional Inform-

ation

• In order to find a “performing” group or team mem-

ber, additional information like the grade point aver-

age of the group members could be voluntarily

provided.

• Saves time and effort inside a course, because students

can organize their groups themselves via the applica-

tion. There is no further need for lists and track-keep-

ing of groups with respect to changing group mem-

bers.


4. Use Cases

Use Case Asking questions in the Audimax


Description Students who attend large lectures can ask questions via their

smart-phones and vote for asked questions. The question list

is ordered by the vote count. The lecturer answers the most

important questions for example in the last 15 minutes of the

lecture.

Actors Students, lecturer(s), guests

Stakeholders Students, lecturer

Trigger Events • Student has a question and decides to ask it

Scenario Steps 1. Student launches the mobile app

2. The question is entered and submitted

3. Students sees a list with all questions

4. Student votes for the questions which are of importance

to him or her

Issues • Complex questions can not be asked.


4. Use Cases

Use Case Controlling room equipment


Description Presenters control the lightening and ventilation levels, pro-

jector settings, speaker volume and other equipment via their

smart-phones. Predefined “situation profiles” (like “film”,

“presentation”, “night”, “day”) are available but profiles can

also be created by the users. A NFC reader embedded inside

the presenters table detects the smart-phones' NFC hardware

ID in order to authenticate the presenter.

Actors Lecturer(s), students, guests

Stakeholders Lecturer(s), students, guests

Trigger Events • Presenter prepares the presentation

Scenario Steps 1. Presenter places smart-phone near the NFC reader

2. Presenter starts the application

3. Presenter adjusts the settings

3.1 via a profile

3.1 via individual settings

Preconditions • Presenter is authorized to adjust settings

Postconditions • Settings has been changed


4. Use Cases

Use Case Transferring notes from the blackboard


Description It is planned to introduce new teaching methods at the new

WU which make use of modern technology. Digital black-

boards will be available in seminar rooms. The lecturer and

the students can interact with it like with an ordinary black-

board, but dynamic content can be displayed as well. It can

even be used as a computer to access the internet. These new

features may increase the teaching efficiency but they also

make it harder for students to take notes and to record the

contents which are shown to them. The contents of these elec-

tronic blackboards could copied to the mobile phones of the

students automatically at the end of each lesson.

This could be achieved by a software which takes snapshots

regularly or records the whole lecture.

Actors Students, lecturer, classroom server


Trigger Events • The end of a lesson has been reached.

Scenario Steps 1. Lecturer writes on the electronic blackboard

2. A software records the lecture.

3. A file containing the snapshots or the recording is

created automatically.

4. The file or a link to to a server where it will be stored is

transferred on the phones of the students at the end of

the lecture via Blue Tooth or Wireless LAN.

Additional Inform-

ation

• As for today students are stressed with taking an act-

ive part in lessons and copying the contents of the

blackboard at the same time. This results in less con-

centration of the students for the teaching of the lec-

turer. Creating the notes automatically would improve

the attention of the students for the lecture.

• Modern mobile phones possess internal memory in the

range of gigabytes. These capacities can be used to


4. Use Cases

turn phones into mobile storage devices which collect

the contents of each lesson the student attends. This

content can either be viewed on the go by the student

or it can be transferred to the student's computer at

home later.


4. Use Cases

Use Case Retrieving course information on site


Description At the current WU course information can be retrieved by ac-

cessing the WU’s main website and at Learn@WU. However

these two locations sometimes possess different information.

Additionally the student has to navigate step by step though

the websites to get the desired information. NFC readers

could be placed at the entrance of lecture rooms which trans-

mit the identification number of the current course to the mo-

bile devices.

Actors Students


Trigger Events • Student enters course premises

Scenario Steps 1. Student holds smart-phone near a NFC reader which is

located in front of a room where a lecture takes place

2. The smart-phone's browser will be redirected to a

website which offers all the important information for

the user or an application retrieves the information

from the internet.

3. A student sees important (partly personal) information

regarding the lecture on the smart-phone, for example

exam dates or credits for active cooperation

Preconditions • Student is registered for a course, Student is physic-

ally present

Postconditions • NFC readers have to be installed.

Additional Inform-

ation

• All the information can, of course, also be displayed

apart from the premises via a system like Learn@WU

or BACH. The NFC-initiated displaying shall just be a

convenient and quick additional way.


4. Use Cases

Use Case Controlling attendance

Goal Room usage and attendance control

Description In 2011 students still prove their attendance in courses by

signing a paper list which is handed out by the lecturer at each

course date. These lists are a wasted amount of paper and cre-

ate an unnecessary workload for the lecturer in controlling the

attendance of the students manually after each course.

Placing NFC readers at the entrance of a course room simpli-

fies the verification of the attendance of the students.

Actors Students, lecturers, server

Stakeholders Lecturers

Trigger Events • Student attends a course

Scenario Steps 1. Student enters the room

2. Student holds smart-phone near a NFC reader

3. The ID of the smart-phone is read and it is transferred to

the university's authentication server

4. The server compares the smart-phone ID to the re-

gistered IDs of the students enrolled in the course.

IF (ID matches)

5. The student's attendance has been verified.

Preconditions • The smart-phone's ID has to be connected with a stu-

dent ID at the authentication server of the university.

• The student has to be enrolled in the course.

Postconditions • The students attendance has been registered.

Issues • Each mobile phone of the participating students has to

be equipped with a NFC chip.

• The proper function of this service is crucial.

Additional Inform-

ation

• The information gathered by NFC readers about the

actual usage of course rooms helps to calculate the op-

timal allocation of the available rooms to the different

courses for the next semester.


4. Use Cases

4.3 WU-Administration

Use Case Controlling the access of rooms

Goal Security and analysis of usage

Description Mobile phones can serve as key cards for access control.

Phones are equipped with NFC chips. The ID of the phone is

connected to the identity of the user. People who possess

NFC-capable phones may use them instead of authentication

cards or pin codes.

Actors Students, lecturers, WU staff, authentication server

Stakeholders WU administration

Trigger Events • User wants to access a room in the university building

Scenario Steps 1. Mobile phone is placed to the NFC reader at the entrance

of a room

2. ID is submitted to an authentication server

3. Access is granted if the user has the rights to enter the

room

Preconditions • NFC readers have to be installed.

Issues • Security issued may arise if a phone which grants ac-

cess to crucial areas of the campus is lost.


4. Use Cases

Use Case Telephony via wireless LAN

Goal Increase reachability of administrative and scientific staff

Description Staff members connect to the WU telephone system via a

VoIP application, providing an own phone extension for each

mobile user. This way, staff can be reached everywhere via

the WU telephone system on the campus, independent of the

office telephone.

If desired, the connection can also be maintained outside of

the WU campus (e.g. via mobile internet connections like HS-

DPA/HSUPA or via the staff member's home network).

Actors WU staff

Stakeholders WU staff

Preconditions • A staff member has started the VoIP application and

logged into the VoIP system (for example an “Aster-

isk” server)

Postconditions • Staff member can place and receive calls via the WU-

own VoIP system

Issues • Cellular connections could be susceptible to faults in-

side lifts or at certain outside areas of the campus (like

most cellular services).

Additional Inform-

ation

• An WU-own VoIP service decreases communication

costs while at the same time increasing reachability.

• Individual WU staff member may not want to be

reachable persistently, so it must be ensured that the

user can control on-and-off times.


4. Use Cases

4.4 Additional Use Cases

The use cases listed below were also conceived by the authors. They are only de-

scribed briefly because most of these use cases either already occur similarly in the

work of Bayat, Cendik, Durmus, Föls, Tacetdin and Mühlbacher [BCDF11].

Use Case Short Description

Retrieving grades

[BCDF11]

At the moment grades are visible either at Learn@WU

which displays only the ones for the registered courses,

or at the LPIS website which shows all grades of past

courses. This use case presents the idea to merge these

two system and make them accessible for mobile

devices.

Registering for courses

[BCDF11]

Currently registration for courses can only be done over

the LIPS website. The layout of this website is inappro-

priate for the small screen resolutions of mobile

devices.

Announcing news

[BCDF11]

A news feed function which allows the lecturer to send

important messages directly to the students of the spe-

cific course. For example this could be implemented as

a kind of widget which runs on the desktops of the

smart phones.

Conducting a mobile survey

[BCDF11]

Before deciding important decisions which affect life at

the university, the university's administration or the ÖH

could conduct a quick mobile survey to examine the

students and administrative staff's opinion on a topic.

Getting mobile feedback

[BCDF11]

Feedback is gathered from students about the overall

situation at the university using mobile devices.

Creating a mobile univer-

sity calendar

[BCDF11]

Currently the data from the BACH system and from

Learn@WU are not synchronized. Students have to ac-

cess

Mobile Video Streaming

[BCDF11]

Courses are recorded by a web-cam: Students can

stream these records using their mobile devices.


4. Use Cases

Posting questions

[BCDF11]

Students, who a not able to attend a course, could have

the possibility to send questions during to the lecturer

while the course is running. This extends the mobile

video streaming use case.

Mobile chatting and forum

[BCDF11]

Each course has its own chat room and forum which can

easily be accessed with a mobile device.

Catching the subway Much time of people is wasted for waiting. If the user

can be localized and the time of arrival for the next sub-

way trains is known than a software can notify the user

in time for the best moment to leave for the subway.

Using bonuses with NFC If the mobile device has an NFC chip integrated than

this device can be used as a sort of “bonus cart”. The

user would not have to carry around many cards and

stickers for different stores and services (like the “M” in

the university's cafeteria). For example a mobile phone

would be sufficient to replace them all.


5. Implemented Projects

5 Implemented Projects

The following section describes the implementation of two of the use cases men-

tioned in the section above. These two examples will be implemented separately by

the authors.

The first project was handled by Belk Stefan. Its focus lies on implementing an ap-

plication to demonstrate the possibility of a reservation system for learning places

in the WU library. The application is designed to work on mobile devices. Mainly

HTML 4.0 will be used for this purpose. Due to the fact HTML 5.0 is not fully sup-

ported by mobile browsers at the time of the creation of this paper, only elements

which can be processed by the most common mobile browsers will be used.

The second project was created by Dennis Robert Stöhr. It is a mobile app which al-

lows digital questioning inside large lectures. Because it was implemented via the

Android framework, Android powered devices are needed to run the application.



5.1 Mobile Library Reservation System

5.1.1 Introduction

At the library of the current WU learning places are occupied by students using the

policy of first-come, first-served. This policy is sufficient for low and medium de-

mand, but during peak times students waste time searching for free learning places

in the library and some even have to leave the library after not finding a free one.

An online reservation system where the user can decide at which area of the library

a learning station should be reserved can help to reduce the human traffic inside the

library. Students can choose places which are closest to the area where the books of

the desired topic are located.

The information gathered by this system can help the administration of the library

to improve their service.

Figure 5.1: LLC [CAMPWU]

Picture 6.1. shows a rendering of the future learning area inside the library which

will be located in the “Library Learning Center - LLC”. The total amount of learn-

ing places in the LLC is yet unknown during the creation of this paper. Considering

the lack of available learning stations at the current WU library during the last week

before the exams and the increasing amount of students enrolled at the WU, a reser-



vation system for the new library and learning center can help to reduce the number

of students who commute to the university. In this week before the exams many

students have to leave the library for not finding a free learning place. This waste of

time could be prevented by such a system. Students can check the availability of

free learning stations prior to going to the library. In case of a time where learning

places are in high demand students can reserve a learning place for one or more of

the upcoming days.

However this system poses the thread that learning places are reserved by students

but they are not used. So some sort of punishment for unreliable students has to be

introduced as well. An example could be that the user is prohibited from making

any new reservations for a specified period of time. Reducing the maximum

amount of time a person can reserve a learning place can be another possibility to

penalize the abuse of the system.

The example presented in this paper should demonstrate how such an application

could be realized and which problems may occur.

In the following pages the terms “learning place” and “learning station” will occur

several times. These terms are used as synonyms. A learning place or station com-

prises a place where there is a seating, a desk and electronic equipment such as a

light and a power outlet.



5.1.2 Modelling

Three UML modeling tools are used to describe the design of this system, the inter-

actions between its different parts and the interaction with the user.

The Use Case Diagram and the Entity Relationship Diagram were created using the

“Dia Diagram Editor”. A free web tool was used for the Sequence Diagram.

5.1.2.1 Use Case Diagram

Figure 5.2: Use Case Diagram

The system will be used by users such as students who place reservations in times

when there is a high demand of learning places at the library. On the other hand the

library can use the data generated by this system to monitor the utilization of the

learning places. If students prefer learning places at a specific level or area, the lib-

rary can react accordingly. More learning stations can be placed at locations where

there is a high demand and learning places which are rarely used can be removed to

make room for other installations.



5.1.2.2 Sequence Diagram

Sequence diagrams help to understand how the communication between the differ-

ent parts of the system takes place.

For the creation of sequence diagram the free web tool from “http://www.web-

sequencediagrams.com” was used. This tool uses an easy syntax to automatically

create sequence diagrams. An object A sends [ → ] to object B [ : ] a message. For

example: Web-App → Web-Server: HTTP Request.

This tool is used to show the reservation process. Three objects are involved in the

communication – the user, the web-server and the database.

Figure 5.3: Sequence Diagram



User → Web-Server: HTTP request for reservation

Web-Server → Library Database: Reservation(date,

startTime, endTime)

Library Database → Library Database: Avaiability check

Library Database → Web-Server: List of possible

stations on differnt levels

Web-Server → User : HTTP response for level selection


Web-Server → Library Database: Reservation(level)


Library Database → Web-Server: List of possible

stations in different areas

Web-Server → User : HTTP response for area selection


Web-Server → Library Database: Reservation(area)


Library Database → Web-Server: Reservation accepted /

denied

Web-Server → User : HTTP response

The reservation process can be seen as a three step process. First the user asks the

server for a reservation on a specific date and time. The server transmits this request

to the database and asks for a list of learning places ordered by the floors where

these stations are located. Subsequently the user selects the floor where a learning

station should be reserved and sends this information to the server. The database is

asked for a list of all available learning stations at this level which are free during

the reservation time. If this floor contains more than one zone where the user can

reserve a free learning place, the server will request an input from the user to

choose the desired zone. If there is only one zone at the selected floor the server

will place the reservation automatically and the request for the selection of a zone

will be skipped.



The disadvantage of this three step process is that it may take more time than a re-

servation process where all information is entered by the user at once, but it facilit-

ates the selection of a free place. If the user enters the desired date, time, duration,

floor and area at once it may occur that there is no free place available. In this case

the user would have to enter the parameters a second time with a slight change and

try again. This process would be repeated until a free place will be found. Splitting

the reservation process into three steps avoids this inconvenience.



5.1.2.3 Entity Relationship Model

Figure 5.4: Entity Relationship Diagram

The database is modeled via a simple ER model. Five entities are used in this mod-

el. The “User” is the first entity which represents the people who want to use the

system and who place reservations for learning stations. The primary key is an id

which is distributed by the database. The students' register number is not used as a

primary key because the system may also be used by people who are not students.

Therefore the attribute “Number” is used which contains a value. This value may be

a student record number, a library user id, or any other user identification number.

The nature of this number is described as a textual description in the attribute

“type”.

A user places a reservation whose information is stored in the attributes of the entity

“Reservation”. The “date”, “startTime” and the “endTime” are necessary to manage

the reservations for a single learning place. The attribute “unused” is supposed to be

a Boolean value which is set to true by default. This value will only be set to false if

the user makes use of his reservation. The presence of the specific person at the

learning station may be detected with NFC readers for student identification cards

and/or bar-code readers for the library identification cards. If the user who reserved



a learning station does not appear at the station after a predefined time, the reserva-

tion will not be valid any longer and the attribute “unused” will stay true. Users

with a high count of expired reservations may be punished. For example an unreli-

able user may not be able to place a reservation for the next month.

Each reservation is bound to a specific learning station. In the entity “Station” the

information about the location will be stored. The field “level” ranges from two to

fife and represents the different floors of the library inside the LLC. According to

the overview maps [CAMPWU] each floor has at least one self studying zone and

the fifth floor even has five of these zones. In which zone a learning place is located

will be stored in the “area” field. This information will be used in the application to

help the user choosing a free station which is located near the area of the library

where the user wants to sit.



5.1.3 Implementation

5.1.3.1 Database

To test the applications' abilities a temporal database was set up using a mySQL

database. The database is located at the server “xmdimrill.ai.wu.ac.at” from the de-

partment of information management. The database was named “h0750926”. It can

be accessed with the password “h0750926”.

Deducted from the UML modelling of the database which can be seen in section

6.1.2.4 three tables were created.

CREATE TABLE user (

id BIGINT NOT NULL AUTO_INCREMENT,

number INT NOT NULL,

type Text NOT NULL,

PRIMARY KEY (id)

)

The table user stores a “number” value which represents the student record number.

Due the fact that the value “type” contains a description of the stored number differ-

ent kinds of numbers can be stored in the “number” field. Typically student record

numbers would be stored there.

CREATE TABLE reservation (

id BIGINT NOT NULL AUTO_INCREMENT,

date Date NOT NULL,

startTime Time NOT NULL,

endTime Time NOT NULL,

unused boolean NOT NULL,

user_id BIGINT NOT NULL,

station INT NOT NULL,

PRIMARY KEY (id)

)



The field “user_id” contains a reference to the table “user” which corresponds to

the “id” in that table. The same goes for “station” which points to the “id” of the

table “station”.

CREATE TABLE station (

id INT NOT NULL,

floor INT NOT NULL,

area text NOT NULL,

PRIMARY KEY (id)

)

The values “floor” and “area” contain important information where learning places

can be found inside the library. Learning places have to be labeled with a number

that corresponds with the “id” of the learning place. The library will occupy the

levels two to five in the LLC. According to the current layout the levels two to four

will each have one area where learning places will be located. Whereas there will be

five of these areas at the fifth floor. Therefore an additional value named “area” will

be needed. Either these areas will be numbered which can easily be seen by students

inside the library or the field “area” will store a textual description of the learning

place's location.

5.1.3.2 Server

The server which generates the HTML output is an Apache Tomcat 5.0. The source

code which is responsible for the creation of the output was written in Java using

Java Server Pages (JSP). In these “.jsp” files Java code can be mixed with HTML

code. This Java code is translated into Java byte code. When a HTTP request for a

JSP file is sent by a client the Apache Tomcat Server executes the Java Byte Code

and sends the created HTML code back to the client. This offers the advantage to

use the entire functionality of the Java system libraries.



5.1.3.3 Mobile Application

The application is located at the server “xmdimrill.ai.wu.ac.at” and can be ac-

cessed via:

“http://xmdimrill.ai.wu.ac.at:8180/h0750926/bachelor_project/ReservationSystem”

It is written in Java Server Pages which allows the usage of the Java System Library

to dynamically create HTML code. The code below is an example from the “dele-

teReservation,jsp” which removes a reservation from the database. It is shown to

demonstrate how Java Server Pages are structured. The same functionality can also

be achieved by using other programming languages. In the following pages after

this one the Java code will be removed from the important code snippets to improve

readability.

<%@ include file="SQL.jsp" %>

<%@ page import="java.sql.*" %>

<%

/*

Deletes a reservation fro the database.

*/

String user = (String) session.getAttribute("user");

String id = request.getParameter("id");

if(user!=null){ //check if the user is logged in

int res = updateDB("delete from

bachelor_reservation where id="+id);

out.println("<meta HTTP-EQUIV='REFRESH'

content='0; url=myReservations.jsp'>");

}else{

//user not logged in -> redirect

out.println("<meta HTTP-EQUIV='REFRESH'

content='0; url=index.jsp'>");

}

%>

<%@ include file="footer.jsp"%>



It can be seen that the content of this file is a combination of HTML and Java. The

start of the Java code is marked by “<%” tags. The “include file” statement imports

source code form another JSP file. This “SQL.jsp” file contains the code which

helps to communicate with the SQL database. Two functions exist within this

“SQL.jsp”, which provide the functionality to query the database and to add or

change values in the database. Including other JSP files helps to avoid redundancy

and to reduce the programming work by reusing code which is often needed.

The statement “session.getAttribute()” retrieves a session attribute belonging to the

individual session which is stored at the server. In this case the user number with

which the user originally logged into the application and which identifies his reser-

vations in the database is returned.

The statement “request.getParameter()” returns a parameter which was sent via the

HTML request from the client. The parameter “id” is the identification number of

the corresponding reservation for learning place which shall be deleted.

The code “if(user!=null)” checks weather the user is logged in or not. If the user is

not logged in correctly he will be redirected to the log-in page and the reservation

will not be deleted. If the user is logged in the reservation will be deleted and the

user will be redirected to the overview page “myReservations.jsp” where he can see

his remaining reservations.

The “include” code at the bottom inserts the footer from “footer.jsp”. This is done

for the same reason as with “SQL.jsp” at the top.

The “out.println” method prints text to the HTML file which is constructed during

the execution of the Java code and which will be sent to the client afterward.



The application's entry point is located at “index.jsp” where the user has so enter

his number and password. This data will be checked for correctness by using the

functionality of the BACH API which is provided by the WU. Only users who have

passed the security check are allowed to use the system. This check offers the pos-

sibility to assign each reservation to a distinct person. If there was no security check

unused reservations could not be assigned to a distinct person too and therefore

punishment could not be enforced.

Figure 5.5: Entry Point

<HEADER>



<DIV ID="b3k_header_top">

<UL ID="b3k_header_top_nav">

<LI ID="b3k_header_top_nav_home"

CLASS="b3k_firstchild"><A HREF="http://www.wu.ac.at/"

TITLE="Startseite der Wirtschaftsuniversitaet

Wien"><EM>Home</EM></A></LI>

<LI ID="b3k_header_top_nav_apps"><A

HREF="http://bach.wu.ac.at/">Applications</A></LI>

</UL>

</DIV>



</HEADER>

In the header there is a navigation bar which leads to the new central WU web page

for mobile applications. This header is fixed an will be visible on each page of the

reservation system. The “<header>” tag was introduced in HTML 5 and describes

content which should be displayed at the top of a page such as a navigation bar.



Figure 5.6: WU Applications [WUAPPS11]

The layout of this example equates to the new layout of the bach.wu.ac.at web page

which is designed to be used by mobile devices. This site serves as a central access

point for mobile devices an provides links to the most used services of the WU. To

create a similar look and feel the CSS files of this site were included into the ex-

ample's header file “header.jsp” which will be included into every page.

<HEAD>

<META NAME="viewport" CONTENT="width=device-width;

initial-scale=1.0; maximum-scale=1.0">

<TITLE>WU Library App</TITLE>

<LINK REL="stylesheet"

HREF="https://bach.wu.ac.at/3ksd/css/base.css"

MEDIA="all" TYPE="text/css" />

<LINK REL="stylesheet"

HREF="https://bach.wu.ac.at/3ksd/css/datatable.css"

MEDIA="all" TYPE="text/css" />

<LINK REL="stylesheet" HREF="resApp.css" MEDIA="all"

TYPE="text/css" />



The first “<meta>” tag tells the browser to render the site with the display's width.

This prevents the site to be rendered wider than than the screen size and it spares

the user from scrolling sidewards to view the whole page.

The first two “<link>” tags are references to the CSS files of the bach.wu.ac.at web

site. These CSS files basically define the look of the two menu bars at the top of the

page.

The third CSS file is specific for this example and defines the look of the HTML

tables used in the example. Due the usage of foreign CSS files to create a homogen-

ous look of the reservation system only a few lines of code are needed in the applic-

ation's own CSS file.

/*

CSS file for additional styles. Determines the look of

the HTML tables used in the application.

*/

TABLE.resList{

BORDER: 1px solid black;

BORDER-COLLAPSE:collapse;

WIDTH: 100%;

}

TD {

BORDER: 1px solid black;

}

TR.first{

BACKGROUND: #334B68;

COLOR: #fff;

}

footer{

POSITION:fixed;

BOTTOM:0px;

}

This code is responsible for the design of the table used in the overview where the

user can see the reservations which were already placed.



After the security check from the “index.jsp” the browser will be redirected to the

main website where the user can find a navigation menu.

By default the user will be redirected to “myReservations.jsp”. At this page the

user's reservations are listed. It displays the date of the reservation, its starting and

ending time and where the selected learning place is located.

Figure 5.7: Reservation List

By clicking on one of the list elements the location of the selected learning station

will be shown. The library spreads over four floors in the LLC. Each floor of the

library possesses designated “self studying zones” where learning places are loc-

ated. The floors two to four of the LLC only contain one of these zones each, The

fifth floor has five zones.



Students need to know where they can find the reserved learning place. By clicking

on one of the elements in the list, the user will be redirected to the site “reservation-

Info.jsp” where the location of the selected learning place is shown. The area field

of the table bachelor_station in the database contains an integer value which corres-

ponds to the numbers in the picture shown above.



The area in which the reserved learning place is located will be shown as a high-

lighted zone in the overview map of the selected floor. Additionally the user has the

possibility to delete the reservation. For this example application the pictures of the

LLC' floors were taken from campuswu.at .

Figure 5.9: Reservation Detail

Mobile devices can be separated into two major groups. These groups are tables

PCs and smart-phones. Tablet PCs generally are equipped with large screens which

simplifies the design of web pages for these devices. The displays of smart-phones

usually are much smaller than the ones of the tablet PCs. So mobile web sites have

to be designed to cope with the small screen sizes. Menus elements such as the one

in the example application have to merged together into one single button at the top

of the page.



Figure 5.10: Application Drop Down Menu

By clicking onto this button a list of menu items is revealed. The height of the

smart-phones' screens is usually greater than the width, therefore the elements of

this list are shown in a vertical alignment. On devices which posses a screen width

which is big enough to display all of the menu elements, this menu is not shown as

a drop down menu. Instead all menu items are shown simultaneously in a horizontal

list at the top of the page.

When the user decides to place a new reservation by clicking on the corresponding

menu item he will be redirected to “reservationDateTimeChooser.jsp”. This is the

first page in the reservation process.



Figure 5.11: Day & Time Selection

To place a reservation the desired date, time and duration have to be entered. The

next 14 days are listed in the selection menu date. The dates are retrieved from the

database using a SQL query

SELECT DATE_FORMAT( CURRENT_DATE+day, '%a') as

DayOfWeek, DATE_FORMAT( CURRENT_DATE+"+i+", '%d') as

NumberOfDay, DATE_FORMAT( CURRENT_DATE+"+i+", '%b') as

Month ;

This query returns the name of the day, its number (1 to 31) and the current month.

The “day” in the first row of the statement represents an iterator variable which iter-

ates from 1 to 14.

Currently the reservation time ranges from 9 AM to 9:30 PM. The duration of a re-

servation lies between 30 minutes and 6 hours at maximum. These are the opening

hours of the old library. [WULIB11] The closing time of the old library is 10 PM.

Therefore the last time which can be selected in the application is 9:30 PM together

with a maximum duration of 30 minutes.



Additionally a link is provided at the bottom of the page which leads to

“video.jsp”. This page provides an introduction video which shows the user how to

use the web page and how to place a reservation.

Figure 5.12: HTML 5 Video working

This page offers an introduction video which explains how to use the system. The

video content is embedded into the web page by using the new HMTL 5 standard.

HTML 5 defines special “<video>” tag.

<VIDEO class='intro' poster='mobile-img

/video_background.jpg' controls>

<SOURCE src='videos/intro.flv'>

<SOURCE src='videos/intro.mp4'>

<P>Ihr Browser unterst&UUML;tzt leider noch

keine HTML5 Videos! Sry :(</P>

</VIDEO>



If the browser supports HTML 5 video, it will automatically choose the correct

video format from the options in the two different “<source>” tags. Currently

HTML 5 does not specify which video formats web-browsers have to support in

the video tag. [HTML5]

Figure 5.13: HTML 5 Video not working

In figure 5.13 the text “Ihr Browser unterstützt leider noch keine HTML5 Videos!

Sry :(“ can be seen, which is a fallback content. This content is displayed if the

browser does not know the “<source>” tags. Browsers will ignore the unknown tag.

Instead the content which is written between the paragraph “<p>” tags will be

shown.

Other HTML 5 tags such as the “<footer>” tag are used at all visible pages of the

example. This element defines a line at the bottom of the page where important in-

formation like the author of the document, copyright information, links to terms of

use, privacy policy, etc.



After the user has selected the reservation date and time an overview page is loaded.

A query is executed which returns the amount of free learning places for each floor

of the library.

Figure 5.14: Floor Overview

The original source code of this query also contains java code which was removed

for the review of this code snippet for easier readability. Bold characters are Java

variables, whereas normal text represents the SQL code.

select count(id) as freeStations, level, area from

(select id as reservationID, startTime, endTime,

date, station from bachelor_reservation where

(time=startTime and endTime=endTime ) or

(time>startTime and endTime<endTime ) or

(time<startTime and endTime>startTime ) or

(time<endTime and endTime>endTime ) or



(time<startTime and endTime>endTime ) and

date=CURRENT_DATE+"+day+") as tempTable

right join bachelor_station on tempTable.station =

bachelor_station.id where reservationID is null

group by level;

This statement consists of two nested statements. The inner one creates a temporary

table from the table where the reservations are stored. The temporary table now

holds all information about the reservations in the database of the reservations

which collide with the given parameters of the starting and ending time at the given

day. In the outer statement a right join will be performed with the bachelor_station

table and the temporary table. Each station which is occupied at the reservation time

will have a row of valid values. The free learning places on the other hand will be

returned as rows with null values in some of their columns. In the last step the rows

without the null values will be eliminated from the table.

The result will be a table where only the stations which are not occupied at the time

of the new reservation will remain. These learning places are grouped by the floor

where they are located.

By clicking on one of the rows of the HTML table the user can select the desired

floor where a learning place should be reserved.



Figure 5.15: Area Selection

According to the current layout shown at [CAMPWU] the lower levels each only

have one studying area, but the fifth floor has fife areas. Therefore an additional

step is needed for reservations concerning the fifth floor. At this page the user can

choose the area where the learning place should be located. The drop down menu

will only list those areas where stations will be available at the reservation's date

and time.

Two important queries are used in “newReservation.jsp” to create the list of areas

where free learning places are available.

select count(area) as areaCount from (select stationID,

startTime, endTime, date, level, area from (select

bachelor_station.id as stationID ,

bachelor_reservation.id as reservationID,

startTime, endTime, date, level, area from

bachelor_station left join bachelor_reservation on

station=bachelor_station.id) as tempTable where



(time >= endTime or endTime <= startTime or

startTime is NULL) and (date = CURRENT_DATE+day

or date is NULL) and level = level group by area)

as tempTwo;

select stationID, startTime, endTime, date, level, area

from (select bachelor_station.id as stationID ,

bachelor_reservation.id as reservationID,

startTime, endTime, date, level, area from

bachelor_station left join bachelor_reservation on

station=bachelor_station.id) as tempTable where

(time >= endTime or endTime <= startTime or

startTime is NULL) and (date=CURRENT_DATE+day

or date is NULL) and level = level group by

area;

The first statement counts the number of areas where free learning places are avail-

able at the given day and time. The second one returns a list of all theses areas will

will be displayed in the drop down list of the HTML page.

Free stations are determined by comparing the times of the reservations in the data-

base with the starting and ending times of the new reservation. If the starting time

of the new reservation is later than the ending time of all existing reservations of a

learning place than this added to the list of possible free stations. The same goes if

the ending time of the new reservation is earlier than the starting times of the exist-

ing reservations. If there are no reservations at all this learning place can also be

considered as free for the specified date.



Figure 5.16: Reservation Done

After all information was entered a text will be displayed which tells the user if the

reservation was placed successfully or if an error occurred. If the reservation pro-

cess was completed the browser will be redirected to “myReservations.jsp” where

the user can see the recently placed reservation in the list.



5.1.3.4 Learning places

First of all users have to be able to identify which place in the library was reserved

by them. Therefore a number should be assigned to each learning place

Of course if such a system would be introduced there has to be some kind of detec-

tion system to check if the person who placed the reservation really uses it.

Two problems arise with this idea. First, “how can the attendance of the user be

checked” and second “how can other people be informed that learning places are re-

served at a particular time”?

A possible mechanism to check the attendance would be an NFC reader where the

user has to place his student identification card or an NFC-capable smart-phone.

The phones identification number is transmitted to the server where the identity of

the user and the correctness of the reservation can be checked.

Another way to monitor the usage of reserved learning places could be the use of

RFID tags which identify each learning place. The user could place his NFC cap-

able phone next to the tag. A software at the phone reads the tag and transmits the

identofication number to the library server. The server can check the correctness of

the reservation and send a feedback back to the mobile phone.

This identification should happen within the first 30 minutes of the reserved time

otherwise the reservation will be declared invalid and the users misbehavior will be

recorded in the database. If the amount of unused reservations of a single user ex-

ceeds a predefined threshold a punishment could be enforced. An example for such

a punishment could be that the user is prevented from making any new reservations

in the near future. Another way to assure that reserved learning places are not

wasted would be to reduce the time to 15 minutes within the user has to be at the

learning place. If the time is exceeded the reservation will expire automatically and

every other person will be allowed to use the learning place.

An information system will have to be installed in the library, which tells people

who did not place a reservation when and how long a learning place will be free.

Small flat screen monitors could undertake this task. They could be attached to the

learning places or they could be positioned at central places near the self studying

zones.



If these monitors possess touchscreen capabilities they could as well be used for fast

access to the internet. Students could not only see the future reservations but the

could access the library's book reservation system or the library's database to find

literature.



5.1.4 Project Conclusion

The most extensive task in programming a mobile application is to make sure that

the content is rendered correctly at different screen sizes. Attention has to be payed

to the size of the elements which gather input from the user. Especially buttons have

to be rendered large enough so that the user can use them easily. It is also important

to choose the right type of input field. Fields where the user has to enter characters

should be avoided. Instead selection menus could be used.

HTML 5 is not yet fully supported by mobile browsers. This obstacle makes HTML

5 programming time-consuming and error-prone. The figure below shows the sup-

port of the new HTML 5 features by the most common mobile browsers in June

2011.

Figure 5.17: HTML5 Support [caniuse.com]

At the moment Android devices with the most recent operation system version per-

form best in rendering HTML 5 web pages. Anyhow Android 3.0 only supports

61% of the specifications and the other most used mobile browsers perform ever

worse.

While programming a mobile web page which uses HTML 5 the programmer can

either focus on the HTML tags which are fully supported by the major mobile

browsers at the moment or the web server has to determine the type of the client's

browser, which will be used to exclude unsupported tags and assemble the page dif-

ferently to produce the desired output. To achieve an optimal result on different

browsers the second way should be preferred. However due to the fact that HTML 5

is still a working draft changes may occur in the language specification which will

make the maintenance of the code expensive until the development of HTML 5 will

be complete. Secondly the amount of supported HTML 5 tags varies highly between



the different mobile browsers which increases the need for browser specific pro-

gramming and therefore the costs for the creation of such a web application. Addi-

tionally the source code has to be adapted when new updates for these browsers are

released.

Writing a mobile application for web browsers which operate on mobile devices can

also be achieved using HTML 4 and older standards. HTML 5 simplifies this ask

with its innovations such as the easier implementation of video content or the sup-

port of fast drawing operations on canvas objects.

Anyhow programmers have to decide if they want to use HTML 5 now which may

result in certain incompatibilities on different mobile web browsers or if they want

do implement the application without the new features and integrate them later

when HTML 5 is fully supported.

In the end a few questions have to be taken into account before the implementation

of such a reservation system.

• Which technology should be used?

• How can users be prevented from abusing the system?

Different approaches can be used to resolve the in the implementation. The most

appropriate solution depends on the requirements of the WU administration, the in-

frastructure and the available time of the programmers for implementing this sys-

tem.



5.2 Audimax Query Tool

5.2.1 Introduction

As a second implementation we have chosen our use case “Asking questions in the

Audimax”. Of course, this tool can also be used in any environment with a high

number of participants.

A basic problem for individual participants is that they have, due to their high over-

all number, only a limited chance of getting a request to speak in order to pose one

or more questions. Besides this, one may assume that students are often shy or

anxious because they think their questions may be irrelevant or the matter is per-

fectly being understood by other students. Good questions, possibly being of in-

terest also to others, may therefore not being asked.

The application is relatively simple from a user's point of view. It allows to enter

one or more questions in a text field and posts them to a database. All users can see

all the posted questions real-time in a list and tap on those which are of interest to

them, which will increase the respective individual vote counts. The application

ranks questions accordingly to their vote counts. This way, questions, which are of

interest for many participants, show up first. The lecturer may either reserve a time

frame at the end of a lecture or regularly check the question list in order to get feed-

back or to answer the highly ranked questions.

It was programmed for Android devices, but an implementation in HTML, for ex-

ample, would also be possible. This may even increase the user base because all

mobile operating systems do have a browser pre-installed and no further software

would be needed, only an URL would have to be accessed.

The primary reason why this project was implemented via the Android framework

was the author's intention to further extend his Android programming knowledge.

Also, as shown in chapter 2.2, Android has a very positive tendency regarding its

rate of dissemination which, the author suspects, may last for the immediate future.

While working on this implementation the following versions were used:

• Release number of the Android SDK: 11

• Installed Android API-Level: 10, revision 1

• Version of the ADT plugin: 11.0.0.v201105251008-128486



• Version of Eclipse: 1.4.0.20110615-0550

• Build id of Eclipse: 20110615-0604

The next chapter 5.2.2 provides a visual introduction to the application. Thereafter

the programming structure is represented by various UML diagrams in chapter

5.2.3. The implementation is explained in the subsequent chapter 5.2.4. The conclu-

sion will be covered in the last chapter 5.2.5.

To fully understand all programming concepts following chapter 5.2.3, it is recom-

mended to get known to the basics of Android programming. One of the authors has

composed an introductory seminar paper [Stoe11] on this topic.

5.2.2 “Look and Feel” of the Query Tool

When the user starts the application, an opening screen is displayed, as shown in

figure 5.18.

The user gets to the input mask for posing a question by tapping on the first button

(“Ask a question”). Figure 5.19 shows how it looks.


Figure 5.18: Opening screen


After a question has been entered, the user can still correct or adjust it. Multi-line

input is supported, so that the user is not restricted in regards to the length of the

question. When the question is ready the user can submit it by tapping on the “Post

question” button and is informed by a text popup. The text input field is emptied

and a new (follow-up) question can instantly be written and posted. To quit ques-

tioning and return to the opening screen, the user presses or taps on the Android

devices “Return” hard- or soft-button, which is normally labeled with a rounded ar-

row (as can be seen on the emulator on the right side of figure 5.19).

The second button hosted by the opening screen (“List and rate questions”) leads to

a list where all posted questions are displayed and where questions can be rated by

tapping on them. A representation is given by figure 5.20. The list contains exem-

plary questions from a fictitious economics lecture in the Audimax, which could

have been posted by students of such a lecture.

If the user has set a nickname in the application's configuration (configuring the ap-

plication is explained shortly), it will be assigned to questions when posted and is

then shown below the respective questions in the list. If provided, the lecturer (but


Figure 5.19: Asking questions


also other students, “for good or for bad”) can later see who asked and check back

or can give credits to students for good questions.

By tapping on a question, the vote count will be increased and the question “walks

up” to the top of the list. Figure 5.20 also shows the application in the state when

the user taps on a question. The question on top got 34 votes, the next one 21 votes

and the user now votes for the question with number 4 and a current vote count of

20. Each user has one vote per question. In order to return to the opening screen, the

Android “Return” button has to be pressed.

By pressing the Android devices “Menu” hard- or soft-button, the application can

be configured (see figure 5.21). Via the first option (“Select your lecture hall”) the

user has to select one out of three halls (see figure 5.22): “Audimax”, “Festsaal” or

“Aula”. Posting and listing questions is dependent on this selection. The second op-

tion (“Enable vibration” when a new question was asked) is only a dummy and was

not fully implemented. Via the third option, the user can set a nickname which will

be assigned to each posted question (see figure 5.23). If no room is selected (this is

the case when the application is freshly installed), the user gets prompted to config-

ure the application when trying to ask a new question (see figure 5.24).


Figure 5.20: Listing and voting for questions



Figure 5.21: Configuration screen

Figure 5.22: Selecting a lecture hall



Figure 5.24: Prompt to configurate

Figure 5.23: Setting a nickname


The opening screen's “About” button simply displays some authoring information

about the application (see figure 5.25) .

The “Exit” button will close the application.

From a technical perspective, the buttons start so called Android activities which

handle the respective tasks, as described by the button labels. All details can be

found in the project implementation documentation (see chapter 5.2.4).

5.2.3 Modeling

In this chapter, three types of UML diagrams graphically present the functional,

structural and sequential views of the Query Tool application.

In chapter 5.2.3.1, a use case diagram shows the functionality that the Query Tool

provides the user.

The class diagram in chapter 5.2.3.2 gives a blueprint of the application's program-

ming structure. It also shows which parts of the Android framework are being util-

ized by the Query Tool.

In chapter 5.2.3.3, a sequence diagram reflects how the application's system parts

are operating with one another.


Figure 5.25: About screen


5.2.3.1 Use case diagram

As set forth by figure 5.26, the system offers the user the possibility to write and

post questions, which are then stored in a database (use case “Post questions”). The

precondition for this use case is that the user has done the lecture hall configuration.

The scenario steps are:

1) The user taps on the “Ask a question” button.

2) The system displays the input mask.

3) The user enters the question and taps on the “Post question” button.

4) The system performs the insertion of the question into the database.

Furthermore, the system offers the user a question list. Firstly, this list allows the

user to see all questions with their vote counts (use case “View questions”) and

secondly, the user can vote for listed questions (use case “Rate questions”). The pre-

condition is again that the lecture hall configuration has been done. The scenario

steps for both use cases are:

1) The user taps on the “List and rate questions” button.

2) The system displays a list with all questions asked.

3) (Additional) If the user taps on specific questions, the respective vote counts

will increase.

The “Database”, represented as an actor in the diagram, “is provided” the storage

and management of the pool of questions.



5.2.3.2 Class diagram

Figure 5.27 outlines the Java classes and interfaces which make up the Query Tool.

On the left-hand side, those interfaces of the Android framework are positioned

which have been implemented by certain classes of the project. Those

(super-)classes of the Android framework which have been extended are displayed

on the right-hand side. The project's custom classes can be found in the middle.

According to [Holu11], who provides a quick reference of the guidelines of the offi-

cial Object Management Group's “UML 2.0 Superstructure Final Adopted specifica-

tion” [OMG03], the attributes and operations of each class or interface are listed

with a prefixed plus for public or minus for private visibility. Then the format is as

follows: Name of the attribute or operation (in the latter case with the expected

parameter's data types listed inside round brackets appended), followed by a colon

and the data type of the attribute (or in case of an operation, the data type which is

returned by the operation).

The project's complete source code is listed and explained in detail in chapter 5.2.4.

For the purpose of an abstract overview, the following list points out the main pur-

pose of each class.

• Queries.java takes care of the opening screen. It displays the WU

logo, a heading and the selection buttons (see figure 5.18). The application's con-

figuration (called “shared preferences” in Android) is also accessed from within

this view.

• Config.java implements the configuration view (see figures 5.21,

5.22 and 5.23).

• About.java sets up a small information dialog about the application,

its version and the author.

• DbHelper.java and DbConst.java provide the database con-

nectivity.

• Query Tool's main functionality is implemented in the classes Ask-

ing.java and Listing.java. The former handles the input of new ques-

tions (see figure 5.19), while the latter sets up the questions asked list and

provides the rating mechanism (see figure 5.20).



Of course, the Activity.java class and certain more specific child classes (ListActiv-

ity.java and PreferenceActivity.java) of Android are being extended by most of

Query Tool's classes. SQLiteOpenHelper.java is extended by DbHelper.java.


Figure 5.27: UML Class Diagram


5.2.3.3 Sequence Diagram

Figure 5.28 shows how the classes (resp. objects) interact with one another.

The events, occurring in chronological order in the sequence diagram, shall repres-

ent those actions of an user first trying out the application. This means that the con-

figuration has to be done first of all. Afterwards, the user composes and posts a

question and then views all questions and votes for some of them. Finally, the user

views the application's authoring information via the “About” button.


Figure 5.28: UML Sequence Diagram


The Queries activity is the starting point of the project, represented by the left-

most life line.

First of all the user configures the application and therefore presses the Android

“Menu” button. A MenuInflater object is created to display a menu list, con-

taining only one item called “Configuration” according to the respective XML re-

source menu.xml. When it is touched by the user, the Config activity is started

which reads its configuration (e.g. its layout, items, default values) from the XML

resource config.xml and displays a so called Preference Screen to the user

where the application's settings can be adjusted. The preferences (this is the Android

term for settings the user sets) are stored as a XML file and therefore, no message is

sent back to the Queries object. Note that in respect to the Android life cycle, all

of the project's activities (resp. objects), once they were created, cease to exist only

if the operating system decides so due to of lack of memory, over-utilization and the

like. This is visualized in the sequence diagram by the long tails that extend down

to the bottom.

Next, the user selects the “Ask a question” button and the Asking activity is star-

ted. It immediately instantiates the DbHelper class for database connectivity.

After a question was entered and the user wants to post it, a query looks up if an

identical question got already posted. After this check, the question is inserted into

the database with the respective hall (must have been set) and nick name (if avail-

able).

Then the user selects the button “List and rate questions”. Once again, the database

helper class is immediately instantiated. The hall name is retrieved from Queries

and a database query is performed which returns all questions for the respective

hall. They are presented to the user via data binding, in this case the SimpleCurs-

orAdapter is being used. If the user touches a question, the vote count for that ques-

tion is updated in the database and the list of questions is refreshed (visualized by

the arrow which points back).

Finally, the user selects the button “About” and the About activity is started which

simply displays the authoring information as a dialog.



5.2.3.4 Entity Relationship Model

The database schema as used by the Query Tool is represented by the E-R diagram

in figure 5.29.

A single entity (resp. table) called “Question” holds all the relevant data as attrib-

utes. The problem with this design is that anomalies can easily occur. Deleting a

question (resp. row) from the “Questions” table will not only remove the question's

text, but also all other attributes like the author, the time that the question was

asked, the rank of the question and so forth (= deletion anomaly). More information

gets lost then expected. This could produce follow-up errors and distort statistical

analysis or logging. Update anomalies can occur for example when the author

changes his or her nick name. Every question (resp. row) has to be updated separ-

ately, which increases system load and the likelihood of failures. The insertion an-

omaly does not occur, because no NOT NULL constrains have been specified

(meaning that an all-empty set of attributes can theoretically be inserted).

Besides these anomalies, the data is also redundant, e.g. the hall name, author and

rank are physically stored multiple times in the database.

This are classical database design problems. As a try to avoid anomalies and re-

dundancy, the database schema could also be designed the way it is shown in figure

5.30.


Figure 5.29: E-R Diagram of the database


In this data design approach, the hall and author attributes have become entities and

are related to questions via a ternary relationship type. Each hall and author must

only be stored once.

5.2.4 Implementation

This chapter introduces the project's source code and explains it following the se-

quence shown in figure 5.28 in part.

The project's file tree is shown in figure 5.31.

• The Java class files are located in the directory src/.

• The R.java file holds references to resources and is located in gen/. It

is not listed in the following because it is generated automatically by the Android

development environment.

• The project's resources are located in the res/ directory. Android re-

sources are for example images, layouts and values (e.g. strings or arrays). The

idea behind this is that it makes the application easier adaptable, for example by

simply changing the string values to another language or defining layouts for dif-

ferent screen sizes without the need to adapt the Java source code. The standard

format for these data is XML.

• The AndroidManifest.xml “presents information about the applica-

tion to the Android system” [ADev11a]. The file basically described the compon-

ents of the application, this are, in case of the Query Tool, solely activities.


Figure 5.30: Revised E-R Diagram of the database


5.2.4.1 AndroidManifest.xml

As a good starting point, it is best to begin the code documentation with the pro-

ject's manifest file AndroidManifest.xml (see figure 5.32).


Figure 5.31: Project skeleton


The attributes of the <manifest> element specify the XML namespace, the pro-

ject's package and versioning information about the Query Tool. As this is the first

programming version, android:versionCode is set to “1”, but it is the de-

veloper's choice which integer to begin with. android:versionName is a string

that is presented to the user, in respect to this project it will identify itself as “Query

Tool 1.0”. If the application is developed further, the version code would increase to

the number “2” and the version name to “1.1” or “2.0”, for example.

The next element <application> has two attributes: android:icon for the

Query Tool's icon, which is being displayed on the devices application menu or

home screen. android:label holds the name of the application, which is “WU

Query Tool”, via a reference to the XML data file res/values/strings.xml

that can be found in appendix 8.2.

Note that the values of these attributes are pointers to the drawable resource (the

icon) and string value (the application's name). As explained before, this detour fa-

cilitates adaptations without the need to modify the source code directly but only

the XML data. The auto-generated R.java indexes all resources and provides

these human-readable linking shortcuts. For illustration purposes, this is the extract


<?xml version="1.0" encoding="utf‐8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"package="at.ac.wu.wise2011s.android" android:versionCode="1"android:versionName="1.0">

<application android:icon="@drawable/icon" android:label="@string/app_name">

<activity android:name=".Queries" android:label="@string/app_name"android:screenOrientation="portrait"><intent‐filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /></intent‐filter>

</activity>

<activity android:name=".Asking" android:label="@string/ask_title"android:theme="@android:style/Theme.Dialog" />

<activity android:name=".Listing" android:label="@string/list_title" />

<activity android:name=".About" android:label="@string/about_title"android:theme="@android:style/Theme.Dialog" />

<activity android:name=".Config" android:label="@string/config_title" />

</application>

</manifest>

Figure 5.32: AndroidManifest.xml


of the two respective entries in the R.java file. The integer values are the Android

internal references and not human-readable.

public static final class drawable { public static final int icon=0x7f020000; }

public static final class string { public static final int app_name=0x7f070000; }

Inside the <application> element are the activities definitions of the Query

Tool. These are the opening screen (.Queries), the asking and listing screens

(.Asking and .Listing), the authoring information dialog (.About) and the

configuration screen (.Config).

An activity is “a single, focused thing that the user can do. Almost all activities in-

teract with the user, so the Activity class takes care of creating a window […].”

[ADev11b]

Activities have a name (the class name), a label and additional attributes like the

screen orientation or the applied theme if any (figures 5.19 and 5.25 show how the

applied “Dialog” theme for .Asking and .About looks).

The <intent-filter> specified for the .Query activity hold two elements,

<action> and <category>. The following citation of the Android Developers

website explains the purpose of these elements: “Activities that can initiate applica-

tions have filters with "android.intent.action.MAIN" specified as the ac-

tion. If they are to be represented in the application launcher, they also specify the

"android.intent.category.LAUNCHER" category […]. The standard

MAIN action is a main entry point (not requiring any other information in the

Intent), and the LAUNCHER category says that this entry point should be listed in

the application launcher.” [ADev11c]

5.2.4.2 Queries.java

The Queries activity is the entry point (resp. opening screen) of the Query Tool.

Figure 5.33 shows its source code.

The class extends the Android Activity class and implements the OnClick-

Listener interface.




package at.ac.wu.wise2011s.android;

import java.util.ArrayList;

import android.app.Activity;import android.content.Context;import android.content.Intent;import android.os.Bundle;import android.preference.PreferenceManager;import android.view.Menu;import android.view.MenuInflater;import android.view.MenuItem;import android.view.View;import android.view.View.OnClickListener;import android.widget.Toast;

public class Queries extends Activity implements OnClickListener {private static ArrayList<Long> alreadyVotedIds;

public void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.main);

alreadyVotedIds = new ArrayList<Long>();

View askButton = findViewById(R.id.button_ask);askButton.setOnClickListener(this);View listButton = findViewById(R.id.button_list);listButton.setOnClickListener(this);View aboutButton = findViewById(R.id.button_about);aboutButton.setOnClickListener(this);View exitButton = findViewById(R.id.button_exit);exitButton.setOnClickListener(this);

}

public void onClick(View view) {switch (view.getId()) {case R.id.button_ask:

if (getHall(this) == "")Toast.makeText(getBaseContext(),

"Please configure the application first!",Toast.LENGTH_LONG).show();

else {Intent iAsking = new Intent(this, Asking.class);startActivity(iAsking);

}break;

case R.id.button_list:Intent iListing = new Intent(this, Listing.class);startActivity(iListing);break;

case R.id.button_about:Intent iAbout = new Intent(this, About.class);startActivity(iAbout);break;

case R.id.button_exit:finish();

}}

public static ArrayList<Long> getAlreadyVotedIds() {return alreadyVotedIds;

}

public boolean onCreateOptionsMenu(Menu menu) {super.onCreateOptionsMenu(menu);MenuInflater inflater = getMenuInflater();inflater.inflate(R.menu.menu, menu);return true;

}


A private ArrayList called alreadyVotedIds is initialized which is used

later to store the IDs of the questions the user has voted for in order to ensure the

rule “one vote per question per user”. Solely the onListItemClick method of

the Listing activity (see chapter 5.2.4.6) gets a handle on this ArrayList and

operates on it.

The onCreate method, which is called by the Android system when the activity is

created, calls the onCreate method of the superclass and sets up the screen layout

according to the definition in the res/layout/main.xml data file, referenced

by "R.layout.main" via the R.java indexer. This layout can be seen in figure

5.18 and the res/layout/main.xml code is listed in appendix 8.2. For details

on the layout data file's elements and attributes, please refer to [Stoe11] or the offi-

cial Android Developers website.

Next, the ArrayList is initialized. Note that the content of the ArrayList is

persistent during the OS runtime because of the applications life cycle. This means

even if the user switches to another Android application, the Query Tool keeps run-

ning in the background and the onCreate method would not be called again on

return. Only if Android kills the application due to system overload or the device is

being restarted, the ArrayList content gets lost, because no saving mechanism is


public boolean onOptionsItemSelected(MenuItem menuItem) {switch (menuItem.getItemId()) {case R.id.config:

startActivity(new Intent(this, Config.class));return true;

}return false;

}

public static String getHall(Context context) {return PreferenceManager.getDefaultSharedPreferences(context)

.getString("hall", "");}

public static boolean vibrationIsEnabled(Context context) {return PreferenceManager.getDefaultSharedPreferences(context)

.getBoolean("vibration", false);}

public static String getNickname(Context context) {return PreferenceManager.getDefaultSharedPreferences(context)

.getString("nickname", "");}

}

Figure 5.33: Queries.java


implemented. OnCreate would be called again and the ArrayList is being ini-

tialized. In a real use environment, this would enable the user to cheat on the voting

count restriction.

The next instructions set up the onClick functionality for the opening screen's

buttons via the View class method setOnClickListener. For each button,

firstly a handle to the respective button is created (also look for the button specifica-

tions in the res/layout/main.xml in appendix 8.2 - this is where the buttons

actually originate). Secondly, the button's setOnClickListener method is

called. The parameter "this" tells the method that the onClick method of the

Query instance shall be called when the button is touched.

The onClick method consists of a switch statement which branches contain the

statements that are executed for the relevant button. The control variable is the ID

of the button. In case of the “Ask a question” button (= button_ask), it is veri-

fied if the lecture hall was set by the user in the application's configuration. This is

done by calling the getHall method which returns a hall name as a string (the

getHall method is explained at the end of this chapter). If that string is empty, a

Toast object will be used to display the text “Please configure the application

first!” (see figure 5.24). If a hall is set, the Asking activity is invoked and dis-

played via an Intent. For the other buttons, no checks are done and the respective

activities are directly invoked. The “Exit” button simply calls the finish method

of the Activity superclass. This is a bit unconventional because it is contradict-

ory to the concept of the Android application life cycle. Normally, a user leaves an

Android application by pressing the Android “Return” button and the operating sys-

tem takes care of the application's running state (it quits the Query Tool if memory

runs out for example). No application programmed by the Android developers do

have an exit button. The author nevertheless inserted the button, because users may

expect it.

The getAlreadyVotedIds method simply returns the ArrayList

alreadyVotedIds. It is used by the Listing activity. The reason why the list

is not directly implemented there is to keep its contents when the user switches to

other activities (for example asking a new question and returning to the list later).



The onCreateOptionsMenu method takes care of the menu which is shown

when the user presses the Android “Menu” hard- or soft-button while the opening

screen is being displayed. For this, a MenuInflater object is instantiated by call-

ing the activity's getMenuInflater method. In the next step, it is instructed to

inflate the contents of the res/menu/menu.xml data file. In this project,

there is only one option item called “Configuration” (refer to

/res/menu/menu.xml in appendix 8.2).

The functionality when touching the “Configuration” item of the options menu is

implemented in the method onOptionsItemSelected. The Config activity

is then started (see figures 5.21, 5.22 and 5.23). The way Android applications store

and retrieve preferences is explained in the following chapter 5.2.4.3 where the

Config activity is covered.

Finally, the getHall, getNickname and vibrationIsEnabled methods

use the Android PreferenceManager to get relevant parts of the application's

shared preferences which were set via the user's interaction with the Config activ-

ity.

5.2.4.3 Config.java

Figure 5.34 shows the source code of the Config activity. It extends the Pref-

erenceActivity class, which is a specialization of the Activity class (or

rather the ListActivity class, which extends the Activity class). Its purpose

is to “show a hierarchy of preferences to the user” [ADev11d], which are added

from the res/xml/config.xml data file (see appendix 8.2) via the addPref-

erencesFromResource method. This is where the configuration screen, shown

in figure 5.21, is being established.



import android.os.Bundle;import android.preference.PreferenceActivity;

public class Config extends PreferenceActivity {

protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);addPreferencesFromResource(R.xml.config);

}

}

Figure 5.34: Config.java


In the res/xml/config.xml data file, there is twice the element Prefer-

enceCategory. Such an element has a heading and encapsulates a sets of prefer-

ences, for example all settings regarding the lecture hall. Here it is solely a List-

Preference, displaying a list from which the user has to select the hall. The

items of that list come from a string-array which is defined in res/val-

ues/halls.xml (see appendix 8.2). The second PreferenceCategory col-

lects the settings for personal preferences. It contains two items, a CheckBox-

Preference to set vibration either to enabled or disabled, and an EditText-

Preference where the user can set a nick name.

The PreferenceActivity superclass takes care of storing the preferences, and

that is the reason why the Query Tool's Config activity (as an extension) is so

compact.

Figure 5.35 shows where the superclass stores the shares preferences on a device's

file system. It is saved in XML format in the applications data directory

/data/data/at.ac.wu.wise2011s.android in the file at.ac.wu.-

wise2011s.android_preferences.xml of the sub-directory

shared_prefs/.

This is also from where the PreferenceManager, which is utilized when the

need arises to fetch user settings, retrieves the values.


adb shell

# cd /data/data/at.ac.wu.wise2011s.androidcd /data/data/at.ac.wu.wise2011s.android

# lslsshared_prefslib

# cd shared_prefscd shared_prefs

# lslsat.ac.wu.wise2011s.android_preferences.xml

# cat at.ac.wu.wise2011s.android_preferences.xmlcat at.ac.wu.wise2011s.android_preferences.xml<?xml version='1.0' encoding='utf‐8' standalone='yes' ?><map><string name="nickname">Dennis Robert Stoehr</string><string name="hall">Audimax</string></map>#

Figure 5.35: Shared preferences


5.2.4.4 DbHelper.java and DbConst.java

Before code documentation can proceed to the Asking and Listing activities,

this chapter takes a glance at the DbHelper class and DbConst interface.

Query Tool uses the Android on-board SQLite DBMS to store question data into a

database. For this, a helper class is implemented (DbHelper extending SQL-

iteOpenHelper) which represents this database.

The DbConst interface holds the description of the database (that is its table and

field names) in static fields so that all package classes can retrieve the database de-

scription centrally from that interface. Instead of inheriting from the interface,

Query Tool's classes use static imports which are possible since Java 5.0. This way,

the so called “Constant Interface Antipattern” is avoided. Refer to [Orac11] for

more details on this.

Figure 5.36 shows the DbConst interface which extends BaseColumns. It holds

the name of the TABLE storing the questions and the fields' names for the HALL,

the QUESTION's text, NICKNAME, the TIME and RANK (= vote count) as constant

string values. Inherited fields from BaseColumns are _COUNT and _ID with the

respective constant string values "_count" and “_id”.

The DbHelper class is listed in figure 5.37. It extends the SQLiteOpenHelp-

er, which provides database creating and management functionality. As already

mentioned, the database description from the DbConst interface is imported. The

database file name is stored as a String constant (DATABASE_NAME) and the ver-

sion as an integer constant (DATABASE_VERSION). If the database design would

change (for example, a new column would be added), the version number is needed

to be increased.



import android.provider.BaseColumns;

public interface DbConst extends BaseColumns {public static final String TABLE = "questions";

public static final String HALL = "hall";public static final String QUESTION = "question";public static final String NICKNAME = "nickname";public static final String TIME = "time";public static final String RANK = "rank";

}

Figure 5.36: DbConst.java


This constants are then passed to the constructor of the superclass from within the

DbHelper constructor, which then starts to manage the database, if it exists.

In case the database queries.db does not exist, the superclass calls the onCre-

ate method which is overwritten by the DbHelper class. The execSQL method

executes a SQL CREATE TABLE statement on a new database. This sets up the ini-

tial table with the columns (_ID, HALL, etc.), the data types (INTEGER or TEXT)

and constraints (PRIMARY KEY, AUTOINCREMENT, NOT NULL).

If DATABASE_VERSION changed, the superclass calls the overwritten onUp-

grade method. The implementation of this method is just to DROP the old table

and call the onCreate method in order to recreate the database according to the

new description. Note that the database contents get lost with this implementation.

The methods getReadableDatabase and getWritableDatabase, which

are inherited from the superclass, can be called to get a handle on the database



import android.content.Context;import android.database.sqlite.SQLiteDatabase;import android.database.sqlite.SQLiteOpenHelper;

import static android.provider.BaseColumns._ID;import static at.ac.wu.wise2011s.android.DbConst.TABLE;import static at.ac.wu.wise2011s.android.DbConst.HALL;import static at.ac.wu.wise2011s.android.DbConst.QUESTION;import static at.ac.wu.wise2011s.android.DbConst.NICKNAME;import static at.ac.wu.wise2011s.android.DbConst.TIME;import static at.ac.wu.wise2011s.android.DbConst.RANK;

public class DbHelper extends SQLiteOpenHelper {private static final String DATABASE_NAME = "queries.db";private static final int DATABASE_VERSION = 1;

public DbHelper(Context context) {super(context, DATABASE_NAME, null, DATABASE_VERSION);

}

public void onCreate(SQLiteDatabase database) {database.execSQL("CREATE TABLE " + TABLE + " (" + _ID

+ " INTEGER PRIMARY KEY AUTOINCREMENT, " + HALL+ " TEXT NOT NULL, " + QUESTION + " TEXT NOT NULL, " + NICKNAME+ " TEXT, " + TIME + " INTEGER NOT NULL, " + RANK+ " INTEGER NOT NULL);");

}

public void onUpgrade(SQLiteDatabase database, int oldVersion,int newVersion) {

database.execSQL("DROP TABLE IF EXISTS " + TABLE);onCreate(database);

}

}

Figure 5.37: DbHelper.java


where it is needed. In case of the Query Tool, the classes Asking and Listing

are working with the database and call this methods.

5.2.4.5 Asking.java

Assuming that the application was configured beforehand, the Asking activity is

started as soon as the user touches the “Ask a question” button. Figure 5.38 shows

the source code of that activity.

Like the Query activity, it extends the Activity class and implements the On-

ClickListener interface. A DbHelper is declared for class-wide usage.

When the activity is first created, the layout is set to the specifications in

res/layout/asking (see appendix 8.2 for the code or figure 5.19 for a graph-

ical representation). It consists of an EditText element (for editing the questions)

and a Button element (for submitting the questions). The button's functionality is

added in the usual way by creating a handle on the button via its ID and calling its

onClickListener method. Finally, the DbHelper object is created and stored

in the dbh variable for later database operations.



import android.app.Activity;import android.content.ContentValues;import android.database.sqlite.SQLiteDatabase;import android.os.Bundle;import android.view.View;import android.view.View.OnClickListener;import android.widget.EditText;import android.widget.Toast;

import static at.ac.wu.wise2011s.android.DbConst.TABLE;import static at.ac.wu.wise2011s.android.DbConst.HALL;import static at.ac.wu.wise2011s.android.DbConst.QUESTION;import static at.ac.wu.wise2011s.android.DbConst.NICKNAME;import static at.ac.wu.wise2011s.android.DbConst.TIME;import static at.ac.wu.wise2011s.android.DbConst.RANK;

public class Asking extends Activity implements OnClickListener {private DbHelper dbh;

public void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.asking);

View askButton = findViewById(R.id.askButton);askButton.setOnClickListener(this);

dbh = new DbHelper(this);}

public void onPause() {super.onPause();dbh.close();

}


When the user has finished posting questions and quits the Asking activity, it is

important to close the database so that all changes are committed and to avoid inter-

ference when the database is opened by another activity (e.g. switching to the

Listing activity, where the questions are displayed and voted for). This is en-

sured by

• overwriting the onPause method (called when the user leaves the activity)

and calling the close method of the DbHandler instance.

• overwriting the onResume method (called when the user returns to the

activity) and re-instantiating the DbHandler.


public void onResume() {super.onResume();dbh = new DbHelper(this);

}

public void onClick(View view) {String question = ((EditText) findViewById(R.id.askInput)).getText()

.toString();if (view.getId() == R.id.askButton && !question.isEmpty()) {

postQuestion(question);((EditText) findViewById(R.id.askInput)).getText().clear();

}}

private void postQuestion(String question) {SQLiteDatabase db = dbh.getWritableDatabase();

if (db.query(TABLE, null, QUESTION + "=" + "'" + question + "'", null,null, null, null).getCount() != 0) {

Toast.makeText(getBaseContext(),"Exact same question has already been posted!",Toast.LENGTH_LONG).show();

return;}

ContentValues values = new ContentValues();values.put(HALL, Queries.getHall(this));values.put(QUESTION, question);values.put(TIME, System.currentTimeMillis());values.put(RANK, 0);

if (Queries.getNickname(this) != "")values.put(NICKNAME, Queries.getNickname(this));

db.insertOrThrow(TABLE, null, values);db.close();

Toast.makeText(getBaseContext(), "Your question was posted!",Toast.LENGTH_LONG).show();

}

}

Figure 5.38: Asking.java


In the onClick method, the question's text, which was entered into the Edit-

Text widget, is stored as a String object. The widget provides a getText

method that returns an Editable object. This object contains the text which can

be obtained as a string via the toString method, but also provides methods for

altering it (e.g. insert, replace, append or delete). The following if-

statement checks if the source of the event was the “Post question” button

(askButton) and if the EditText actually contains a text. In case both is true,

the String object containing the question's text is handed over to the

postQuestion method and the EditText widget is emptied by calling its

clear method.

The postQuestion method takes care of inserting the question and its meta data

into the database. For this, an instance of the database is created by calling the

getWritableDatabase method of the DbHandler object.

The following if-clause checks if the question is already in the database, in case

someone else submitted the exact same text. This query is the control statement of

the if-clause. It returns a Cursor object with the resulting rows, on which the

getCount method is invoked to determine the number of rows. If that row count

is not zero, it indicates that the question already exists (in that case the row count is

“1”, the control statement returns the boolean value TRUE and the if branch is

entered). A Toast object is created to inform the user, and the method execution is

aborted by the return statement (without reaching the point where the question is

being inserted into the database a second time). The schema of the table does not

have a UNIQUE constraint on the question column, so it would be possible to

insert the same question multiple times, but this is not desired, of course. The ques-

tion would be listed repeatedly in the Listing activity.

If no equal question exists, the insertion is prepared by creating a ContentVal-

ues object which encapsulates the question's (meta) data. The HALL is retrieved

from the getHall method of the Queries class, the text of the QUESTION

comes from the method's argument, the TIME is determined by calling a static Java

System class method and the RANK is initially set to zero. Another if-clause

checks if the user set a nick name (optional) by calling getNickname of the

Queries class and storing it as the value NICKNAME in the ContentValues



object. Finally, the data is inserted into the database using the SQLiteDatabase

object's method insertOrThrow, the database is being closed and the user is

informed by another Toast object.

5.2.4.6 Listing.java

The Listing activity manages the presentation of questions to the user and also

provides the possibility to vote for individual questions. Only those questions from

the database content are displayed which originated from the hall the user has selec-

ted in the Query Tool's configuration. The questions are listed in descending order

of vote count.

Figure 5.39 shows the source code of the Listing activity.



import android.app.ListActivity;import android.content.ContentValues;import android.database.Cursor;import android.database.sqlite.SQLiteDatabase;import android.os.Bundle;import android.view.View;import android.widget.ListView;import android.widget.SimpleCursorAdapter;import android.widget.Toast;

import static android.provider.BaseColumns._ID;import static at.ac.wu.wise2011s.android.DbConst.TABLE;import static at.ac.wu.wise2011s.android.DbConst.HALL;import static at.ac.wu.wise2011s.android.DbConst.QUESTION;import static at.ac.wu.wise2011s.android.DbConst.NICKNAME;import static at.ac.wu.wise2011s.android.DbConst.RANK;

public class Listing extends ListActivity {private static String[] COLUMNS = { _ID, QUESTION, NICKNAME, RANK };private static String ORDER_BY = RANK + " DESC";private static int[] TARGET = { R.id.identifier, R.id.question,

R.id.nickname, R.id.rank };

private DbHelper dbh;

public void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.listing);setTitle(getTitle() + " from within " + Queries.getHall(this));

dbh = new DbHelper(this);

showQuestions(getQuestions());}

public void onResume() {super.onResume();dbh = new DbHelper(this);

}

public void onPause() {super.onPause();dbh.close();

}


The extended ListActivity class “displays a list of items by binding to a data

source such as an array or Cursor, and exposes event handlers when the user selects

an item.” [ADev11e] The data binding is set up by the showQuestions method,

which is covered shortly.

There are three class-wide variables. The first static String array named COLUMNS

holds, as the name suggests, the columns for which the database will be queried

later. The SQLiteDatabase's query method (used in the method getQues-

tions) is just a more convenient way to query the database (instead of executing a

SQL statement directly) and accepts a String[] object as a parameter to specify

the columns to be returned. In figure 5.20 it can be seen that a list item contains the


private Cursor getQuestions() {SQLiteDatabase db = dbh.getReadableDatabase();Cursor cursor = db.query(TABLE, COLUMNS,

HALL + "=" + "'" + Queries.getHall(this) + "'", null, null,null, ORDER_BY);

startManagingCursor(cursor);return cursor;

}

private void showQuestions(Cursor cursor) {SimpleCursorAdapter adapter = new SimpleCursorAdapter(this,

R.layout.item, cursor, COLUMNS, TARGET);setListAdapter(adapter);

}

public void onListItemClick(ListView listView, View view, int position,long id) {

if (Queries.getAlreadyVotedIds().contains(id))return;

SQLiteDatabase db = dbh.getWritableDatabase();Cursor cursor = db.query(TABLE, new String[] { RANK }, _ID + "=" + "'"

+ id + "'", null, null, null, null);

cursor.moveToNext();int currentRank = cursor.getInt(cursor.getColumnIndex(RANK));

ContentValues values = new ContentValues();

values.put(RANK, currentRank + 1);

if (db.update(TABLE, values, _ID + "=" + "'" + id + "'", null) == 1) {Queries.getAlreadyVotedIds().add(id);Toast.makeText(getBaseContext(),

"Question with ID " + id + " has been voted up!",Toast.LENGTH_SHORT).show();

}

showQuestions(getQuestions());}

}

Figure 5.39: Listing.java


vote counts on top of the question's text, the question's text itself as well as the au-

thor and ID of the question below it.

The second static String ORDER_BY specifies in what order the database shall re-

turn the resulting rows of the query, and that order is set to be descending by the

RANK value (which is the vote count).

The integer array TARGET is later used in the showQuestions method for bind-

ing the questions' data to the single list items. The specified target elements for the

data can be found in res/layout/item.xml (see appendix 8.2), where the

look of a single list entry is defined.

Storing parts of the SQL query statement and the target for data binding in variables

allows easier modifications and makes the source code more readable.

When the Listing activity is first opened (and the onCreate method is called),

the layout is set according to res/layout/listing.xml (see appendix 8.2)

and the activity's title is set to be “Listing questions from within” with the name of

the currently configured hall being appended (see figure 5.20). The getTitle

method is inherited from the superclass and returns “Listing questions” (defined in

AndroidManifest.xml as the default label of the Listing activity). Next, a

DbHelper object is created like in the Asking activity for database operations.

Finally, the list is populated by calling showQuestions(getQuestions()).

The getQuestions call is evaluated first. It gets a handle on the database (this

time only readable instead of writable) and performs a query for all questions

where the hall in the question row equals the hall configured by the user. The third

argument of the query method is a filter and is expected to be a String holding

text in SQL syntax (without the “WHERE” clause). Because ORDER_BY was stated

(as the last argument), the resulting question rows are stored in the Cursor object

in descending order of the RANK column value. The startManagingCursor

method is inherited from the superclass and takes care about the life of the Cursor

object in respect to the activity life cycle. This is not really needed because the on-

Pause and onResume methods close and re-instantiate the Cursor, but using

this method is actually how cursor management in an Activity should be implemen-

ted. Finally, the Cursor is returned to the calling method and passed on as a para-

meter in the showQuestions method call.



The showQuestions method instantiates a SimpleCursorAdapter which

maps the columns' values from the passed-in Cursor object to the elements of the

list item defined in res/layout/item.xml (see appendix 8.2). The Adapter

is then provided for the list view via the setListAdapter method.

Now all questions are being displayed to the user as shown in figure 5.20, but the

list does not yet have the rating functionality. This is implemented by overriding the

onListItemClick method. When a question item is touched by the user, the su-

perclass calls this method and passes along, inter alia, the row id of the item (the

question) that was touched. The first instruction is an if-statement that checks if

this id already exists in the Queries' ArrayList. If so, this would mean that

the user already voted for the question and method execution is aborted by calling

the return statement. After this check, a handle on the database is created (writ-

able) and a query is executed. The resulting Cursor only contains the RANK

column (the vote count) of the question where the id equals the row id. The

moveToNext method moves the Cursor to this entry. This is necessary because

initially the Cursor is positioned before its first row entry. Then, the value of the

RANK column is stored into a auxiliary integer variable using the Cursor's

getInt method and a ContentValues object is created which stores the new

value for the RANK column (old vote count plus one). The following if-statement

executes the update to the database as its control statement. It stores the new vote

count by overwriting the RANK column value of the question row where again the

id equals the row id. If the result of the control statement is TRUE (the SQLite-

Database update method returns the number of rows affected by the update

which is checked to be “1”), the id is added to the alreadyVotedIds Ar-

rayList. A Toast object informs the user that the vote was successful. Finally,

the question list is refreshed by calling showQuestions(getQuestions())

again.

5.2.4.7 About.java

The About activity is a simple dialog that shows the authoring information of the

Query Tool (see figure 5.25 for a graphical representation).



As can be seen in figure 5.36, only the respective layout is set up from res/lay-

out/about.xml (see appendix 8.2). In the AndroidManifest.xml, the “Dia-

log” theme is applied to the About activity. The text that is appearing is stored in the

res/values/string.xml data file as a <string> element named

about_text.



import android.app.Activity;import android.os.Bundle;

public class About extends Activity {

public void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.about);

}

}

Figure 5.40: About.java


5.2.5 Project Conclusion

The Query Tool was programmed by the author who has a little more than half a

year of casual experience in Android programming as of the date of writing. What

this shows is that a basic Android application with quite useful functionality is not

hard to develop.

A experienced Android developer could make a more extensive use of the rich API

which the Android application framework provides and enrich the Query Tool by

implementing capabilities like location detection based on WLAN access points'

MAC addresses, NFC readers (e.g. positioned in front of each lecture hall) or via

the interpretation of QR tags (which could be printed on lecture notes or the hall

time table).

The use of semantic analysis could detect identical questions and purge the query

list. Keeping in mind that this are lectures of large size, it would also allow statistic-

al analysis which could further increase the lecture quality by adapting the lecture's

content presentation to include regularly asked questions.

Besides such extension possibilities, there are fundamental adaptions that has to be

made when using the Query Tool in a real environment:

• The database has to be set up centrally. Due to its demonstration purpose,

the present implementation uses the Android on-board SQLite DBMS.

• A mechanism to archive and clear the question list has to be added that is,

for example, automatically executed according to a lecture hall's timetable.

• Because not every lecturer does have a mobile device (in this case it must

even be an Android one) or wants to use it, the Query Tool must inform the

students that digital asking is not possible during such a lecture's timeframe.

• A bad-words filter could be implemented.

It is also useful to consider if the Android or any other device-specific framework is

an appropriate basis for implementing such a tool. It restricts its use to a certain

group of students and lecturers. The better choice would be to use HTML, which is

supported by browsers which are virtually available on every device.


6. Conclusion

6 Conclusion

After studying the WU's different IT services, the authors have come to the conclu-

sion that the services should be accessible from a central access point. Currently

there are two main web pages. The main web page of the WU and “Learn@WU”.

Many services which are used by students, employees or other stakeholders are only

accessible by navigating through various sub-menus of these pages. The important

services and applications should be listed at a distinct location where the user can

find them easily.

The new “WU Applications” web page at “bach.wu.ac.at” is a first step in the right

direction to give the users a central entry point to their applications.

Currently the ideas for the development of new applications originate from the de-

velopment teams themselves. It may be useful to include the users into this idea

generating process. Surveys could be conducted to collect input from the students

and employees for new applications which could be useful for their daily life at the

university.

There are many different applications which can facilitate studying and working at

the university. From a technological perspective, most applications can be imple-

mented without much effort. Mainly a client/server architecture is needed, but some

of them may also need special hardware such as NFC devices or RFID chips which

should be installed during the building phase of the new WU to avoid future modi-

fication work.

Furthermore, there is a need for special personnel which develops and maintains

these applications so that the university's applications follow a consistent standard.

Design guidelines concerning the look and feel of these applications should also be

established in order to help users to get along with new applications.


7. References

7 References

[IEEE11] N/A: IEEE 802.11 WIRELESS LOCAL AREA NETWORKS. Institute of

Electrical and Electronics Engineers, Inc., 20. http://www.ieee802.org/11/, as of May

21th, 2011.

[Blue11] N/A: Bluetooth Basics. Bluetooth SIG, 2011.

http://www.bluetooth.com/Pages/Basics.aspx, as of May 30th.

[ADev11] N/A: Android Bluetooth API. Android Developers, 2011.

http://developer.android.com/guide/topics/wireless/bluetooth.html, as of May 26th,

2011.

[Frau11] N/A: Was ist ZigBee?. Frauenhofer IIS, 2011.

http://www.iis.fraunhofer.de/bf/med/sens/zigbee/zigbee_was/, as of May 30th, 2011.

[Ambr11] Luca de Ambroggi: NFC and Bluetooth: Complementary or Competitive? .

IHS iSuppli Market Research, 2011. http://www.isuppli.com/automotive-infotainment-

and-telematics/marketwatch/pages/nfc-and-bluetooth-complementary-or-competitive-

both-offer-distinct-advantages-for-users-in-vehicles.aspx, as of June 3rd, 2011.

[Wiki11] N/A: Uses of Near field communication. Wikipedia, 2011.

http://en.wikipedia.org/wiki/Near_field_communication#Uses, as of June 3rd, 2011.

[Aste11] N/A: About The Asterisk Project. Asterisk website, 2011.

http://www.asterisk.org/asterisk, as of June 5th, 2011.

[HeMu04] Martin Herfurt, Collin Mulliner: Blueprinting. trifinite.group, 2004.

http://trifinite.org/Downloads/Blueprinting.pdf, as of June 6th, 2011.

[HaSK04] Mike Hazas, James Scott, John Krumm: Location-AwareComputing

Comes of Age. Microsoft Research, 2004. http://research.microsoft.com/en-

us/um/people/jckrumm/Publications%202004/lac%20final.pdf, as of June 7th, 2011.

[Linn10] Claudia Linnhoff-Popien: WLAN Positioning. LMU München, 2010.

http://www.mobile.ifi.uni-

muenchen.de/studium_lehre/verg_semester/ws1011/msp/08_wlan_positioning.pdf, as

of June 8th, 2011.

[Niel11] N/A: Who is Winning the U.S. Smartphone Battle?. nielsenwire, 2011.

http://blog.nielsen.com/nielsenwire/online_mobile/who-is-winning-the-u-s-

smartphone-battle, as of March 26th, 2011.


7. References

[NFCWORLD] Unkown Authors: nearfieldcommunicationsworld.com.

nearfieldcommunicationsworld.com, 2011.

http://www.nearfieldcommunicationsworld.com/nfc-phones-list/, .

[CAMPWU] Projektgesellschaft Wirtschaftsuniversität Wien Neu GmbH:

campuswu.at. , 2011. http://www.campuswu.at/, .

[WUIT00] WU, Unknown Authors: ARBEITSPAPIER IT-BASIERTE SERVICES

AM CAMPUS WU V2.7 IN PROGRESS. , 2011.

[Baudisch, et al.] Baudisch, P., Cutrell, E., Robbins, D., Czerwinski, M., Tandler, P.,

Bederson, B., et al.: Drag-and-Pop and Drag-and-Pick: techniques for accessing

remote screen content on touch- and pen-operated systems.. Microsoft Research,

Redmond, WA; Fraunhofer IPSI, Darmstadt, Germany; HCIL, University of Maryland,

MD; Maila Push, Darmstadt, Germany, 2003. ISBN:

[WUOfficeMedia11] WU, unknown Authors: NEUBAU WU CAMPUSBeschreibung

eines multimedialen Lehr- und Lernarrangements,welche Anforderungen an zukünftige

Lernräume erfüllt. , 2011.

[Zeitler09/10] Zeitler Wolfgang: NEW WU: NEW CONCEPTS AND

APPLICATIONS FOR LECTURING INFRASTRUCTURES. , 2011.

[BCDF11] Bayat, Cendik, Durmus, Föls, Mühlbacher, Tacetdin: Adaptierung der

Lernumgebung Learn@WU für mobile Endgeräte. WU Wien, 2011.

[LEARNWU] Unkown Authors: Mobile Learn@WU. , 2011. https://learn.wu.ac.at/, .

[WUdoo Facebook] WU, unkown Authors: WUdoo Facebook. , 2011.

http://www.facebook.com/wudoo.mobile, .

[fh-kaernten.at] FH Kaernten: Fachhochschule Kärnten -studentsLife – iPhone App

für Studierend. , 2011. http://www.fh-

kaernten.at/aktuelles/newsdetails/article/studentslife-iphone-app-fuer-studierende.html,

.

[androidzoom.com] : WUdroid - Android. , 2011.

http://de.androidzoom.com/android_applications/productivity/wudroid_lrdk.html, .

[HaNe09] Hansen, Hans Robert; Neumann, Gustaf: Wirtschaftsinformatik 1. UTB,

Stuttgart, 2009. ISBN: 9783825226695


7. References

[Cole98] Coleman, Derek: A Use Case Template draft for discussion. Hewlett

Packard Software Initiative, 1998. http://www.bredemeyer.com/pdf_files/use_case.pdf,

as of April 11th, 2011.

[OMG05] N/A: Unified Modeling Language Specification , Version 1.4.2 formal/05-

04-01. Object Management Group, 2005.

http://www.omg.org/spec/UML/ISO/19501/PDF/, as of April 11th, 2011; Note: This

specification is also available from ISO as ISO/IEC 19501.

[WUAPPS11] : WU Applications. , 2011. bach.wu.ac.at, .

[WULIB11] Wirtschaftsuniversität Wien: Library Opening Hours. , 2011.

http://www.wu.ac.at/library/about/openinghours, .

[HTML5] W3C, Unknown Authors: The video element - HTML5. , 2011.

http://www.w3.org/TR/html5/video.html, .

[caniuse.com] caniuse.com: Compatibility tables for support of HTML5, CSS3, SVG

and more in desktop and mobile browsers.. , 2011. http://caniuse.com, .

[Stoe11] Stoehr, Dennis Robert: Introduction to Android Programming. WU Vienna,

2011. http://wi.wu-

wien.ac.at:8002/rgf/diplomarbeiten/Seminararbeiten/2011/201102_Stoehr/201102_Sto

ehr_AndroidProgramming.pdf, as of June 16th, 2011.

[Holu11] Allen I. Holub: UML Quick Reference. , 2011.

http://www.holub.com/goodies/uml/, as of June 21th, 2011.

[OMG03] Object Management Group: UML 2.0 Superstructure Final Adopted

specification. , 2003. http://www.omg.org/cgi-bin/doc?ptc/2003-08-02, as of June

21th, 2011.

[ADev11a] N/A: The AndroidManifest.xml File. Android Developers, 2011.

http://developer.android.com/guide/topics/manifest/manifest-intro.html, as of June

24th, 2011.

[ADev11b] N/A: public class Activity. Android Developers, 2011.

http://developer.android.com/reference/android/app/Activity.html, as of June 24th,

2011.

[ADev11c] N/A: Intents and Intent Filters. Android Developers, 2011.

http://developer.android.com/guide/topics/intents/intents-filters.html, as of July 24th,

2011.


7. References

[ADev11d] N/A: PreferenceActivity. Android Developers, 2011.

http://developer.android.com/reference/android/preference/PreferenceActivity.html, as

of June 26th, 2011.

[Orac11] Oracle: Static Import. JDK 5.0 Documentation, 2010.

http://download.oracle.com/javase/1,5.0/docs/guide/language/static-import.html, as of

June 27th, 2011.

[ADev11e] N/A: ListActivity class. Android Developers, 2011.

http://developer.android.com/reference/android/app/ListActivity.html, as of June 28th,

2011.


8 Appendix – Source Code

8.1 Project 1: Mobile Library Reservation System

header.jsp

<!DOCTYPE html><html lang="de">

<head>

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0"><title>WU Library App</title>

<link rel="stylesheet" href="https://bach.wu.ac.at/3ksd/css/base.css" media="all" type="text/css" /><link rel="stylesheet" href="https://bach.wu.ac.at/3ksd/css/datatable.css" media="all" type="text/css" />

<link rel="stylesheet" href="resApp.css" media="all" type="text/css" />

</head>

<header><div id="b3k_header_top"> <ul id="b3k_header_top_nav"> <li id="b3k_header_top_nav_home" class="b3k_firstchild"><a href="http://www.wu.ac.at/" title="Startseite der Wirtschaftsuniversitaet Wien"><em>Home</em></a></li> <li id="b3k_header_top_nav_apps"><a href="http://bach.wu.ac.at/">Applications</a></li> </ul> </div></header>

footer.jsp

<footer><p><br>Bachelor thesis application example by Stefan Belk, June 2011.</footer>

index.jsp

<%@ include file="header.jsp"%>

<body><h3>WU-Biblothek Reservierungssystem</h3>

<form class='Login' action=loginVerify.jsp>

Matrikelnummer: <br><input type="text" name=nr> <br>Passwort: <br><input type=password name=pwd><p>

Belk/Stöhr, June 2011 CXVI

<input type=submit value=LOGIN></form>

</body><%@ include file="footer.jsp"%></html>

loginVerfy.jsp

<%@ include file="/idb1/shop/SQL.jsp" %><%@ page import="java.sql.*" %><%@ page import="java.lang.Integer" %><%

String nr = request.getParameter("nr"); String pwd = request.getParameter("pwd");boolean authentic = false;

/*At this point a connection to the WU's database should be established to check the usersnumber and password. If the database returns that the entered password is valid the booleanvariable authentic should change to true.After a conversdation with Mathias Frey it was decided that this login should remaina dummy login.*/

authentic = true;nr = nr.replaceAll("h", "");

if(authentic == true && nr!=null && pwd!=null){ ResultSet res = queryDB("select id from bachelor_user where number="+new Integer(nr)); if(res.next()){ //registered user -> set session attribute for identification session.setAttribute("user", res.getString("id")); out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=myReservations.jsp'>");

}else{ //new user -> add to database + set session attribute updateDB("insert into bachelor_user(number, type) values("+nr+"+,'matrNr')"); session.setAttribute("user", nr); out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=myReservations.jsp'>"); }

}else{

out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");}%>

myReservations.jsp

<%@ include file="SQL.jsp" %><%@ page import="java.sql.*" %><%@ include file="header.jsp"%>

<script type="text/javascript">

Belk/Stöhr, June 2011 CXVII

function ChangeColor(tableRow, highLight) { if (highLight) { tableRow.style.backgroundColor = '#dcfac9'; } else { tableRow.style.backgroundColor = 'white'; } }

function DoNav(theUrl) { document.location.href = theUrl; }</script>

<%String self = request.getParameter("self");%>

<body><div id="b3k_contentarea_header"> <div id="b3k_contentarea_header_nav"> <ul <% if(self!=null && self.equals("true")) { out.println("class=\"b3k_menumode\">"); }else{ out.println(">"); } %>

<li class="b3k_firstchild b3k_active"> <a href="myReservations.jsp?self= <% if(self!=null && self.equals("true")) { out.print("false"); }else{ out.print("true"); } %> " title="Meine Reservierungen">Meine Reservierungen</a> </li> <li class="b3k_lastchild"> <a href="reservationDateTimeChooser.jsp" title="Neue Reservierung">Neue Reservierung</a> </li>

<li class="b3k_lastchild"> <a href="logout.jsp" title="Logout">Logout</a> </li> </ul> </div></div>

<%String user = (String) session.getAttribute("user");

if(user!=null){

Belk/Stöhr, June 2011 CXVIII

ResultSet res = queryDB("select bachelor_reservation.id as resID, date, startTime, endTime, station, level, area from" +" bachelor_reservation, bachelor_station" +" where user_id='" + user +"' and station = bachelor_station.id and" +" date>=CURRENT_DATE order by date");

out.println("<h3>Zeile ausw\u00E4hlen um Details zu sehen:</h3>"); out.println("<p><table class='resList'>"); out.println("<tr class='first'><td>Datum<td>Beginn<td>Ende<td>Stock<td>Bereich<td>Station");

while (res.next()) { //add script for highlight to table String script = "onmouseover='ChangeColor(this, true);' onmouseout='ChangeColor(this, false);' onclick='DoNav(" +"\"reservationInfo.jsp?station="+res.getString("station")+"&reservation="+res.getString("resID") +"\");' ";

out.println("<tr "+script+"><td>"+res.getString("date")+ "<td>"+res.getString("startTime")+ "<td>"+res.getString("endTime")+ "<td>"+res.getString("level")+ "<td>"+res.getString("area")+ "<td>"+res.getString("station") ); }//while end}else{

out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");

}%></table>


reservationInfo.jsp


<%/*Displays information about a specific reservation. And shows the floor map where the station is located.*/

String self = "false"; //request.getParameter("self");%>

<body>



<div id="b3k_contentarea_header"> <div id="b3k_contentarea_header_nav"> <ul>

Belk/Stöhr, June 2011 CXIX

<li class="b3k_firstchild b3k_active"> <a href="myReservations.jsp?self= <% if(self!=null && self.equals("true")) { out.print("false"); }else{ out.print("true"); } %> " title="Meine Reservierungen">Meine Reservierungen</a> </li> <li class="b3k_lastchild"> <a href="reservationDateTimeChooser.jsp" title="Neue Reservierung">Neue Reservierung</a> </li>

<li class="b3k_lastchild"> <a href="logout.jsp" title="Logout">Logout</a> </li> </ul> </div></div>



<%

String station = request.getParameter("station");String reservation = request.getParameter("reservation");String user = (String) session.getAttribute("user");

if(user!=null){ ResultSet res = queryDB("select * from bachelor_reservation where id="+reservation); ResultSet res2 = queryDB("select * from bachelor_station where id="+station);

res.next(); res2.next();

out.println("<p><table class='resList'>"); out.println("<tr class='first'><td>Datum<td>Beginn<td>Ende<td>Stock<td>Bereich<td>Station"); out.println("<tr><td>"+res.getString("date")+ "<td>"+res.getString("startTime")+ "<td>"+res.getString("endTime")+ "<td>"+res2.getString("level")+ "<td>"+res2.getString("area")+ "<td>"+res2.getString("id") );

out.println("</table><p>"); out.println("<form class='search' action='deleteReservation.jsp'>"); out.println("<input type='hidden' name='id' value='"+res.getString("id")+"'/>"); out.println("<input type='submit' value='Stornieren'/>"); out.println("</form>");

out.println("<hr><p><h2>"+res2.getString("level")+". Stock</h2>"); out.println("<img src='mobile-img/level"+res2.getString("level")+"explained.jpg' border='0' width='350' height='410'>");

Belk/Stöhr, June 2011 CXX

}else{

out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");

}%>


seleteReservation.jsp

<%@ include file="SQL.jsp" %><%@ page import="java.sql.*" %>

<%/*Deletes a reservation fro the database.*/

String user = (String) session.getAttribute("user");String id = request.getParameter("id");

if(user!=null){ //check if the user is logged in

int res = updateDB("delete from bachelor_reservation where id="+id); out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=myReservations.jsp'>"); }else{ //user not logged in -> redirect out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");

}%><%@ include file="footer.jsp"%>

video.jsp

<%@ include file="header.jsp"%><%/*This pages demonstrated HTML 5 video within the application.*/

String user = (String) session.getAttribute("user");if(user==null){ //redirect if the user is not logged in out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");}%>

<body><div id="b3k_contentarea_header"> <div id="b3k_contentarea_header_nav"> <ul> <li class="b3k_firstchild"> <a href="myReservations.jsp" title="Meine Reservierungen">Meine Reservierungen</a> </li>

Belk/Stöhr, June 2011 CXXI

<li class="b3k_lastchild b3k_active"> <a href="reservationDateTimeChooser.jsp?self=false" title="Neue Reservierung">Neue Reservierung</a> </li>

<li class="b3k_lastchild"> <a href="logout.jsp" title="Logout">Logout</a> </li> </ul> </div></div>

<p><video class='intro' poster='mobile-img/video_background.jpg' controls> <source src='videos/intro.flv'> <source src='videos/intro.mp4'> <p>Ihr Browser unterstützt leider noch keine HTML5 Videos! Sry :(</p></video>


reservationDateTimeChooser.jsp


<%/*This is the first page which is loaded at the beginning of a new reservation process.The user can enter the desired date */

String self = request.getParameter("self");String user = (String) session.getAttribute("user");

if(user==null){ out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");}%>

<body>

<div id="b3k_contentarea_header"> <div id="b3k_contentarea_header_nav"> <ul <% if(self!=null && self.equals("true")) { out.println("class=\"b3k_menumode\">"); }else{ out.println(">"); } %> <li class="b3k_firstchild"> <a href="myReservations.jsp" title="Meine Reservierungen">Meine Reservierungen</a> </li>

Belk/Stöhr, June 2011 CXXII

<li class="b3k_lastchild b3k_active"> <a href="reservationDateTimeChooser.jsp?self= <% if(self!=null && self.equals("true")) { out.print("false"); }else{ out.print("true"); } %> " title="Neue Reservierung">Neue Reservierung</a> </li>

<li class="b3k_lastchild"> <a href="logout.jsp" title="Logout">Logout</a> </li> </ul> </div></div><h2>

<form class='search' action=freeStationsOnDate.jsp><p>Datum: <select name="day">

<%//creates the options of the select tag

for(int i=0; i<14; i++){

ResultSet res = queryDB("SELECT DATE_FORMAT( CURRENT_DATE+"+i+", '%a') as DayOfWeek, "+ "DATE_FORMAT( CURRENT_DATE+"+i+", '%d') as NumberOfDay, "+ "DATE_FORMAT( CURRENT_DATE+"+i+", '%b') as Month ;"); res.next(); out.println("<option value='"+i+"'>" +res.getString("DayOfWeek")+", "+res.getString("NumberOfDay")+". "+res.getString("Month")+"</option>");

}

%></select><br>

Uhrzeit:<select name="time"> <% for(int t=9; t<22; t++){ out.println("<option value='" +t+ "00'>" +t+ ":00</option>"); out.println("<option value='" +t+ "30'>" +t+ ":30</option>"); } %></select><br>

Dauer:<select name="duration">

Belk/Stöhr, June 2011 CXXIII

<% for(int t=0; t<=6; t++){ if(t!=0) out.println("<option value='" +t+ "00'>" +t+ ":00</option>"); if(t!=6) out.println("<option value='" +t+ "30'>" +t+ ":30</option>"); } %></select>

<br><p>

<input type="submit" value="Suchen" /></form>

</h2><p>

<a href="video.jsp">Wie reserviere ich? - Videoanleitung</a></body>

<%@ include file="footer.jsp"%></html>

freeStationsOnDate.jsp


//javascript for highlighting the table's rows<script type="text/javascript"> function ChangeColor(tableRow, highLight) { if (highLight) { tableRow.style.backgroundColor = '#dcfac9'; } else { tableRow.style.backgroundColor = 'white'; } }

function DoNav(theUrl) { document.location.href = theUrl; }</script>


<body>

<div id="b3k_contentarea_header"> <div id="b3k_contentarea_header_nav"> <ul <% if(self!=null && self.equals("true")) { out.println("class=\"b3k_menumode\">");

Belk/Stöhr, June 2011 CXXIV

}else{ out.println(">"); } %> <li class="b3k_firstchild"> <a href="myReservations.jsp" title="Meine Reservierungen">Meine Reservierungen</a> </li> <li class="b3k_lastchild b3k_active"> <a href="reservationDateTimeChooser.jsp?self= <% if(self!=null && self.equals("true")) { out.print("false"); }else{ out.print("true"); } %> " title="Neue Reservierung">Neue Reservierung</a> </li>

<li class="b3k_lastchild"> <a href="logout.jsp" title="Logout">Logout</a> </li> </ul> </div></div><h2>

<%//retrieving the parameters transmitted in the URL

String user = (String) session.getAttribute("user");String day = request.getParameter("day");String time = request.getParameter("time");String duration = request.getParameter("duration");

if(user!=null){ Integer t = new Integer(time) + new Integer(duration); //change the time values into integer values if(t%100 == 60) t = t + 40 ; //if the time+duration contains a 60 at the end, the hour is rounded up using +40 String endTime = null; if(t<1000){ endTime = "0"+t.toString(); //adding 0 to get the time format 00:00 if it was in 0:00 }else{ endTime = t.toString(); } //change endTime to match xx:yy endTime = endTime.substring(0, 2)+":"+endTime.substring(2);

//change time to match xx:yy if(new Integer(time)<1000){ time = "0"+time; } time = time.substring(0, 2)+":"+time.substring(2);

Belk/Stöhr, June 2011 CXXV

if(t<=2200){ //time maximum is 22:00 = 10 PM which is the maximum opening hour of the library //reservations can only be placed if the opening hour is not exceeded ResultSet res = null;

out.println("<p><table class='resList'>"); out.println("<tr><td>");

res = queryDB("SELECT DATE_FORMAT( CURRENT_DATE+"+day+", '%a') as DayOfWeek, "+ "DATE_FORMAT( CURRENT_DATE+"+day+", '%d') as NumberOfDay, "+ "DATE_FORMAT( CURRENT_DATE+"+day+", '%b') as Month ;"); res.next(); out.println("<table>"); out.println("<tr class='first'><td>"+res.getString("DayOfWeek")+ ", "+res.getString("NumberOfDay")+". "+res.getString("Month")); out.println("<td>"+time+" - "+endTime); out.println("</table>");

//returns the free learning stations to the given date and time at the given level

String sql = "select count(id) as freeStations, level, area from "+ "(select id as reservationID, startTime, endTime, date, station from bachelor_reservation where "+ "('"+time+"'=startTime and '"+endTime+"'=endTime ) "+ "or ('"+time+"'>startTime and'"+endTime+"'<endTime ) "+ "or ('"+time+"'<startTime and'"+endTime+"'>startTime ) "+ "or ('"+time+"'<endTime and'"+endTime+"'>endTime ) "+ "or ('"+time+"'<startTime and'"+endTime+"'>endTime ) "+ "and date=CURRENT_DATE+"+day+") as tempTable "+ "right join bachelor_station on tempTable.station = bachelor_station.id "+ "where reservationID is null group by level" ;

ResultSet res2 = queryDB(sql); out.println("<tr><td>Gew"+"\u00FC"+"nschtes Stockwerk anklicken:"); out.println("<tr><td>"); out.println("<table>"); out.println("<tr class='first'><td>Stock<td>freie Pl"+"\u00E4"+"tze"); //creates the table for the differnt levels while(res2.next()){ String script = "onmouseover='ChangeColor(this, true);' onmouseout='ChangeColor(this, false);' onclick='DoNav(" +"\"newReservation.jsp?level="+res2.getString("level")+"&day="+day+"&time="+time +"&endTime="+endTime +"\");' ";

int free = 0; free = res2.getInt("freeStations"); out.println("<tr "+script+"><td>"+res2.getString("level")+"<td>"+free); }

Belk/Stöhr, June 2011 CXXVI

out.println("</table>");

}else{ //if time exceeds 24h out.println("<h2>Zeitangabe ung\u00FCltig!</h2>"); out.println("<meta HTTP-EQUIV='REFRESH' content='2; url=reservationDateTimeChooser.jsp'>"); }

}else{ //if user is not logged in -> redirect out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");

}%></table></body><%@ include file="footer.jsp"%></html>

newReservation.jsp

<%@ include file="SQL.jsp" %><%@ page import="java.sql.*" %>

<%@ include file="header.jsp"%>


<body>

<div id="b3k_contentarea_header"> <div id="b3k_contentarea_header_nav"> <ul <% if(self!=null && self.equals("true")) { out.println("class=\"b3k_menumode\">"); }else{ out.println(">"); } %> <li class="b3k_firstchild"> <a href="myReservations.jsp" title="Meine Reservierungen">Meine Reservierungen</a> </li> <li class="b3k_lastchild b3k_active"> <a href="reservationDateTimeChooser.jsp?self= <% if(self!=null && self.equals("true")) { out.print("false"); }else{ out.print("true"); } %> " title="Neue Reservierung">Neue Reservierung</a> </li>

<li class="b3k_lastchild"> <a href="logout.jsp" title="Logout">Logout</a> </li>

Belk/Stöhr, June 2011 CXXVII

</ul> </div></div>

<%String user = (String) session.getAttribute("user");String day = request.getParameter("day");String time = request.getParameter("time");String endTime = request.getParameter("endTime");String level = request.getParameter("level");String area = request.getParameter("area");

if(user!=null){ ResultSet res = null;

String sqlAreaCount = "select count(area) as areaCount from (select stationID, startTime, endTime, date, level, area from "+ "(select bachelor_station.id as stationID , bachelor_reservation.id as reservationID, "+ "startTime, endTime, date, level, area from bachelor_station left join bachelor_reservation "+ "on station=bachelor_station.id) as tempTable where "+ "('"+time+"'>=endTime or '"+endTime+"'<=startTime or startTime is NULL) and "+ "(date=CURRENT_DATE+"+day+" or date is NULL) and "+ "level="+level+" group by area) as tempTwo;" ;

String sqlAreaList = "select stationID, startTime, endTime, date, level, area from "+ "(select bachelor_station.id as stationID , bachelor_reservation.id as reservationID, "+ "startTime, endTime, date, level, area from bachelor_station left join bachelor_reservation "+ "on station=bachelor_station.id) as tempTable where "+ "('"+time+"'>=endTime or '"+endTime+"'<=startTime or startTime is NULL) and "+ "(date=CURRENT_DATE+"+day+" or date is NULL) and "+ "level="+level+" group by area;" ;

if(area==null){ //no area selected res = queryDB(sqlAreaCount); res.next(); int areaCount = res.getInt("areaCount");

if(areaCount>1){ //multiple areas avaiable res = queryDB(sqlAreaList); out.println("<h2> Mehrere freie Breiche gefunden. Bitte ausw\u00E4hlen:</h2><h3>"); out.println("<form class='search' action=newReservation.jsp>"); out.println("<select name='area'>"); while(res.next()){ out.println("<option value='" +res.getString("area")+ "'>Bereich " +res.getString("area")+ "</option>"); }

Belk/Stöhr, June 2011 CXXVIII

out.println("</select>"); out.println("<input type='hidden' name='day' value='"+day+"'/>"); out.println("<input type='hidden' name='time' value='"+time+"'/>"); out.println("<input type='hidden' name='endTime' value='"+endTime+"'/>"); out.println("<input type='hidden' name='level' value='"+level+"'/>"); out.println("<input type='submit' value='Reservieren'/>"); out.println("</form></h2>");

out.println("<img src='mobile-img/level"+level+"explained.jpg' border='0' width='350' height='410'>");

}else{

//only one area found if(areaCount==1){ res = queryDB(sqlAreaList); res.next(); area=res.getString("area");

out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=newReservation.jsp"+ "?level="+res.getString("level")+ "&day="+day+ "&time="+time+ "&endTime="+endTime+ "&area="+area+ "'>"); }else{ //error if area count is 0 out.println("<h1>Datenbankfehler!</h1>"); } }

}else{ //if area was selected //perform reservation

String sqlFreeStationOnLvlAndArea = "select stationID, startTime, endTime, date, level, area from "+ "(select bachelor_station.id as stationID , bachelor_reservation.id as reservationID, "+ "startTime, endTime, date, level, area from bachelor_station left join bachelor_reservation "+ "on station=bachelor_station.id) as tempTable where "+ "('"+time+"'>=endTime or '"+endTime+"'<=startTime or startTime is NULL) and "+ "(date=CURRENT_DATE+"+day+" or date is NULL) and "+ "level="+level+" and area="+area+";" ;

res = queryDB(sqlFreeStationOnLvlAndArea); res.next(); String station = res.getString("stationID");

String sqlInsert = "insert into bachelor_reservation(date, startTime, endTime, unused, user_id, station) values "+ "( CURRENT_DATE+"+day+", '"+time+"', '"+endTime+"', true, "+user+", "+station+" )" ;

Belk/Stöhr, June 2011 CXXIX

int rv = updateDB(sqlInsert); if(rv>0) { out.println("<br><h2>Lernplatz reserviert!</h2>"); out.println("<meta HTTP-EQUIV='REFRESH' content='2; url=myReservations.jsp'>"); }else{ out.println("<h1>Datenbankfehler!</h1>"); } }

}else{ //user not logged in -> redirect to login out.println("<meta HTTP-EQUIV='REFRESH' content='0; url=index.jsp'>");}%>


SQL.jsp

<%@ page import="java.sql.*" %><%@ page import="java.lang.System" %>

<%! public ResultSet queryDB(String query) { String url = "jdbc:mysql://localhost.localdomain/h0750926"; ResultSet result = null; try { DriverManager.registerDriver(new com.mysql.jdbc.Driver()); Connection conn = DriverManager.getConnection(url, "h0750926", "h0750926"); Statement stmt = conn.createStatement (); ResultSet rset = stmt.executeQuery(query); result=rset; } catch (SQLException e) { //out.println(e); }

return result;

}%>

<%! public int updateDB(String update) { String url = "jdbc:mysql://localhost.localdomain/h0750926"; int result = -1; try { DriverManager.registerDriver(new com.mysql.jdbc.Driver()); Connection conn = DriverManager.getConnection(url, "h0750926", "h0750926"); Statement stmt = conn.createStatement (); result = stmt.executeUpdate(update); } catch (SQLException e) { //out.println(e); }

return result;

Belk/Stöhr, June 2011 CXXX

}%>

ResApp.css

/*CSS file for additional styles. Determines the look of the HTML tables used in the application. resApp.css stands for “reservation application style sheet”.*/

TABLE.resList{BORDER: 1px solid black;BORDER-COLLAPSE:collapse;WIDTH: 100%;}

TD {BORDER: 1px solid black;}

TR.first{BACKGROUND: #334B68;COLOR: #fff;}

footer{POSITION:fixed;BOTTOM:0px;}

Belk/Stöhr, June 2011 CXXXI

8.2 Project 2: Query Tool (XML data files)

res/values/strings.xml


<resources>

<string name="app_name">WU Query Tool</string>

<string name="heading">Query Tool</string>

<string name="button_ask">Ask a question</string><string name="button_list">List and rate questions</string><string name="button_about">About</string><string name="button_exit">Exit</string>

<string name="ask_title">Please enter your question:</string><string name="ask_button">Post question</string>

<string name="list_title">Listing questions</string><string name="list_empty">No questions were posted yet.</string>

<string name="about_title">About Query Tool</string><string name="about_text">This application allows students to ask questions

inside large lectures.\n\n (c) WU Wien, 2011</string>

<string name="config_title">Configuration</string><string name="config_shortcut">c</string>

<string name="config_category_location">Location</string><string name="config_category_user">User preferences</string>

<string name="config_hall_title">Select your lecture hall</string><string name="config_hall_summary">Questions are posted and displayed exclusively for

the hall selected here.</string>

<string name="hall1">Audimax</string><string name="hall2">Festsaal</string><string name="hall3">Aula</string>

<string name="config_vibration_title">Enable vibration</string><string name="config_vibration_summary">Let your device vibrate if a new question was

posted.</string>

<string name="config_nickname_title">Enter a nickname</string><string name="config_nickname_summary">Allows the lecturer to identify an asker for

further discussion.</string>

</resources>

res/layout/main.xml


<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"android:background="@color/background" android:layout_height="fill_parent"android:layout_width="fill_parent" android:padding="30dip"android:orientation="horizontal">

<LinearLayout android:orientation="vertical"android:layout_height="wrap_content" android:layout_width="fill_parent"android:layout_gravity="center">

<ImageView android:src="@drawable/wuw"android:layout_height="wrap_content" android:layout_width="wrap_content" />

<TextView android:text="@string/heading"android:layout_height="wrap_content" android:layout_width="wrap_content"

Belk/Stöhr, June 2011 CXXXII

android:layout_gravity="center" android:layout_marginBottom="25dip"android:textSize="24.5sp" />

<Button android:text="@string/button_ask" android:id="@+id/button_ask"android:layout_width="fill_parent" android:layout_height="wrap_content" />

<Button android:text="@string/button_list" android:id="@+id/button_list"android:layout_width="fill_parent" android:layout_height="wrap_content" />

<Button android:text="@string/button_about" android:id="@+id/button_about"android:layout_width="fill_parent" android:layout_height="wrap_content" />

<Button android:text="@string/button_exit" android:id="@+id/button_exit"android:layout_width="fill_parent" android:layout_height="wrap_content" />

</LinearLayout>

</LinearLayout>

res/menu/menu.xml


<menu xmlns:android="http://schemas.android.com/apk/res/android">

<item android:id="@+id/config" android:title="@string/config_title"android:alphabeticShortcut="@string/config_shortcut" />

</menu>

res/xml/config.xml


<PreferenceScreen xmlns:android="http://schemas.android.com/apk/res/android">

<PreferenceCategory android:title="@string/config_category_location">

<ListPreference android:key="hall" android:title="@string/config_hall_title"android:summary="@string/config_hall_summary" android:entries="@array/halls"android:entryValues="@array/halls" />

</PreferenceCategory>

<PreferenceCategory android:title="@string/config_category_user">

<CheckBoxPreference android:key="vibration"android:title="@string/config_vibration_title"

android:summary="@string/config_vibration_summary"android:defaultValue="false" />

<EditTextPreference android:key="nickname"android:title="@string/config_nickname_title"

android:summary="@string/config_nickname_summary" />

</PreferenceCategory>

</PreferenceScreen>

res/values/halls.xml


<resources><string‐array name="halls">

<item>@string/hall1</item><item>@string/hall2</item><item>@string/hall3</item>

</string‐array></resources>

Belk/Stöhr, June 2011 CXXXIII

res/layout/asking.xml


<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"android:layout_width="fill_parent" android:layout_height="fill_parent">

<LinearLayout android:layout_width="match_parent"android:layout_height="match_parent" android:orientation="vertical">

<EditText android:id="@+id/askInput" android:layout_width="match_parent"android:layout_height="wrap_content" android:inputType="textMultiLine"><requestFocus></requestFocus>

</EditText>

<Button android:id="@+id/askButton" android:layout_width="match_parent"android:layout_height="wrap_content" android:text="@string/ask_button"></Button>

</LinearLayout>

</FrameLayout>

res/layout/listing.xml


<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"android:layout_width="fill_parent" android:layout_height="fill_parent">

<!‐‐ Note built‐in ids for 'list' and 'empty' ‐‐>

<ListView android:id="@android:id/list" android:layout_width="wrap_content"android:layout_height="wrap_content" />

<TextView android:id="@android:id/empty" android:layout_width="wrap_content"android:layout_height="wrap_content" android:text="@string/list_empty" />

</LinearLayout>

res/layout/item.xml


<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"android:layout_width="fill_parent" android:layout_height="fill_parent"android:orientation="horizontal" android:padding="10sp">

<TextView android:id="@+id/rank" android:layout_width="wrap_content"android:layout_height="wrap_content" />

<TextView android:id="@+id/rank_suffix" android:layout_width="wrap_content"android:layout_height="wrap_content" android:layout_toRightOf="@id/rank"android:text=" Votes:" />

<TextView android:id="@+id/question" android:layout_width="fill_parent"android:layout_height="wrap_content" android:layout_below="@id/rank"android:textStyle="bold" android:padding="10sp" />

<TextView android:id="@+id/nickname_prefix"android:layout_width="wrap_content" android:layout_height="wrap_content"android:layout_below="@id/question" android:text="Asked by "android:textStyle="italic" />

<TextView android:id="@+id/nickname" android:layout_width="wrap_content"android:layout_height="wrap_content" android:layout_below="@id/question"android:layout_toRightOf="@id/nickname_prefix" android:textStyle="italic" />

Belk/Stöhr, June 2011 CXXXIV

<TextView android:id="@+id/identifier_prefix"android:layout_width="wrap_content" android:layout_height="wrap_content"android:layout_below="@id/question" android:layout_toRightOf="@id/nickname"android:text=", ID: " android:textStyle="italic" />

<TextView android:id="@+id/identifier" android:layout_width="wrap_content"android:layout_height="wrap_content" android:layout_below="@id/question"android:layout_toRightOf="@+id/identifier_prefix" android:textStyle="italic"android:ellipsize="end" android:singleLine="true" />

</RelativeLayout>

res/layout/listing.xml


<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"android:layout_width="fill_parent" android:layout_height="fill_parent"android:padding="10dip">

<TextView android:id="@+id/aboutText" android:layout_width="wrap_content"android:layout_height="wrap_content" android:text="@string/about_text" />

</ScrollView>

res/values/colors.xml


<resources>

<color name="background">#FFFFFFFF</color>

</resources>

Belk/Stöhr, June 2011 CXXXV

Documents

Innovative Use of Mobile Applications Supporting Learning and