Linking the three Sections

This is the most important part of the project - if the sections cannot be linked together then we only have 3 individual parts which do not pass information between them.  


We've allocated all of the time between now and the bench inspection for linking, testing, and refining the code.

Quitting the Application

It was found that the accelerometer does not turn off when the application had quit by the user and so the phone continued to vibrate. This is because android does not close an application but lets it continue to use some of the memory.

A way of stopping the accelerometer was devised so that the phone didn't  continually vibrate.

Method 1.

Use the onDestroy method, code for this is shown below:

protected void onDestroy()//Stops all activity when it is Destroyed

{

   super.onDestroy();

   // After this is called, your app process is no longer available in DDMS

   android.os.Process.killProcess(android.os.Process.myPid());

}

Method 2. - Overwrite Back button to close application when pressed (Android doesnt allow the Home Button to be overwritten) Code for this is shown below:

public boolean onKeyDown(int keyCode, KeyEvent event) 

{ 

if(keyCode==KeyEvent.KEYCODE_BACK) 

{ 

this.finish(); 

return super.onKeyDown(keyCode, event); 

//Overrides the Back Key to quit Activity when it is pressed

}

Chris

Extras to the GUI

The application worked at a basic level, in order to make it more exciting to the user extra features could be added to it. The two ideas which were to be implemented were:

1. Using the Accelerometer to make sure the user is holding the phone flat, vibrating if it isn't
2. Reading whether the shot is to be a hit or miss to the user.

A lot of modern phones running the android operating system contain accelerometers within them, they also contain a vibrate function normally used when the user wants the phone to be quiet.

The android website contains an example of using the accelerometer:

http://developer.android.com/resources/samples/AccelerometerPlay/src/com/example/android/accelerometerplay/AccelerometerPlayActivity.html

There is also the source code for using the Vibrate function which is found here:

http://developer.android.com/reference/android/os/Vibrator.html

When the activity is created, a new sensor manager is set up which 'listens' for a change in the sensor values, the threshold was set as 1 or -1 in both the x and y direction for the vibrate function to be turned on, the implemented code is shown below:

 Vibrator v = (Vibrator) getSystemService(Context.VIBRATOR_SERVICE);

  v.cancel();

// check sensor type

if(event.sensor.getType()==Sensor.TYPE_ACCELEROMETER){

// assign directions

float x=event.values[0];

float y=event.values[1];//Measure the Acceleromter in the X and Y direction

if(x>1||x<-1||y>1||y<-1){//Occurrs if they Exceed defined values

 

v.vibrate(1000);//Makes Phone Vibrate for 1 Second

}

Chris

Extracting the Data from the Web-server

The application requires that the phone gets the data back from the web-server.

This data is to be a result integer which is a '1' if the shot is to be a hit or a '2' if it is to be a miss.

A method of doing this is to use JSONS (http://www.json.org/)

The JSON is built on two structures:

1. A collection of names and Values
2. An ordered list of values

Twitter uses JSONS in order to store a users tweets and they can then be accessed by applications

The New Boston offers tutorials on the application side of JSONS

http://thenewboston.org/watch.php?cat=6&number=150

The tutorial returns the last tweet of a twitter user.

The server then needs to store the integer as a JSON so that it can be accessed using similar code.

To make creating the JSON objects simple for amateur developers, Google have created an API which can be used to create the JSON objects. This source is found here:

http://code.google.com/p/json-simple/

After this the integer from the physics engine was returned to the phone as a string.

User Preferences

A good application allows the user to modify some of the software properties in order to match their needs and tastes. This is where preferences are used.

For our application, our preferences would be :

1. User Name - A string with the users name(Needed if we were to use a database)
2. Manually Re-Take Photo, the user can choose whether the application would re-take a photo automatically or do it manually. This is a checkbox and returns a boolean.
3. Camera Timer, user can user the length of time the camera waits before taking a photo, can range from 2-5 seconds.

The New Boston offers tutorials on how to integrate user preferences with an Application:

http://thenewboston.org/watch.php?cat=6&number=54

The finished preferences are shown below:

Chris

Tidying up the Code

Before the sections are combined, the code needs to be tidied up.  This involves removing all statements that are printed into the command box as the program is running.

As a result, the program will be able to run quicker and more efficiently

Grace

Cue Direction

The cue direction is taken from the Data Acquisition section and passed via the Web Server to the Physics Engine.  


It can be used to set the initial ball direction.. One of the initial assumptions is that the cue is always set up to hit the ball straight on so that it can be assumed that the cue ball will always move in the direction of the cue.

Updating the Physics Engine

A more Updated version of the Physics engine was ready to be placed on the Web Server.

The physics engine was being tested by using a mouse click to place a ball and create a movement vector on the ball which simulated the shot.

For the web server, this mouse click was undesirable and it was required that the mouse handlers be removed which is difficult since the mouse clicks determine the ball positions.

Instead of the mouse click determining the position of the balls, a 2-d Array which acted as a map was used, this contained a value of '2' where the balls where. The location of the twos gave the co-ordinates of the balls, and so a ball was placed at the co-ordinate.

It was tested using a perfect circle drawn on a rectangle on microsoft paint. This didn't include the scaling algorithm and so the pixel co-ordinate matched the table co-ordinate.

Chris

Camera Resolutions

It should be noted that throughout the development of the project, testing is an ongoing activity

The image upload process has been tested on several phones (HTC Explorer, HTC Desire and HTC Desire S) When the program is tested on HTC Explorer and HTC Desire the image has a resolution of 768x1024 but when the HTC Desire took an image, the resolution was 1952x2592. This image was too large a file for the server to accept.

IT was decided that all photos that were taken should be of the resolution 768x1024.

In order to set the resolution of the Camera, several steps must be taken by the software:

1. Camera Hardware needs to be asked what resolutions are supported, this is returned as a list of heights and widths
2. List is then to be scanned for right resolution
3. Once Resolution found, list number is returned
4. Camera Set at correct resolution by the list number

The list is also shown to the user in the instructions so that they know which resolution is suported and whether the correct resolution is available:

Creation of the Tab Layout

The Tab layout view was created showing the 3 tabs which run in tandem with each other. The user can quickly switch between all the activites. Below is the Picture showing the Instructions to the user

Above is the Camera View which uses a surface view to take a picture

 This is the Web View which shows the web page output to the user (Note: Server was off at Time of Writing)

This is the Splash screen which was initially displayed to the user