- Core Servlets and JavaServer Pages, 2nd Edition: Volume 1 – Marty Hall & Larry Brown
- Beginning PHP5, Apache, MySQL web Development – Naramore, Gerner, Le Scouarnec, Stolz, Glass
- Build Your Own Database Driven Website Using PHP & MySQL
- Enterprise J2ME - Developing Mobile Java Applications, Prentice Hall
- Software Engineering: A Practitioner’s Approach 6th Edition, Roger S Pressman
- http://www.java-tips.org
- http://www.sun.com
- http://www.java2s.com
- http://www.netbeans.org
- http://www.w3schools.com
- http://www.phpbuilder.com
- http://www.roseindia.net
- http://www.php.net
- http://www.swish-db.com
- http://www.devx.com
- http://www.wirelessdevnet.com
- http://www.handicapmaster.org/
- http://www.pallasweb.com/color.html
- http://www.conniq.com
- http://www.webmasterworld.com
- http://www.bb-europe.com
- http://www.whatis.com
- http://www.wikipedia.org
- http://www.brsgolf.com
- http://www.teetimes.com
- http://www.milltowngolfclub.ie/onlinebooking/
- http://www.golfregistrations.com
- http://www.oobgolf.com
- http://http://www.testiphone.com/?scroll=off&url=http://www.smartscorecard.com/oobgolf/login.php?reset=true
- http://www.boards.ie
Sunday, January 29, 2012
Bibliography
Appendix
PHP
A scripting language originally designed for producing dynamic web pages. It has evolved to include a command line interface capability and can be used in standalone graphical applications
Java
An object-oriented programming language
JavaScript
A scripting language used to enable programmatic access to objects within other applications
MySQL
A relational database management system
JDBC (Java Database Connectivity)
An API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database
Servlets
Java programming language objects that dynamically process requests and construct responses
Macros
A procedure that specifies how a certain input sequence should be mapped to an output sequence
HTML (HyperText Markup Language)
A markup language for web pages
CSS (Cascading Style Sheets)
A style sheet language used to describe the presentation of a document written in a markup language
J2ME (Java 2 Platform, Micro Edition)
A specification of a subset of the Java platform aimed at providing a certified collection of Java APIs for the development of software for small devices
MIDlet
A Java application framework for the Mobile Information Device Profile (MIDP)
CLDC (Connected Limited Device Configuration)
A specification of a framework for Java ME applications targeted at devices with very limited resources such as PDAs and mobile phones
MIDP (Mobile Information Device Profile)
A specification published for the use of Java on embedded devices such as mobile phones and PDAs
Par
A scoring system used in most amateur golf clubs
Index
Each hole has an index. 1 for the hardest, 2 for the next hardest, and so on
SSS (Standard Scratch Scoring)
A baseline for how the course plays in practice. Used in the calculation of handicaps
Handicap
A numerical measure of an amateur golfer's playing ability based on the tees played for a given course
Category
Golfers are divided into 4 categories, depending on their handicap
Front 9
Score of first nine holes on a golf course
Back 9
Score of last nine holes on a golf course
Meeting Summary
05/11/08
Initial project proposal discussed. Objectives had to be rewritten. Asked to research connectivity from PC to Mobile device and what systems are already available.
19/11/08
Connectivity research discussed and needed to be expanded. Asked for project plan, user requirements and use-case design. Asked to research existing systems, the need for the system, booking via a mobile device and the authenticity of scorecards that are sent via mobile device.
28/11/08
Connectivity research discussed. Asked for more research into existing systems.
05/12/08
Project plan discussed and needed to be extended. Research documentation was discussed and what needed to be included.
15/12/08
Discussed the non-functional requirements, the UI and the Methodology of the project.
Finalised the documentation of the research phase.
19/12/08
Submitted research phase and presentation.
13/02/09
Asked for a database design, risk assessment for the mobile application, class diagrams and to have to simple mobile application working.
20/02/09
Discussed the website and agreed that it had to look well and be well designed. Discussed the risk assessment and mobile application. Asked to revise the project plan.
06/03/09
Asked to update the project plan, revise the mobile application, revise the database design and class diagram. Also, have a servlet set up for sending the scores via mobile device. Asked to check firewall issues.
20/03/09
Asked for documentation outline. Asked to review the web UI and get an outside opinion. Look at the download option. Asked to finish the servlet.
27/03/09
Asked to get the Update Handicaps functionality working. Alter functionality of events so user can view them by month. Test mobile application on few other mobile devices.
03/04/09
Asked to finish of all coding of the website and mobile application in couple of weeks. Start on testing and documentation.
29/04/09
Discussed what to include in the documentation and what to include on the CD. Discussed the implementation for the documentation. Discussed presentation dates and times.
06/05/09
Submitted Implementation Phase.
Future Enhancements
During the course of this work I met some unexpected problems which delayed my work progress and meant that I was unable to deliver on all of the intended parts of the system. I also identified some other key areas that could be improved on, but due to the time constraints I was unable to do so.
Develop the mobile application fully including adding a colourful GUI and design it to be user friendly. At the moment, the user can’t enter one score and save it, the application has to be kept open, which is awkward while playing a round of golf.
Use Canvases instead of Forms, Lists and Textboxes as the GUI for the Mobile application.
This would result in a more professional looking GUI for the application. Most applications on phones do not use the basic J2ME GUI but use some sort of Canvas or similar custom feature. The use of Canvases is a well documented area in J2ME and would be very possible to implement.
Use XML as the method for passing data between the Client Mobile device and the Server. Initially, the application of XML was not fully comprehended, but near the end of the project lifecycle some material was found that showed how XML worked and how it could be implemented in J2ME.
Although XML is still in development for J2ME, there are open source and commercially available XML parsers available for use on mobile devices such as kXML or NanoXML ranging from 6 KB to 14 KB in size.
In the website application, have an option for a greens keeper to log onto the system and have a function to post messages for all users to see. This wasn’t included in the project proposal, but it was recommended that it should try to be incorporated it into the system. Due to time constraints, this was not possible.
In the website application, have an option for an administrator to send text messages to users regarding events and closing of the club. This was in the project proposal, but due to time constraints, it was not possible to get this function working and it was not included in the application. Currently, there is an option where the administrator can send an e-mail, but not everyone would check their e-mails regularly so the text option would be better.
In the website application, develop the ‘Print Scorecard’ option. The application has an option to get a scorecard where the scorecard is downloaded and then the user has to input it to an Excel document. There is a lot to do here for the user and if there was an option just to print a scorecard straight from the website it would be a lot more straightforward for the user.
In the website application, set the ‘Update Handicap’ option to automatically update the handicaps on the last day of every month. Currently, the administrator has to do this.
In the website application, develop an option for users to sign up to the golf club and pay their Membership Fees through the website. Currently, anyone could use this site, as it is implemented for multiple clubs.
Conclusion
Overall, the end product that has been designed and developed for this project is quite satisfactory. Although not all of the specified targets have been met, the targets that have been delivered on are of a high standard.
Through the areas of research, design and implementation, some valuable lessons have been learnt in development of web sites and mobile applications, from research right through to documenting findings and investigations into areas.
In hindsight, if this project was undertaken again, there would be some changes in the approach to the project. First off, the focus would be on one area until complete rather than splitting the time and effort between two (Mobile and Web-Site). Although the end result of the system is of a high standard, focusing on one area would have delivered a better application. Secondly, during the course of designing the system, the opinion of someone working in the domain that the application is intended for would be sought. There were features that would prove useful in the system that were only realised near the end of the project development, had they been realised earlier they could have been implemented or catered for, for some future development.
UI Testing
As most of the testing was done using Mozilla Firefox, other web browsers had to be checked to see if the they produced the same layout as Mozilla Firefox, which can be seen below.
Mozilla Firefox
One web browser that was checked was Internet Explorer. The testing done here was to check if the layout of the pages displayed on Mozilla Firefox were the same on Internet Explorer. The index page, as can be seen below, has the same layout. Many other pages had the same layout, except for one or two, mainly ones that have many buttons on the page, such as the Events page.
Internet Explorer
The next web browser that was checked was Google Chrome. Again, the testing done here was to check if the layout of the pages displayed on Mozilla Firefox were the same on Google Chrome. As expected, every page produced the same layout.
Google Chrome
However, due to testing done on the user interface, it is clear that the layout of the pages produced won’t always be the same and this has to be incorporated in when designing and implementing the website.
Testing
1. User on the Online System
- 1.1 Register on the System
- 1.2 Log On/Off
- 1.3 View Homepage
- 1.4 View Scorecards
- 1.4.1 Add Scorecard
- 1.4.2 Get & Print Scorecard
- 1.5 Book Tee-off Times
- 1.5.1 View Your Bookings
- 1.5.2 Delete Your Bookings
- 1.6 View All Events
- 1.6.1 View Events by Month
- 1.6.2 Sign Up to Event
- 1.6.3 View Events you have Signed Up to
- 1.7 Access Help Files
- 1.8 Download Mobile Application
2. User on the Mobile Application
- 2.1 Send Scorecard
3. Administrator
- 3.1 Log On/Off
- 3.2 Course Maintenance
- 3.2.1 Add a New Course
- 3.2.2 Alter an Existing Course
- 3.2.3 View Tee-off Times
- 3.2.4 Book Tee-off Times
- 3.2.5 Add a New Administrator
- 3.3 Events Maintenance
- 3.3.1 Add a New Event
- 3.3.2 Alter an Existing Event
- 3.4 Email Users
- 3.5 Update Handicaps
- 3.6 View All Members Rankings
- 3.6.1 View Rankings by Gender
- 3.6.2 View Rankings by Category
- 3.7 View All Live Feed of Scores
- 3.7.1 View Scores by Month
- 3.7.2 View Scores by Current Day
- 3.8 Access Help File
Implementation of Mobile Application
When analysing the mobile application, numerous problems were encountered for the actual implementation of the mobile application.
The first problem encountered was how to transfer the application onto a mobile device. After researching the various ways of transferring the application, the easiest way to do this is for the user to download the application and then transfer the application via Bluetooth, USB connection or memory card, whichever is more convenient for the user.
Another problem encountered was how to actually implement the application. Every mobile device is different; whether it is a standard colour phone or a QWERTY device. They also have different device configurations (CLDC-1.0, CLDC-1.1), and different device profiles (MIDP-1.0, MIDP-2.0, and MIDP-2.1). Deciding on which type of phone, which configuration and which profile was the problem.
After going through the possible options it was decided to implement the application for a standard colour phone, with the device configuration set as CLDC-1.1 and the device profile set as MIDP-2.0.
The reason for this is because these settings are used on most popular phones at the moment, and all up-to-date Nokia phones have these settings.
The next issue to be resolved was the user interface of the mobile application. The decision was to use Forms and Text Fields to design the UI. The first form would display information about the application. The text fields would be used for the user’s GolfX username and password, and there is another 18 text fields that are used to enter the user’s scores. The application also has an option to calculate the user’s score before it is sent to the GolfX website.
Here is the UI once the application is loaded. As you can see, the information about the application is displayed to the user. This screen also shows the application with the username and password entered. The second screen shows the first five scores entered on the application.
This screen shows the application with the user’s scores calculated and the second screen shows the application sending the scores to the GolfX website.
The UI of this application is in black and white, but a mobile theme has been created which gives the following background to the application.
When this theme is applied to the application, this background will appear, along with a green font.
Another issue was how to send the scores from the mobile device to the database. There are several ways to do this, but deciding on the best was the problem.
The decision was made to use servlets to send the scores from the mobile device to the database. The servlet would include JDBC and transfer the user’s scores into the database so the user could view them on their online account.
Here is a data flow diagram illustrating what is happening between the mobile phone and the servlet.
Implementation of Online Application
Firstly, the language had to be decided on. After some research into scripting languages, it was between two, JavaScript and PHP. JavaScript is primarily used in the form of client-side JavaScript for the development of dynamic websites, and PHP is a server-side language used for designing dynamic websites.
As both languages have plenty of advantages and disadvantages, it had to be decided whether to use a client-side or server-side language. The decision was finally made on PHP, which would be imbedded in HTML scripts, mainly for the reason that it’s a server-side language. The reason for this was because it is straightforward to access and alter the database, which was needed for the project. Even though JavaScript can be used as a server-side language, it is complicated compared to PHP.
The next issue was the layout of the interface. There are two parts to the online application, the user application and the administrator application. The decision was made to implement the two applications the same way, with the same layout and colour scheme.
Firstly, a HTML page was designed, using a standard layout of tables and divisions. Then, a Cascading Style Sheet (CSS) was designed to give the HTML page some colour and design.
Once the layout and colour scheme was decided on, the PHP scripts were introduced into the HTML pages.


Here’s the layout eventually decided on, without any PHP scripts. The logo would appear on the top of the page. The five header links, as well as the 5 bottom links, would be links to other pages on the website, depending on the user application and administrator application. The picture in the centre is to resemble a fairway of a golf course. The grey section below it will give an explanation of the page, and the white section is where all the information will go, such as user details, events, scorecards, etc. The page here looks a bit empty but when the PHP scripts are included, as well as all the other information, the page fills out and looks very well.
The decision was to use dark colours for the online application. The reason for this is that dark colours, and mainly black, add a contemporary style and a sense of sophistication to a website. The dark blue where the logo appears will add tradition and loyalty. Also, dark colours reduce the amount of energy used by computer monitors.
The section in the middle was left white so that the user can easily read the information on the page.

From here a user can register, log in or view the help pages. An administrator can also log in from here.
Once a user has logged in, he/she is presented with the following page.


This needs to be included in all scripts that are connecting to the database.
The next PHP script is in the ‘Welcome’ field which is the following.

This gets the user’s first name from the database and inserts into the page.
The final PHP script on this page is the information field. The users name, gender, handicap and course is displayed for the user to see.

This PHP code will vary, depending on what information is to be displayed on the screen.
One of the hardest coding aspects of this project was that Update Handicaps function. This is in the administrator application of the system. The updating of handicaps is a complex formula, due to different handicaps, standard scratch scores (SSS), and categories. A buffer score is also used, where your buffer score is the total number of shots minus the standard scratch score for that course.
Handicaps vary from 0.1 to 28.4 for men, and for women, it can reach anything. These handicaps are broken down into 4 categories for men, and five for women.
Category 1 – handicap of 0.1 to 5.4
Category 2 – handicap of 5.5 to 12.4
Category 3 – handicap of 12.5 to 20.4
Category 4 – handicap of 20.5 to 28.4
Category 5 – above 28.4 (only women)
For a category 1 golfer, their handicap gets increased by 0.1 times their buffer score. So if a golfer scores a 66 on a course with the SSS 62, their buffer score is 4 and therefore their handicap will increase by 0.4.
For a category 2 golfer, their handicap gets increased by 0.2 times their buffer score, 0.3 for category 3 and 0.4 for category 4. The same values are used for decreasing handicaps.
The formula produced for this was very long and complex, and needed to be perfect.
Below is part of the code as all the code would be too long.

Use-Cases
1. User on the Online System
- 1.1 Register on the System
- 1.2 Log On/Off
- 1.3 View Homepage
- 1.4 View Scorecard
- 1.4.1 Add Scorecard
- 1.4.2 Get & Print Scorecard
- 1.5 Book Tee-off Times
- 1.5.1 View Your Bookings
- 1.5.2 Delete Your Booking
- 1.6 View All Events1.6.1 View Events by Month
- 1.6.2 Sign Up to Event
- 1.6.3 View Events you have Signed Up to
- 1.7 Access Help Files
- 1.8 Download Mobile Application
2. User on the Mobile Application
- 2.1 Send Scorecard
3. Administrator
- 3.1 Log On/Off
- 3.2 Course Maintenance
- 3.2.1 Add a New Course
- 3.2.2 Alter an Existing Course
- 3.2.3 View Tee-off Times
- 3.2.4 Book Tee-off Times
- 3.2.5 Add a New Administrator
- 3.3 Events Maintenance
- 3.3.1 Add a New Event
- 3.3.2 Alter an Existing Event
- 3.4 Email Users
- 3.5 Update Handicaps
- 3.6 View All Members Rankings
- 3.6.1 View Rankings by Gender
- 3.6.2 View Rankings by Category
- 3.7 View All Live Feed of Scores
- 3.7.1 View Scores by Month
- 3.7.2 View Scores by Current Day
- 3.8 Access Help File
Analysis/Research
Online Application
The analysis of the online application was fairly straightforward. The only decisions to be made were what language to use to implement the website, the layout of the website and what colours to use.
Mobile Application
When analysing the mobile application, numerous problems were encountered for the actual implementation of the mobile application.
One problem encountered was how to transfer the application onto a mobile device. The preferred option for this is for the user to download the application and then transfer the application via Bluetooth, USB connection or memory card, whichever the user feels is easier.
The application could be downloaded onto the club house computer and users can get this application themselves from this, saving them from downloading themselves.
Bluetooth would be the preferred option as most mobile devices are now Bluetooth enabled and the transfer of files is quite fast.
Another issue encountered was how to actually implement the application. Every mobile device is different; whether it is a standard colour phone or a QWERTY device. They also have different device configurations (CLDC-1.0, CLDC-1.1), and different device profiles (MIDP-1.0, MIDP-2.0, and MIDP-2.1). Deciding on which type of phone, which configuration and which profile was the problem.
Proposed System Feasibility
After researching to see what’s already available and finding out that there is quite a few systems already available online, it seems that there is a market available, especially in Ireland, for this application.
Of course there are many practical problems there for this application. The first is whether or not this mobile application would ever replace the card and pencil, which is quick and easy, and it’s hard to see the convenience being bettered by the mobile phone.
Another problem is the fact that mobile phones are frowned upon on golf courses, and some courses even banning them completely from play.
However, there are many advantages to having an online golf system and mobile application. The first is the automatic update of handicaps when the score is registered in the online account. Another is the online booking of tee-off times for members and signing up to competitions.
The main advantage of having the mobile application is that you can have a live feed of scorecards set up in the clubhouse so people can see who is leading. One clubs competition secretary has told me that it would be great to have SMS score reporting after every hole for each competitor, where there is a live feed available.
The advantage of the website is that it will improve communication between the club and members and give information on the club and upcoming events.
Overall, it is clear that this system is needed for every golf club, whether or not its functionality is used to its maximum capacity.
Project Overview
The objective of this project is to create an efficient online golf system for golfers where users can create an online account for the golf club. Here users can view which time slots are available, make a booking, cancel a booking, view up and coming events, and sign up to competitions. The system will send emails to users informing them of events and competitions.
The system will include a mobile application which will allow a user to submit score cards via a handheld mobile device and send them back to a system, whereby scores can be updated automatically on the online system. Once uploaded, the user can print off the scorecards from their home computer.
There is an administrative application where an administrator manages time slots for bookings, competitions, members ranking and time slots for course maintenance.
The administrator can view a live feed of scores which could be useful for competitions to see who is in the lead.
The diagram below shows the overall system layout.
Project Proposal
1. Name:
Sean McCarthy
2. Contact Information:
E-mail: seanmac00@gmail.com
3. Project Title:
Online Golf System
4. Project Background:
This application would be an online golf system, designed for numerous clubs, but only implemented for one club, where users can go online and book tee-off times from their home computer.
There would be an application that the user can download onto their phone, and while playing a round of golf, the user can enter the scores into their phone. When the user is finished, they can save their scores and it will be sent back to the user’s account on the online application. When back at home or the club house the user can print off their score cards and their handicap will be updated automatically if needed.
The online application will give details on the club and golf course for new users, such as hole details (par and distance), address of the golf club, directions to the club and green fees.
A website for the club will increase publicity and help attract visitors, societies and members to the club leading to increased revenue. It will improve communication between the club and its members through e-mails, fixture lists, club news and competition reports, all of which will be done on an administrative application.
There is a need for this application as there doesn’t seem to be many online applications for golf clubs and a Java MIDlet application for recording scores would be extremely useful.
5. Overall Project Goal:
The purpose of this application is to develop a PHP based application that will be run over a network where users can book online and to develop a Java MIDlet application that users can use on their mobile device.
6. Objectives:
(i) Design an online golf system, to allow users sign up to the system, to select tee off times, view up and coming events, sign up to the events and print off score cards.
(ii) Design a mobile application, to allow members record their scores on their mobile devices and send them to their online account.
(iii) Design an administrative application, to allow an administrator manage time slots, competitions, members ranking, handicaps and course maintenance, view a live feed of scores for competitions, and to send emails to members.
7. Development Tools:
Java, JSP, PHP, VB Macros, MySQL, HTML, CSS
8. Learning Outcomes:
(i) Development of a Java application on a network
(ii) Development of PHP
(iii) Development of a Java MIDlet application on a network
9. Software Requirements:
NetBeans 6.5 IDE
MySQL Server 5.0
Tomcat Apache 2.2
Adobe Dreamweaver CS4
Microsoft Excel
Mozilla Firefox / Internet Explorer
Nokia PC Suite
Xpert Mailer Version 4 (XPM4)
10. Hardware Requirements:
Mobile phone with colour display and Java support
Number of computers for development and testing
About Golf X
Golf X is an online golf system, designed for multiple clubs, where users could login and book tee-off times from any computer. There was also a mobile device application, where users could enter their golf scores directly into their mobile, and upload them to their online account. From their account, they could see and print their golf scores. Each user’s handicap was also updated automatically at the end of each month. There was also an administrative application where administrators could manage tee-off times, view live feeds of scores, and email each user with upcoming event details.
The online application was implemented using HTML and PHP, linked to a local SQL database. The mobile application was implemented with J2ME, using threads and servlets to connect to the database.
Development Tools:
Java, JSP, PHP, VB Macros, MySQL, HTML, CSS

