Closed themartorana closed 9 years ago
This looks good to me. @bdotdub
There was some talk of making Alert a pointer but what you have here looks like a good step in the interim.
Oh. See #26.
The only problem with using a series of pointers in structs is they can end in race conditions if any goroutines mutate the underlying pointer.
For that reason, I took the same approach here for omitempty
badges: https://github.com/joekarl/go-libapns/pull/8
It's not "pretty" but it's thread-safe. (I can move this discussion to #26 if you like.)
That is a good point. We aren't wanting to share the data (pointers). I wonder if we should do something like that for badges too?
(I'd be happy to code that up and submit a pull request, although it would break the API.)
For this, though, I'm hesitant to make Alert
a pointer for the same reason. If Alert
were type interface{}
though, wouldn't that get us 90% of the way there? You can check for nil, and it will pass by value.
Edit: Test: http://play.golang.org/p/1OwVR_fTzT
I'd wait for some feedback from @bdotdub, who is the maintainer of the project.
:+1:. I was a proponent of pointers before, but this is semantically nice. Also like the badge approach from joekarl/go-libapns#8. I wish they were more convergent, but I'll live.
If this beats #36 then #36 becomes unnecessary. If #36 beats this in then it's a simple merge conflict.
@themartorana Sorry, there is a merge conflict due to my changes in #36. Should be easy to resolve.
@nathany fixed!
LGTM
Following Apple's specs, this changes the marshaled JSON for
apns.Alert
to set thealert
key to the text ofAlert.Body
if all other fields of the alert are empty. Also updated the.isZero()
check to check the.Title
and.Action
properties of the alert.From: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html