ToothlessGear / node-gcm

A NodeJS wrapper library port to send data to Android devices via Google Cloud Messaging
https://github.com/ToothlessGear/node-gcm
Other
1.3k stars 206 forks source link

Support for creating notification keys server-side #108

Open hypesystem opened 9 years ago

hypesystem commented 9 years ago

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 commented 9 years ago

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

eladnava commented 8 years ago

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

hypesystem commented 8 years ago

It is! Let's close this.

hypesystem commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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:

brianbowden commented 8 years ago

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 commented 8 years ago

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