Archive | Programming RSS feed for this section

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!

Updated Requirements

13 Jan

On the basis of the heuristic evaluation, the change in deadline, and weeks of development and testing, I have updated the requirements:

Primary (“Must-haves”)

  • Colour-coded tile screen comparing current weather in different cities
  • Basic set of weather variables to select from
  • City-sorter algorithm to arrange the tiles N to S, W to E on the screen
  • Updating mechanism  – automatic and manual
  • Settings to change the units and update frequency
  • Map-based interface for changing the selected cities
  • Europe-wide coverage
  • Android compatibility (e.g. for resolutions) and design consistency (icons, menus, settings etc.)
  • Easy to use – clean interface, help documentation
  • Gestures to change weather variable on home screen, to complement the buttons that do this too
  • Local storage of data in an SQLite database, updated from a web server which will hold all possible data in a MySQL database, updated from an API.

Secondary (“Should/Could-haves”)

  • City summary to show all data for a single city – accessed from clicking tile
  • Quick view of all cities available and their current data, sort-able by name or value
  • Multiple user-defined city collections for the main screen so > 9 cities can be saved
  • Searchable cities on a map and non-map interface
  • Option to display rank data (amongst all 100+ cities) as well as the absolute values.

Postponed (“Wants”)

  • Drag-able tiles to enable custom arrangement
  • Pre-set city collections for major countries, and “random set” option to generate a collection
  • Animation (tile rotation, colour transitions)
  • Ability to change time-frame of data (max/min/yesterday…)
  • Extensive, customisable set of weather variables
  • Ported to Windows 8  platform
  • Ported to iOS platform.

Removed from previous requirements

  • Reliable data – bad sites to be blacklisted
  • A mechanism for users to report bad data
  • Global coverage
  • Graph-based view.



  • The handling of bad data requirements have been removed after extensive testing, including with users, showed them to be redundant.
  • Global coverage and a graph-based view were deemed to be outside the scope of the app so could conflict with its purpose.
  • Several secondary requirements have been demoted owing to time constraints.
  • The gestures requirement has been promoted following the consideration of Norman’s principles (see that post for detail).
  • Heuristic evaluation and my own testing revealed the benefits of the “quick view of all cities data…” requirement. It will be added if time allows.
  • A few other minor features have been thought up and added to either the Secondary or Postponed list.

Android AlertDialog Bug

9 Jan

I found a bug in the android API: when showing an AlertDialog, you cannot set both a message (setMessage) and a list (setItems or setMultiChoiceItems etc.). They somehow cancel each other and nothing gets displayed. So when using lists, you are stuck with just having a title.

Annoying, but solved thanks to stackoverflow (of course).

Requirements – summary

17 Dec

Based on interviews, private thinking, the brainstorm, competitor analysis, personae, and informal discussions, I have gathered the requirements for my app.

Primary requirements will be implemented for this coursework (Version 1.0 of the app). Secondaries will only be implemented if time allows, else they will be postponed. Postponed requirements will be considered for inclusion in future versions of the app, partially based on the results of feedback from version 1.0.

Primary (“Must-haves”)

  • Main screen with colour-coded tiles comparing current weather in different cities
  • Basic set of weather variables to select from
  • City-sorter algorithm to arrange the tiles in a grid: N to S, W to E on the screen
  • Updating mechanism  – automatic and manual
  • Settings to change the units and update frequency
  • Map-based interface for changing the selected cities
  • Europe-wide coverage
  • Completed to a standard that meets the requirements of apps for the Android store
  • Compatibility with the look of existing Android apps
  • Clean user interface, appropriate feed-back, and a help page
  • Local storage of data in an SQLite database, updated from a web server which will hold all possible data in a MySQL database, updated from an API.

Secondary (“Should/Could-haves”)

  • Extensive, customisable set of weather variables
  • Global coverage
  • Multiple user-defined city collections for the main screen
  • Ability to change time-frame of data (max/min/yesterday…)
  • Gestures to change weather variable or time-frame
  • Searchable cities on a map and non-map interface
  • City summary to show all data for a single city – accessed from clicking tile
  • Ported to be Windows 8 –compatible
  • Reliable data – bad sites to be blacklisted.

Postponed (“Wants”)

  • Animation (tile rotation, colour transitions)
  • Graph-based view
  • Ported to be iOS -compatible
  • Draggable tiles to enable custom arrangement
  • A mechanism for users to report bad data.

Data Model

17 Dec

Data Model


The web server (owned by me) will access the API through a PHP script which is set up (through Cron) to retrieve and store the data every 30 minutes. The data are stored in a MySQL database running on the server. The app will have an Android Service to asynchronously grab and save the data from the server (through a PHP-managed web page to process the request). This data will be stored locally on an SQLite database so that only data needed by the user will be stored, making this is an efficient model. The user database will also have a table of every city available, along with lat/long data so the user can select cities from a maps interface.


Speed –In-app URL-fetching followed by XML parsing is resource intensive and potentially error-prone, especially as 9+ locations are needed. By giving this job to a web service scheduled script, errors can be caught and execution time is fairly irrelevant.

Efficiency – Let’s say a hundred people are using my app simultaneously, and all use London as one of their cities. This means the very same London XML page from the API is parsed 100 times.

Scalability – The API only allows 500 requests per hour, so if my app had very many users (wishful thinking, maybe, but the concept is important), in-app parsing of the API XML could lead to my being disconnected from their service, leading to the failure of  my app. By storing the data on my own server, I am free to scale up the resources as necessary.

Portability: If I had chosen to process the data on the app itself, I would have to code this up for each platform I develop on. In contrast, this model allows the whole chunk of data processing, filtering and storage to occur within a reusable framework (a web server), so it is only written, modified, (debugged, enhanced etc.) once.

App Idea | Motivation

12 Dec

This post aims to cover point one of the HCI specification –

A short description of what your app does and explains the motivation behind building it, for example, what problem does it solve?

The app compares the weather in different cities using a unique colourful visual interface

My app is a city weather comparison visualisation interface. The idea is to have nine cities represented on coloured tiles in a grid arrangement. The tiles will display the city name and the value of the weather variable (e.g. temperature, atmospheric pressure) being displayed. The colour of each tile is dependent on the value, so the effect is an easy visual way of comparing the weather in different cities. The cities can be user-specified by selecting them from a map interface (making use of the GoogleMaps or Bing API). The visualisation interface, “dashboard”, will be clear and simple, and make use of graphics to give the app a modern and mobile-device-specific feel (no desktop-style text-heavy menus).


I came up with the idea because I am a weather fanatic and love to see how the weather in my home city (London) compares to other European cities that I have visited. I created a really quick testing version of the app and already I find myself viewing it several times a day simply because I think it’s interesting. I know that there many other weather freaks out there too, so that is clearly my biggest market. However, I aim to keep the design straightforward enough so that anyone can use it, and hopefully be interested in it too. This probably means not including complex weather variables such as the dew point (though perhaps a setting to add this could be included).

New App

12 Dec

I can now confirm that I will be developing my own app. Whether or not my client app will be continued is uncertain but should not impact on the process of developing my new app.