Push notifications for mobile apps

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.

Note that the thumbnails below are just to show which slide the notes below go with. See the actual slides (in Flash format or downloadable PDF) for better quality images.

The talk was intended as a developer’s workshop, with a number of code samples and walkthroughs.

It seemed safe to assume that an audience at Over The Air wouldn’t be afraid of looking at a little code!


As mobile data plans get more affordable, mobile developers are writing apps making more and more use of the network – relying on data on the Internet and from web services.

And the more we do this, the more we hammer our user’s batteries.


I didn’t want to labour this point at the event – for fear of trying to teach mobile developers how to suck eggs!

In many situations, for mobile apps which need to react to some data from a remote server, it is more efficient for changes to the data to be pushed to the mobile, rather than for the mobile to repeatedly poll the server.

Polling is generally an unsatisfactory compromise. Polling infrequently results in an application which can appear slow to respond to changes in the data – for example, polling every 30 minutes could potentially result in an application which takes 29 minutes before it notices the queried data has changed. Polling very frequently mitigates this, but at the cost of increasing the app’s battery usage.

It’s better for the mobile app to do neither – and simply wait for the server to tell it when the data changes.

Apple have popularised this approach, with a lot of talk around the iPhone’s Push Notification Service.

They also use this as an alternative for any task which would otherwise require background threads – run as much code as you can on central servers where battery life is less of an issue, and have the server notify the mobile app when there is something to bring to the user’s attention.

Apple aren’t the only ones doing “push”, of course.

BlackBerry have been doing this for email for years, and they have an SDK which allows push notifications for other applications.


Vodafone’s betavine also offer a push notification API.

I think it uses an SMS-based approach, however I’ve not tried it for myself.


Alternatively, you can implement your own home-grown approach. Many mobile platforms allow you to intercept incoming SMS messages before the user sees them.

You can come up with a custom SMS data format that can be interpreted by your app, and this gives you simple push notification. However, the cost of sending SMS makes this an unpopular approach – you wouldn’t want to write an instant messaging client using SMS as a transport, for example!

My talk aimed to introduce developers at Over The Air to another approach: MQTT.

While it’s not necessarily ideal for every situation, my hope was that it would at least be new to my audience.

At a worst case, it’s another tool for their toolboxes – another approach to consider when they next need to implement a mobile application that might otherwise poll a server.

The obligatory disclaimer slide.

MQTT is a protocol created by my employer – IBM, and the approach outlined in my talk relies on server software available from IBM.


I wanted to be clear that this was not a sales pitch. I don’t work on commission – I’m a geek not a sales person, and have no interest in selling anything, particularly at a tech event like this.

Everything that I demonstrated can be downloaded for free. The MQTT specification is published and used by companies other than IBM.

As I have blogged before, I use MQTT for a lot of my own personal projects. I have an MQTT broker running in my house that I use for stuff like home energy monitoring. I use it because I think it’s good, and I wanted to share it for that reason.

MQTT is a lightweight way to connect multiple clients together: both mobiles and code running on servers.

Everything goes through a central message broker which is responsible for getting messages to and from the different clients.


To send a message, a client “publishes” it to the message broker.


The message broker delivers it to the correct client(s).


Publishing a message needs two things.

Payload : the data you want to send



And a topic.

This is how you address the message – by identifying what the message is about.

I used an example topic structure from a developerWorks article to explain how topics are hierarchical.

The “Topics” section of the article does a better job of explaining this than I probably did in my talk. 🙂

A client identifies what messages it wants to receive by “subscribing” to a topic.

For example, recalling the sample topic structure from my last slide, a client can subscribe to get updates about the arrival time of a specific flight flying into Heathrow.



If another client publishes an update with information about the arrival time of a different flight – our client will not get it.


We will only get messages published – in this case – with updates about flight 1024.


You don’t have to be so specific.

Wildcards are supported – either for a specific level of the topic tree structure, or for a whole subtree.


I gave an example of subscribing using wildcards.

For example, again referring back to the sample topic structure I showed, a client can subscribe to get updates about the arrival time of any flight for any airline coming into Heathrow

The first “+” is a wildcard for the airline name, and the second “+” is a wildcard for the flight number.


Or it could subscribe to receive any flight time updates for Heathrow – arrivals or departures, for any airline, for any flight number.

I think I may have been labouring the idea by this point! 🙂


Another example to demonstrate topic strings, this time translating twitter following into MQTT terminology.

You could subscribe to receive my tweets (“twitter/tweets/dalelane”), or everyone’s updates (“twitter/tweets/+”).


Topic strings are completely arbitrary – and as the developer, you can decide on how to structure your topic tree hierarchy.

A more complex topic tree could let you subscribe to only get my updates if I sent them from TweetDeck (“twitter/tweets/TweetDeck/dalelane”).

Or get anyone’s updates if they sent them from twhirl (“twitter/tweets/twhirl/+”).

Or get all of my updates regardless of what client I used (“twitter/tweets/+/dalelane”).

Or get everyone’s tweets regardless of client (“twitter/tweets/#”).

With the basics out of the way, I moved on to using MQTT for mobile.

First, a review of the traditional polling approach: a mobile app which polls something in “the cloud”.


With MQTT, you can move that polling to a server.

Let an app on the server (where you don’t care about battery life, etc.) poll the web service.

And use MQTT to push it to the mobile when it gets something of interest.


You end up with something like this.

The cogs represent the code you write – some of it lives on a server (probably the same server as your message broker) and polls the web service.

When it gets something different back from the cloud web service, it publishes it to the message broker.

Your mobile app can choose which updates of interest it receives from the broker.

Your code – both server code and your mobile app – uses MQTT to communicate with the message broker.

And the server code is free to query the cloud however you want.


The point is that we’ve moved polling to the connection between the web service and your server code – where battery life is not as expensive.


That was more than enough theory.

Time to walk through an example app: an MQTT Hello World.


First, you need the message broker software to run on the server.

You can download one for free from IBM alphaWorks.


What you get is a zip file with versions of the server software for a variety of platforms, including the obvious (Windows, Red Hat, Ubuntu, Mac OS, etc.).


It is very configurable, but for now, you can just run the executable – and the server is running.



As a quick aside, I highlighted that the server output on the previous slide showed that the server was listening on port 1883.

This is the assigned port number for the MQTT protocol, which is why it is used by default.

You can change this if you want to use a different port number.


Now we need an MQTT client – something to send and receive (to publish and subscribe) messages to the broker.

The Java client is an easy place to start.

Again, you can download it from an IBM site.


The zip file you download includes a jar with a sample Java client.


Just run the sample jar …


… and you get a little GUI utility app


For my first code-free example, I used two clients, so that I could send and receive messages.

First thing I did was give each client a unique name.

Imaginatively, I used “client1” and “client2”.


Once that’s done, I clicked “Connect” on each GUI.

The server output showed the connection of each client.

Note that you need to specify the address and port number, but I just left the localhost:1883 defaults for this demonstration.


For my first example:

On client1, I subscribed to “dalelane/hello/world” by entering the topic name and clicking Subscribe.

On client2, I published a message by entering the topic, and the message payload and clicking Publish.


The message was received by the first client and displayed here.

We sent our first message.


I also demonstrated wildcards, using the client GUIs to subscribe to “hello/#” and then publish to any topic string that starts with “hello/”.


I also highlighted that I could subscribe to as many topics (with or without wildcards) as I wanted.

The GUI is good for learning, practising and testing. But it is obviously more interesting to try doing it yourself from code.

The Java client zip I downloaded earlier includes a smaller client library.

I used this to give a walkthrough of a simple Java application that I wrote for my presentation.

The same three operations apply : connect, publish, subscribe.

First, I need to connect to the message broker. I went through the couple of lines of code necessary to do this, highlighting where you provide the hostname, port number and unique client id, as I did before using the test GUI.


To publish a message, you just call the publish method, giving it the two bits of information I mentioned before: the topic and the payload.

The payload needs to be in bytes, so I just got the bytes from the test string my sample app published.


To subscribe to receive messages, there are a couple of things that you need to do first.

Firstly, you need to implement one of the MQTT callback interfaces. I used the simple one, “MqttSimpleCallback”, for my sample.

Secondly, I registered to receive call backs from the MQTT client library.

Once we’ve done this, we can subscribe to a topic string.

I showed how the code allows this, and highlighted again that you can subscribe to multiple topics – either in a single subscribe() call, or by making multiple calls to the subscribe method.


I demonstrated using Java because it’s a nice, easy start.

But I explained that you can do the same from other languages if you prefer.

As I noted in my talk, not all of the client libraries I mentioned have been produced by IBM. The MQTT spec is published, so some developers have implemented client libraries in their language-of-choice and shared it with the community.

As a result, I cannot comment on the quality and/or completeness of some of the implementations.

The point remains, however, that you have a lot of choice as a developer in how to use MQTT.


The Java client library runs on many mobile platforms.

For example, Android.

To support any possible overnight hacks, I created a “Hello World” project for doing this MQTT stuff from an Android phone.

I don’t have slides to walkthrough my sample Android code, but I shared both the source code for the Android app as a zipped Eclipse project, and the compiled, installable Android application.

As I mentioned at the time, it’s important to note that this was the first Android app I’d ever written.

I shared this as an example of how to do MQTT, not a sample of how to write an Android app. For all I know, as an Android app, it’s garbage! 😉

(Although, that said, it seems to work okay.)

And here is my sample app running, with buttons to connect / disconnect to a message broker, subscribe / unsubscribe to message topics and publish messages.


I used the sample Java MQTT GUI on my desktop as before, but this time to publish messages to and from my Android phone.


That was pretty much the end of my how-to talk.

I used the rest of my time to go through some examples of what could be done with push notifications to mobiles using MQTT.


To start with, twitter.

Each of the twitter clients I have on my mobile phones poll twitter for new tweets. Typically, they let the user specify how often they should poll. Poll very often and you can drain your battery in hours. Poll infrequently, and you might not receive a message for quite a while.


Why not poll twitter as frequently as you like from a server app?

Then use MQTT to push the tweets I’m interested in to my phone.



The twitter API is simple enough that I threw together a quick test app for my talk that could be run on a server.

It polls twitter.com and republishes tweets or replies I receive to the message broker.



I demonstrated how I can subscribe to receive these published tweets on my Android MQTT app.

As I mentioned while I talked about topic structures before, clients can as selective or as general as they want when they subscribe.

In this slide, I showed a client subscribed to get everyone’s tweets. More usefully, you could only subscribe to get tweets from a particular subset of the people you follow.

This would mean more than just not displaying tweets from other people you follow.

When you subscribe you tell the message broker which messages you want to receive. It wont send you anything else. (And you’re not polling needlessly in the meantime.)

If you subscribed to get tweets from a single person, you’d only pay the network and battery life hit on the mobile when they actually tweeted. (Even if the server app is needlessly polling every minute.)

My sample Android app isn’t very pretty, and this isn’t something you’d put in front of a user as a Twitter application.

But even now – after just a couple of hundred lines of code – we’ve got something very powerful.

Other things we’ve done using MQTT for mobile include apps like this: applications which let a user specify information that they want to be informed about.

If the specified information changes, this is pushed to the mobile app immediately. Each update also includes information about what the user can request in response.

The simple example shown in my talk was getting updates if the lamp in our office is on or off. In response, a user can remotely switch the lamp on (if it’s off) or off (if it’s on).

Other examples include allowing users in an office environment to subscribe to receive notifications relevant to the office where they are working.

This could be subscribing to receive fire alarms or other emergency notifications to their mobile – particularly useful for deaf users who might not hear a conventional fire alarm.

This is also a good example of situations where polling is not good enough. With something like a fire alarm, you want the mobile to receive the message immediately. You can’t afford to wait for a mobile app which polls every 30 minutes for example.

I shared a few more links about what I talked about. And that was it.

I was pleased that the talk sparked a lot of questions and discussion.

There were several questions about the difference between MQTT and other technologies such as XMPP, SIP, and pubsubhubbub.

I was also pleased to have a couple of guys from Ericsson who talked about their Mobile Java Push API. They also had some interesting material to share, such as a graph showing the relative battery impact of different polling periods vs their push API.

I hope people found the talk useful. I was certainly aware of a number of people who downloaded a message broker and client to give it a try for themselves, which I guess is a good sign!

As I said after my talk, if anyone has any questions about doing mobile push notifications using MQTT, please do feel free to get in touch.

Tags: , , , , , , , ,

53 Responses to “Push notifications for mobile apps”

  1. […] push-based approach is much more efficient – each web page tells the server which match it is interested in, and when a new score is […]

  2. thanks for sharing, I have never seen such a great site before

  3. […] push notifications (by dale lane, https://dalelane.co.uk/blog/?p=938) Alongside the standard polling and long polling techniques to retrieve new data from a mobile […]

  4. dale says:

    Update: I just came across an interesting blog post on doing push notifications to Android from the experience of developers of foursquare’s Android app – worth a look if you are looking into doing push to Android.

  5. Interesting though I ask myself “How does it compare to XMPP?” which has proven to work well on new generation mobile phones.

  6. dale says:

    Sylvain

    Thanks very much for your comment

    The blog post I linked to above says:

    XMPP/Jabber is even worse. Not only is xmpp/jabber a very chatty protocol, but as it works with one long xml stream, the disconnected nature of a cell phone does not jive well with it… holding an open xmpp connection is probably a very bad idea.

    To be honest, I don’t know XMPP very well, so I am not really well placed to know how fair this comment is.

    The fact that is XMPP is XML-based certainly means that it will have a larger overhead per message than MQTT (which has a *very* low overhead in terms of additional bytes per message sent), which is an important factor for mobiles.

    It’d be interesting to see a proper comparison, though.

  7. Sylvain Hellegouarch says:

    Considering that XML is massively compressible, I’d say size doesn’t matter. XMPP is indeed verbose however but also very extensible which may make it more attractive.

  8. dale says:

    Sylvain

    I’m reluctant to write-off message size (with the battery and bandwidth issues it creates) as I think it is an important factor for mobile apps. And while compression is a useful strategy, I would expect that it would be equally useful whichever protocol you went with – in which case, the size of the message to start with is still a factor.

    Extensibility is an interesting point – what sort of extension do you mean?

  9. Sylvain Hellegouarch says:

    Well, we have actually run tests at work on Android phones which have showed us that XMPP long connections (not BOSH) weren’t consuming more than one of HTTP ones.

    We weren’t using compression mind you because there was an issue with the Android SDK and SSL.

    Regarding extensibility, I mean being able to define more to the core protocol, look at Google Wave for instance.

  10. […] 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 […]

  11. John says:

    Great write-up Dale. I used your android client code to write an android service that places notifications in the task bar, and it seems to work great so far.

    I’m curious, what is the licensing situation for the IBM rsmb? I see that the license is only for evaluation purposes. What if someone wants to use it in a commercial app?

    Looks like there’s also an open source MQTT broker in the works at https://launchpad.net/mosquitto. Any experience with that yet?

    Thanks,
    -John

  12. dale says:

    John – Thanks for the reply, glad it was useful!

    I’ve just started to do something useful with MQTT on Android, and something I’d add since writing this first attempt was that creating the MQTT client in the Activity constructor isn’t a good move – I didn’t realise how often that gets called (e.g. when the screen is rotated) so in my latest app I’ve made the IMqttClient a static and moved it outside the Activity instance.

    As for licensing…. I’m not 100% sure (I’m a code monkey, and try to avoid stuff like sales and licensing issues!) but I think that you’re right that RSMB is intended for non-commercial or evaluation use. If you wanted to use it for commercial purposes, you’d need to move to something like Microbroker, for which there would be a license fee.

    Finally – I hadn’t heard of mosquitto – many thanks for the heads-up. I’ve seen open source MQTT clients released before, but this is the first open source MQTT broker I’ve heard of, so it’s great news! 🙂

    Kind regards

    D

  13. Ryan says:

    First of all, thank you for posting this blog.

    It was so helpful for me to understand how to work about push.

    I just have a question.

    It is that if andriod phone’s network configurartion is changed, I have to connect to server and re-subscribe?

    I think there are so many cases you have to consider.

    1. from 3G to WiFi

    2. from AP in office to AP in home

    ..

  14. dale says:

    Ryan – You do need to reconnect, but there is a callback method on connectionLost, so that’s pretty easy to do.

    (I also use the Android OS callback methods for network connectivity to help with this, so if the MQTT connectionLost method is called because the phone is out of signal area, my code gets called back to let me reconnect to the broker when it has a network connection again).

    You don’t have to resubscribe, and (if you want) you can get the broker to send you anything you missed while you were offline when you re-connect.

  15. Ben Tobin says:

    I’m working on an Android app that uses MQTT for push notifications, and I’ve found your example very useful as a start. Thank you.

    However, I’ve discovered a number of things that I’ve had to do in order to make the connection robust and consistent on the Android platform. First, I noticed that the client often misses its ping timeout when the device is asleep. The server never receives the ping, and disconnects the client, which then gets its connectionLost method called, and can reconnect. I seem to recall that certain Java timing methods cannot be relied upon to be accurate while in sleep mode, so I set up my own Android-based alarm and receiver to perform pings at intervals of 90% of the configured period. That seems to have solved that issue.

    The second issue, and one that tends to be more of a problem practically, is that the connectionLost method often does not get called when the device switches between Networks, as Ryan mentioned. I don’t know the underlying implementation, so I don’t know if this is something that can be fixed in the MQTT client API. It may again be a quirk of Android. I thought that perhaps sending a manual Ping at this point might force the client to realize that it’s disconnected, and cause it to call connectionLost. This does not appear to be the case. I call the ping method, but the server never receives it, and the client never calls connectionLost.

    In order to handle this case, I set up an Intent listener for “android.net.conn.CONNECTIVITY_CHANGE”. I get the NetwokInfo object from the Intent and, using the coarse network state, watch for state changes. Whenever I receive a CONNECTED state and the previous state received was something other than CONNECTED, I tell the mqtt client to reconnect.

    So far, this seems to have done the trick, though I’m still testing and trying to solve an occasional issue where the client repeatedly gets disconnected almost immediately after connecting, and goes into a loop of reconnection. I don’t yet know if this is a bug in my code, another Android oddity to be worked around, or a bug in the open source Mosquitto server implementation I’m using.

    I hope this is useful to you or to any other Android developers who wander by. And if anyone finds a better way of dealing with these issues, please let me know.

  16. dale says:

    Hiya Ben

    Thanks very much for your comment. In hindsight, this early code is pretty poor – demonstrating my inexperience with Android at the time. For example, I hadn’t heard of a Service or how it fits in with Activities, etc. – putting background network connection code in the Activity was a bit of a newbie mistake.

    In writing MQTT Android apps (such as a client for our sensors middleware and a little notifications app) since, I’ve learnt a lot about Android since writing this post.

    Like yourself, I’m using a broadcast listener to get notified about connectivity changes, which has helped. I really should come back and update this though… because it’s perhaps not very helpful as a guide!

    To address your issue about missing stuff when the device is asleep – are you using a Service? Because Activities are stopped when the device is asleep. There is a good section in the Android developer docs on Process lifecycles which is a useful read, if you haven’t seen it before.

  17. Ben Tobin says:

    Yes, I’m using a service with its own process. I don’t know if it was my particular choice of keepalive period (too long? too short?) or a quirk of Android, but the client was overshooting an awful lot of those keepalives, resulting in disconnects from the broker. They were resolved seconds later, because the client saw the connection get dropped, but it seemed like it would be better if the client kept on top of its connection more consistently.

    I don’t think you can rely on regular java timers to wake the device up from sleep, which is why the Alarm type “ELAPSED_REALTIME_WAKEUP” exists. I also make sure to get a WakeLock when the alarm goes off to make sure that the device doesn’t go back to sleep before I’m done with the work I need to do.

    My next test is going to be setting up a script to keep doing publications that my Droid is subscribed to, then go for a drive down the highway to make sure the connection can be maintained while being handed from tower to tower. I don’t know if that will be completely transparent, or if it will need to reconnect at each handoff.

  18. Ben Tobin says:

    Turns out the connect/disconnect loop problem was my fault. I accidentally created the mqtt client object twice during the service’s startup, and that caused all kinds of problems.

  19. dale says:

    Glad to hear you got to the bottom of it! Thanks for letting me know.

  20. […] the battery life is vastly improved from apps using push. Some mobile platforms allow you to intercept the SMS before the user sees it, thereby enabling a mode of communication that will work even if data […]

  21. Ben Tobin says:

    Sadly, it would appear that rsmb has a hard maximum connection limit of 1024. That doesn’t really make it feasible to use for published mobile apps.

  22. dale says:

    Ben – My understanding is that RSMB isn’t meant for production use.

    Check the license for a definitive explanation, but as far as I remember, the license says that it is made available for free for personal, and technical development and evaluation use. Supporting 1000 or so connections should be sufficient for such uses?

    There are other versions of the Broker that better suited to production use – check out http://mqtt.org/software for a list.

  23. Ben Tobin says:

    Unfortunately, Mosquitto can handle even fewer users. I’ll report some bugs, though, and that might improve.

    I’m a bit confused by the Expiditor pricing page. I’m not sure which version I need, and I see a client user license listed. Would I have to buy a license for each of my 5000 users? That would be a deal breaker. The WebSphere page is even more intimidating — no prices listed.

    I guess I’ll email someone there and see if there’s an option that’s financially realistic for my project.

  24. dale says:

    As a techie, I never get involved in licensing or pricing concerns, so it’s interesting to hear an experience of our stuff from the outside! Good luck with it – I hope you get a sensible answer from the email contact.

  25. jason says:

    So I have a working Android service running on a client (ERIS) that seems to get disconnected from time to time. Also, it misses its ping window as well from time to time. It looks like a few posts show that this is an issue. Can someone post some code to show how they used the Alarm Manager and Network Connectivity Intents to make the connection more robust?

    What I have so far:

    I have a service running all the time using a WaitLock. I think within this service I need to perform a ping on a regular interval before the timeout using an Alarm Manager. I also use the message handler to queue the incoming publish received messages in an Array List and turn on GPS and respond back to all who are requesting location updates. The GPS will then turn off if no messages are received for 30 seconds.

  26. dale says:

    jason – Unfortunately my code isn’t in a state that I can share at the moment. When I get a spare evening or two, I will pull together a better MQTT sample from the few apps that I’ve got working. It wont be for a week or two though – sorry.

  27. Ben Tobin says:

    Jason: Firstly, holding a Wake Lock all the time is both unnecessary and inadvisable. I obtain a Wake Lock as soon as I receive an MQTT message or a Broadcast, and release it once I’m done with whatever processing I need to do. Holding it all the time will hurt your battery life. Magically, it seems, that the Android system will wake itself up when it receives data on the persistent connection, and you only need the Wake Lock to keep it from going to sleep before you’re done responding to it.

    For my ping alarms, I subclass a BroadcastReceiver, which you should be able to find lots of examples for. That Broadcast Receiver is set in the AndroidManifest to receive the action: com.myAndroidApp.PUSHPINGALARM and android.net.conn.CONNECTIVITY_CHANGE.

    In that BroadcastReceiver subclass, I obtain a Wake Lock, then look at the action in the incoming Intent, and if it’s a PUSHPINGALARM, I call my ping() on the mqtt object. If it’s CONNECTIVITY_CHANGE, I do this:
    NetworkInfo netInfo = intent.getParcelableExtra(“networkInfo”);

    NetworkInfo.State netState = netInfo.getState();

    if (netState == State.CONNECTING || netState == State.DISCONNECTING)
    {
    doThis = NOTHING;
    }
    else if (netState == State.CONNECTED)
    {
    if (lastNetState != State.CONNECTED)
    {
    doThis = CONNLOST;
    }
    else
    {
    doThis = NOTHING;
    }
    }
    else
    {
    doThis = NOTHING;
    }
    Log.i(TAG, “Old Net State: “.concat(lastNetState.name()).concat(” New Net State: “).concat(netState.name()));
    lastNetState = netState;
    }

    Then, if doThis == CONNLOST, I tell the mqtt object to reconnect.
    Then I release the WakeLock.

    I use the following function to set the ping alarm. I call this whenever I tell mqtt to connect, after I’ve received a push message, and after pinging. It’s fine to set the alarm again even if the last alarm hasn’t gone off. Setting the new alarm replaces the old.
    private void setPingAlarm()
    {
    Log.d(TAG, “setPingAlarm Called”);
    short keepAlive = KEEP_ALIVE;

    // Set ping alarm — This should happen before the KeepAlive period
    int keepAliveTrimMillis = (keepAlive*1000)/10; // trim 10% of the ping time.
    if (keepAliveTrimMillis 60*15)
    {
    long interval = AlarmManager.INTERVAL_FIFTEEN_MINUTES;
    alMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, trigTime, interval , alarmIntent);
    }
    else
    {
    alMgr.set(AlarmManager.RTC_WAKEUP, trigTime, alarmIntent);
    }
    }

    I think you’ll need to add this permission in your AndroidManifest: android.permission.ACCESS_NETWORK_STATE

    I think that should cover it. I hope the code formatting survives. I have noticed that my connection has gone missing even with all this set up, though it’s rare. It’s possible that I’m not using the network State info correctly. If the user switched networks and the state was only reported as CONNECTED without other states in between, my code wouldn’t reconnect. So you may want to actually look more closely at that.

  28. Varun says:

    Sir,
    The blog entry was extremely helpful to get started with Push notifications.
    I spent some time looking into the basic function calls to push messages via the IBM really small broker.
    I have a query.How can we make the ‘push messaging’ localized to a specific device id?..The publish function for the client has only four parameters namely
    Topic,payload,qos and the retained flag i.e.:
    “publish(java.lang.String thisTopic, byte[] thisMessage, int thisQoS, boolean retained)”
    Since the source of the IBM broker is not available , how is the default broadcasting of the broker replaced by the ability to push messages to a particular device(cell) with a specific device id can be implemented?

  29. dale says:

    Varun,

    Later version of the MQTT protocol includes direct point-to-point messaging as well as publish/subscribe. I don’t think the RSMB implements this, however other brokers which support MQTT do.

    Alternatively, you can get around this with a topic structure which includes a unique identifier for the intended destination.

    Kind regards, D

  30. check out Xtify – Xtify is easy on the battery and processor, does a lot more than most of the other services out there and does it across Android, iPhone and Blackberry.

    xtify uses an SDK for easy implementation and has a web console and web service to configure messages to one, some or all of your users.

    you can create rules that determine when a message gets sent – you can even push notifications using location as the trigger as the SDK runs in the background and provides access to persistent location.

    reach out with questions to business@xtify.com

  31. Petar K. says:

    Hi I recently added mqtt to my android code and it works great i am really happy with it, however I want to add it in my blackberry app as well, since getting approval from the RIM has been a pain. I tried to implement into my blackberry app (since it is java after all) and i am having lots of difficulties. So i was wondering if this is possible and if so can you provide a really simple code example (differences from android)

    Thanks,

  32. dale says:

    Peter – Sorry, I don’t have any BlackBerry code that I can share. Best of luck, D

  33. Hema says:

    I have the MQTT broker running and I want Iphone application to communicate with it? Should I use only MQTT client or can I use IPhone Push Notification Service. How do I broadcast the device id with this? Is a MQTT client available with Objective-C?

  34. dale says:

    Hema

    Should I use only MQTT client or can I use IPhone Push Notification Service

    I don’t know much about iPhone’s push service, so I can’t really comment. It’s not something you could mix and match with MQTT, though – it’s a separate implementation of a similar idea.

    How do I broadcast the device id with this?

    Sorry, I’m not sure what you mean by that.

    Is a MQTT client available with Objective-C?

    I’m not aware of any objective C clients currently available. If you wanted to write your own, there are C clients around – both on ibm.com and mosquitto – that might help get you started.

    The #mqtt channel on IRC might be a good place to go for support if you get stuck.

    Hope that helps.

    Kind regards, D

  35. Burk Ferden says:

    Your example looks great and really gave me a head start on doing a push notification framework for android. One question / problem, if the android device looses connectivity briefly, can the notification be queued somehow so it can be delivered when they come online?

  36. dale says:

    Burk – Thanks very much for the kind comment. Yes – it is possible for an MQTT broker to store messages published while a client is offline, which the client can retrieve when it next reconnects.

    Kind regards, D

  37. David Mytton says:

    Push notifications on Android are fairly fragmented right now. The Urban Airship solution we use on our server monitoring apps works well but we do want to use C2DM in the future so we can avoid requiring users to install a separate, 3rd party app.

    We explored the various options you outlined but there are some issues with using MQTT.

    – Your app still has to maintain an open connection and that uses up a lot of battery if other apps are doing the same.

    – It requires the app to maintain connections to your servers on a custom port with a custom server. This makes it difficult to load balance and scale. It also requires opening a custom port and handling that kind of traffic. Our service currently operates entirely over HTTP/HTTPS and we like it that way. Communication with custom services like Apple is outgoing only.

    – The protocol is open by default. This means “anyone who knows the IP and the PORT at which the broker is running can connect and intercept your Push messages”, unless you write your own authentication.

    I’ve written up a tutorial at http://blog.boxedice.com/2010/10/07/android-push-notifications-tutorial/ that covers the options you mentioned and provides code samples and instructions for using C2DM.

  38. dale says:

    David

    Thanks very much for the comment. It raises some interesting questions, which I’ll try and pick up on here:

    1) Open connection means high battery draw – This is something I’ve been meaning to try and measure for *ages*! I keep meaning to have a go at measuring battery drain several times with and without an MQTT client running and see what difference it makes. Until I get around to doing this, though, I’m not 100% sure what the impact is. I don’t think it is too bad, though.
    I’m not sure I’d agree with the argument that multiple client instances requiring multiple connections is a technological flaw with MQTT as a protocol, though. There is nothing stopping an MQTT client being reused between apps, if you wanted to develop a Service that way.

    2) Custom port on custom server software makes scaling difficult – There are several different implementations of server software supporting the MQTT protocol. I’m far from a performance expert (quite the opposite!), but using some of the IBM server software instances, I’ve had very large numbers of clients connecting to server(s). So it is absolutely possible.

    3) Protocol being open by default means you have to roll your own authentication – This is true for v3 of the protocol, however v5 of the spec does include options for authentication. Where I’ve had to use a server that only supports v3, I’ve made the connection through an SSL tunnel, and that is a pretty straightforward workaround.

    Thanks for the link to your tutorial – it was an interesting read. Good to see an example of C2DM being used, as it’s not something I’ve had a chance to try yet. And the link to Urban Airship was interesting – I’ve not come across them before.

    Kind regards, D

  39. john sheehy says:

    Hi Dale,

    First of all, great presentation! I was wondering where I might find an implementation of MqttSimpleCallback. I suppose that I’m looking for a jar containing the com.ibm.mqtt.* classes. I’ve downloaded your sample Android app but there is no MQTT jar in the zip. I’m interested in MQTT on Android.

    Best Regards,
    John.

  40. dale says:

    Hiya John

    Thanks very much for the kind comment.

    I used the J2SE jar from http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24006006

    Kind regards, D

  41. […] 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 […]

  42. Jason says:

    Has anyone ever had a problem using MQTT with AWS and getting the error “Cannot bind to port 1883” ?

  43. Jason,
    Open port on your aws firewall.
    Craig

  44. Dale,
    Is the apk is somewhere here, I can’t find it. Did you pull it and I need to compile source myself?
    Thanks for the great example.
    Craig

  45. dale says:

    Hi Craig

    Yeah, I pulled it because there were a ton of problems with it – which I describe at https://dalelane.co.uk/blog/?p=1599

    That post includes full source for an Android MQTT Service, though – hope that helps.

    Kind regards, Dale

  46. I figured as much (there’s nothing like supporting test code). I’ll get it compiled, thanks for the quick reply.

  47. Vinay says:

    HI,

    I am facing
    =====================================
    Socket error 98 in bind for socket 3
    Cannot bind port 1883
    Cannot start listener on port 1883
    MQTT protocol stopping
    Messages sent: 0
    Messages received: 0
    Uptime: 0 seconds
    Maximum heap use: 65490 bytes
    Broker stopped
    =====================================

    I was able to succesfully implement push notification and was able to send notifications to my android phone.

    This morning, I was unable to start the broker.

    Am I missing something this time ?

    Help.

    Thanks,
    Vinay

  48. dale says:

    Hi Vinay

    I *think* a socket error 98 means the port is already in use. Which means you’ve already got something listening on port 1883 – most likely another broker still running?

    Kind regards, D