Flurry Push for iOS¶
Flurry Push enables app developers to send targeted messages to re-engage and retain users. To start using Flurry Push on iOS:
Integrate the latest Flurry SDK for iOS
If using Cocoapods, include “pod ‘Flurry-iOS-SDK/FlurryMessaging’” in your podfile
Follow the integration steps below
Provide Flurry your authorization credentials
Test your integration via test push
Enable Push Notifications
Enable Background Modes (Background Fetch and Remote Notifications turned on)
Include header file
If using Objective-C, include FlurryMessaging.h.
If using Swift, no action is required.
import Flurry_iOS_SDKincludes messaging header file.
Auto Integration - With Auto Integration, Flurry handles everything for you. All you have to do is to call the integration API
[FlurryMessaging setAutoIntegrationForMessaging]. We’ll receive the notification, convert it to a FlurryMessage, show the notification, handle the notification click, handle the dismissed notification, and handle all the Flurry logging associated with it. Want some customized functionality? You have the option of passing us a delegate to handle any of these steps yourself.
Manual Integration - With Manual Integration, your app is responsible for handling the notification receivers and logging events like “Opened” to Flurry. Flurry will check if a notification is sent from Flurry Portal or not. If so, Flurry has
receivedNotificationResponsethree methods to help you organize what to do when a remote Flurry notification is arrived.
If you are integrating Flurry Push alongside one or more other push providers, we recommend using manual instead of auto integration.
Flurry will receive the push notification (from APNs) and convert it to a Flurry Message. You may optionally set a listener to get notified when a push is received and opened. This allows you to handle and customize each event as you wish.
Setup for receiving push Notifications - Flurry will register with UNUserNotificationCenter (>= iOS 10) or UIUserNotification. Also, set up the delegate to receive the below notifications
Notification Received - Flurry will LOG and SHOW the notification if the app is in the background. If the app is in foreground Flurry will LOG but NOT show the notification.
Flurry will also return a callback, if the delegate is set.
Notification Clicked - Flurry will LOG notification when a user clicks on it. By default Flurry would launch the app.
Flurry will also return a callback, if the delegate is set. This would be the place to use the deep link to load the appropriate View.
In your AppDelegate class, place the following code in application:willFinishLaunchingWithOptions:
Registration & Setup
Implement the Delegate method for Received
Implement the Delegate method for Clicked
Manual integration helps you handle it all. Flurry provides a few helper methods for you to determine if a notification is from Flurry, and if so, convert the notification into a FlurryMessage. In manual integration, you must log the following events as described:
Set token - If you receive a callback that the token has been set, provide Flurry with the token via the
Notification Received - When a notification from Flurry is received log it to Flurry via
Notification Clicked - When a notification from Flurry is clicked, log this event to Flurry via the
In your AppDelegate class, implement as follows:
Setup and Registration
Set the device token
Log Notification Received & Clicked
When pushes are received or tapped, a Flurry background session occurs to allow Flurry to measure push metrics. Flurry exposes a method to allow you to determine whether such sessions are counted in the same way that foreground sessions are counted: withIncludeBackgroundSessionsInMetrics. Make sure to set withIncludeBackgroundSessionsInMetrics according to your app measurement needs.
Setting this method to YES/true:
Background sessions initiated by push notifications, as well as session data for other background sessions, will be included in overall session metrics. This will impact time spent, uniques and other metrics.
Setting this method to NO/false
Background sessions including sessions initiated by push notifications will not be included in overall session metrics. Push events such as PushOpened will be reported even if set to NO/false.
You must set to NO/false to exclude push-initiated background sessions from being counted as sessions for your app.
This is set in the Builder:
FlurrySessionBuilder* builder = [[[FlurrySessionBuilder alloc] withIncludeBackgroundSessionsInMetrics:NO];
[Flurry startSession:@”API_KEY” withOptions:launchOptions withSessionBuilder:builder];
Deep linking is the ability for an app to direct a user to a specified location in the app. When setting up a campaign, users may input a deep link.
Flurry has reserved the “deeplink” keyword in the app data payload. You may leverage the deeplink string the user enters during campaign set up via the appData property (message.appData). By setting up the proper handling of this string during integration, you will ensure that the user lands on the deep link location after tapping on the notification.
While Flurry can’t define the deep linking experience for an app, here is an example on how to use our suite to implement it.
Deep Linking Example¶
Imagine you are building an app which contains a series of news articles. Each news article is identified by a unique integer identifier. Let’s say the local sports team drafts a top prospect, and you want to send a push notification with the breaking news article. On the Flurry portal, you can create a new push campaign, set the title to “Breaking News!”, set the body to “49ers pick up top prospect”, and set the reserved “deeplink” field to “appproject://main/article?number=149”.
This is a sample deep link. You should format your deep links in accordance with your app’s deep link schema.
Now, when the FlurryMessage is received by the application, you may use appData property (message.appData) to retrieve your custom deep link string. Be sure to do your null checks, and use the deep link string retrieved to instrument the tap action.
There is another way to implement deep linking using key-value pairs. On the flurry portal, you can add a custom key value pair as: key=article and value=149. On the app side, fetch this key value pair by message.appData[@”article”]. Now the app can download the article with unique identifier “149”, and display that to the user. Code for this use case is shown in the Sample Code section.
Deep Linking Sample Code¶
If you are in auto mode, then you should choose option 2 and confirm the FlurryMessaging delegate method. If you are in manual mode, then you can choose either one option below.
Option 1: Using the AppDelegate callbacks
Option 2: Using the FlurryMessaging delegate method (Optional Delegate)