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!
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.
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!
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.
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
WonderPushDelegate you can implement for a tighter integration.
Currently only proposes urlForDeepLink() for advanced handling of deep links throughout the entire SDK.
Setup Android O Notification Channels for each WonderPushChannel and WonderPushChannelGroup modification supplied to WonderPushUserPreferences.
Properly handle Android O background limits by fetching notification resources (images and sound) using a scheduled job.
Builds against Android SDK 26 (Android O) Note: It is not required to update targetSdkVersion to 26 as well.
minSdkVersion is raised to 14. See d895ea6a12c648ff96f83e214920a23bedd5a7e4
Updating com.google.android.gms:play-services-gcm to 11.0.4. See d895ea6a12c648ff96f83e214920a23bedd5a7e4
The SDK no longer uselessly sets targetSdkVersion as it would be inherited by your applications.
Fix notification color on notifications received in foreground
Upgrading:
Starting with this version, as Android O Notification Channels are created and updated, the WonderPush SDK requires you to use at least compileSdkVersion 26 and support libraries must use version 26.0.2 minimum.
This in turn requires you to use at least minSdkVersion 14.
Here is an extract of the changes needed in your app/build.gradle:
Note that this does not force you target Android O, you can keep a lower targetSdkVersion if you need to.
Minimum SDK version 14
In order to be able to register Notification Channels in Android O, the WonderPush SDK has to compile against the Android SDK version 26.
This requires using Support libraries version 26, which, along with updating com.google.android.gms:play-service-gcm above version 10.2 for the latest push notification-related fixes, bumps the minSdkVersion to 14, as far as WonderPush is concerned (your application may already target a higher minimum version).
Compared to the previously imposed minSdkVersion 9, jumping to minSdkVersion 14 only affects 0.7% of all Android users. Note that Android SDK 14 (aka Android 4.0, Ice Cream Sandwich) was released on October 2011, more than 6 years ago. In addition, in their blog post, Google says that ``We believe that many of these old devices are not actively being used.''
You can avoid to left those users behind if this is a strong requirement for your application, by building multiple APKs using build variants as shown in the blog post. Doing so you can either drop support for push notifications or use the version 1.2.3.3 of the WonderPush SDK.
You probably use one of the Android Support Libraries (starting with com.android.support:) in your project, you will need to ensure that you use version 26.0.2 at minimum.
After updating the WonderPush SDK version, make sure that your project uses the same version of these libraries all over the place.
See Mixed versions of support libraries for more information.
Conflicting versions of Google Play Services
Likewise, if you declare a dependency on one of the com.google.android.gms:play-services libraries, you will need to ensure that you use version 11.0.4 at minimum.
After updating the WonderPush SDK version, make sure that your project uses the same version of these libraries all over the place.
See Conflicting versions of Google Play Services for more information.
