We have release the ability to segment on custom properties of an event.

You could previously segment on the event type and restrict on its age, and segment on user and installation custom properties, but segmenting on an event custom properties was not possible… until today!

In the segmentation form you will notice a new Event category with the known User event criterion you already know along with 5 new Event custom field entries:

The criterion in itself is pretty simple; it's a mix of User event and the custom field segmentation you already know:

As an example use case, one of our customer is using this brand new criterion to exclude users that have already read the article that they are going to notify their audience about, so they won't bug them uselessly and keep a smooth user experience.

We can't wait to see what you'll build with this new tool!

We have released the ability to control notification collapsing on iOS, completing the feature already available on Android and the Web.

By default, notifications sent inside a given campaign will update one-another, in order to avoid stacking up in the user's device.
We've been proposing the ability to manually control collapsing on Android and Web since a long time, but our implementation was lacking support for iOS… until today!

In the Management API, in the notification parameter of the POST /v1/deliveries call – parameter whose format reference is available here – accepted an alert.android.tag and alert.web.tag field. It now accepts an alert.ios.tag fields to complete the set, as well as the global alert.tag field to rule them all.

We will be exposing this feature from the dashboard soon.

A good use case is to assign a unique tag to a unique topic you might send multiple notifications updates about, like the live score of an ongoing match, or live updates about a breaking news.

We can’t wait to see what you’ll build with this new tool!

GitHub release
Integration guide

Changelog:

• README, description and keyword changes.
• No code changes from v1.0.0.

GitHub release
Integration guide

Changelog:

No changes from v1.0.0.
This release was needed because an older v1.0.0 likely was published then unpublished to the npm registry, making that version impossible to reuse.

GitHub release
Integration guide

Changelog:

• Initial stable version
• Simpler basic setup
• Supports both Android and iOS
• Supports rich notifications
• Exposes most native SDK functions

Note: You may not find that version on the NPM Registry because it likely was published and unpublished while in very early development stage, and an unpublished version cannot be reused. So simply use v1.0.1 instead, there are no code change.

We have released the ability to segment based on the user time zone.

In the segmentation form you will notice a new Time zone criterion under the Basic category.
This allows you to choose the precise time zone a user belongs to.

We can’t wait to see what you’ll build with this new tool!

We have released a new way of securing your communication with our Management API in presence of network failures.

Read the full reference on our API documentation.

Say you called our POST /v1/deliveries API endpoint to trigger the delivery of an important notification to millions of users, but as it sometimes happen on the internet, the connection failed, or worst, you sent the request but got no response after a abnormally long timeout. You would have no easy way of knowing whether or not the notification was actually sent and you simply did not receive the response, or if the WonderPush API didn't even read your whole request… until today!

The core idea to be robust in such incertain circumstances is the ability to safely retry an API call. An idempotent call is a call that you can perform multiple times and the result would be the same as if it was applied once – that's exactly what we want!
But how could we make the creation of a new delivery indempotent? We simply assign it a kind of unique identifier. If it's the first time we see that identifier, we go on and process the request, if not, then it's a retry and we can stop working right away, avoiding duplicate work.
The way we've implemented this is through the use of a dedicated header X-WonderPush-Idempotency-Key that you can mention in your requests with a unique identifier. Hence any POST/PUT/PATCH/DELETE request bearing this header can be safely retried.

Using such feature you can even lower your timeouts and retry API calls earlier.

Read the full reference on our API documentation.

Tell us if you like this and it proved useful facing unexpected network issues!

GitHub release
Integration guide

Changelog:

• WonderPushDelegate protocol you can implement for a tighter integration.
  Currently only proposes wonderPushWillOpenURL: for advanced handling of deep links throughout the entire SDK.
• Fixed a crash when PATCH /installation fails, and debug logs are enabled

GitHub release
Integration guide

Changelog:

• WonderPushDelegate you can implement for a tighter integration.
  Currently only proposes urlForDeepLink() for advanced handling of deep links throughout the entire SDK.

GitHub release
Integration guide

Changelog:

• Fix empty-named notification channels in Android O
• Fix default channelId fallback