App updated

21 Aug

The update is complete, but only the top-priority requirements were fulfilled due to my loss of interest in the project. However, all source code is now released on GitHub, and I’ve set-up a home page for the app.

Application Update

30 Jul

I have finally started work on the first update to Europe Live Weather Compare.

I can only work on it every odd weekend or so, meaning only slow progress will be made.

To-do list

Top priority:
Implement new cities
Find a place for non-Euro cities
Add units to webview
Make webview only load the data
make homepage for

Mid priority:
Implement feels-like and wind direction

Low priotiry:
Implement draggable tiles
Allow multiple user-defined city collections
List-based city-selection

List of available cities read from server rather than locally

Project Report

23 Jan

Firstly some admin:

I forgot to generate the javaDoc, so please view that here. Thank you for your understanding.

I only managed to test on two devices – Nexus (small tablet), and HTC desire (medium-size phone). Efforts were made in layout design to be cross-device compatible but I don’t know how successful these were without testing. I therefore recommend that you test my app on a 480 x 800 screen (my main testing device).

Executive Summary


The project was designed to be as re-usable and manageable as possible by using the Model-View-Controller (MVC) approach.
A Singleton was used for the user settings and session variables – this is very handy as it means they can be accessed anywhere (global access) without having to pass objects around, which is fiddly in Android.


This was implemented at the java package level, one package for each.

The Model layer contains the singleton class mentioned above, a static Library of common methods, and the UpdaterService which handles the data update procedure.
The Controller level handles the gesture listening and processing, database access, and the navigation between different Activities
The View layer is just the Activities, so is largely GUI-based code.

See the UML at the bottom for the full class structure.

The Data

A lot of research and thinking went into this, as data handling and management is crucial to this app.

Thankfully I was able to make use of a web server to handle a lot of the processing so that it was abstracted from the app. This is good for efficiency and portability of code.

More extensive discussion is in the data model post.



Android Activities

Most of the app is written in native Android code. Efforts were made to optimise data manipulation to prevent laggy behaviour, which can be a problem on mobile devices. This was especially true on the map view, where over 100 map markers are overlayed. By good object management, I managed to make this screen smooth to navigate. Regarding native Android UI, I followed best practices where appropriate (e.g. using the recommended PreferencesActivity).

The Webview (sortable table of all city data)

This page was a late addition to the app inspired by feedback from user testing, and possible thanks to the deadline extension. Initially my reasoning for using an Android WebView for this was that there would be a large amount of data to transfer over network, so extending a class dedicated to data transfer would make this task easier. I therefore went about designing the webpage and its implementation in HTML/CSS/PHP/JS. This approach has the advantage of  portability (the webpage sits on a server that can accessed from any web browser so it is independent of platform ( iOS, Windows, Android etc.). Despite this advantage, native design is better for user experience, and as it subsequently emerged that the whole webpage is only around 40KB, this approach would have been perfectly feasible. Nevertheless, I am pleased with the end-product, and pleased to have been able to demonstrate coding ability in a range of different languages. P.S. view said page online.



  • As mentioned above, the webview could be made native.
  • Implementation of more of the “wanted” requirements – e.g. multiple city collections, extension to global coverage, porting.
  • Testing on more devices and screen resolutions.
  • More layouts to deal with landscape rotation and to make the app look better on tablets.
  • Move to higher level minimum API so deprecated practices and method calls can be removed.


Here’s the UML of my classes (arranged by layer – View on top, Model on bottom, Controller in middle):


App finish and release onto stores

23 Jan

Now published on Google Play!

I have also submitted the app to Samsung, and they are now reviewing it. It takes about two weeks for a decision, apparently.

Finally available on Samsung store!

User Testing

22 Jan

I conducted a user test with a non-Android App developer who had never seen my app before, but is a user of Android apps. As is traditional, I left the user to explore the system without intervening or allowing questions. This is to determine whether features are obvious and easy to access. The results:

  • User launches app and examines main screen
  • User presses a tile, taking him to the detail view
  • Tries to swipe several times.. system does nothing so he gives up
  • Goes to back to main page and presses the variable bar to change the view
  • User visits the settings, explores, but finds nothing he wishes to change
  • Goes to the table view and plays around… eventually figures out that it can be sorted by clicking the column headers
  • Goes back and visits the map view… clicks a few markers and dismisses them… clicks a marker and sets that location as his new city without problems.
  • Views the main screen and sees his new location
  • Explores the help pages briefly
  • Exits the app.

Key findings

  • User could not get the swipe to work even though that feature is enabled. This doesn’t prevent access to any features but it is handy and neat, and consistent with modern apps. I changed the system to be more sensitive to swipes in an effort to resolve this.
  • The navigation system presented no problems and buttons were readily identified, despite one of the heuristic analysers suggesting that some didn’t look buttony enough.
  • The table view needs a GUI enhancement to make it clear that it is sortable. The user told me at the end that he worked it out because the navigation bar said “Rank View”, but it took him a good 10s to see this so I will enhance the system visibility as this is not acceptable and other users may not be successful in finding this feature.***
  • Dialogs and toasts did not frustrate or confuse user. Excellent.

***Here’s a mockup of the changes I plan to make to this screen:


User testing gives a real insight into how my app might actually be navigated, making it, in my opinion, an invaluable exercise in determining whether all that HCI planning, design and analysis has actually succeeded. Concluding, I have found this process very helpful and would ideally do many more user tests, but with the deadline 24hrs away this is implausible and I must focus on implementing the lessons learned so far.

Heuristic Evaluation (ii)

22 Jan

This second evaluation was shorter and more casual. The expert was an Android App developer looking for violations of Nielsen’s principles.

  • Aesthetic/consistency problem – rows on the table view were too short. This looked poor and was inconsistent with the spacious layout of the rest of the app.
  • Possible metaphor violation – swiping usually causes the screen to wobble or otherwise visibly move. My swipe simply changes the data. The potential complexity of this fix means it may not be implemented.
  • Consistency/metaphor of the buttons – on press, the expert felt they should react by lighting up with a border colour change so that users know it is a button. I agree, and will add this to the implement-queue.

The expert was pleased with the rest of the app, though was not interested to read the help pages. Perhaps that is just the nature of experts, or maybe I should consider condensing them.


Casual screen flow diagram using screenshots

22 Jan


This shows most of the events that occur in the app as a result of button pressing.