I don't know if it's possible, but it would be nice to have ability to check and validate the format of the device registration token before we pass to the server.

Hi,

xmppUser method is generating XMPP user string by concatenating "senderId" with "xmppHost". It's a problem as host is set to "gcm-xmpp.googleapis.com". This results in auth error as GCM seems to be accepting only "[email protected]" as user. Changing "xmppHost" const to "xmpp.googleapis.com" solves the problem.

If my assumption on the problem is correct, I would suggest separating xmppHost from user string generation.

Hi folks,
I noticed that the TimeToLive field in the message structs is tagged as `json:"time_to_live,omitempty". From what I understand, this means that if TimeToLive has the default value (zero), then it will be omitted when marshaling the struct. If this is indeed the case (and according to my tests it is), then there is a discrepancy in the time_to_live usage, according to [https://developers.google.com/cloud-messaging/http-server-ref]:
time_to_live = 0, means that the notification should not be throttled and delivered immediately, and if this is not possible, then it should be discarded. However if I set TimeToLive = 0, it will be omitted from the message sent to the GCM server, and then the server will assume the default value, which is 4 weeks -- clearly, not what my intention was.

@silvolu please take a look at our fork https://github.com/rounds/go-gcm

• code refactored, http and xmpp clients separated
• monitors xmpp connection with xmpp pings, redials when it fails
• handles CONNECTION_DRAINING properly
• graceful close
• improved logging with logrus
• various govet/golint fixes
• Travis and Codecov added

The project runs in production for a couple of months, looks good)

xmppAddress is currently defined as a constant (https://sourcegraph.com/github.com/google/go-gcm/-/blob/gcm.go#L42) - this prevents clients from specifying the pre-prod server at gcm-preprod.googleapis.com:5236, or (more importantly for my use-case) connecting to the newer fcm-xmpp.googleapis.com:5235

What about: Firebase Cloud Messaging (FCM) is the new version of GCM. It inherits the reliable and scalable GCM infrastructure, plus new features! See the FAQ to learn more. If you are integrating messaging in a new app, start with FCM. GCM users are strongly recommended to upgrade to FCM, in order to benefit from new FCM features today and in the future.

How to use FCM endpoints?
fcm.googleapis.com/fcm/ and fcm-xmpp.googleapis.com

This is more of a usage question. I have started using this code in a server to listen to incoming GCM messages. I noticed that the GCM's stopped reaching my server suddenly but on restarting the server I got all the queued up GCM's. I am guessing that the listen connection had dropped in the night.

Should the the gcm.Listen call be in a forever loop like so:

func (r *Receiver) startListener() {
    for {
        err := gcm.Listen(r.gcmSenderId, r.googleApiKey, messageHandler, stopChannel)
        revel.INFO.Println("Restarted listener because of err", err)
    }
}

When a message is sent with the DryRun field set to true, FCM returns -1 as the MessageId. This causes unmarshalling to fail since the MessageId field is of type uint. Here's the fix

type HttpResponse struct {
    ...
    MessageId    int     `json:"message_id,omitempty"`
    ....
}

For XMPP there shouldn't be more than 100 messages pending:
https://developers.google.com/cloud-messaging/ccs#flow

Check the flow, add some more detail

There are two problems with this library
1.you must change Priority in HttpMessage struct in file gcm.go to int
2.if every things is ok but you get error Error=DeprecatedEndpoint
go to gcm.go again and on const section change httpAddress from this "https://gcm-http.googleapis.com/gcm/send" to "https://fcm.googleapis.com/fcm/send"

Recently, SendXmpp() started failing for me with the following error:

write tcp <IP>:<port>-><IP>:<port>: write: connection timed out

Restarting the Go process that called SendXmpp() makes this error go away, and push notifications start working again. But of course, restarting the Go process isn't ideal. Is there something I can do explicitly to handle this kind of error? For instance, is there a way to close the current XmppClient and retry sending the message, so that the retry instantiates a new XmppClient and opens a new connection?

After attempt to send message:

gcm.SendHttp(apiKey, message)

I'm receiving error:

error sending request to GCM HTTP server: error unmarshaling json from body: json: cannot unmarshal number 7168156478862157292 into Go value of type int

DebugMode = true:

sending:{"to":"dQmz...CRyA","data":{"message":"hello world"}}
received body:{"multicast_id":7168156478862157292,"success":1,"failure":0,"canonical_ids":0,"results":[{"message_id":"0:1469779167530028%d86f1c9df9fd7ecd"}]}

May be is necessary to change the type of HttpResponse.MulticastId to int64 or string?

Need to handle cases where we need to connection open (one is draining, one is new), and understand how long should the connection under draining be kept open.

Writing test code for packages using this lib is difficult because of the static send methods. Exposing an interface wrapping the public facing methods will help writing more testable code for users depending on this lib.

Thoughts?

Re-structure the code in the process

Any plans to implement the server-side changes to support encrypted payload data into go-gcm so that notifications to Chrome 50 (and in the current version of Firefox on desktop) can contain extra information?

https://developers.google.com/web/updates/2016/03/web-push-encryption

Can someone post a sample code of basic use of this library.(Listen , Send, Receive)

http.DefaultTransport and http.DefaultClient are not available in App Engine.