You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+51-7Lines changed: 51 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -150,22 +150,66 @@ pusher.trigger_batch([
150
150
])
151
151
```
152
152
153
-
#### Event Buffer
153
+
##Push Notifications (BETA)
154
154
155
-
Version 1.0.0 of the library introduced support for event buffering. The purpose of this functionality is to ensure that events that are triggered during whilst a client is offline for a short period of time will still be delivered upon reconnection.
155
+
Pusher now allows sending native notifications to iOS and Android devices. Check out the [documentation](https://pusher.com/docs/push_notifications) for information on how to set up push notifications on Android and iOS. There is no additional setup required to use it with this library. It works out of the box wit the same Pusher instance. All you need are the same pusher credentials.
156
156
157
-
**Note: this requires your Pusher application to be on a cluster that has the Event Buffer capability.**
157
+
### Sending native pushes
158
158
159
-
As part of this the trigger function now returns a set of event_id values for each event triggered on a channel. These can then be used by the client to tell the Pusher service the last event it has received. If additional events have been triggered after that event ID the service has the opportunity to provide the client with those IDs.
159
+
The native notifications API is hosted at `nativepushclient-cluster1.pusher.com` and only accepts https requests.
160
160
161
-
##### Example
161
+
You can send pushes by using the `notify` method, either globally or on the instance. The method takes two parameters:
162
+
163
+
-`interests`: An Array of strings which represents the interests your devices are subscribed to. These are akin to channels in the DDN with less of an epehemeral nature. Note that currently, you can only send to _one_ interest.
164
+
-`data`: The content of the notification represented by a Hash. You must supply either the `gcm` or `apns` key. For a detailed list of the acceptable keys, take a look at the [docs](https://pusher.com/docs/push_notifications#payload).
Push notification requests, once submitted to the service are executed asynchronously. To make reporting errors easier, you can supply a `webhook_url` field in the body of the request. This will be used by the service to send a webhook to the supplied URL if there are errors.
186
+
187
+
You may also supply a `webhook_level` field in the body, which can either be INFO or DEBUG. It defaults to INFO - where INFO only reports customer facing errors, while DEBUG reports all errors.
188
+
189
+
For example:
190
+
191
+
```python
192
+
data = {
193
+
"apns": {
194
+
"aps": {
195
+
"alert": {
196
+
"body": "hello"
197
+
}
198
+
}
199
+
},
200
+
'gcm': {
201
+
'notification': {
202
+
"title": "hello",
203
+
"icon": "icon"
204
+
}
205
+
},
206
+
"webhook_url": "http://yolo.com",
207
+
"webhook_level": "INFO"
208
+
}
209
+
```
210
+
211
+
**NOTE:** This is currently a BETA feature and there might be minor bugs and issues. Changes to the API will be kept to a minimum, but changes are expected. If you come across any bugs or issues, please do get in touch via [support](support@pusher.com) or create an issue here.
0 commit comments