Repository navigation
Conversation
It seems like a good idea to read out other things then just the message. Backwards compatibility is ensured by still sending the message as a first parameter. In these examples: https://developers.google.com/cloud-messaging/downstream#receiving-messages-on-an-android-client-app it would seem that that is the intention of the message. I'm not quite sure if this will work though, because I couldn't find a 'how-to-contribute' kind of page. So I'm not sure how to build the `.jar` that's a part of the npm package. Let me know what you think of this change.
* Java Bundle as json, to string.. which is meh 😵
76b65a9 to
2fd96ff
Compare
|
I adjusted this a bit. I'm not sure if this is something everyone wants. At the moment I'm not sure how to pass through a JSONObject as json in JS but maybe someone can help. I guess it could be more efficient than making a JSONObject passing it as |
|
+1 Was just about to crete a pull request when I realized that atm one can't pass for example some metadata to the NativeScript app, which I need. One only seems to get the "message". |
|
Hi again. Just wanted to elaborate why I think this is important. What I think is needed is a way of letting the app know that it is suppose to fetch a new "object" from the backend. In my previous project we have implemented that with the push functionality, either via "silent" pushes i.e not notifying the user or notification and db update (in the background) so that when the user starts/activates the app they will have update information from the backend. As I understand it we can't achieve this given that the whole "object" isn't passed to the callback? Since it seems that this implementation is more geared towards the actual message that is being displayed. Thanks in advance |
|
Hi Niclas, That's what I thought. The whole point of the GCM was that you can also send extra information about what is updated etc, or the source. (e.g. someone sends message you want to send message back). But now that can almost solely be done by parsing the message or thinking of some other round about way. What I tried in my pull request to push through the whole object. And for me it's working (I built it and am using my version of the plugin). The extra info is all coming through. Then after that it's up to the developer what he/she is going to with it, right? Fritz |
|
+1 |
3 participants
It seems like a good idea to read out other things then just the message. Backwards compatibility is ensured by still sending the message as a first parameter.
In these examples: https://developers.google.com/cloud-messaging/downstream#receiving-messages-on-an-android-client-app
it would seem that that is the intention of the message.
I'm not quite sure if this will work though, because I couldn't find a 'how-to-contribute' kind of page. So I'm not sure how to build the
.jarthat's a part of the npm package.Let me know what you think of this change.