Using MQTT in Android mobile applications

Overview

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

Background

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 ibm.com). Hopefully the comments in it are clear enough, but here are a few of the key points.

Services vs Activities

Let’s start with an easy one. The most obvious screw-up in my first attempt was not realising the difference between Activities and Services.

When you’re writing an Android GUI, you extend Activity. Only one Activity runs on the phone at a time – the app the user is using. When you switch to another app or close the app, the Activity is trashed. If you rotate the phone while the app is running, the Activity is trashed and a new one is started to implement the GUI in the new orientation.

The point is – Activities are short-lived. Make them pretty. Don’t make them do any long-running heavy lifting.

Don’t put any of the MQTT stuff into your Activity. Because it will be killed soon, without much warning. It doesn’t matter if you kick off background threads as they’ll be killed off, too.

My first MQTT sample (which did everything in an Activity) was totally unreliable. I created an MQTTClient object which creates a long-running TCP/IP connection. And then if I turned the phone round a little bit, my MQTTClient object would get garbage collected.

Instead, I now use a Service. Services are meant for implementing longer-running operations – more than one Service can be running at a time. It doesn’t matter if you’re GUI Activity class gets trashed and garbage collected – the Service can keep running along in the background.

An MQTTClient object can survive in a Service object, and it’s persistent TCP/IP connection can be kept open.

Make it sticky

Services are meant to be long-running, but they don’t stick around forever. If the phone gets low on memory – typically because the user is using an app in the foreground (therefore is treated as high priority) which needs a lot of memory.

This happens frequently – it’s not an unusual thing that might possibly happen once a blue moon. My experience suggests that it’ll happen to your Service every day. Several times. My service might bumble along for a few hours happily, but then it’ll get killed off without warning.

By returning the START_STICKY constant when your Service is started, you tell Android that if it has to kill the Service to free up valuable resources, then you’d like it to restart the Service when resource become available again.

A persistent connection

Here’s something you get for free, but I thought was interesting enough to note.

When you create an MQTTClient object, one of the things it does is set up a long-running TCP/IP connection. If a message is received, the callback method publishArrived method is called.

When the user isn’t using their phone and has it turned off, Android starts turning stuff off to save battery life. My concern was that turning the phone off might break my connection, or stop the code that is waiting for incoming messages.

Although I haven’t found a good example of where this is documented, it seems that even if your phone is asleep, if data is received on the connection, your code will be woken up and publishArrived is called. The MQTT client library code that is blocking on the socket will revive when any data arrives on that socket.

Keeping the connection alive – in a bad way

Well… you nearly get it for free.

When you connect to the MQTT server, one of the parameters is a keepAlive period – an agreement between the client and server for how frequently the server should expect to hear from the client.

If the server doesn’t hear from the client for this keepAlive period, then it assumes that the client has gone and closes the connection.

The MQTTClient object kicks off a background thread that is responsible for sending a ping message to the server frequently enough to keep the connection alive.

I mentioned above that when the user isn’t using their phone and has it turned off, Android starts turning stuff off to save battery life. That includes the CPU. And if the CPU is stopped, this background thread stops.

Without the background thread going, after the keepAlive period expires the server closes the connection. If you’re using RSMB, you see that in the server log.

20110130 234952.683 CWNAN0024I 1200 second keepalive timeout for client 12964204954459774d56d6, ending connection

The easiest approach is to use a Wake Lock. This is a way for an application to prevent the phone from turning off. By taking a PARTIAL_WAKE_LOCK, you keep the CPU running, even if the user presses the power button.

If you take a PARTIAL_WAKE_LOCK before you do your MQTT connect, and keep it, then the CPU will not stop while your app is running, the standard MQTTClient background thread never stops, and the long running network connection is kept up.

But… erm… it also means that you’ve stopped the user from being able to turn off their phone! It’s a little aggressive, as it has a big impact on the phone’s battery life. So I prefer to avoid that.

Testing what happens when you turn your phone off – a gotcha

Some of my early attempts at an MQTT Service for Android didn’t take a wake lock, but still worked fine.

What I didn’t realise was that I had a couple of apps installed on my phone that hold partial wake locks all the time. Even though my app wasn’t stopping the phone’s CPU from turning off, other apps were. And I was getting the “benefit” of this and not realising that I had a problem.

The command adb shell dumpsys spits out a ton of stuff about the connected phone, including a list of current wake locks. (Search for ‘mLocks.size’ in the output). You have to do this a few times to get a picture of what is happening – some apps will, entirely legitimately, take a partial wake lock from time to time while they do something critical that they don’t want to be interrupted.

The problems are the apps that take a wake lock when they start, and keep it forever – the ones that are always in the mLocks table in the dumpsys output.

After uninstalling these apps, the results from my testing was very different, and was what showed me that I needed to do something to keep the connection alive.

Keeping the connection alive – in a good way

The best approach might be to write the MQTT client library to work in a more Android-centric way. But, to be honest, I’m too lazy for that – so I’m using the existing Java J2EE client library, but in addition to that I implement my own keepAlive approach, in the assumption that the client library’s one wont be good enough.

AlarmManager provides a way to ask Android to wake up a device that is asleep at a specified time, to run a specific method in your code.

I schedule something to wake up the phone before the current keepAlive period expires, long enough to send an MQTT ping, after which it is free to go back to sleep. This doesn’t wake up the phone screen if it is off – it just starts the CPU so that my keep-alive code can run.

Note that the MQTT specification says that the server should give the client a “grace period” of half the keep alive interval again (e.g. if the keep alive is 20 minutes, then the server wont cut off a client until 30 minutes after it has last heard from it). This means I don’t need to worry about getting my ping in just before the keepAlive interval – there is enough leeway in the specification that I can just schedule a ping for keepAlive seconds after the last interaction with the server.

Don’t rely on connectionLost

The MQTTClient library has a connectionLost callback that should be called to tell your code if the connection is broken. If you have a long keep alive interval, then the client can wait for a long time before considering that not hearing from the server means the connection is broken.

It’s a helpful callback, but by itself is not responsive enough, particularly for something like a phone where the connection state changes so frequently (e.g. moving out of mobile data coverage and losing the connection, moving between a wifi and a mobile cell data connection, etc.)

Android provides a notification system to inform your app of such changes. In response to these notifications, I assume that my connection is no longer reliable and re-connect.

If you’re using RSMB, you see that in the server log.

20110129 230652.613 CWNAN0033I Connection attempt to listener 1883 received from client 12963424184129774d56d6 on address 93.97.32.135:61055  
20110129 230703.834 CWNAN0033I Connection attempt to listener 1883 received from client 12963424184129774d56d6 on address 82.132.248.199:58529  
20110129 230703.834 CWNAN0034I Duplicate connection attempt received for client identifier "12963424184129774d56d6", ending oldest connection

Respect the user’s requests

screenshot - hosted by PhotobucketAndroid provides a way for the user to disable background data use by applications. But this isn’t enforced.

The user can untick the “Background data” check to indicate that applications should not use the network in the background, and provides an API for applications to check this value.

But applications are free to ignore this.

That’s not a good thing – users should be able to decide how their mobile is used.

I check this value before doing anything, and set up a listener in case the value is changed while my Service is running.

Create a unique client ID

The MQTT specification requires a unique client ID for every client.

I’m using a unique device ID from the phone to create this. Annoyingly, this isn’t available on emulators, so with these I’m using a timestamp – the current time in milliseconds since Jan 1 1970.

Note that the specification also defines the maximum allowable length for a client ID, so I truncate this as necessary.

Assuming that you will spend time without a connection

This is more a general approach thing, rather than a specific bit of code. But the Service has to assume that it will frequently be disconnected, and should handle reconnecting when possible without requiring user intervention.

I’ve seen apps (I’m looking at you, facebook!) which if they fail to connect to their server, just get stuck in an endless loop of retries – constantly trying and failing.

On a personal note, I have more mobiles than SIM cards. And I notice that with such apps installed, the battery life of the phone is worse when there is no SIM card in it than when there is, in part because these apps are constantly trying to communicate with a server with no network connection.

Instead, detect when the network is not available and stop everything. Don’t poll, don’t ping, don’t keep trying or checking, just request to be notified when the connection is back, stop whatever keepalive timers are running, and sleep. And be ready to get everything back up and running quickly when a connection is available again.

There is also a consideration for how you send messages server-side. When you publish a message, there is an option to make the message ‘retained’. This means that if a client is unavailable, the server will store messages for it safely, and pass them on when the client reconnects.

This might not be suitable for all scenarios, but it’s certainly something that I use a lot, and seems to fit well with mobiles which are often disconnected, the client need not miss messages published while it’s in a black spot.

Reminding the user that you’re running

In desktop window environments, users are used to knowing what’s running on their system – because they can see the windows that they have open.

On a mobile OS, where only one app is open at a time, it’s harder to have that sense of what is running in the background. It’s okay for Services which are left running to do a specific thing, and will stop when they are complete. But for Services like this, which intend to run forever until manually stopped, the user should really be reminded that it’s there.

In my sample, I use an ongoing notification in the status bar, that will stay there whenever the Service is running. This way the user is reminded that it is using some of their phone’s resource.

You might think this could get annoying, so perhaps this should be made optional – providing the user with a way to hide the notification if they are happy to leave it running without a reminder. But even then, I would have the notification by default.

Keeping the received data safe

It’s likely that for the majority of the time that the Service is running, there wont be an Activity UI showing the latest data. The Activity UI might be started at a later time, and will want to be able to access messages that were received while it wasn’t running.

This means that the Service should probably store the messages that it receives somewhere. This will be dependent on the particular app.

Applications that handle very small amounts of data – e.g. updates and notifications that don’t need to be persisted if the app and/or phone is restarted etc. may find it acceptable to store this data in a variable in the Service. That’s what I’m doing in the sample below – storing it in a local hashtable.

Applications that handle larger amounts of data, and/or need the data to be persisted even if the app and/or phone is restarted, need to store the data somewhere safely. There are a variety of storage options available – choose the one that best suits the type / frequency / size etc. of your data.

Choosing a keep-alive value

I mentioned the keepAlive parameter above – how frequently the client should contact the server to keep the connection alive. It’s a tricky decision. Ping too frequently, and you needlessly waste battery life. If you ping too infrequently, and you might not notice if you lose your connection until the next unsuccessful attempt to ping. It’s a trade-off between how time-sensitive the data is that your app is handling, against the acceptable impact on battery life.

But there are also possibly network specific concerns? How long will a mobile network operator leave an idle connection open before they trash it? For example, it may be that there is no point having a keep alive of 40 minutes, if your user’s network operator will trash an idle connection after 20 minutes.

I need to experiment with this more, but in the meantime I’ve been using a keep alive of 20 minutes, which seems to be reliable enough.

Passing config values

A small point, but it’s worth thinking about how you give the Service the connection parameters it needs, such as the server host name. There are a variety of ways to do this.

As I don’t want the users to have to have to enter these parameters every time the Service is launched, I also needed to persist these settings. The easiest way to persist small amounts of config information in a way that is accessible to the Service and modifyable by the Activity UI is using SharedPreferences – this is how the sample below does it.

Rebroadcasting received messages for interested UIs

I’ve outlined previously the basic division between back-end, long running network connection implemented in a Service, and the UI implemented in an Activity. There are a variety of ways that these can communicate with each other.

For this sample, I use Broadcasts. It’s essentially a pub/sub engine local to the phone. Whenever the Service receives an MQTT message from the network, it re-broadcasts it locally on the phone. If an Activity UI is running, it will subscribe to these messages by creating a BroadcastReceiver. When the Activity is not active, it can unregister these listeners.

This means that the Service doesn’t need to keep track of whether an Activity UI is running or not – removing an element of coupling between the back and front ends of your application.

My sample Service – the code

With all of that waffling out of the way – here is the code. My blog doesn’t display code very well, so you’re probably better off copy-and-pasting it into your favourite IDE with Java colouring/formatting enabled.

I’m putting it out there in the hope that it is helpful. If you do use it, I’d appreciate a thanks and/or a link. 🙂

package dalelane.android.mqtt;

import java.lang.ref.WeakReference;
import java.util.Calendar;
import java.util.Date;
import java.util.Enumeration;
import java.util.Hashtable;

import android.app.AlarmManager;
import android.app.Notification;
import android.app.NotificationManager;
import android.app.PendingIntent;
import android.app.Service;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.content.IntentFilter;
import android.content.SharedPreferences;
import android.graphics.Color;
import android.net.ConnectivityManager;
import android.os.Binder;
import android.os.IBinder;
import android.os.PowerManager;
import android.os.PowerManager.WakeLock;
import android.provider.Settings;
import android.provider.Settings.Secure;
import android.util.Log;

import com.ibm.mqtt.IMqttClient;
import com.ibm.mqtt.MqttClient;
import com.ibm.mqtt.MqttException;
import com.ibm.mqtt.MqttNotConnectedException;
import com.ibm.mqtt.MqttPersistence;
import com.ibm.mqtt.MqttPersistenceException;
import com.ibm.mqtt.MqttSimpleCallback;

/*
 * An example of how to implement an MQTT client in Android, able to receive
 *  push notifications from an MQTT message broker server.
 *  
 *  Dale Lane (dale.lane@gmail.com)
 *    28 Jan 2011
 */
public class MQTTService extends Service implements MqttSimpleCallback
{
    /************************************************************************/
    /*    CONSTANTS                                                         */
    /************************************************************************/
    
    // something unique to identify your app - used for stuff like accessing
    //   application preferences
    public static final String APP_ID = "com.dalelane.mqtt";
    
    // constants used to notify the Activity UI of received messages    
    public static final String MQTT_MSG_RECEIVED_INTENT = "com.dalelane.mqtt.MSGRECVD";
    public static final String MQTT_MSG_RECEIVED_TOPIC  = "com.dalelane.mqtt.MSGRECVD_TOPIC";
    public static final String MQTT_MSG_RECEIVED_MSG    = "com.dalelane.mqtt.MSGRECVD_MSGBODY";
    
    // constants used to tell the Activity UI the connection status
    public static final String MQTT_STATUS_INTENT = "com.dalelane.mqtt.STATUS";
    public static final String MQTT_STATUS_MSG    = "com.dalelane.mqtt.STATUS_MSG";

    // constant used internally to schedule the next ping event
    public static final String MQTT_PING_ACTION = "com.dalelane.mqtt.PING";
    
    // constants used by status bar notifications
    public static final int MQTT_NOTIFICATION_ONGOING = 1;  
    public static final int MQTT_NOTIFICATION_UPDATE  = 2;
    
    // constants used to define MQTT connection status
    public enum MQTTConnectionStatus 
    {
        INITIAL,                            // initial status
        CONNECTING,                         // attempting to connect
        CONNECTED,                          // connected
        NOTCONNECTED_WAITINGFORINTERNET,    // can't connect because the phone
                                            //     does not have Internet access
        NOTCONNECTED_USERDISCONNECT,        // user has explicitly requested 
                                            //     disconnection
        NOTCONNECTED_DATADISABLED,          // can't connect because the user 
                                            //     has disabled data access
        NOTCONNECTED_UNKNOWNREASON          // failed to connect for some reason
    }

    // MQTT constants
    public static final int MAX_MQTT_CLIENTID_LENGTH = 22;
    
    /************************************************************************/
    /*    VARIABLES used to maintain state                                  */
    /************************************************************************/
    
    // status of MQTT client connection
    private MQTTConnectionStatus connectionStatus = MQTTConnectionStatus.INITIAL;
    

    /************************************************************************/
    /*    VARIABLES used to configure MQTT connection                       */
    /************************************************************************/
    
    // taken from preferences
    //    host name of the server we're receiving push notifications from
    private String          brokerHostName       = "";
    // taken from preferences
    //    topic we want to receive messages about
    //    can include wildcards - e.g.  '#' matches anything
    private String          topicName            = "";    

    
    // defaults - this sample uses very basic defaults for it's interactions 
    //   with message brokers
    private int             brokerPortNumber     = 1883;
    private MqttPersistence usePersistence       = null;
    private boolean         cleanStart           = false;
    private int[]           qualitiesOfService   = { 0 } ;

    //  how often should the app ping the server to keep the connection alive?
    //
    //   too frequently - and you waste battery life
    //   too infrequently - and you wont notice if you lose your connection 
    //                       until the next unsuccessfull attempt to ping
    //
    //   it's a trade-off between how time-sensitive the data is that your 
    //      app is handling, vs the acceptable impact on battery life
    //
    //   it is perhaps also worth bearing in mind the network's support for 
    //     long running, idle connections. Ideally, to keep a connection open
    //     you want to use a keep alive value that is less than the period of
    //     time after which a network operator will kill an idle connection
    private short           keepAliveSeconds     = 20 * 60; 

    
    // This is how the Android client app will identify itself to the  
    //  message broker. 
    // It has to be unique to the broker - two clients are not permitted to  
    //  connect to the same broker using the same client ID. 
    private String          mqttClientId = null; 

    
    
    /************************************************************************/
    /*    VARIABLES  - other local variables                                */   
    /************************************************************************/
    // connection to the message broker
    private IMqttClient mqttClient = null;
    
    // receiver that notifies the Service when the phone gets data connection 
    private NetworkConnectionIntentReceiver netConnReceiver;
    
    // receiver that notifies the Service when the user changes data use preferences
    private BackgroundDataChangeIntentReceiver dataEnabledReceiver;
    
    // receiver that wakes the Service up when it's time to ping the server
    private PingSender pingSender;
    
    /************************************************************************/
    /*    METHODS - core Service lifecycle methods                          */
    /************************************************************************/

    // see http://developer.android.com/guide/topics/fundamentals.html#lcycles
    
    @Override
    public void onCreate() 
    {
        super.onCreate();
        
        // reset status variable to initial state
        connectionStatus = MQTTConnectionStatus.INITIAL;
        
        // create a binder that will let the Activity UI send 
        //   commands to the Service 
        mBinder = new LocalBinder<MQTTService>(this);
        
        // get the broker settings out of app preferences
        //   this is not the only way to do this - for example, you could use 
        //   the Intent that starts the Service to pass on configuration values
        SharedPreferences settings = getSharedPreferences(APP_ID, MODE_PRIVATE);
        brokerHostName = settings.getString("broker", "");
        topicName      = settings.getString("topic",  "");
        
        // register to be notified whenever the user changes their preferences 
        //  relating to background data use - so that we can respect the current
        //  preference
        dataEnabledReceiver = new BackgroundDataChangeIntentReceiver();
        registerReceiver(dataEnabledReceiver,
                         new IntentFilter(ConnectivityManager.ACTION_BACKGROUND_DATA_SETTING_CHANGED));
        
        // define the connection to the broker
        defineConnectionToBroker(brokerHostName);
    }
    
    
    @Override
    public void onStart(final Intent intent, final int startId) 
    {
        // This is the old onStart method that will be called on the pre-2.0
        // platform.  On 2.0 or later we override onStartCommand() so this
        // method will not be called.        
        
        new Thread(new Runnable() {
            @Override
            public void run() {
                handleStart(intent, startId);
            }
        }, "MQTTservice").start();
    }

    @Override
    public int onStartCommand(final Intent intent, int flags, final int startId) 
    {
        new Thread(new Runnable() {
            @Override
            public void run() {
                handleStart(intent, startId);
            }
        }, "MQTTservice").start();
        
        // return START_NOT_STICKY - we want this Service to be left running 
        //  unless explicitly stopped, and it's process is killed, we want it to
        //  be restarted
        return START_STICKY;
    }

    synchronized void handleStart(Intent intent, int startId) 
    {
        // before we start - check for a couple of reasons why we should stop
        
        if (mqttClient == null) 
        {
            // we were unable to define the MQTT client connection, so we stop 
            //  immediately - there is nothing that we can do
            stopSelf();
            return;
        }
        
        ConnectivityManager cm = (ConnectivityManager)getSystemService(CONNECTIVITY_SERVICE);
        if (cm.getBackgroundDataSetting() == false) // respect the user's request not to use data!
        {
            // user has disabled background data
            connectionStatus = MQTTConnectionStatus.NOTCONNECTED_DATADISABLED;
            
            // update the app to show that the connection has been disabled
            broadcastServiceStatus("Not connected - background data disabled");
            
            // we have a listener running that will notify us when this 
            //   preference changes, and will call handleStart again when it 
            //   is - letting us pick up where we leave off now 
            return;
        }
        
        // the Activity UI has started the MQTT service - this may be starting
        //  the Service new for the first time, or after the Service has been
        //  running for some time (multiple calls to startService don't start
        //  multiple Services, but it does call this method multiple times)
        // if we have been running already, we re-send any stored data        
        rebroadcastStatus();
        rebroadcastReceivedMessages();
        
        // if the Service was already running and we're already connected - we 
        //   don't need to do anything 
        if (isAlreadyConnected() == false) 
        {
            // set the status to show we're trying to connect
            connectionStatus = MQTTConnectionStatus.CONNECTING;
            
            // we are creating a background service that will run forever until
            //  the user explicity stops it. so - in case they start needing 
            //  to save battery life - we should ensure that they don't forget
            //  we're running, by leaving an ongoing notification in the status
            //  bar while we are running
            NotificationManager nm = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
            Notification notification = new Notification(R.drawable.icon, 
                                                         "MQTT",
                                                         System.currentTimeMillis());                                                         
            notification.flags |= Notification.FLAG_ONGOING_EVENT;
            notification.flags |= Notification.FLAG_NO_CLEAR;
            Intent notificationIntent = new Intent(this, MQTTNotifier.class);
            PendingIntent contentIntent = PendingIntent.getActivity(this, 0, 
                                                                    notificationIntent, 
                                                                    PendingIntent.FLAG_UPDATE_CURRENT);
            notification.setLatestEventInfo(this, "MQTT", "MQTT Service is running", contentIntent);        
            nm.notify(MQTT_NOTIFICATION_ONGOING, notification);
            
            
            // before we attempt to connect - we check if the phone has a 
            //  working data connection
            if (isOnline())
            {
                // we think we have an Internet connection, so try to connect
                //  to the message broker
                if (connectToBroker()) 
                {
                    // we subscribe to a topic - registering to receive push
                    //  notifications with a particular key
                    // in a 'real' app, you might want to subscribe to multiple
                    //  topics - I'm just subscribing to one as an example
                    // note that this topicName could include a wildcard, so 
                    //  even just with one subscription, we could receive 
                    //  messages for multiple topics
                    subscribeToTopic(topicName);
                }
            }
            else
            {
                // we can't do anything now because we don't have a working 
                //  data connection 
                connectionStatus = MQTTConnectionStatus.NOTCONNECTED_WAITINGFORINTERNET;
                
                // inform the app that we are not connected
                broadcastServiceStatus("Waiting for network connection");
            }
        }
        
        // changes to the phone's network - such as bouncing between WiFi 
        //  and mobile data networks - can break the MQTT connection
        // the MQTT connectionLost can be a bit slow to notice, so we use 
        //  Android's inbuilt notification system to be informed of 
        //  network changes - so we can reconnect immediately, without 
        //  haing to wait for the MQTT timeout
        if (netConnReceiver == null)
        {
            netConnReceiver = new NetworkConnectionIntentReceiver();            
            registerReceiver(netConnReceiver, 
                             new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION));
            
        }
        
        // creates the intents that are used to wake up the phone when it is 
        //  time to ping the server
        if (pingSender == null)
        {
            pingSender = new PingSender();
            registerReceiver(pingSender, new IntentFilter(MQTT_PING_ACTION));
        }
    }

    @Override
    public void onDestroy() 
    {
        super.onDestroy();

        // disconnect immediately
        disconnectFromBroker();

        // inform the app that the app has successfully disconnected
        broadcastServiceStatus("Disconnected");
        
        // try not to leak the listener        
        if (dataEnabledReceiver != null) 
        {
            unregisterReceiver(dataEnabledReceiver);
            dataEnabledReceiver = null;
        }
        
        if (mBinder != null) {
            mBinder.close();
            mBinder = null;
        }
    }
    
    
    /************************************************************************/
    /*    METHODS - broadcasts and notifications                            */
    /************************************************************************/
    
    // methods used to notify the Activity UI of something that has happened
    //  so that it can be updated to reflect status and the data received 
    //  from the server
    
    private void broadcastServiceStatus(String statusDescription) 
    {
        // inform the app (for times when the Activity UI is running / 
        //   active) of the current MQTT connection status so that it 
        //   can update the UI accordingly
        Intent broadcastIntent = new Intent();
        broadcastIntent.setAction(MQTT_STATUS_INTENT);
        broadcastIntent.putExtra(MQTT_STATUS_MSG, statusDescription); 
        sendBroadcast(broadcastIntent);        
    }
    
    private void broadcastReceivedMessage(String topic, String message)
    {
        // pass a message received from the MQTT server on to the Activity UI 
        //   (for times when it is running / active) so that it can be displayed 
        //   in the app GUI
        Intent broadcastIntent = new Intent();
        broadcastIntent.setAction(MQTT_MSG_RECEIVED_INTENT);
        broadcastIntent.putExtra(MQTT_MSG_RECEIVED_TOPIC, topic);
        broadcastIntent.putExtra(MQTT_MSG_RECEIVED_MSG,   message);
        sendBroadcast(broadcastIntent);                
    }
    
    // methods used to notify the user of what has happened for times when 
    //  the app Activity UI isn't running
    
    private void notifyUser(String alert, String title, String body)
    {
        NotificationManager nm = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
        Notification notification = new Notification(R.drawable.icon, alert,
                                                     System.currentTimeMillis());
        notification.defaults |= Notification.DEFAULT_LIGHTS;
        notification.defaults |= Notification.DEFAULT_SOUND;
        notification.defaults |= Notification.DEFAULT_VIBRATE;
        notification.flags |= Notification.FLAG_AUTO_CANCEL;        
        notification.ledARGB = Color.MAGENTA;
        Intent notificationIntent = new Intent(this, MQTTNotifier.class);
        PendingIntent contentIntent = PendingIntent.getActivity(this, 0, 
                                                                notificationIntent, 
                                                                PendingIntent.FLAG_UPDATE_CURRENT);
        notification.setLatestEventInfo(this, title, body, contentIntent);
        nm.notify(MQTT_NOTIFICATION_UPDATE, notification);        
    }
    
    
    /************************************************************************/
    /*    METHODS - binding that allows access from the Actitivy            */
    /************************************************************************/
    
    // trying to do local binding while minimizing leaks - code thanks to
    //   Geoff Bruckner - which I found at  
    //   http://groups.google.com/group/cw-android/browse_thread/thread/d026cfa71e48039b/c3b41c728fedd0e7?show_docid=c3b41c728fedd0e7
    
    private LocalBinder<MQTTService> mBinder;
    
    @Override
    public IBinder onBind(Intent intent) 
    {
        return mBinder;
    }
    public class LocalBinder<S> extends Binder 
    {
        private WeakReference<S> mService;
        
        public LocalBinder(S service)
        {
            mService = new WeakReference<S>(service);
        }
        public S getService() 
        {
            return mService.get();
        }        
        public void close() 
        { 
            mService = null; 
        }
    }
    
    // 
    // public methods that can be used by Activities that bind to the Service
    //
    
    public MQTTConnectionStatus getConnectionStatus() 
    {
        return connectionStatus;
    }    
    
    public void rebroadcastStatus()
    {
        String status = "";
        
        switch (connectionStatus)
        {
            case INITIAL:
                status = "Please wait";
                break;
            case CONNECTING:
                status = "Connecting...";
                break;
            case CONNECTED:
                status = "Connected";
                break;
            case NOTCONNECTED_UNKNOWNREASON:
                status = "Not connected - waiting for network connection";
                break;
            case NOTCONNECTED_USERDISCONNECT:
                status = "Disconnected";
                break;
            case NOTCONNECTED_DATADISABLED:
                status = "Not connected - background data disabled";
                break;
            case NOTCONNECTED_WAITINGFORINTERNET:
                status = "Unable to connect";
                break;
        }
        
        //
        // inform the app that the Service has successfully connected
        broadcastServiceStatus(status);
    }
    
    public void disconnect()
    {
        disconnectFromBroker();

        // set status 
        connectionStatus = MQTTConnectionStatus.NOTCONNECTED_USERDISCONNECT;
        
        // inform the app that the app has successfully disconnected
        broadcastServiceStatus("Disconnected");       
    }
    
    
    /************************************************************************/
    /*    METHODS - MQTT methods inherited from MQTT classes                */
    /************************************************************************/
    
    /*
     * callback - method called when we no longer have a connection to the 
     *  message broker server
     */
    public void connectionLost() throws Exception 
    {
        // we protect against the phone switching off while we're doing this
        //  by requesting a wake lock - we request the minimum possible wake 
        //  lock - just enough to keep the CPU running until we've finished
        PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
        WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MQTT");
        wl.acquire();
        
        
        //
        // have we lost our data connection?
        //
        
        if (isOnline() == false)
        {
            connectionStatus = MQTTConnectionStatus.NOTCONNECTED_WAITINGFORINTERNET;
            
            // inform the app that we are not connected any more
            broadcastServiceStatus("Connection lost - no network connection");
        
            //
            // inform the user (for times when the Activity UI isn't running) 
            //   that we are no longer able to receive messages
            notifyUser("Connection lost - no network connection", 
                       "MQTT", "Connection lost - no network connection");

            //
            // wait until the phone has a network connection again, when we 
            //  the network connection receiver will fire, and attempt another
            //  connection to the broker
        }
        else 
        {
            // 
            // we are still online
            //   the most likely reason for this connectionLost is that we've 
            //   switched from wifi to cell, or vice versa
            //   so we try to reconnect immediately
            // 
            
            connectionStatus = MQTTConnectionStatus.NOTCONNECTED_UNKNOWNREASON;
            
            // inform the app that we are not connected any more, and are 
            //   attempting to reconnect
            broadcastServiceStatus("Connection lost - reconnecting...");
            
            // try to reconnect
            if (connectToBroker()) {
                subscribeToTopic(topicName);
            }
        }
        
        // we're finished - if the phone is switched off, it's okay for the CPU 
        //  to sleep now
        wl.release();
    }

    
    /*
     *   callback - called when we receive a message from the server 
     */
    public void publishArrived(String topic, byte[] payloadbytes, int qos, boolean retained)  
    {
        // we protect against the phone switching off while we're doing this
        //  by requesting a wake lock - we request the minimum possible wake 
        //  lock - just enough to keep the CPU running until we've finished
        PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
        WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MQTT");
        wl.acquire();
        
        //
        //  I'm assuming that all messages I receive are being sent as strings
        //   this is not an MQTT thing - just me making as assumption about what
        //   data I will be receiving - your app doesn't have to send/receive
        //   strings - anything that can be sent as bytes is valid
        String messageBody = new String(payloadbytes);

        //
        //  for times when the app's Activity UI is not running, the Service 
        //   will need to safely store the data that it receives
        if (addReceivedMessageToStore(topic, messageBody))
        {
            // this is a new message - a value we haven't seen before
            
            //
            // inform the app (for times when the Activity UI is running) of the 
            //   received message so the app UI can be updated with the new data
            broadcastReceivedMessage(topic, messageBody);
            
            //
            // inform the user (for times when the Activity UI isn't running) 
            //   that there is new data available
            notifyUser("New data received", topic, messageBody);
        }
 
        // receiving this message will have kept the connection alive for us, so
        //  we take advantage of this to postpone the next scheduled ping
        scheduleNextPing();

        // we're finished - if the phone is switched off, it's okay for the CPU 
        //  to sleep now        
        wl.release();
    }

    
    /************************************************************************/
    /*    METHODS - wrappers for some of the MQTT methods that we use       */
    /************************************************************************/
    
    /*
     * Create a client connection object that defines our connection to a
     *   message broker server 
     */
    private void defineConnectionToBroker(String brokerHostName)
    {
        String mqttConnSpec = "tcp://" + brokerHostName + "@" + brokerPortNumber;
        
        try
        {
            // define the connection to the broker
            mqttClient = MqttClient.createMqttClient(mqttConnSpec, usePersistence);

            // register this client app has being able to receive messages
            mqttClient.registerSimpleHandler(this);            
        }
        catch (MqttException e)
        {
            // something went wrong!
            mqttClient = null;
            connectionStatus = MQTTConnectionStatus.NOTCONNECTED_UNKNOWNREASON;
            
            //
            // inform the app that we failed to connect so that it can update
            //  the UI accordingly
            broadcastServiceStatus("Invalid connection parameters");

            //
            // inform the user (for times when the Activity UI isn't running) 
            //   that we failed to connect
            notifyUser("Unable to connect", "MQTT", "Unable to connect");
        }        
    }
    
    /*
     * (Re-)connect to the message broker
     */
    private boolean connectToBroker()
    {
        try
        {            
            // try to connect
            mqttClient.connect(generateClientId(), cleanStart, keepAliveSeconds);

            //
            // inform the app that the app has successfully connected
            broadcastServiceStatus("Connected");
            
            // we are connected
            connectionStatus = MQTTConnectionStatus.CONNECTED;

            // we need to wake up the phone's CPU frequently enough so that the 
            //  keep alive messages can be sent
            // we schedule the first one of these now
            scheduleNextPing();

            return true;
        }
        catch (MqttException e)
        {
            // something went wrong!
            
            connectionStatus = MQTTConnectionStatus.NOTCONNECTED_UNKNOWNREASON;
            
            //
            // inform the app that we failed to connect so that it can update
            //  the UI accordingly
            broadcastServiceStatus("Unable to connect");

            //
            // inform the user (for times when the Activity UI isn't running) 
            //   that we failed to connect
            notifyUser("Unable to connect", "MQTT", "Unable to connect - will retry later");        
            
            // if something has failed, we wait for one keep-alive period before
            //   trying again
            // in a real implementation, you would probably want to keep count
            //  of how many times you attempt this, and stop trying after a 
            //  certain number, or length of time - rather than keep trying 
            //  forever.
            // a failure is often an intermittent network issue, however, so 
            //  some limited retry is a good idea
            scheduleNextPing();
            
            return false;
        }
    }
    
    /*
     * Send a request to the message broker to be sent messages published with 
     *  the specified topic name. Wildcards are allowed.    
     */
    private void subscribeToTopic(String topicName)
    {
        boolean subscribed = false;
        
        if (isAlreadyConnected() == false)
        {
            // quick sanity check - don't try and subscribe if we 
            //  don't have a connection
            
            Log.e("mqtt", "Unable to subscribe as we are not connected");
        }
        else 
        {                                    
            try 
            {
                String[] topics = { topicName };
                mqttClient.subscribe(topics, qualitiesOfService);
                
                subscribed = true;
            } 
            catch (MqttNotConnectedException e) 
            {
                Log.e("mqtt", "subscribe failed - MQTT not connected", e);
            } 
            catch (IllegalArgumentException e) 
            {
                Log.e("mqtt", "subscribe failed - illegal argument", e);
            } 
            catch (MqttException e) 
            {
                Log.e("mqtt", "subscribe failed - MQTT exception", e);
            }
        }
        
        if (subscribed == false)
        {
            //
            // inform the app of the failure to subscribe so that the UI can 
            //  display an error
            broadcastServiceStatus("Unable to subscribe");

            //
            // inform the user (for times when the Activity UI isn't running)
            notifyUser("Unable to subscribe", "MQTT", "Unable to subscribe");        
        }
    }
    
    /*
     * Terminates a connection to the message broker.
     */
    private void disconnectFromBroker()
    {
        // if we've been waiting for an Internet connection, this can be 
        //  cancelled - we don't need to be told when we're connected now
        try
        {
            if (netConnReceiver != null) 
            {
                unregisterReceiver(netConnReceiver);
                netConnReceiver = null;
            }
            
            if (pingSender != null)
            {
                unregisterReceiver(pingSender);
                pingSender = null;
            }
        }
        catch (Exception eee)
        {
            // probably because we hadn't registered it
            Log.e("mqtt", "unregister failed", eee);
        }

        try 
        {
            if (mqttClient != null)
            {
                mqttClient.disconnect();
            }
        } 
        catch (MqttPersistenceException e) 
        {
            Log.e("mqtt", "disconnect failed - persistence exception", e);
        }
        finally
        {
            mqttClient = null;
        }
        
        // we can now remove the ongoing notification that warns users that
        //  there was a long-running ongoing service running
        NotificationManager nm = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
        nm.cancelAll();
    }
    
    /*
     * Checks if the MQTT client thinks it has an active connection
     */
    private boolean isAlreadyConnected()
    {
        return ((mqttClient != null) && (mqttClient.isConnected() == true));
    }
    
    private class BackgroundDataChangeIntentReceiver extends BroadcastReceiver
    {
        @Override
        public void onReceive(Context ctx, Intent intent) 
        {
            // we protect against the phone switching off while we're doing this
            //  by requesting a wake lock - we request the minimum possible wake 
            //  lock - just enough to keep the CPU running until we've finished
            PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
            WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MQTT");
            wl.acquire();
   
            ConnectivityManager cm = (ConnectivityManager)getSystemService(CONNECTIVITY_SERVICE);
            if (cm.getBackgroundDataSetting()) 
            {
                // user has allowed background data - we start again - picking 
                //  up where we left off in handleStart before
                defineConnectionToBroker(brokerHostName);
                handleStart(intent, 0);
            }
            else 
            {
                // user has disabled background data
                connectionStatus = MQTTConnectionStatus.NOTCONNECTED_DATADISABLED;
                
                // update the app to show that the connection has been disabled
                broadcastServiceStatus("Not connected - background data disabled");
                
                // disconnect from the broker
                disconnectFromBroker();
            }            
            
            // we're finished - if the phone is switched off, it's okay for the CPU 
            //  to sleep now            
            wl.release();
        }        
    }
    
    
    /*
     * Called in response to a change in network connection - after losing a 
     *  connection to the server, this allows us to wait until we have a usable
     *  data connection again
     */
    private class NetworkConnectionIntentReceiver extends BroadcastReceiver
    {
        @Override
        public void onReceive(Context ctx, Intent intent) 
        {
            // we protect against the phone switching off while we're doing this
            //  by requesting a wake lock - we request the minimum possible wake 
            //  lock - just enough to keep the CPU running until we've finished
            PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
            WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MQTT");
            wl.acquire();
            
            if (isOnline())
            {
                // we have an internet connection - have another try at connecting
                if (connectToBroker()) 
                {
                    // we subscribe to a topic - registering to receive push
                    //  notifications with a particular key
                    subscribeToTopic(topicName);
                }
            }
            
            // we're finished - if the phone is switched off, it's okay for the CPU 
            //  to sleep now
            wl.release();
        }
    }
        

    /*
     * Schedule the next time that you want the phone to wake up and ping the 
     *  message broker server
     */
    private void scheduleNextPing()
    {
        // When the phone is off, the CPU may be stopped. This means that our 
        //   code may stop running.
        // When connecting to the message broker, we specify a 'keep alive' 
        //   period - a period after which, if the client has not contacted
        //   the server, even if just with a ping, the connection is considered
        //   broken.
        // To make sure the CPU is woken at least once during each keep alive
        //   period, we schedule a wake up to manually ping the server
        //   thereby keeping the long-running connection open
        // Normally when using this Java MQTT client library, this ping would be
        //   handled for us. 
        // Note that this may be called multiple times before the next scheduled
        //   ping has fired. This is good - the previously scheduled one will be
        //   cancelled in favour of this one.
        // This means if something else happens during the keep alive period, 
        //   (e.g. we receive an MQTT message), then we start a new keep alive
        //   period, postponing the next ping.
        
        PendingIntent pendingIntent = PendingIntent.getBroadcast(this, 0, 
                                                                 new Intent(MQTT_PING_ACTION), 
                                                                 PendingIntent.FLAG_UPDATE_CURRENT);
        
        // in case it takes us a little while to do this, we try and do it 
        //  shortly before the keep alive period expires
        // it means we're pinging slightly more frequently than necessary 
        Calendar wakeUpTime = Calendar.getInstance();
        wakeUpTime.add(Calendar.SECOND, keepAliveSeconds);
        
        AlarmManager aMgr = (AlarmManager) getSystemService(ALARM_SERVICE);        
        aMgr.set(AlarmManager.RTC_WAKEUP,  
                 wakeUpTime.getTimeInMillis(),                 
                 pendingIntent);
    }
    
    
    /*
     * Used to implement a keep-alive protocol at this Service level - it sends 
     *  a PING message to the server, then schedules another ping after an 
     *  interval defined by keepAliveSeconds
     */
    public class PingSender extends BroadcastReceiver 
    {
        @Override
        public void onReceive(Context context, Intent intent) 
        {
            // Note that we don't need a wake lock for this method (even though
            //  it's important that the phone doesn't switch off while we're
            //  doing this).
            // According to the docs, "Alarm Manager holds a CPU wake lock as 
            //  long as the alarm receiver's onReceive() method is executing. 
            //  This guarantees that the phone will not sleep until you have 
            //  finished handling the broadcast."
            // This is good enough for our needs.
            
            try 
            {
                mqttClient.ping();                
            } 
            catch (MqttException e) 
            {
                // if something goes wrong, it should result in connectionLost
                //  being called, so we will handle it there
                Log.e("mqtt", "ping failed - MQTT exception", e);
                
                // assume the client connection is broken - trash it
                try {                    
                    mqttClient.disconnect();
                } 
                catch (MqttPersistenceException e1) {
                    Log.e("mqtt", "disconnect failed - persistence exception", e1);                
                }
                
                // reconnect
                if (connectToBroker()) {
                    subscribeToTopic(topicName);
                }                
            }

            // start the next keep alive period 
            scheduleNextPing();
        }
    }

    
    
    /************************************************************************/
    /*   APP SPECIFIC - stuff that would vary for different uses of MQTT    */
    /************************************************************************/
    
    //  apps that handle very small amounts of data - e.g. updates and 
    //   notifications that don't need to be persisted if the app / phone
    //   is restarted etc. may find it acceptable to store this data in a 
    //   variable in the Service
    //  that's what I'm doing in this sample: storing it in a local hashtable 
    //  if you are handling larger amounts of data, and/or need the data to
    //   be persisted even if the app and/or phone is restarted, then 
    //   you need to store the data somewhere safely
    //  see http://developer.android.com/guide/topics/data/data-storage.html
    //   for your storage options - the best choice depends on your needs 
    
    // stored internally
    
    private Hashtable<String, String> dataCache = new Hashtable<String, String>(); 

    private boolean addReceivedMessageToStore(String key, String value) 
    {
        String previousValue = null;
        
        if (value.length() == 0)
        {
            previousValue = dataCache.remove(key);
        }
        else
        {
            previousValue = dataCache.put(key, value);
        }
        
        // is this a new value? or am I receiving something I already knew?
        //  we return true if this is something new
        return ((previousValue == null) || 
                (previousValue.equals(value) == false));
    }

    // provide a public interface, so Activities that bind to the Service can 
    //  request access to previously received messages
    
    public void rebroadcastReceivedMessages() 
    {
        Enumeration<String> e = dataCache.keys();         
        while(e.hasMoreElements()) 
        {
            String nextKey = e.nextElement();
            String nextValue = dataCache.get(nextKey);
            
            broadcastReceivedMessage(nextKey, nextValue);
        }
    }
    

    /************************************************************************/
    /*    METHODS - internal utility methods                                */
    /************************************************************************/    
    
    private String generateClientId()
    {
        // generate a unique client id if we haven't done so before, otherwise
        //   re-use the one we already have

        if (mqttClientId == null)
        {
            // generate a unique client ID - I'm basing this on a combination of 
            //  the phone device id and the current timestamp         
            String timestamp = "" + (new Date()).getTime();
            String android_id = Settings.System.getString(getContentResolver(), 
                                                          Secure.ANDROID_ID);        
            mqttClientId = timestamp + android_id;
            
            // truncate - MQTT spec doesn't allow client ids longer than 23 chars
            if (mqttClientId.length() > MAX_MQTT_CLIENTID_LENGTH) {
                mqttClientId = mqttClientId.substring(0, MAX_MQTT_CLIENTID_LENGTH);
            }
        }
        
        return mqttClientId;
    }
    
    private boolean isOnline() 
    {
        ConnectivityManager cm = (ConnectivityManager)getSystemService(CONNECTIVITY_SERVICE);
        if(cm.getActiveNetworkInfo() != null &&
           cm.getActiveNetworkInfo().isAvailable() &&
           cm.getActiveNetworkInfo().isConnected())
        {
            return true;
        }
        
        return false;
    }   
}

Using the Service

Finally, some comments on how to use this sample Service from your Activity.

First off, you need to make sure you have the required permissions set:

<uses-permission android:name="android.permission.INTERNET"></uses-permission> 
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"></uses-permission> 
<uses-permission android:name="android.permission.VIBRATE"></uses-permission> 
<uses-permission android:name="android.permission.WAKE_LOCK"></uses-permission>

To start the MQTT client, set the broker host name and topic string to subscribe to in SharedPreferences.

SharedPreferences settings = getSharedPreferences(MQTTService.APP_ID, 0);  
SharedPreferences.Editor editor = settings.edit();  
editor.putString("broker", preferenceBrokerHost);  
editor.putString("topic",  preferenceBrokerUser);	  
editor.commit();

Then set up the receivers to get the messages rebroadcasted by the Service. There are two types of messages broadcast by the Service – MQTT messages, and the current connection status.

private StatusUpdateReceiver statusUpdateIntentReceiver;  
private MQTTMessageReceiver  messageIntentReceiver;  

@Override  
public void onCreate(Bundle savedInstanceState)   
{  
    ...  

    statusUpdateIntentReceiver = new StatusUpdateReceiver();  
    IntentFilter intentSFilter = new IntentFilter(MQTTService.MQTT_STATUS_INTENT);  
    registerReceiver(statusUpdateIntentReceiver, intentSFilter);  

    messageIntentReceiver = new MQTTMessageReceiver();  
    IntentFilter intentCFilter = new IntentFilter(MQTTService.MQTT_MSG_RECEIVED_INTENT);  
    registerReceiver(messageIntentReceiver, intentCFilter);  
      
    ...  
}  

public class StatusUpdateReceiver extends BroadcastReceiver  
{  
    @Override   
    public void onReceive(Context context, Intent intent)  
    {  
        Bundle notificationData = intent.getExtras();  
        String newStatus = notificationData.getString(MQTTService.MQTT_STATUS_MSG);	    	  

        ... 
    }  
}  
public class MQTTMessageReceiver extends BroadcastReceiver  
{  
    @Override   
    public void onReceive(Context context, Intent intent)  
    {  
        Bundle notificationData = intent.getExtras();  
        String newTopic = notificationData.getString(MQTTService.MQTT_MSG_RECEIVED_TOPIC);  
        String newData  = notificationData.getString(MQTTService.MQTT_MSG_RECEIVED_MSG);	    	  

        ... 
    }  
}  

@Override  
protected void onDestroy()   
{  
    ...  

    unregisterReceiver(statusUpdateIntentReceiver);  
    unregisterReceiver(messageIntentReceiver);  

    ...  
} 

Now you’re ready to start the MQTT Service running.

Intent svc = new Intent(this, MQTTService.class);  
startService(svc); 

Similarly, to disconnect and stop:

Intent svc = new Intent(this, MQTTService.class);  
stopService(svc);

You probably also want to clear notifications created by the Service:

@Override  
public void onWindowFocusChanged(boolean hasFocus)   
{  
    super.onWindowFocusChanged(hasFocus);  
    if (hasFocus)  
    {  
        NotificationManager mNotificationManager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);  
        mNotificationManager.cancel(MQTTService.MQTT_NOTIFICATION_UPDATE);  
    }  
} 

Lastly, you might want to directly call methods in the Service from your Activity. Most of them are private, but you can put some public methods in there.

For example, I mentioned previously in ‘Keeping the received data safe’ that when an Activity starts, it may want to retrieve from the Service all of the pushed data it has received while it has been running.

I’ve added support to the Service for making calls like this through a local binder, which you can use like this:

bindService(new Intent(this, MQTTService.class),   
            new ServiceConnection() {                                  
                @SuppressWarnings("unchecked")  
                @Override  
                public void onServiceConnected(ComponentName className, final IBinder service)   
                {  
                    MQTTService mqttService = ((LocalBinder<MQTTService>)service).getService();                                      
                    mqttService.rebroadcastReceivedMessages();  
                    unbindService(this);  
                }  
                @Override  
                public void onServiceDisconnected(ComponentName name) {}  
            },   
            0); 

But what about… (insert alternative push framework here – e.g. Google’s Push Notification Service)?

I think this post is already long enough, right? 🙂

I’ve written before about why you might want to do PUSH at all. And in this post, I’ve aimed at someone who has decided that they want to use MQTT on Android, and wants some guidance on how. I’ll leave the debate for how MQTT compares with alternative frameworks for another time.

I hope this is useful to people – please do let me know in the comments if you use it, or spot something that it could do better.

Update 28-May-2011: Updated the code to correct a bug pointed out by Ngewi Fet in the comments.

Tags: , , , ,

68 Responses to “Using MQTT in Android mobile applications”

  1. Thanks Dale, I’ll check it out…

  2. iggy says:

    Thanks Dale, I’ll look into thread pools asap. And thanks for the article, I’ve been through all the mqtt android examples online and this is the most complete and well written one.

  3. PraveenG says:

    sounds good !! am trying this out and wl let you know the results.

  4. hershey says:

    I didn’t see any reference to the MQTTNotifier.class in com.ibm.mqtt. What am I missing?

  5. dale says:

    MQTTNotifier is whatever activity you would want to be launched by the notification – so the Activity for your UI.

    https://dalelane.co.uk/blog/?p=1599&cpage=1#comment-113860

  6. Jim Warner says:

    I have built your service code and am able to test to the point of connecting to a broker. Is there a server that will accept a connection that I can test against?

  7. dale says:

    There is a list of options at http://mqtt.org/software

    In particular, RSMB http://www.alphaworks.ibm.com/tech/rsmb and Mosquitto http://mosquitto.org/ are easy to get up and running quickly for dev/test purposes.

  8. […] Dave Lane kindly described using of the MQTT protocol with Android. Many thanks to Dave. It will save developers some time and hopefully one of them will make some more code, tips and hints public. The whole story of Dave here: MQTT in an Android mobile application […]

  9. Xavier says:

    Hi Dale, thanks for the amazing code. I am using it with success, but there’s yet something not working as expected and don’t know how to solve it.

    After a connection loss, the service manages to connect to the broker and subscribe inmediately after the connection is recovered, however if there was some message sent during that period, it is not recovered inmediately after subscribing but on the next keepalivetimeout. I tried forcing a ping after subscribing but that did not help neither.

    Are you seeing also this behaviour?

  10. Xavier says:

    My test scenario, using a qos of 1 and a keep alive of 2 minutes for faster debugging:

    1. Phone is connected and subscribed.
    2. Cut down net connection from phone settings (currently can only try 3g not wifi)
    3. Publish a message from an external client
    4. Turn on net connection.

    And after some debugging, this is exactly what’s going on:

    1. When the net is turned off, NetworkConnectionIntentReceiver is triggered, but obviously can’t connect.

    2. When the net is turned on, NetworkConnectionIntentReceiver is triggered again and connectToBroker() and subscribeToTopic() both succeed without throwing any exception, however the message previously published does not arrive, neither any further published message.

    3. After the 2 minutes keep alive period, PingSender is triggered but ping fails throwing mqttNotConnectedException and WMQtt clients prints on console: “Lost connection…”. Then Service triggers it’s connectionLost() method, and connectToBroker() and subscribeToTopic() succeed, and all the messages arrive.

  11. dale says:

    Xavier – Sorry, I don’t remember seeing this happening. I don’t have an environment to recreate this at the moment – I’m on holiday – but will give it a try when I get home.

  12. Xavier says:

    Thx Dale I appreciate! Enjoy your holidays now.

  13. […] Android MQTT example project Monday, October 31st, 2011 | Mobile I’ve put together a simple Android example based on the MQTT service code written by Dale Lane. […]

  14. Xavier says:

    One thing than comes to my mind Dale, wouldn’t a WIFILOCK be also required at some point?

  15. Vaidas says:

    Hello,

    Thanks for the article. It’s really helpful!

    I have a problem though and maybe somebody else has faced it.

    I’ve downloaded the Mosquitto broker both for windows and ubuntu. It seems to work as expected when using IBM’s stdinpub.exe and stdoutsub.exe. I can receive and send messages on both platforms (from diffent computers as well). But when I try to connect to the mosquitto broker from android using your code I always get an exception (it basically cannot connect and throws connection timed out exception). Has anybody seen this happening?

    BTW, When using IBM’s RSMB it works perfectly (android can connect with no problems at all).

    P.S. All of the devices are on the same LAN.

  16. dale says:

    That’s odd – I can’t think of any reason why that would happen. I assume you’ve checked that a firewall isn’t getting in the way?

    Is there any (debug?) output from mosquitto that might give a reason why this happens, or does mosquitto just not hear from Android at all?

    It might be worth asking on https://launchpad.net/~mqtt-users mailing list, as I must admit I’ve not tried mosquitto for myself.

    Sorry I can’t be more help!

  17. Vaidas says:

    Dale, thanks for the reply. The problem was that mqtt part was using different IP (problem in my code where server’s IP was set incorrectly while initializing the background service).

    Thanks for sharing this awesome piece of code!

    Vaidas

  18. dale says:

    That’s good to hear – thanks for letting me know.

    If you’re doing anything interesting with it, I know that the mosquitto developer would love to hear about it – http://mosquitto.org/2012/01/do-you-use-mqtt/