Java程序辅导

Technical Report 
Technical Report ...................................... 1 
Abstract.................................................... 1 
Introduction.............................................. 1 
Background.............................................. 1 
Aims ........................................................ 2 
Related work and features of related work 2 
Questionnaire ....................................... 2 
Questionnaire findings.......................... 2 
Design and design rational ....................... 2 
Quantitative.......................................... 2 
Qualitative............................................ 2 
Prototyping........................................... 3 
Case Study ............................................... 3 
Use case 1: view todays reminders ....... 3 
Use case 2: view location reminders ..... 3 
Use case 3: edit a reminder ................... 3 
Use case 4: add a location..................... 3 
Technical analysis .................................... 4 
PocketPC.............................................. 4 
Java Calendar Systems ......................... 4 
PlaceLab Developing ........................... 4 
Platform independent design – SWT..... 5 
J9 Java runtime environment provided 
by IBM................................................. 5 
Storage of data ..................................... 5 
Error Handling ......................................... 6 
QA........................................................... 6 
Testing – code and peer assessment.......... 6 
Bugs and PlaceLab performance .............. 6 
Future improvements................................ 6 
Resilience................................................. 6 
Conclusion ............................................... 7 
Acknowledgements .................................. 7 
Bibliography ............................................ 7 
 
Abstract 
 
Location aware computing is an area which 
is increasingly growing within the 
computing community. There are currently 
many ways to find a location of a user, for 
example using mobile phone infrastructure, 
GPS and more recently WIFI. All of these 
technologys have their strengths and 
weaknesses WIFI's major strength is its 
ability to give a constant stream of location 
input both indoors and outdooors and in 
areas with lots of high rise buildings. 
Organiser software can be found on almost 
all hand-held devices and we decided upon 
creating software which combines the 
features of organiser software with location 
aware computing, that is, software which 
can remind the user of tasks relative to 
location as well as time. 
 
Introduction 
 
Our implementation of location aware 
software was built using Intel's Place Lab 
software, written in Java. Place Lab uses 
802.11 standard Wi-Fi access points to 
determine the position of the user. We 
decided to implement our software on a 
Personal Digital Assistant (PDA), a portable 
device using Wi-Fi. Deciding upon using a 
PDA to run our software came fairly easily, 
as compatibility extends to laptop use also, 
but primarily the PDA is portable with an 
interactive screen and keyboard and allows 
for audio interaction with the user. The 
portability is of particular note as of course 
the more portable a device the more relevant 
the location of the device is, for instance 
having the software on a home pc will not be 
of much use as you probably will not be 
moving around with such device turned on. 
 
Background 
 
PlaceLab is a library file written in java that 
can be used to help implement a location 
aware application. The PlaceLab files allow 
for positioning both indoors and outside and 
does not need to be linked to a central 
service to determine its position. It allows 
PDA's, notebooks and cellphones and other 
hardware to locate themselves by listening 
for what is known in PlaceLab as a 'radio 
Beacon' which are either 802.11 access 
points, GSM telephones or fixed location 
bluetooth devices.  
 
 
 
Aims 
 
Having looked at wifi and PlaceLab we have 
decided to undertake a project where the aim 
is to provide a piece of software that will run 
on a PDA, laptop and PC. To create a real 
world useable application using PlaceLab. 
We will be looking at the PlaceLab code and 
remove unneeded modules, as size is a big 
concern in mobile computing, then on top of 
this interface create a location aware to-do 
list. 
 
Related work and features of related 
work 
 
We can find organiser software on a variety 
of platforms and devices. When looking at 
portable devices there are familiar features 
seen throughout: 
Calendar view – this shows the user a list of 
days and dates for the month 
Today view – a list of hours in the day and 
tasks at those times 
Reminders – a list of reminders possibly with 
alarms 
 
With the additional use of location aware 
computing we add to these functions the 
ability to provide reminders based on 
location and screen to view positional 
information.  
 
Questionnaire 
 
We decided upon using a questionnaire to 
gather data about users of organiser software 
to find the features most commonly used 
additional features that they require and their 
opinions on the addition of our location-
aware components, namely location 
reminders. We asked people in the computer 
science building as this would lead us to 
having more information about PDA users. 
 
 
Questionnaire findings 
 
We found that for those that use portable 
computer devices or those who see 
themselves getting such a device they would 
find location reminder system useful. We 
found that there were a very limited number 
of PDA users in the computer science 
building, but having spoken to those that did 
we found that they all frequently use Wi-Fi 
and were interested in our project. 
 
Design and design rational 
 
Having looked at existing organiser systems 
and how potential end-users interact with 
organisers we have developed the following 
quantitative and qualitative specifications: 
 
Quantitative 
● must be able to run on a PDA 
● must be able to make reminders 
● must be able to display reminders 
● must be able edit reminders 
● must be able to be navigated 
● must be able to define locations 
● must be able to make location 
reminders 
● must be able to display where the user 
is – if no beacons 
● must be able to display locations 
● must be able to display tasks in a 
calendar view 
● must be able handle errors 
● must be able to alert the user to 
reminders 
 
Qualitative 
● not be too memory intensive 
● have a good response time 
● alert appropriately 
● have a consistent user interface 
● be consistent with schemas for ease of 
use – should not need a manual 
 
Prototyping 
 
We decided upon using extreme 
programming techniques, which involves 
lots of iterations of the software in order to 
get prototypes with more functionality added 
at each iteration. The aims of extreme 
programming as a development methodology 
are 
● Communication 
● Simplicity 
● Feedback 
● Courage 
● Respect 
●  
Essential features 
 
This is an extension of the specification to 
move into the specifics of the design and 
how we wanted the needs in specifications to 
be implemented. Essential features are: 
View of today – this is to show the hours of 
the day with the relevant reminders shown 
next to the time day. 
View of the month – this is to be a calendar 
styled view showing days and allowing the 
user to navigate to a view of reminders for 
that particular date. 
View of the map – this is to show the user 
their approximate location and let the user 
define places. 
User Guide – we have provided a concise 
user guide but ideally the user would not 
need to read it to use the software. 
 
Case Study 
 
We have provided case studies to illustrate 
use of our software which were used in 
testing to gauge the effectiveness of our 
software. 
 
Use case 1: view todays reminders 
 
Aim: This is a basic use case whereby we 
view a screen containing todays reminders 
 
 
Success Scenario: 
1. double click an icon to open the 
software 
2. click on a button to take us to the 
reminders for today 
3. read off the reminders for today. 
 
Use case 2: view location reminders 
 
Aim: This is a basic use case whereby the 
user navigates to view the valid location 
reminders 
 
Success Scenario: 
1. double click an icon to open the 
software 
2. click on a series of gui buttons to 
view the valid location reminders 
3. read off the location reminders 
Use case 3: edit a reminder 
 
Aim: To view a reminder and go to an edit 
screen to change the description of the 
reminder 
 
Success Scenario: 
1. double click an icon to open the 
software 
2. navigate to view an existing reminder 
3. navigate easily to an edit screen 
4. edit the description of the reminder 
5. navigate back to viewing reminders 
6. check that the description has changed 
 
Use case 4: add a location 
 
Aim: to view your location on a map and add 
a location name and description for that 
location. 
view a  location 
 
Success Scenario: 
1. double click an icon to open the 
software. 
2. navigate to view the map. 
3. click a button to add location 
4. input information about the location 
5. confirm adding a location 
6. view the map 
7. add the view of the location just 
inputted 
8. check that the location is now being 
viewed 
 
Technical analysis 
 
The development environment that we chose 
was the Netbeans 5.0 IDE. We have used this 
for a CO831 Mobile and Ubiquitous project 
and gained familiarity with its features and 
functions. [8] 
● It can make accessor and mutator 
methods automatically for variables 
defined in a class. 
● Can refactor offering renaming of 
classes, methods, fields, packages, 
local variables, and parameters .  
● Has syntax highlighting for Java .  
● Code folding to hide unimportant 
code.   
● Shortcuts for creating new methods. 
 
We found the installation of PlaceLab to be 
somewhat annoying especially when trying 
to develop using the platform, mainly due to 
how it finds its data. We have included an 
installation guide in the appendix containing 
information useful to potential developers on 
how to install all the files required by 
PlaceLab (including SWT, J9 for pc and 
PDA and of course PlaceLab itself). 
 
PocketPC 
 
Using PlaceLab on a PocketPC device has 
some limitations. First of all, the install 
process is itself quite complicated and access 
to the file system is very limited without a 
PC, and even with a PC, you still don’t have 
full control. Also, in addition to PocketPC 
running with limited Java libraries, it also 
runs an old version of Java, specifically 1.1. 
This brought problems where the PCs we 
developed on were running later versions of 
Java, where useful classes and methods had 
to be avoided. 
 
Java Calendar Systems 
 
A small portion of this project was to be the 
calendar part of the application. 
Unfortunately, the time-keeping systems 
proved to be a great hindrance, what with the 
GregorianCalendar class storing the date and 
time in milliseconds, but not having any 
methods to directly show the date in a 
human readable format, and the DateFormat 
class having no simple way of converting 
from it’s human readable format to a number 
possible to do calculations on, we ended up 
creating a whole class to deal with the 
inconsistencies in these formats. This took a 
large amount of time away from the more 
important aspects of the project, and turned 
the calendar part of the application into a 
mountain of work for what was meant to be 
a non-essential part. 
 
PlaceLab Developing 
 
PlaceLab is a fairly large library of files and 
can be hard to navigate through to find the 
required file for a given task. This problem 
is multiplied by the fact PlaceLab itself is 
very poorly commented contains little 
Javadoc or a really useful Developers guide, 
this is amplified even further by its only real 
source of information (its page on 
sourceforge) have its forums full of spam 
making them near unusable. 
 
Examples of where the poor documentation 
of PlaceLab was of real concern is in the 
more complicated classes (such as all the 
custom SWT stuff it implements) where 
fields and methods have non descriptive 
names and no description to be found, 
leaving the only way to get an answer is to 
look in more and more files (as a lot of its 
inherited you find yourself going up and up 
the inheritance tree). Even more bizarrely 
even when you could find out some of the 
methods and fields some where disabled so 
setting them did not actually affect the 
running of the application. 
 
Platform independent design – SWT 
 
SWT uses the native profile of the user to 
provide user interface facilities of the 
operating system on which it is operating. 
Below are pictures of how the same GUI is 
displayed on different operating systems[1]: 
 
 
 
 
 
 
 
 
 
 
 
 
SWT is a graphical user interface that aims 
to get the most out of your PDA. The main 
application is always full size in the PDA 
window to make the most of the limited 
display area. SWT also resizes the screen 
automatically (when set up correctly) when 
the input keyboard panel is set visible or 
hidden offering the user control over the 
viewing area. This is the keyboard for the 
user to operate with a stylus. 
  
 
J9 Java runtime environment provided 
by IBM 
 
The J9 runtime we use on our PDA is based 
on a standard known as Java Personal 
Profile. Personal Profile is one of the lesser 
used Java implementations as most mobile 
developers only use up to MIDP/CLDC. 
Personal profile includes all that MIDP does 
plus CLDC (Connected Limited Device 
Configuration) plus CDC (Connected Device 
Configuration) and then finally its own 
library's offering AWT support. 
 
Although the runtime offered AWT support 
we decided to implement the program fully 
in SWT (which in fact the J9 runtime 
includes some libraries of) mainly due to 
PlaceLab having some custom SWT GUI 
elements. 
 
Storage of data 
 
We have chosen to store persistent data 
using text files. The persistent data that we 
have to store are both types of reminder, 
temporal and geographical, as well as the 
places that the user has defined. We chose 
to use text documents due to previous 
experience with write functions to text 
documents. We also chose text documents 
because it allows us to debug with relative 
ease. This is because we can easily view the 
modified data and check when data within 
these files has changed. We considered 
alternatives to text documents, record 
stores, but to use these effectively we would 
have to have fixed size fields for data entry 
which would limit the user's ability to name 
the reminder, describe the reminder or both. 
When we used record stores in a previously 
we found them especially difficult as they 
use byte streams, a lot more difficult than 
opening text documents. To ensure integrity 
of data, every time a record is modified or 
added we make a new save to the persistent 
storage of the device. Although we hold this 
data in persistent storage, we have a copy of 
each of these as an object of type vector 
within the software in order to make 
modifications and changes using standard 
API. 
 
We have three text files to store our 
reminders and places 
TemporalReminders.txt which stores 
temporal reminders 
LocationReminders.txt which stores location 
based reminders 
Places.txt which stores data about the places 
 
Error Handling 
Time restrictions meant that although we do 
have some error checking, we ran out of time 
to implement error checking on inputs. 
 
QA 
To assure quality of code, we used pair 
programming (part of the extreme 
programming paradigm) on challenging parts 
of the project, to increase efficiency, 
accuracy and maintainability.  
In the final build, all java documents have 
full javadoc comments. However with the 
build submitted with this document, the 
earlier version hadn’t been commented. 
 
Testing – code and peer assessment 
 
Most testing was done via an iterative 
process. This helped to overcome the fragile 
nature of putting together third party code, 
wireless and GUI systems together, and kept 
us on the right track towards complete 
classes. We used high level manual 
walkthroughs and verbal walkthroughs and 
relied heavily upon the System.out.println 
command to check variable states 
throughout walkthroughs. 
 
Bugs and PlaceLab performance 
 
During our use of PlaceLab we found it to be 
relatively error free with only minor 
problems. One of the main problems 
involved PlaceLab’s standard dll spotter. 
This did not function with our device. To 
resolve this we found a different library that 
worked for our device. Beyond this we have 
found minor errors in code but have changed 
them where necessary, such as drawing a 
rectangle glyph in the file 
org.PlaceLab.demo.mapview.mapview.java. 
 
Future improvements 
 
We would like to implement error checking 
on the input from text boxes. Normal use 
works fine however we cannot currently deal 
with the case when the user inputs a new line 
character “\n”. This however is exceptional 
use. 
Our current system is not able to handle 
multiple reminders on the same hour. This is 
a clear improvement for the future. Our code 
can handle multiple reminders accurate to the 
minute; this missing feature is due to limited 
functionality of the GUI as we only have 
enough room to show one object per hour. 
With a new GUI this feature would not be 
beyond the scope of our coding abilities. 
We could have implemented the place to be 
defined as a series of points that the user 
clicks upon and the area within the bounds of 
these points is the place as defined by the 
user. We chose not to do this because we felt 
that the limitation of the system not being 
able to delete locations would mean that the 
user may create undesirable or irregular 
shapes. 
We would have liked to have implemented a 
month view whereby the number of the date, 
so 1 for the first of the month, would appear 
in bold if there were any reminders for that 
day. Due to time constraints we did not 
implement this function. 
 
Resilience 
In a future version we would have liked to 
have implement error checking on input 
boxes, however with normal use, we don’t 
envisage special characters to be inputted on 
purpose, especially the end of line identifiers 
which would cause our storage classes 
problems. 
 Conclusion 
 
What was originally considered a flexible 
project of average difficulty became more 
and more challenging as the project 
developed due to the complex circumstances 
our application has to work through. We are 
pleased with the quality of the build we are 
able to submit with this report, however 
development will continue, to provide a more 
complete package. We felt that this project 
may have been more appropriate for a larger 
group, as it required large amounts of 
development, testing and research into the 
third party libraries. However, we did enjoy 
the project and learnt a lot from the 
challenges it presented us with.  
 
Acknowledgements 
 
Thanks to the Department of Computer 
Science at the University of Manitoba for 
their SWT examples. Coca-cola for fuelling 
our coding sessions. 
Special thanks to Nick Ryan for having great 
patience with this project. 
 
Bibliography 
 
[1]PlaceLab 
www.PlaceLab.org 
 
[2]Configuring Java (J9) on a Pocket PC 
with RMI and SWT using CDC Personal 
Profile 
http://awareness.ics.uci.edu/~rsilvafi/pocketP
C/ 
 
[3]WebSphere Everyplace Micro 
Environment 5.7.1 - Personal Profile 1.0 for 
pocket PC, which is a long name for the J9 
java runtime  
http://www-
306.ibm.com/software/wireless/weme/ 
 
[4]SWT provided by eclipse for PocketPC 
http://www.eclipse.org/downloads/index.php 
 
[5]A small cup of SWT 
http://www.eclipse.org/articles/Article-small-
cup-of-swt/pocket-PC.html 
 
[6]SWT examples and tutorials 
http://www.cs.umanitoba.ca/~eclipse/ 
 
[7]CO831 – Mobile and Ubiquitous 
Computing lecture slides courtesy of the 
University of Kent Computer Science 
Department 
http://www.cs.kent.ac.uk.chain.kent.ac.uk/tea
ching/05/modules/CO/8/31/ 
 
[8]Netbeans community 
http://www.netbeans.org/ 
 
[9]Java Personal Profile 
http://java.sun.com/products/personalprofile/o
verview.html