Issue on getting the subscription packets

[Roger14]

Hi, thanks for sharing this amazing code. I have 2 questions. Appreciate you can assist.

1) Can you provide some sample codes on how the client can receive the published messages from MQTT broker? Based on the readme, below is the subscription codes.

val client = service.addBrokerAndStartClient(connections, connectionRequest)
val subscribeOperation = client.subscribe("test/+", QualityOfService.AT_LEAST_ONCE)

How should we receive the "test/+" topic messages? I was expecting to implement an onMessage method... :)

2) I like to clarify when we create the broker connection using the following way. when the Android app is in the background, with the service suppose to maintain and perform reconnection to ensure the connection between MQTT client and broker is still established? Because I realized when the app is in the background for some time, the connection will be closed. Any advice on how to implement a solution such that the app (in the background) is still able to publish messages to backend MQTT broker server?

val client = service.addBrokerAndStartClient(connections, connectionRequest)

Thanks a lot.

RK

[thebehera]

Good questions, I need to make this clear when I update the readme next.

Can you provide some sample codes on how the client can receive the published messages from MQTT broker?

As of now, there are two options you have:

• The SubscribeOperation object returned from the subscribe method will contain subscriptions: Map<ISubscription, Flow<IPublishMessage>> which you can use to get the messages based on the subscription. This is useful when you have multiple subscriptions within the same subscribe call. Admittedly, there should be a simpler solution when you only subscribe to a single topic as you did in your example subscribe("test/+", QualityOfService.AT_LEAST_ONCE). That's something I'll keep in mind as I plan to update this library.

If you want to go down this route, a you can combine the Flow like this:

combine(subscribe("test/+", qos).subscriptions.values) { pubs:Array<IPublishMessage> ->

}

• You can also use client.observe(Topic.fromOrThrow("test/+", Topic.Type.Filter)) which will return a Flow<IPublishMessage> which you can collect from. This will work regardless if you call subscribe as some mqtt brokers can publish messages to a client without a client explicitly subscribing to a topic. I'll also probably look into simplifying this method as it seems

when the Android app is in the background, with the service suppose to maintain and perform reconnection to ensure the connection between MQTT client and broker is still established?

Yes, however this is based on the background limitations that the Android OS has in place. This library does nothing to extend background execution, that is up you, the app developer to put those in place.

when the app is in the background for some time, the connection will be closed. Any advice on how to implement a solution such that the app (in the background) is still able to publish messages to backend MQTT broker server?

There are different ways to do this but it depends on your use case. For most solutions I would recommend letting the Android OS suspend or kill the service knowing that the mqtt service will automatically startup when the application runs again. If that doesn't fit your needs then I would consider looking into these options with their own pros and cons:

• Foreground Service
  • Pros: My potentially outdated knowledge says this can run indefinitely in the background. Cons: You must have an ongoing notification in the status bar
• Work Manager with multiprocess support. You can use this to bind to the MqttService upgrading it to foreground work, allowing it to stay alive.
  • Pros: No ongoing notification needed. Cons: Does not run at all times and can be killed/restarted based on the rules defined by the OS and library
• Do nothing, letting the OS kill or suspend the process. You might be missing published messages, but when you reconnect the messages from the mqtt broker should be queued server side and sent to you on reconnect. Comparing to iOS or Web, this might be the best solution for you as it doesn't drain the battery as much.

[thebehera]

closing for now, feel free to reopen if there are any other questions

[Roger14]

Hi,

Thanks for the quick answers. Appreciate it.

I followed your recommendations and tried to publish and subscribe to the same topic.
In addition, I deployed another standalone MQTT client connecting to the same broker, to listen to the topic.
Below are the key codes:

client.subscribe("test/a", QualityOfService.AT_LEAST_ONCE)

client.observe(Topic.fromOrThrow("test/+", Topic.Type.Filter)).collect{
       println("$it.topic | $it.payload")
}

val payloadBuffer = PlatformBuffer.allocate(payload.length, AllocationZone.SharedMemory)
payloadBuffer.writeString("abc") 
client.publish("test/a", QualityOfService.EXACTLY_ONCE, payloadBuffer, false)

The result was that after I published using the above codes, the standalone MQTT client was able to receive the message. However, the above observe flow didn't get called and didn't receive any message.

May I know is there something which I did wrongly? Thanks for your time, once again. :)