Last week was a hectic one. I had a coursework deadline for my Adaptive Learning Agent Systems module, and a exam for Static Analysis and Verification. Amongst all the work I received my results for my Topics in Privacy and Security Module.
The module was assessed by a 100% weighted coursework for which the aim was to develop both a security risk management strategy for a telehealth company and develop some software to determine the best reputation metric for a star-rating system for e-commerce websites to reduce the effect of self-promoting and slandering attacks at different scales.
For the security risk management strategy the ISO/IEC 27002 and ISO/IEC 27005 standards were followed. Assets, user roles, system boundaries and businesses processes were identified, possible violations were considered, threat agents and paths were analysed and critical analysis of which risks had to be managed and which controls to use to mitigate their risks took place.
I used the programming portion of the coursework as an opportunity to learn cross-platform GUI development in Java, using JavaFX. As of the time of writing JavaFX still doesn’t support simple dialog boxes without a host of libraries… which made it interesting. However, it was quite impressive to see ‘write once (carefully), run anywhere (conditionally)’ work in action. I also used it as a chance to try out a form of more modular development, in which all of my business logic was in a library which any GUI could tap into, whether that be a Java Servlet, JavaFX or Command Line program. For the coursework I developed both the aforementioned GUI and a simple Terminal Interface, both running on the same shared .jar library.
Thankfully, now that this week is over, so is the taught portion of my masters degree. For the next 4 months I will be working on my research project, which will be discussed in a future blog post.
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!
I’ve posted a lot of non computer science blog posts recently, but this is supposed to be “the blog of a budding computer scientist!”. So here’s a post which I hope will help a few of my fellow computer science bloggers who use the WordPress blogging platform — which by the way is fantastic.
Quite often when I see blog posts that contain source code it’s formatted in an annoying way, doesn’t have any colour coding or in a worst case scenario is a screenshot of an IDE. It’s impossible for people to copy your code if you take a screenshot of it, and in my experience if you post your code online you want people to copy and adapt it for their own use.
On wordpress you could use <pre> tags in the HTML editor to make code boxes like the following:
//Here's some <pre> formatted code
public static void Main()
Thats all well and good, it keeps the code seperate from the content of the blog post and gives it a different font and background colour to differentiate it as code, however those of us who are used to working in an IDE, such as Visual Studio, with its syntax highlighting may find it less friendly to read. This is where one of WordPress’ best features comes in.
//Here's some [ sourcecode ] formatted code
public static void Main()
All you have to do is wrap your code like so
[ sourcecode language="LANGUAGECODEHERE" ]
[ /sourcecode ]
Without the space in front of sourcecode (Which I’ve had to put to prevent WordPress from actually making it into a source code box). You then have to replace LANGUAGECODEHERE with the code corresponding to the programming language you are posting: