Posts Tagged ‘mobile’

My first experience using BlueVia APIs

Sunday, October 2nd, 2011

I wrote yesterday about a quick hack I did at Over The Air using the BlueVia API. I thought it was worth a quick post to show just how simple it was.

Read yesterday’s post for background to the idea behind the hack, but in essence, what I wanted was:

  • monitor the location of my mobile phone
  • send an SMS to a different mobile number when my phone goes into a predefined known area

BlueVia provides an API that let me doing this using network operator data. In other words, nothing needs to run on my phone itself as location data is obtained from where O2 thinks my phone is.

This means there is no battery-life impact on the phone for this monitoring.

It also means this will work with any phone – from iPhones and Androids to cheap feature phones.

The whole thing took me less than an hour and needed only 90 lines of Python.

This is how I did it.


MQTT over WebSockets

Sunday, April 10th, 2011


Extending WebSphere MQ to include support for WebSockets, allowing messaging to web browsers, including mobile browsers, without any additional client software


I’ve talked about MQTT before – a lightweight messaging protocol that I’ve used both on personal projects and my day job.


It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.

I’ve used it in CurrentCost projects, mobile apps and with small and embedded computers like my Slug.

But in all cases, I’ve needed MQTT client software to talk to the messaging server. Whether writing in C, C#, Java or Python, I’ve needed a client library to get me started, something that knows the sequence of packets that make up the MQTT protocol.

It’d be useful to have a zero-install MQTT client: an MQTT client app delivered over the web, without the user needing to install any additional client libraries, or resort to Java applets.

What this does

One possible way to do this could be WebSockets. Part of HTML5, this is a protocol that describes how to do two-way messaging between web servers and web browsers. And I mean proper two-way communication, including push-notification from the server to the browser, without resorting to hacks or kludges like long polling or hidden iframes.

It’s an emerging protocol, still in draft form, but there are a few implementations around so there are already a few browsers that know how to manage WebSockets.

We’ve been exploring recently how this could work with MQTT – the aim was to build in support for WebSockets into an MQTT messaging server: IBM WebSphere MQ (WMQ).

I’ve mentioned WebSphere MQ before, as back in the dim-and-distant past (well, five or six years ago) I used to be a developer of it.

It’s one of the server implementations that support the MQTT protocol.

By adding support for WebSockets to it, it means that WMQ could send and receive messages to web browsers. It means a web app could be a fully-fledged MQTT client.


Making National Traffic Control data more useful

Sunday, September 12th, 2010

or ‘my hack for Over The Air 2010’

National Traffic Control Centre - on AndroidYesterday was Over The Air 2010 – a very cool event for mobile developers, that really warrants a post to itself, but I’m too tired so that will have to wait for another day.

But while I was there, I had a go at the hack challenge. I’m pleased that there was a fair amount of interest in what I did, so in this post, I want to share some of the technical details.

The hack centred around getting access to (pseudo-)realtime data about UK roads. It turns out that there is an effort to make traffic and road monitoring data available in a consistent, interchangeable format: DATEX II.

The DATEX site has a list of documentation for the traffic data made available for England, Scotland, Sweden, Italy, Spain, Portugal, Netherlands, and regions in France and Germany. For a data geek, this was quite a cool find 🙂

I only had 24 hours to play, so started with the data available for England – covering the motorway and trunk roads. The web page includes a 39-page PDF which documents the data that the National Traffic Control Centre publishes for England.

The nice thing about DATEX II being an agreed standard is that although I spent the evening working with the English traffic data, once the code was done, there wouldn’t be anything to stop me using the same code with the Scottish data too.

They publish a lot of data – more than I realised was being collected, let alone made publicly available. This chimed well with the keynote on Saturday morning by the brilliant Tim Berners-Lee, in which he talked about the importance of publicly available data.

The data includes:

  • current and future planned roadworks
  • current and future planned events expected to affect traffic
  • unplanned events affecting traffic
  • the current message being displayed on variable message signs (the electronic traffic signs that can be set to display text messages like “don’t drink and drive”)
  • the current graphic being displayed on matrix signs (those square electronic displays that can display icons like which motorway lanes are closed)
  • information about traffic on monitored stretches of road

This was an impressive list – is it just me, or is the ability to find out what is currently written on the electronic sign hanging over every major road in the country seriously cool? No? Okay… so I’m a geek. 🙂

But beyond the list, what was impressive was the amount of detail.

National Traffic Control Centre - on AndroidFor roadworks, you can find out not only where they are, but what type of roadworks they are – e.g. resurfacing, barrier repairs, bridge repairs, etc., what times of day they will be active, when they are expected to finish, the anticipated level of disruption, number of lanes to be closed, and much more.

For events, you can find out the type of event (e.g. if it’s a sports event what type of sport, if it’s an entertainment event what type of entertainment – e.g. boat show), as well as details about times, expected level of disruption, and so on.

For unplanned events, there are codes for a variety of types of events e.g. Spillages are divided into types like chemical, oil, and – unusually – “shed load”. Accidents are categorised into serious, multi-vehicle, vehicle fire, vehicle recovery, overturned vehicle, and so on. Other event codes include animals on road, people on road, obstructions, severe weather like fog, rain, snow, ice, high winds, etc. And loads more. And again, you get all the detail about times, level of disruption and so on.

For the variable message signs, you get the message text itself, the location of the sign, the source of the message (which authority set it), and so on. For the matrix signs, you get the code for the icon being displayed, the location of the sign, the time the message was set, etc.

National Traffic Control Centre - on AndroidFor the traffic data, you get data divided into monitored stretches of road. In the England data, there were tens of thousands of these road sections. For each stretch of road, you get:

  • current average travel times to traverse the section
  • the typical travel for this stretch of road for this time and day of the week based on historical profiles
  • the theoretical ideal travel time if there was no traffic
  • the current average vehical flow rates (number of vehicles per hour) divided into the length of vehicle – how many vehicles shorter than 5.2m, how many vehicles between 5.2m and 6.6m in length, how many vehicles between 6.6m and 11.6m, and how many vehicles longer than 11.6m (the doc warns that “The accuracy of the loops when classifying vehicle lengths is 1% so measurements around each breakpoint could fall into adjacent categories” – like that’s a problem!)
  • the current average vehicle speeds on the stretch of road
  • the current average occupancy for the road

Not only was it detailed, but it was up-to-date. Data is updated at two-minute intervals if you pay for a premier account, or ten minute interals for the free standard account.

This was awesome. So much information!


Adjusting mobile web font-sizes to fit screen resolutions

Monday, August 9th, 2010

This might be obvious to someone less ignorant in the mystic ways of CSS, but I thought it was worth sharing anyway. 🙂

I was struggling to work out a suitable font-size for a mobile web page. Whether I tried using size names like “x-large”, or values with em, pt, px or %, the same basic problem remained:

CSS - not working

Font-sizes were either too small on smartphones with high-resolution screens, or too large on other smartphones.

If I increased the font-size to look better on a high-res screen, it was too big for other phones. If I decreased the font-size for those other phones, it looked tiny on a high-res screen.


Releasing apps in the Android Market app store

Monday, June 14th, 2010

I’ve just added my first app to the Android Market app store, so I thought I’d write a quick post to share what is involved.

Note: This post isn’t aimed at mobile devs. The process is documented clearly enough that there really isn’t any need. Rather, this was more written at people who are probably never going to write and submit an app to a mobile app store, but who might have an idle curiosity about what is involved getting an app from a developer’s workstation to the app store.

Step 1 – Write the code

click to see full-size version - thanks to PhotobucketThis is really the fun bit 😉

The Android plugin for Eclipse gives you nice integration for publishing.

You can right-click on the project, choose “Export Signed Application Package” and the wizard spits out a signed file ready for publishing.

Step 2 – Register with Android

click to see full-size version - thanks to PhotobucketThis is the painful bit 🙁

You visit the Market site at and pay your $25 to register with Android as a developer. For me, it worked out to a bit over £17.


UK traffic news for Android

Thursday, May 6th, 2010

Update: (April 2011) The app is no longer available

I’ve been travelling a lot for work recently. Most of it has been by car, and on a few occasions, I’ve run into traffic problems that have made me late.

This got me thinking about what I could do to make things easier.

There are websites with traffic info – such as the Highways Agency or motoring organisations like the AA and RAC. They show travel information for a particular region, or the UK as a whole.

But that’s not really enough.

For one thing, I have to remember to check. I’m not a morning person – particularly when I need to get up at 5am so I can drive for hours. Any approach that relies on me remembering to do something isn’t off to a great start.

And it’s too manual. They show me all of the traffic problems, and it’s up to me to manually work out which of them might affect my route. There is too much noise, with too many traffic reports for places that are nowhere near me, or where I want to go. It’s up to me to filter that out.

At any rate, I don’t want to boot up a computer at 5am, so an AJAX-heavy website that doesn’t work on mobiles isn’t an ideal fit anyway.

My ideal approach would be:

My mobile phone is already my alarm clock. It’s the only screen I look at when I get up in the morning, so this is the ideal place to get traffic info.

My mobile knows when I’m going to go somewhere, and where I’m planning to go. It shouldn’t need me to manually check every day – it should check for me automatically, and alert me if it finds any problems.

Showing me every traffic problem is too much. My mobile knows where I am, and where I’m going. I only want to see problems that are on (or perhaps very near) my route. Anything else should be filtered out, leaving me with just the updates relevant to me.

I went looking for a mobile app that does this, but didn’t have any luck. There are a couple of Android apps with UK traffic information (one from the RAC, the other by the brilliant Simon Judge).

They at least get the traffic info into a mobile-friendly format. But they still show you every traffic problem, and only when you remember to check. I couldn’t find anything that meets all three of my needs.

So I’ve written one.

It’s basic looking… and perhaps a little rough around the edges. But it’s a start.

You enter in routes – which is a start and an end location. This can be a town or city name, a full address, or a postcode.

From there, you can either check the traffic now, or schedule the app to check at a later date and time. For regular journeys, you can describe a repeating pattern – so for example, I can tell it to check my route to work every weekday morning at 7am, and my route home every weekday evening at 4.45pm.

The app works out the route, and compares it with known traffic problems.

This can be done in the background, so it doesn’t matter if your phone is switched off when it’s time to check, or if you’re using another app.

If it finds any matches, it puts a warning in the notifications bar. Tapping on this can take you to a list of the problem descriptions, or an interactive map with both the route and the traffic problems marked on it.

It’s pretty neat, even if I say so myself. 🙂

And it’s something that I can see myself using.

So why am I not making it available for others now? I’ll leave that for another post…

Using my mobile as a TV remote control for vdr

Monday, February 22nd, 2010

remote controlsI can never find the TV remote.

Whether it’s slipped somewhere in or under the sofa, or been hidden by the kids, I’m often at a loss to find it.

A mobile phone, on the other hand, is rarely too far from my hand 🙂

So I’ve hacked together a quick app to put a TV remote control interface on my phone. It’s definitely a quick-and-dirty chunk of code, but it does now mean that I can work my TV from my mobile if I can’t find the real remote.

On the off-chance that this is useful to other vdr users, I wanted to share how I did it.


Your data. Mobile. (a hackday hack)

Thursday, November 12th, 2009

screenshot stored on PhotobucketWhat do the following have in common?

Weather Channel Max – an iPhone weather app. StockWatch – an iPhone stock prices app. CNN Mobile – an iPhone news app. FlightTrack – an iPhone flight updates app. Tweetie – an iPhone twitter app.

They are all apps which provide users with updates to their phone when some information changes. The information in question is different. But they’re all ways for users to get information that they are interested in, while they are on the move.

Having a dedicated hard-coded app for each type of data is great for information that a large number of people are interested in.

For example, there are enough people who are interested in the weather that it’s worth having an app dedicated to it.

But what if you want updates for information that isn’t so widely needed? What about niche interests?

We’re all different. There is going to be something that you’re interested in that not everyone else is. Or at least a particular set of interests that noone else exactly shares.

People’s needs and interests are almost infinitely varied, so we can’t come up with enough applications to meet everyone’s unique needs. Particularly for more esoteric topics, which are too long tail to each justify a specific mobile app.

For these situations, we need something generic that individual users can customise.

This was an idea I played with on the last IBM HackDay. I managed to get a proof-of-concept working on the day, but not had the chance to share it before now.

What I tried to create was:

  • a generic mobile application – something that can display an arbitrary number of bits of information
  • a browser extension approach – some way that a user can pick any bit of any webpage, adding it to their list of information that will be pushed to their mobile

I’ve recorded a video of it running. (Difficult to see without full-screen – sorry!)

To summarise, the steps involved are:

  1. User visits a webpage at their computer
  2. User highlights a portion of the page, and uses a Firefox extension to register this with my notifications server
  3. The notifications server informs the mobile app of the new topic of interest
  4. The notifications server continues to monitor the webpage
  5. When the highlighted portion of the webpage changes, the updated contents are pushed to the phone
  6. The mobile app notifies the user of the change