Mobile Devices and Applications Coursework Result – 100%
On Monday 12th May our Mobile Devices and Applications coursework was due in at 9am and I had to demonstrate mine at 1:30pm, which was a very quick turn-around! At the demonstration I received my grade of 100%, which I was of course very happy with.
The coursework this year was to develop an Android Application called AMULET – “An m-health (mobile health) tool for the valid self-assessment of alcohol-induced impairment” for a real-world research project in the University of Hull’s Social Sciences Department. In this post I will briefly outline the functions of the application.
All users of the service had to sign up to use the AMULET service, which keeps track of all their data. They could do this inside the application itself, and information could be synced with however many devices they decide to use. The interaction with the AMULET web service is via a RESTful JSON API. The user could also manage their account from within the application including deleting it and changing its password.
The main point of the application was for users to be able to self-test various attributes and skills whilst sober, as a calibration, and then compare this score with their current score at the time of intoxication. Users were asked to input details of their current drinking session before taking a test, and shown results afterward.
The Inspection Task measures the users speed of information intake. It does this by showing the user 8 sheep and changing one of them to be a wolf for a small period of time — 100ms — the wolf then changes back to being a sheep and the user has to select the correct sheep. If the user selects the correct sheep then they complete the same task again, this time with less time — it goes down in 10ms increments. When they eventually fail this is their recorded score. A sober person should manage a time around 60ms.
The Sequence Task measures the users ability to locate information. It does this by asking them to tap every number, in order, from highest to lowest. The users score is the number of seconds it takes for the user to complete the task.
Finally, the Pilot Task measures the users ability to split their attention between multiple objects. In this task the user has to drag around the white square and keep it away from the red enemy squares. The recorded score is the amount of time in seconds the user avoids the enemies.
In my implementation each task had 3 different difficulty settings; easy, medium and hard.
In the inspection task on easy mode the sheep would change to a wolf (which was both a different shape and colour), on medium mode the sheep would change to a purple sheep, (which was the same shape but a different colour) and on hard mode the sheep colour would change only slightly.
In the sequence task easy mode makes the user count to 9, medium mode makes the user count to 16 and hard mode makes the user count to 28.
In the pilot task the enemies move faster at the higher difficulty settings, and believe me it gets rather tough. Different calibration scores and results are stored for each setting, meaning users can’t calibrate on hard and then compare that score to an easy result when drunk — because that would be cheating!
Before each task the user was shown the task brief, which allowed them to access instructions for the particular task they were about to start. At the end they were shown the task finished screen, which compared their results to a calibration or prompted them to make one. At any time the user could go to the home screen and tap “task history” to see their results from the past.
Drink Diary & Unit Calculator
As well as keeping track of the users abilities at times of sobriety and intoxication the application also kept track of the users drinking habits through a “drink diary”. This diary allowed users to enter information about a particular brand of drink including the brand name, alcoholic % and portion size, and then store how many they had drank along with a timestamp.
A unit calculator was also included for the users convince. The user could input the number of drinks they had consumed, the class of drink (e.g. Red Wine, White Wine, Average Strength Beer), and the portion size and be given a reasonable estimate of the number of units consumed. This functionality was also called when the user input drinks for the drink diary, to make data entry easier.
RESTful Server Interaction
One of the most interesting parts of the coursework was ensuring we stuck to the standard required by our lecturers server to send and receive data. This server allowed for research to take place on the information submitted by users, backed the data up and allowed users to carry information from one device to another.
All drink diary entries and task results were synced.
Though the design of the application was very “windows phone-eseque” it was somewhat unique and supported many of the android features users have become familiar with; such as landscape and portrait support, different screen resolution support (from 3 inch phones to 12″ tablets and above) and notifications for long running processes such as data upload.
Thoughts on Developing for Android
I thought this coursework was a really nice way to pick up the programming language Java which, until now, I hadn’t needed to use. It’s similar to C# in a lot of ways with a few of its own idiosyncrasies, but a lot of the industry (and The University of York) use it extensively, so its a good thing to have learnt.
It was also interesting to have developed an application which worked across mobile phones, from small 3 inch screen devices, to much larger 12 inch tablets. This made me really think about the best way to develop the user interface, and I think I found a good compromise — it was certainly at least usable on all of these devices.
The main issue a lot of people had, including myself, wasn’t with Android itself, or indeed Java but rather the Eclipse IDE which most android developers use when writing applications. We all know that Visual Studio is in a class of its own, but it was a bit of a culture shock to change to an IDE that didn’t support debugging in quite the same way for example. Having said this I think this ability to switch between development environments is a good skill to have picked up. The other issue was just how slow the default andoird emulator is on a non-intel PC — but this can be solved through the use of Genymotion.
I will be getting my results for the module as a whole, along with my final university grade itself on the 2nd of July. I will of course update the blog then!
- 55,331 hits