GitHub release
Integration guide
Changelog:
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.wonderPushWillOpenURL: for advanced handling of deep links throughout the entire SDK.PATCH /installation fails, and debug logs are enabledGitHub release
Integration guide
Changelog:
WonderPushDelegate you can implement for a tighter integration.urlForDeepLink() for advanced handling of deep links throughout the entire SDK.GitHub release
Integration guide
Changelog:
GitHub release
Integration guide
Changelog:
WonderPushChannel and WonderPushChannelGroup modification supplied to WonderPushUserPreferences.targetSdkVersion to 26 as well.minSdkVersion is raised to 14. See d895ea6a12c648ff96f83e214920a23bedd5a7e4com.google.android.gms:play-services-gcm to 11.0.4. See d895ea6a12c648ff96f83e214920a23bedd5a7e4targetSdkVersion as it would be inherited by your applications.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:
android {
compileSdkVersion 26
buildToolsVersion '26.0.1'
defaultConfig {
minSdkVersion 14
}
}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.
Read more:
Mixed versions of support libraries
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.
GitHub release
Integration guide
Changelog:
Start using Android O Notification channels today.
See the WonderPushUserPreferences reference for more.
GitHub release
Integration guide
Changelog:
WonderPushExtension to fix integration with use_frameworks!@APP_OPEN on background SDK interactionsAlthough this is a bugfix release, the SDK integration had to be changed slightly for the Notification Service Extension in order to fix a bug when integrating the SDK while using use_frameworks! in your Podfile.
The new Podfile content for your Notification Service Extension should be:
target 'NotificationServiceExtension' do
pod 'WonderPushExtension', '~> 2.2'
endThe new Objective C include should be (same for the Swift bridging header):
#import <WonderPushExtension/NotificationServiceExtension.h>The new Swift import should be:
import WonderPushExtensionGitHub release
Integration guide
Changelog:
bigPicture to bigText on network error when fetching the image