Synchronous or Asynchronous messaging over MQTT is called first

Question

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.

Answer 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.

Answer 2

...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!