Posts Tagged ‘mqtt’

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.


Using MQTT in Android mobile applications

Tuesday, February 1st, 2011


How to receive push notifications using MQTT in an Android mobile application


I’ve written before about MQTT as a technology for doing push notifications to mobile. When I wrote that, I gave an example Android project. However, it was the first time I’d ever done Android development, and while it was an okay Java MQTT sample, it was a poor Android sample – I didn’t know anything about how Android works as a platform.

I’ve since written other Android MQTT apps, such as a hackday app for pushing updates from websites to your phone and learnt a lot about how to do it properly. Well… if not properly, at least a little better.

But Google is still directing people to my old, and probably unhelpful, sample. So it’s about time that I share something more useful.

I’ve put the full source for a sample implementation below. (Note that I’m using the Java J2EE client library from Hopefully the comments in it are clear enough, but here are a few of the key points.


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


Pushing, pulling, or leaving the door open

Saturday, October 24th, 2009

This weekend is barcamplondon, so another chance for me to ramble incoherently about a technical topic of my choice. 🙂

My presentation started as a bit of a cop-out. I was ill last week and weekend when I was planning to prepare a new presentation, so I decided to give the same talk I did at Over The Air last month and hope that I didn’t get any of the same attendees.

But then I started tweaking it to suit the different audience. Over The Air is an event for mobile developers, so my presentation was pretty much aimed at mobile devs, which wasn’t quite right for a general event like barcamplondon.

Then I started updating it to reflect the feedback I got, both on the day at Over The Air, and through comments and tweets since.

My talk at OTA was a technical “Introduction to MQTT” session.

My presentation for barcamplondon became a broader look at mobile apps that rely on data from the Internet, and the challenges and choices facing mobile app developers who write them.

And I think it’s better for it. I hope it didn’t come across as pimping MQTT. I still talked about MQTT, but this time it was to use it as an example of one of a broader set of choices:

The aim of the talk was to discuss the pros and cons of each approach.


Writing an offline wiki client

Saturday, October 10th, 2009

Friday was the seventh IBM Hack Day, and I again got the chance to spend a day playing with some random ideas.

As Hack Days go, I had a surprisingly productive day! I had four ideas on the day:

  • two mobile hacks (both of which I wrote a chunk of code for),
  • a twitter hack (which never got off the scribbled diagram stage, but it’s an idea I definitely want to come back to), and
  • a hack to extend an IBM product (which I created an alpha version of)

In this post, I’ll describe what I did for the last of these ideas: writing a client app for the wiki that comes with IBM’s Lotus Connections.

The idea

In the same way that I am writing this post in an offline blogging client, I wanted the same for using wikis: read and make changes to a wiki while offline, with changes uploaded to the online wiki the next time you are online.

This wasn’t a new idea. In fact, I tried it at IBM HackDay 4 back in 2007 but the wiki we used at work at the time had no API access for retrieving or updating wiki pages. So I sort of gave up and forgot about the idea.

But now I use Lotus Connections wikis at work. And Lotus Connections does have an API – an AtomPub API that gives you feeds to know when pages are changed, and a way to publish changes.

So I decided to revisit the idea.

The “finished” (ish) hack

It’s still very rough around the edges (this was a HackDay – I wrote the client code in under a day!) but it already shows the basic idea.

Offline wiki client

The top left view shows the list of your wikis.

Clicking on this fills the list below – a list of pages in the selected wiki. Clicking on a page in that list opens the contents of the page in the main view on the right.


Push notifications for mobile apps

Wednesday, September 30th, 2009

Update (1 Feb 2011): I’ve shared some better sample code for Android

Last weekend, I went to Imperial College for Over The Air: a conference for mobile developers.

I gave a talk at the event on how to write a mobile application that uses push notifications. It was pretty well received, so I’d thought I’d share it here, too.

I’ve made some notes below to cover roughly what I said at the event. Any comments or questions (or corrections if you spot any!) are very welcome. 🙂

Update (24/10/2009): I revisited this presentation to address some of the feedback that I got on battery life implications of using MQTT.


Fun with MQTT

Friday, July 18th, 2008

I’ve been quiet for the past month or so, as I was keeping my head down to finish a project at work. It’s done now, so now is a good time to crawl back out of my cave and share a bit about what I’ve been up to. This was for a customer who outsourced a software development project to us.

Some quick background: MQTT is a publish/subscribe messaging protocol that IBM products like WebSphere Message Broker can speak.

Our customer wanted an MQTT library written for the real-time embedded firmware that runs on their products. This client library needed to provide the API of the MQTT specification, implemented within the constraints of an embedded platform with significant resource constraints, and only a subset of the standard C OS functions (e.g. no multi-threading, no dynamic memory allocation, no malloc/realloc/calloc, etc.).