Support for creating notification keys server-side

[hypesystem]

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

[hypesystem]

This blog post with the correct cURL requests might come in handy: https://medium.com/appunite-edu-collection/notifications-d7df385b0ff4

[eladnava]

@hypesystem Isn't notification_key deprecated? Is there any reason to invest time in this?

[hypesystem]

It is! Let's close this.

[hypesystem]

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

[eladnava]

@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.

[hypesystem]

I think this probably calls for some better abstraction than just the Sender. It does not really have anything to do with sending 😄

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 😄

[brianbowden]

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!

[hypesystem]

Hey @brianbowden, that sounds absolutely awesome! We would love to see and hear your thoughts 😄