Open hypesystem opened 9 years ago
This blog post with the correct cURL requests might come in handy: https://medium.com/appunite-edu-collection/notifications-d7df385b0ff4
@hypesystem Isn't notification_key
deprecated? Is there any reason to invest time in this?
It is! Let's close this.
Woops! Looks like I spoke too quickly. While the notification_key
field is deprecated (should use to
instead) the generation of notification keys (representing a group of devices) is still something that the library could assist in. See the docs (up-to-date link) for more details https://developers.google.com/cloud-messaging/notifications
@hypesystem Oh, cool!
Seems pretty easy, we need to add a function that accepts a sender ID
, notification key name
and registration tokens
, executes the following request, and returns the notification key
from the GCM response.
https://android.googleapis.com/gcm/notification
Content-Type:application/json
Authorization:key=API_KEY
project_id:SENDER_ID
{
"operation": "create",
"notification_key_name": "appUser-Chris",
"registration_ids": ["4", "8", "15", "16", "23", "42"]
}
HTTP/1.1 200 OK
{“notification_key”:”<NOTIFICATION-ID>”}
Where should we implement this? I think sender.js
is a good idea, since we need to authenticate the request with a GCM API_KEY
.
I think this probably calls for some better abstraction than just the Sender
. It does not really have anything to do with sending :smile:
I mean, it would be easy to add it to Sender
but I honestly don't think that's where it belongs.
It will be significantly harder to create a new abstraction, because a lot of the code would be shared and a lot of the arguments expected would be the same in Sender#send
and this new createNotificationKey
method.
Basically, I don't know. It's a tradeoff. If you think it would be fine to add it to Sender for now, then I think we could do that :smile:
Hello @hypesystem and @eladnava,
If you would be willing to work with me, I could potentially help with this and other tasks. I submitted a pull request from SpireTeam's yodel-gcm repo a while back, but it was understandably rejected due to the fact that it was huge and basically changed a lot without explaining changes well. However, it contained a lot of functionality for handling notification key creation and management, so I may be able to at least offer a bit of help from that experience.
My notification key management in yodel-gcm now seems a bit awkward after taking a fresh look, and I would like to work with you guys to come up with a more agreeable solution for node-gcm.
While I wrote yodel-gcm as a quick solution for my employer, my contributions here would be personal, and I'd like to do a better job collaborating with you all as a contributor. Thanks!
Hey @brianbowden, that sounds absolutely awesome! We would love to see and hear your thoughts :smile:
It should be possible to create notification keys server side (used for sending user notifications). This, however, is not prioritised as highly as simply sending user notifications.
See documentation: http://developer.android.com/google/gcm/notifications.html#gen-server