This weekend is barcamplondon, so another chance for me to ramble incoherently about a technical topic of my choice. 
My presentation started as a bit of a cop-out. I was ill last week and weekend when I was planning to prepare a new presentation, so I decided to give the same talk I did at Over The Air last month and hope that I didn’t get any of the same attendees.
But then I started tweaking it to suit the different audience. Over The Air is an event for mobile developers, so my presentation was pretty much aimed at mobile devs, which wasn’t quite right for a general event like barcamplondon.
Then I started updating it to reflect the feedback I got, both on the day at Over The Air, and through comments and tweets since.
My talk at OTA was a technical “Introduction to MQTT” session.
My presentation for barcamplondon became a broader look at mobile apps that rely on data from the Internet, and the challenges and choices facing mobile app developers who write them.
And I think it’s better for it. I hope it didn’t come across as pimping MQTT. I still talked about MQTT, but this time it was to use it as an example of one of a broader set of choices:
- polling
- network-supported built-in push support
- e.g. iPhone, BlackBerry
- network provided SMS or WAP Push API
- intercepting incoming SMS messages using mobile OS API
- making an IP connection and leaving it open
- e.g. MQTT
The aim of the talk was to discuss the pros and cons of each approach.
I still reused a bunch of slides from OTA, so it was still a bit of a cop-out. But I’m glad I got the chance to revisit this nonetheless.
I’ve put the slides up on SlideShare. As always, they make next to no sense by themselves, but I did add some speakers notes which are included if you download the presentation file.
Tags: barcamplondon, barcamplondon7, bcl7, mobile, mqtt, push, push notification
[...] (24/10/2009): I revisited this presentation to address some of the feedback that I got on battery life implications of using [...]
Hi Dale
I read your article on MQTT and enjoyed it and had a question for you. I saw that you had created an Android client and was wondering if this worked equally well for iPhone, J2ME and windows mobile clients?
thanks
Nick
I’ve done MQTT client stuff for Windows Mobile, and J2ME. Never tried iPhone, but I imagine it would be more complicated.
I have a question.
I think that the push notification using MQTT needs a lot of connection between mobile phone and server. For example, If 10,000 clients subscribe some topic, the server keep 10,000 IP connections concurrently. Is it correct?
Can the mobile carrier allow such connections?
If you mean – how does a server handle large number of concurrent clients? I believe that this is not in the protocol specification. Which means that this will depend on which implementation of the MQTT server protocol you use.
For example, I would imagine that the free, lightweight RSMB will handle this differently to the enterprise-scale WMB.
Sorry that this isn’t a very helpful answer – but if you have a particular server implementation in mind, I might be able to help get you an answer.
I’m not sure what you meant by “Can the mobile carrier allow such connections?” though.
Thank you for your reply.
I think that MQTT is push notification based on IP connection.
A lot of connection for notification will impose a heavy burden on mobile carrier.
So there is some doubt whether mobile carrier allow a lot of connection for notification. That’s my question.
Do you mean a burden if a large number of mobile subscribers all used an app that requires them to hold a connection open?
It’s an interesting point, but there are enough existing apps around that use this approach that I would hope that it would be okay. Would need to talk to someone from an operator to confirm that, though.