GitHub release
Integration guide

Changelog:

• 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:

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:

• Google Play services and Firebase for Android will support API level 14 at minimum
• Support libraries and minimum supported API level
• Platform versions pie chart

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:

• Android O Notification channels, available to previous Android versions too

Start using Android O Notification channels today.
See the WonderPushUserPreferences reference for more.

GitHub release
Integration guide

Changelog:

• Split extension pod subspec into its own pod: WonderPushExtension to fix integration with use_frameworks!
• Avoid 10s delay and stange log on iOS 10 and deeplinks
• New sync algorithm: Fixes issues when setting properties at the very first launch, and more robust
• Support at notification reception actions
• Debugging: Allow to override notification receipt locally, using data notifications
• Debugging: Allow to override setLogging() locally, using data notifications
• Add actions to act on the new sync algorithm for better SDK-server synchronization
• Avoid spurious @APP_OPEN on background SDK interactions
• Fix date encoding and decoding when saving/restoring previous user data
• Better logs

Upgrading

Although 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'
end

The new Objective C include should be (same for the Swift bridging header):

#import <WonderPushExtension/NotificationServiceExtension.h>

The new Swift import should be:

import WonderPushExtension

GitHub release
Integration guide

Changelog:

• New sync algorithm: Fixes issues when setting properties at the very first launch, and more robust
• Fix spurious @APP_OPEN on background SDK interactions
• Fallback from bigPicture to bigText on network error when fetching the image
• Error-resistant looper for handlers
• Support at notification reception actions
• Debugging: Allow to override notification receipt locally, using data notifications
• Debugging: Allow to override setLogging() locally using data notifications
• Debugging: Promote some error logs to show even if setLogging(false)
• Add actions to act on the new sync algorithm for better SDK-server synchronization

GitHub release
Integration guide

Changelog:

• Fix custom properties merging when receiving access token
• startActivity() from the application context
• Increase job queue from 10 to 32
• More logs in debug mode

GitHub release
Integration guide

Changelog:

• iOS 10 media attachment for rich notifications
• Present notification while app is foreground on iOS 10
• Identify new devices
• Fix rare crash on access token fetch

Upgrading

Supporting iOS 10 rich notifications

In order to use rich notifications, you must add a Notification Service Extension to your project and let the WonderPush SDK do the hard work for you.

First, let's add the new application extension to your project:

• Open the XCode File menu, under New select Target….
• In the iOS tab, in the Application Extension group, select Notification Service Extension and click Next.
• Give it a name you like, here we soberly chose NotificationServiceExtension.
  Choose the same team as your application target.
  Make sure that it is linked to your project and embedded in your application, in the bottom.
  Click Finish.
• XCode will ask you whether you want to activate the new scheme. Click Activate.

Then, we need to link the extension to another pod of the WonderPush SDK.
Open your Podfile and add the following:

# Create a new target using the exact same name that you entered above
target 'NotificationServiceExtension' do
    # Use the same platform as your application target
    platform :ios, '7.0'
 
    pod 'WonderPush/NotificationServiceExtension', '~> 2.0'
end

Then run the following command to incorporate the WonderPush SDK pod to your extension:

pod install

You should see the following files in your Project navigator:

• YourProject
  • NotificationServiceExtension (this is the name of the service extension you chose earlier)
    • NotificationService.h
    • NotificationService.m
    • Info.plist

We are going to remove almost all generated code to rely on a utility class the implements it all for you.

Open NotificationService.h and modify it so that it reads:

#import <WonderPush/NotificationServiceExtension.h>
 
// We delegate everything to WPNotificationService
@interface NotificationService : WPNotificationService
 
@end

Then open NotificationService.m and modify it so that it reads:

#import "NotificationService.h"
 
@implementation NotificationService
 
// The WPNotificationService superclass already implements everything
 
@end

App Transport Security setting for the Notification Service Extension

You probably have set App Transport Security Settings / Allow Arbitrary Loads to YES in your application, if so, you likely want to repeat the same step for your Notification Service Extension.
Without this, you would not be able to load rich media from HTTP resources and attach them to your notifications, only HTTPS resources would work.

Here are the steps:

• Select your project in the Project navigator on the left pane
• Click your Notification Service Extension target (not the application target)
• Go to the Info tab
• Add the App Transport Security Settings key
• Click the + to add an entry inside it
• Set Allow Arbitrary Loads to YES.

Alternatively, open your Notification Service Extension (not the one from your application) Info.plist file and add the following entry:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

ADVANCED

If you want to have your own code running, by example for notifications sent by other push providers, you can keep the code generated by the XCode template.

If not, then skip this sub-section.

Our NotificationServiceExtension SDK functions return a boolean value indicating whether the call has been handled or not.
You can hence keep the generated code and simply add the following import to your NotificationService.m file:

#import <WonderPush/NotificationServiceExtension.h>

And add the following at the beginning of the two methods of your implementation:

- (void)didReceiveNotificationRequest:(UNNotificationRequest *)request withContentHandler:(void (^)(UNNotificationContent * _Nonnull))contentHandler {
    if ([WonderPushNotificationServiceExtension serviceExtension:self didReceiveNotificationRequest:request withContentHandler:contentHandler]) {
        // Handled by the WonderPush NotificationServiceExtension SDK, we're done
        return;
    }
 
    // […]
    // There should be somewhere a call like this: contentHandler(request.content);
}
 
 
- (void)serviceExtensionTimeWillExpire {
    if ([WonderPushNotificationServiceExtension serviceExtensionTimeWillExpire:self]) {
        // Handled by the WonderPush NotificationServiceExtension SDK, we're done
        return;
    }
 
    // […]
}

If you want instead to be able to modify a notification for your own processing while letting the WonderPush NotificationServiceExtension SDK perform its own processing too,
that is if you want the changes to be cumulative, you should pass a modified request to the SDK as shown below:

- (void)didReceiveNotificationRequest:(UNNotificationRequest *)request withContentHandler:(void (^)(UNNotificationContent * _Nonnull))contentHandler {
    // Make your own copy of the content
    UNMutableNotificationContent *content = [request.content mutableCopy];
 
    // Modify the content as needed
    //content.title = [NSString stringWithFormat:@"%@ [modified]", content.title];
 
    // Wrap up your changes in a new request
    request = [UNNotificationRequest requestWithIdentifier:request.identifier content:content trigger:request.trigger];
 
    // Forward the call to the WonderPush NotificationServiceExtension SDK
    if (![WonderPushNotificationServiceExtension serviceExtension:self didReceiveNotificationRequest:request withContentHandler:contentHandler]) {
        // The notification was not for the WonderPush NotificationServiceExtension SDK, handle it ourself
        contentHandler(request.content);
    }
}

New UserNotificationCenter delegate

In order to offer full support for iOS 10 notifications, including presenting them while the app is foreground, you must register a new delegate on the UNUserNotificationCenter class.

This is done very simply by calling [WonderPush setupDelegateForUserNotificationCenter] along with your current call to [WonderPush setupDelegateForApplication:] as shown below:

- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [WonderPush setClientId:@"YOUR_CLIENT_ID" secret:@"YOUR_CLIENT_SECRET"];
    [WonderPush setupDelegateForApplication:application];
    [WonderPush setupDelegateForUserNotificationCenter]; // ← add this new line and you're done!
    return YES;
}

If you do not wish to use this automatic setup, you will have to implement each method of the UNUserNotificationCenterDelegate protocol that have their matching function in the WonderPush SDK, and call the SDK in each of them.

The use of the automatic delegate setup does not prevent your implementations of the same-named methods from being called.
In fact our delegate makes sure that every message it receives is passed on to your delegate, whether it intercepted it for its own needs or not.

GitHub release
Integration guide

Changelog:

• Avoid network call when setNotificationEnabled() is called with the current value

GitHub release
Integration guide

Changelog:

• Broadcast a local intent on push token changes
• Keep activity stack
  Previous behavior launched the targeted or default activity with its natural parent stack, loosing any current navigation. New behavior aims to keep the user navigation intact.
  Here is the detailed flow:
  • Without deeplink:
    • If app is in foreground: display any in-app above current activity
    • If app was in background: raise last activity to foreground and display any in-app above it
    • If app was quit: start the default activity with its natural parent stack
  • With deeplink:
    • If app is in foreground:
      • If already on the desired activity: give it the new deeplink data and display any in-app above it
      • Otherwise, start the target activity. Pressing back will return to the previously displayed activity
    • If app was in background: raise last activity to foreground and proceed like if app was in foreground
    • If app was quit:
      • If the target activity has declared a parent activity, start it with its natural parent stack
      • Otherwise, start it with the default activity as parent and the latter natural parent stack

GitHub release
Integration guide

Changelog:

• Rename WPClient to WPAPIClient to avoid conflicts with WirelessProximity private framework
• Fix background task end when running out of time

GitHub release
Integration guide

Changelog:

• Remove capability detectors that require usage descriptions for iOS 10
• Fix localization with use_frameworks!
• Fix infrequent crash on reading an error response from an network call
• Silence iOS 7 deprecated functions warnings