0

I have been reading this tutorial to learn the basics of Paho android Service API, and some where in the text i read as for client.connect(context, callback which has two methods onSuccess() and onFailure()

As mentioned, a synchronous client is being used in this example (MqttClient as opposed to MqttAsyncClient). This means that requests, like connect, will block and return or throw an exception. There is no polling or read method to get messages from the server, messages from the server can arrive at any time. The library provides a callback mechanism to handle this behavior, methods in an MqttCallback Object registered with a client, will be invoked as appropriate. MqttCallback is an interface that must be implemented by another class...To enable the callback feature, a callback object is registered with a client, this would most logically be done prior to connecting to the server

And after reading the last two lines i mentioned, i got confused.because as far as i understood, the essence of having a client registered to the calback that hasconnectionLost,deliveryComplete,messageArrivedis to handle the server states "asynchronously" and read from the server.

Now, my question is, regarding the last two lines i quoted, How i should register a client to read states from the server prior connecting to the server itself? or in other words, "why, "client.callback" should be called prior to "client.connect()"?"

Can anyone please clarify and explain this point.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Amrmsmb
  • 1
  • 27
  • 104
  • 226
  • I can't pretend to be an expert to MQTT but what I did was to follow this tutorial http://dalelane.co.uk/blog/?p=1599 and implement my own client. It does have bugs which you'll have to fix and is a bit out of date but I think it explains the concepts pretty well and has a semi (90%) working codebase you can look at to understand what's going on behind the scenes. – kha Nov 13 '14 at 14:42
  • thank you for the answer. but i just want to know why, "client.callback" should be called prior to "client.connect()"? – Amrmsmb Nov 13 '14 at 14:45
  • 1
    Ah. I think what that means is that you register you callback before you actually connet() so if there're any notifications pending, you don't miss them between the connect() and the callback being registered and called. Imagine you have a pending notification. on line (1) you have connect() and line (2) you register the callback. Due to the async nature, between your connect and registering the callback (between line 1 and 2) you may miss your pending notification. At least that's my understanding of it. – kha Nov 13 '14 at 14:48
  • almost it is cleear to me now, but would ypu please tell me, how there wil be a pending notification about a topic the i have not connected to it yet?isnt notifications are always about a subscribed topic? – Amrmsmb Nov 13 '14 at 14:59
  • 1
    The point is, in-between you connecting and subscribing, and registering the callback, a message may arrive which is why they recommend you register your callback handler before you connect in case there are stuff pending in a queue. MQQT (over ActiveMQ at least) is like any other queuing system. If you look at your MQQT server, what's happening is that you publish something to a "topic". You can view this topic as an MQ (message queue) where your server puts in content and your clients consume them... (cont.) – kha Nov 13 '14 at 15:06
  • 1
    Your server can easily put messages on that topic if there are no consumers (fire-and-forget) or can choose to persist the messages until they've been delivered (keeping track of delivery to known clients, etc.). In both cases, you can connect and immediately receive something on that topic you just connected and subscribed to before you get a chance to register a callback so it's safer to register your callback before connecting. – kha Nov 13 '14 at 15:07

2 Answers2

1

When you set the callback, all you're doing is registering which function gets called when a new message is received. Nothing actually happens until you connect to the MQTT broker. You should set your callback before you connect so you don't miss any messages.

For example, if cleansession == 0, the MQTT broker will immediately resume your previous session when you connect. If there are messages waiting for you and you haven't set your callback function, you might miss those messages.

Even if cleansession == 1, it's likely that the very next command after you connect is MQTTClient_subscribe. For similar timing reasons, you should set the callback before you call MQTTClient_subscribe. So it's either callback-connect-subscribe or connect-callback-subscribe when you know that cleansession == 1. Not much of a difference, so you might as well get into the habit of setting the callback function before you connect.

swmcdonnell
  • 1,381
  • 9
  • 22
0

...To enable the callback feature, a callback object is registered with a client, this would most logically be done prior to connecting to the server

This almost implies that the MqttClient.setCallback() SHOULD be called prior to connecting, but doesn't need to happen in order for it to work; I haven't tested this but that's what I get from that statement.

What I'm presuming will happen is that the client will connect (or not) and your application will have no way of knowing the result because that decision is arrived via the callbacks. Hope this helps!

Clocker
  • 1,316
  • 2
  • 19
  • 29