How to get channel & custom object

Messaging Service Push Notifications
1

Hello. I have extended the BackendlessPushService and handle my messages in

public boolean onMessage(Context context, Intent intent) {...}

. So far so good, the method gets called and i can get the message if it is a String by calling

intent.getStringExtra("message")

.

But what if I want to send something else that a String? The publishing API on Java (custom business logic) accepts an “Object” as the message, so that implies that I could send, say, a BackendlessUser. But how can I retrieve the message then? And what type/class would it have/be?

And the second question is: How can I get the channel I published the message in. I initialize my service with

Backendless.Messaging.registerDevice("my sender ID", my List<String> of channels, Date in 100 days, AsyncCallback);

. So one service is called “channel.new_match”, for example. How can I get that String from the intent?

2

And how can I get the subtopic?

3

Hi Felix,

You can try to get the object using intent.getSerializableExtra(), but the better approach would be to use any kind of serialization (json, for example) and put/retrieve it as a String.

Also, it seems that you cannot get the channel or subtopic name from a push notification, since it uses Android’s API which doesn’t have such information. As a workaround, you could specify these in the extras by yourself.

4

So on the server-side I could set the custom headers with:

mPublishOptions.putHeader("channel", "my_channel");
mPublishOptions.putHeader("subtopic", "my_subtopic");
mPublishOptions.putHeader("object_id", "376..."); // onject ID of the object to be transmitted

And I can retrieve them by using:

Sting my_channel = intent.getSting("channel");
Sting my_subtopic = intent.getSting("subtopic");
Sting object_id = intent.getSting("object_id");
Backendless.Persistance.of(SomeTable.class).findById(object_id, my_handler);

Did I get that right?

This sould be no problem, although it seems strange to my why you don’t include it in the onMessage() call as third and fourth parameters or something like that since pretty much every logic to deal with messages needs that kind of information.

5

Yes, exactly. Maybe we shall consider adding this automatically in the future.