Mqtt and Push notifications

Question

I have made an app for ios devices that can connect to a mqtt broker and send and receive messages when the app is in the front or background state.

Now I want to archive to receive messages even if I terminate the app from the background state.

I believe pushy is a very good documented service so I was looking at this and its backend tutorial.

For my broker I use hivemq and my question now is, can I modify the code that uses to send messages with that the pushy has? Or maybe could I use another broker more flexible?

To sum up I want to know how can I setup my broker to send push notifications (hivemq or anything else more customizable)

Any documentation will be great

Thanks in advance.

Solution 1

Finally I found out what it should be.

Hivemq has a guide for developing a plugin with java, so that I did, I implemented push notification backend and with mysql connected clients and when the message comes I search offline clients with the topic of the message and send only to them the push!

Thanks all for your help.

Solution 2

A push notification on iOS/Android is generally capable of waking up or even starting the target app from scratch. As compared to MQTT, where an app can receive a message only when it's started and subscribed to the broker. Push notifications are very special and very different kind of message. The fact the one particular push notification service uses MQTT for its transport does not mean that you could do the same. Well, unless you want to code such full blown service yourself. You cannot really do it just with a "more customizable MQTT broker" - MQTT broker can't make your app to start up.

Plus, Pushy uses MQTT only for Android, because on Android, one can reportedly fake the official GCM/FCM push backend - and it's apparently not easy because majority of services just piggybacks on GCM/FCM. On iOS, you are inescapably dependent on the official APNS and even Pushy must use it - no MQTT push on iOS.

Comments

[hardillb]

It's really not clear what you are asking here.

[mike vorisis]

@hardillb thanks for writing your 'argument' and not downvoted the question, I edited so if you have any question please leave a comment

[hardillb]

On Android you can run services permanently in the background which can remain connected to the MQTT broker. iOS only allows a very restricted set of services (BLE, VoIP and location services) to run in the background so you have to use APN to wake the app then connect to MQTT to retrieve messages.

[Pavel Zdenek]

@hardillb there is "background fetch" since iOS 7 for generic network connection tasks. Sure not suitable for sustained service like VoIP, iOS decides when to call it and can run for 30secs max or iOS will kill it. But that's most probably what OP uses.

[Pavel Zdenek]

I don't see how this is related to MQTT which you asked for in the first place

[mike vorisis]

@PavelZdenek because this is what I use to send messages, but I didn't know how to send them when the app is terminated.

[ahalls]

Hello Mike, Your are doing exactly what I want to do as well. Have you made the source for your plugin available?

[mike vorisis]

I will upload it on github along with the swift code until the beginning of July @ahalls