Send message from device to another...Options to consider


My application will be in Android and IOS. I assume that users from any device can send messages to users of any device, correct? If that’s correct, then if an android device sends a message, does it put Android header, IOS headers or Both ? as I wouldn’t know what device the receiver is on
Background Info:
That being said, I am working on the android app now. My goal is to have a user sends a message to another user (push notification regardless whether the app is open or not). The receiver does not have to engage in an accept/decline like the chat example provided by BackendLess

I read a fair amount of documentation about it and at this point I am not sure of the right way to do things. So I will propose the options I have in mind. Please let me know if one is better (or one I shouldn’t do) or even if there is better option

1- Documentation says that you don’t have to use the “channel” concept and you can use deliveryOptions.addPushSinglecast( receiver-device-id );
With this option, I have to know the device ID of the receiver. To know this, I can store it as custom property in the Users table when the device registers so I can pull this info. The problem here is that there might be multiple devices for the user and now I have to keep it as an array. Not an issue, but sounds like a headack maintain this list up to date

2- Use the channel publish/subscribe model with filtering. This way All my users will subscribe to the same channel. I will filter the message based on the “intended user Object ID” in the message/header. I don’t like this option as I fear the channel is being overloaded and too much redundant processing is happening

3- This is my preferred option. Use channel publish/subscribe mode where every user subscribe to a specific channel with a name matching his/her userId (or ObjectId from User table). Therefore when a user A need to message User B, User A publish a message to User B Channel. My 2 worries are a) that we could end up with hundreds of thousands of channel (I noticed from docs that this is not an issue) and b) does the app have to be open to receive the message from the channel (I don’t think so)

So I am in favor of option 3 but what’s your take on this? This is the core of the app

Thank you very much

It seems that options 3 is really the best fit for your requirements, though I would also look further into option 1.

Indeed, the huge number of channels should not be a problem. But with pub/sub you currently need to have the application open, while with push notifications you may receive them also when the app is turned off (silent push notifications). We’re also planning to provide support for pub/sub via pushes (so this way you would be able to receive them with app turned off), but I can’t promise that this feature will available soon.

Hello Sergey,
Thanks for your input.
The only comment I am not sure about is

But with pub/sub you currently need to have the application open, while with push notifications you may receive them also when the app is turned off (silent push notifications).

When I read the documentation, I see that you can send push notification
MessageStatus Backendless.Messaging.publish( String channelName, Object message, PublishOptions publishOptions ) throws BackendlessException

Which is the same method used in the pub/sub. So how is it different?
I assume when you register the device and you put the channel name, then you become a subscriber of that channel and you will get the push notification when the app is not open when the above method is called.

Correct? What am I missing here?

The same method can be used to send out:

    just a publish/subscribe message just a push notification both a pub/sub message AND a push notification
This is done through the following method:

The key here is the DeliveryOptions object. It contains the following method:

setPublishPolicy( PublishPolicyEnum enum );

where PublishPolicyEnum has the following values:


Hope this helps.