innovative use of mobile applications supporting learning and
TRANSCRIPT
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]
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:
Belk/Stöhr, June 2011 2
2. Mobile Devices and Wireless Technology
• 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-
Belk/Stöhr, June 2011 3
2. Mobile Devices and Wireless Technology
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.”
Belk/Stöhr, June 2011 4
2. Mobile Devices and Wireless Technology
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).
Belk/Stöhr, June 2011 5
2. Mobile Devices and Wireless Technology
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.
Belk/Stöhr, June 2011 6
Figure 2.1: Location systems and accuracy [HaSK04]
2. Mobile Devices and Wireless Technology
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)
Belk/Stöhr, June 2011 7
Figure 2.3: WLAN fingerprinting operation modes [Linn10]
Figure 2.2: WLAN fingerprinting visual radio map [Linn10]
2. Mobile Devices and Wireless Technology
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.
Belk/Stöhr, June 2011 8
Figure 2.4: Mobile operating systems by market share [Niel11]
2. Mobile Devices and Wireless Technology
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.
Belk/Stöhr, June 2011 9
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
Belk/Stöhr, June 2011 10
3. Future IT Infrastructure of the New WU
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]
Belk/Stöhr, June 2011 11
3. Future IT Infrastructure of the New WU
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]
Belk/Stöhr, June 2011 12
3. Future IT Infrastructure of the New WU
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.]
Belk/Stöhr, June 2011 13
3. Future IT Infrastructure of the New WU
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-
Belk/Stöhr, June 2011 14
3. Future IT Infrastructure of the New WU
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.
Belk/Stöhr, June 2011 15
3. Future IT Infrastructure of the New WU
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.
Belk/Stöhr, June 2011 16
3. Future IT Infrastructure of the New WU
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]
Belk/Stöhr, June 2011 17
3. Future IT Infrastructure of the New WU
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.
Belk/Stöhr, June 2011 18
3. Future IT Infrastructure of the New WU
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.
Belk/Stöhr, June 2011 19
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].
Belk/Stöhr, June 2011 20
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.
Belk/Stöhr, June 2011 21
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.
Belk/Stöhr, June 2011 22
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)
Stakeholders Students, WU staff
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
Belk/Stöhr, June 2011 23
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.
Belk/Stöhr, June 2011 24
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
Belk/Stöhr, June 2011 25
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.
Belk/Stöhr, June 2011 26
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
Stakeholders Students, WU staff
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.
Belk/Stöhr, June 2011 27
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
Belk/Stöhr, June 2011 28
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.
Belk/Stöhr, June 2011 29
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.
Belk/Stöhr, June 2011 30
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
Stakeholders Students
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
Belk/Stöhr, June 2011 31
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.
Belk/Stöhr, June 2011 32
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
Belk/Stöhr, June 2011 33
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.
Belk/Stöhr, June 2011 34
4. Use Cases
Use Case Asking questions in the Audimax
Goal Improvement of lecture quality
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.
Belk/Stöhr, June 2011 35
4. Use Cases
Use Case Controlling room equipment
Goal Improvement of lecture quality
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
Belk/Stöhr, June 2011 36
4. Use Cases
Use Case Transferring notes from the blackboard
Goal Improvement of lecture quality
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
Stakeholders Students
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
Belk/Stöhr, June 2011 37
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.
Belk/Stöhr, June 2011 38
4. Use Cases
Use Case Retrieving course information on site
Goal Improvement of lecture quality
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
Stakeholders 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.
Belk/Stöhr, June 2011 39
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.
Belk/Stöhr, June 2011 40
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.
Belk/Stöhr, June 2011 41
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.
Belk/Stöhr, June 2011 42
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.
Belk/Stöhr, June 2011 43
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.
Belk/Stöhr, June 2011 44
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.
Belk/Stöhr, June 2011 45
5. Implemented Projects
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-
Belk/Stöhr, June 2011 46
5. Implemented Projects
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.
Belk/Stöhr, June 2011 47
5. Implemented Projects
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.
Belk/Stöhr, June 2011 48
5. Implemented Projects
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
Belk/Stöhr, June 2011 49
5. Implemented Projects
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
User → Web-Server: HTTP request for reservation
Web-Server → Library Database: Reservation(level)
Library Database → Library Database: Avaiability check
Library Database → Web-Server: List of possible
stations in different areas
Web-Server → User : HTTP response for area selection
User → Web-Server: HTTP request for reservation
Web-Server → Library Database: Reservation(area)
Library Database → Library Database: Avaiability check
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.
Belk/Stöhr, June 2011 50
5. Implemented Projects
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.
Belk/Stöhr, June 2011 51
5. Implemented Projects
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
Belk/Stöhr, June 2011 52
5. Implemented Projects
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.
Belk/Stöhr, June 2011 53
5. Implemented Projects
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)
)
Belk/Stöhr, June 2011 54
5. Implemented Projects
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.
Belk/Stöhr, June 2011 55
5. Implemented Projects
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"%>
Belk/Stöhr, June 2011 56
5. Implemented Projects
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.
Belk/Stöhr, June 2011 57
5. Implemented Projects
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>
<!-- Upper menu from bach.wu.ac.at -->
<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>
Belk/Stöhr, June 2011 58
5. Implemented Projects
</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.
Belk/Stöhr, June 2011 59
5. Implemented Projects
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" />
Belk/Stöhr, June 2011 60
5. Implemented Projects
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.
Belk/Stöhr, June 2011 61
5. Implemented Projects
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.
Belk/Stöhr, June 2011 62
5. Implemented Projects
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.
Belk/Stöhr, June 2011 63
5. Implemented Projects
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.
Belk/Stöhr, June 2011 64
5. Implemented Projects
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.
Belk/Stöhr, June 2011 65
5. Implemented Projects
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.
Belk/Stöhr, June 2011 66
5. Implemented Projects
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>
Belk/Stöhr, June 2011 67
5. Implemented Projects
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.
Belk/Stöhr, June 2011 68
5. Implemented Projects
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
Belk/Stöhr, June 2011 69
5. Implemented Projects
(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.
Belk/Stöhr, June 2011 70
5. Implemented Projects
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
Belk/Stöhr, June 2011 71
5. Implemented Projects
(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.
Belk/Stöhr, June 2011 72
5. Implemented Projects
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.
Belk/Stöhr, June 2011 73
5. Implemented Projects
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.
Belk/Stöhr, June 2011 74
5. Implemented Projects
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.
Belk/Stöhr, June 2011 75
5. Implemented Projects
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
Belk/Stöhr, June 2011 76
5. Implemented Projects
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.
Belk/Stöhr, June 2011 77
5. Implemented Projects
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
Belk/Stöhr, June 2011 78
5. Implemented Projects
• 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.
Belk/Stöhr, June 2011 79
Figure 5.18: Opening screen
5. Implemented Projects
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
Belk/Stöhr, June 2011 80
Figure 5.19: Asking questions
5. Implemented Projects
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).
Belk/Stöhr, June 2011 81
Figure 5.20: Listing and voting for questions
5. Implemented Projects
Belk/Stöhr, June 2011 82
Figure 5.21: Configuration screen
Figure 5.22: Selecting a lecture hall
5. Implemented Projects
Belk/Stöhr, June 2011 83
Figure 5.24: Prompt to configurate
Figure 5.23: Setting a nickname
5. Implemented Projects
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.
Belk/Stöhr, June 2011 84
Figure 5.25: About screen
5. Implemented Projects
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.
Belk/Stöhr, June 2011 85
5. Implemented Projects
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).
Belk/Stöhr, June 2011 86
5. Implemented Projects
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.
Belk/Stöhr, June 2011 87
Figure 5.27: UML Class Diagram
5. Implemented Projects
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.
Belk/Stöhr, June 2011 88
Figure 5.28: UML Sequence Diagram
5. Implemented Projects
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.
Belk/Stöhr, June 2011 89
5. Implemented Projects
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.
Belk/Stöhr, June 2011 90
Figure 5.29: E-R Diagram of the database
5. Implemented Projects
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.
Belk/Stöhr, June 2011 91
Figure 5.30: Revised E-R Diagram of the database
5. Implemented Projects
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).
Belk/Stöhr, June 2011 92
Figure 5.31: Project skeleton
5. Implemented Projects
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
Belk/Stöhr, June 2011 93
<?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
5. Implemented Projects
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.
Belk/Stöhr, June 2011 94
5. Implemented Projects
Belk/Stöhr, June 2011 95
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;
}
5. Implemented Projects
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
Belk/Stöhr, June 2011 96
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
5. Implemented Projects
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).
Belk/Stöhr, June 2011 97
5. Implemented Projects
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.
Belk/Stöhr, June 2011 98
package at.ac.wu.wise2011s.android;
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
5. Implemented Projects
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.
Belk/Stöhr, June 2011 99
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. Implemented Projects
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.
Belk/Stöhr, June 2011 100
package at.ac.wu.wise2011s.android;
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
5. Implemented Projects
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
Belk/Stöhr, June 2011 101
package at.ac.wu.wise2011s.android;
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
5. Implemented Projects
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.
Belk/Stöhr, June 2011 102
package at.ac.wu.wise2011s.android;
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();
}
5. Implemented Projects
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.
Belk/Stöhr, June 2011 103
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
5. Implemented Projects
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
Belk/Stöhr, June 2011 104
5. Implemented Projects
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.
Belk/Stöhr, June 2011 105
package at.ac.wu.wise2011s.android;
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();
}
5. Implemented Projects
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
Belk/Stöhr, June 2011 106
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
5. Implemented Projects
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.
Belk/Stöhr, June 2011 107
5. Implemented Projects
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).
Belk/Stöhr, June 2011 108
5. Implemented Projects
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.
Belk/Stöhr, June 2011 109
package at.ac.wu.wise2011s.android;
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. Implemented Projects
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.
Belk/Stöhr, June 2011 110
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.
Belk/Stöhr, June 2011 111
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.
Belk/Stöhr, June 2011 112
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
Belk/Stöhr, June 2011 113
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.
Belk/Stöhr, June 2011 114
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.
Belk/Stöhr, June 2011 115
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>
<!-- style sheets from bach.wu.ac.at for the upper menu --><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" />
<!-- own style sheet --><link rel="stylesheet" href="resApp.css" media="all" type="text/css" />
</head>
<header><!-- Upper menu from bach.wu.ac.at --><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"%><!-- This is the login at the entry point of this application. -->
<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 for highlighting the table rows--><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><!-- main menu --><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><!-- menu end-->
<%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>
</body><%@ include file="footer.jsp"%></html>
reservationInfo.jsp
<%@ include file="SQL.jsp" %><%@ page import="java.sql.*" %><%@ include file="header.jsp"%>
<%/*Displays information about a specific reservation. And shows the floor map where the station is located.*/
String self = "false"; //request.getParameter("self");%>
<body>
<!--MENU -->
<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>
<!-- MENU END -->
<%
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'>");
}%>
</body><%@ include file="footer.jsp"%></html>
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><!-- main navigation --><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><!-- main navigation end-->
<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>
</body><%@ include file="footer.jsp"%></html>
reservationDateTimeChooser.jsp
<%@ include file="SQL.jsp" %><%@ page import="java.sql.*" %><%@ include file="header.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>
<!-- main navigation --><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><!-- main navigation end -->
<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
<%@ include file="SQL.jsp" %><%@ page import="java.sql.*" %><%@ include file="header.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>
<%String self = request.getParameter("self");%>
<body>
<!-- main navigation --><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><!-- main navigation end-->
<%//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"%>
<%String self = request.getParameter("self");%>
<body>
<!-- main navigation --><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><!-- main navigation end-->
<%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'>");}%>
</body><%@ include file="footer.jsp"%></html>
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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"android:layout_width="fill_parent" android:layout_height="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
<?xml version="1.0" encoding="utf‐8"?>
<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
<?xml version="1.0" encoding="utf‐8"?>
<resources>
<color name="background">#FFFFFFFF</color>
</resources>
Belk/Stöhr, June 2011 CXXXV