Message Center on iOS

Mobile App Message Center enables Marketers to persist their sent Push campaign messages, so that mobile app users can view them later in the mobile app. Mobile App Developers can fetch these messages from Responsys and display them to mobile app users.

In this topic:

The Oracle Responsys Mobile App Platform Cloud Service SDK provides an API for fetching the Message Center messages data from Responsys. You must work with the Marketing team to design and develop the user experience in your mobile app.

BEFORE YOU BEGIN:

  • Request access to the Message Center feature by contacting your Customer Success Manager or logging in to My Oracle Support and creating a service request. This feature is currently released under our Controlled Availability program.

  • Your mobile app must use the Oracle Responsys Mobile App Platform Cloud Service SDK version 6.39 (18D) or later. Oracle recommends that your mobile app always use the latest SDK.

Platform-specific topics: This topic provides Developer information common to all platforms. To view information for the platform(s) you support for your mobile app, refer to the topics for each supported platform:

Screenshot illustrating an example message center

How Message Center Works

Message Center requires implementation by the Mobile App Developers, and it must be enabled in a Push Campaign by Marketers using Responsys. Responsys and the mobile app interact at runtime to provide the messages to a known user or device. This section provides details about how Message Center is set up and how it behaves at runtime.

Development

  1. The Responsys Integrated Push customer decides to implement Message Center and submits a service request to Oracle Support.

  2. Oracle enables the customer’s Responsys account for Message Center.

  3. Mobile App Developers create the user experience in their mobile app, with input from the Marketing team.

  4. If the team requires additional custom message centers, Mobile App Developers log in to the Mobile App Developer Console and add message centers to their mobile app. You can add up to four message centers. (Responsys supports five message centers total: Primary plus four custom message centers.)

    Screenshot illustrating where to add custom Message Centers

  5. Mobile App Developers add the SDK call for fetching messages to their code, and then handle the response from Responsys. Depending on your mobile app design, you may choose to use all or some of the data that Responsys returns to the mobile app.

Campaign Design

Marketers use the Push Message Designer in Responsys to design their Push campaign, or, as of 18D, they can create a Message Center campaign. They select whether Responsys should save their Push campaign to the Message Center after the campaign launch, and they configure additional information about the message, such as the subject, message icon, message center name (if using one other than Primary), and message expiration date. Campaign messages are available to the mobile apps for a Message Center campaign, but a Push notification is not sent to mobile app users.

Runtime

  1. Marketers launch the campaign. If the Message Center message is part of a Push campaign, Responsys sends the Push notification to the audience that the Marketers define. Otherwise, the Message Center message becomes available for the next fetch from the mobile apps.

  2. If the Message Center message is part of a Push campaign, mobile app users receive the Push notification.

  3. On the first mobile app launch after installation, and at fixed intervals after that (currently every five minutes), the SDK can fetch messages from Responsys. The SDK will cache the messages on the device. Responsys returns a list of up to 20 for each Message Center defined for the app. These messages are the most recent and unexpired messages stored in the message center, for either a logged-in user or for this specific device. The messages received may vary, depending on whether the user is logged in to the app. Processing occurs in the background, and the user can continue using in the app.

  4. The mobile app user access the Message Center in the mobile app.

  5. The mobile app displays the cached messages.

    • If the mobile app user is logged in, then the mobile app has set the USER_IDENTIFIER to that user. All messages that Responsys returns are the logged-in (known) app user.

    • If the mobile app user is not logged in, then the resulting messages are those meant for this device / all logged out (unknown) users. We use the DEVICE_ID to identify such messages. For unknown or logged out users, we expect the USER_IDENTIFIER to be set to null.

  6. The mobile app user sees the messages listed in the mobile app’s Message Center.

  7. If the Message Center message is part of a Push campaign, and depending on the Push Notification Action defined by the Marketer, App Developers could build varying user experiences for mobile app users. Expected actions for each type:

    • Launch App – Display the message in the Message Center list.

    • Open URL – Display the message in the Message Center list. When the mobile app user clicks the message, the Deep link opens to the URL the marketer entered, typically a section within the mobile app.

    • Open Rich Message – Display the message in the Message Center list. When the mobile app user clicks the message, the mobile app displays the rich HTML message that was sent in the original Push notification.

App Icon Badges

App Icon Badges are supported through Message Center messaging Campaigns. Marketers can display a Badge Count on the App Icon on an end user's device to indicate the number of new Message Center messages available to the app user. Marketers can increment, specify a value, or clear the Badge Count for every message sent to the user's device. App Icon Badging with Message Center Messages can increase app user engagement rates.

Screenshot illustrating an app icon badge

Development Notes

  • Reminder - To use Message Center, a Responsys account must be enabled for Message Center.

  • Obtain the latest version of the SDK for your supported platforms. All developers working on the mobile app must use the same SDK version (current SDK recommended; minimum SDK 6.39.0 or later).

  • You must turn on Message Center in your code, using the SDK's setMessageCenterEnabled method. This applies even if you are already using SDK 6.37.0 or later OR are upgrading from an older SDK version to SDK version 6.39.0 or later. Please see the platform-specific Message Center topics for details.

  • Work with the Responsys Marketer to design the Message Center user interface for your mobile app. For example, Message Center supports Subject (Title) and Message Icon, but those may not be desired features.

  • We support five Message Centers per app, including Primary (the system default). You may add up to four additional message centers.

  • Message Center is not available during Responsys downtime, such as planned maintenance events.

  • Responsys provides the Message Center messages to the mobile app, but the SDK cannot inform Responsys about read, unread, and deleted messages.

Fetching Messages from Message Center

This section describes how the SDK obtains the messages and the data Responsys that are available to your mobile app. The platform-specific sections describe how to use the calls described in this section in mobile apps supporting iOS and Android.

Messages are pre-fetched (for all Message Centers) when the application is first launched after installation. Thereafter, messages are refreshed at fixed intervals (currently every five minutes). If the mobile app user exits the mobile app and then re-opens it, the SDK refreshes Message Center messages from Responsys only if it is due for a refresh.

Data fetched may vary as follows:

  • If the USER_IDENTIFIER is set by the mobile app, then Message Center messages are retrieved for the USER_IDENTIFIER. (USER_IDENTIFIER corresponds to the match key set in Responsys, which links the App Channel List record with a known recipient in the Profile List.)

  • Otherwise, Message Center messages are retrieved for the DEVICE_ID.

When your mobile app calls fetchMessageForMessageCenter, the SDK fetches messages from the SDK's managed local storage. Once the mobile app fetches a list of messages by calling fetchMessagesForMessageCenter, the app must maintain its own storage for the fetched messages.

Transactions with the Responsys servers are asynchronous. The SDK and Responsys process the calls in the background, and the user can continue using the app.

Using the Cached Messages

When the SDK pre-fetches the messages, Responsys returns the most recent 20 non-expired Message Center messages for each Message Center configured for the app, the user, or device:

  • If user is logged in (known), Responsys uses the USER_IDENTIFIER to obtain messages.

  • If user is not logged in (unknown), Responsys uses the DEVICE_ID to obtain messages.

Data retention policy

The duration Oracle caches Message Center messages are subject to change at anytime. Currently, messages are retained for 7 days from the fetched date, and then they are deleted. Apps should not rely on the SDK cache to act as storage for their app's Message Center messages. Apps must maintain their own storage and be developed to either retain messages for as long as messages are required or delete messages when no longer needed. Each message has a unique message ID. Apps should check a message's ID to check whether or not the app has already retrieved and stored a message.

Retrieving rich content

Your mobile app needs to fetch the rich content for the individual Rich Push message. Rich content is served only once for a message, therefore apps must store the rich content upon retrieval.

Message Properties

For each message fetched from Responsys by the SDK, the following message properties are stored in the mobile app's Message Center data store:

Property Description Type Notification action Required/Optional
id Unique message ID Text All Required
sent_ts Sent timestamp - when the campaign was launched UTC Time in ISO 8601 format All Required
subject Subject line of the message Text All Required
message Push notification text, composed by the Marketer. Text All Required
deeplink_url Deep link destination URL. Set by the Marketer. URL Encoded Open URL (Deep link) Optional
richmessage_url External content URL for Rich Push. Set by the Marketer. URL Encoded Open Rich Message (Where rich message content is provided from an external URL) Optional
richmessage_html External content URL for Rich Push. Set by the Marketer. Text Open Rich Message (Where rich message HTML content is selected from the Content Library or entered in the Push Message Designer) Optional
icon_url Message icon image URL. Set by the Marketer. URL Encoded All Optional
expiry_ts Expiration time stamp for time-sensitive messages. Set by the Marketer in the account’s time zone. UTC Time in ISO 8601 format All Optional
message_center_name Message Center name - Destination message center when an App implements multiple message centers. Defaults to Primary. Text All Required

Refer to the platform-specific sections for more information about the data returned for the mobile app SDK calls to the local Message Center data store.

Troubleshooting Message Center

As of the 18B Update and SDK version 6.37.0, the SDK handles any error messages returned when it tries to pre-fetch the Message Center messages from Responsys. Please refer to the platform-specific sections for additional troubleshooting information.

Developing Message Center on iOS

This topic describes how to develop Message Center on iOS using the Oracle Responsys Mobile App Platform Cloud Service SDK. To understand how the SDK and Responsys support Message Center functionality, see the Message Center topic.

BEFORE YOU BEGIN:

  • Request access to the Message Center feature by contacting your Customer Success Manager or logging in to My Oracle Support and creating a service request. This feature is currently released under our Controlled Availability program.

  • Obtain the latest version of the SDK for your supported platforms. All developers working on the mobile app must use the same SDK version (current SDK recommended; minimum SDK 6.39.0 or later).

  • You must turn on Message Center in your code, using the SDK's setMessageCenterEnabled method. This applies even if you are already using SDK 6.37.0 or later OR are upgrading from an older SDK version to SDK version 6.39.0 or later.

Enabling Message Center

To enable Message Center in an iOS app, use the following methods:

[PushIOManager sharedInstance]setMessageCenterEnabled:YES]

[[PushIOManager sharedInstance] isMessageCenterEnabled];

Note
  • Passing NO will remove all previously fetched messages.

Data retention policy

The duration Oracle caches Message Center messages is subject to change at anytime. Currently, messages are retained for 15 days from the fetched date, and then they are deleted. Apps should not rely on the SDK cache to act as storage for their app's Message Center messages. Apps must maintain their own storage and be developed to either retain messages for as long as messages are required, or delete messages when no longer needed. Each message has a unique message ID. Apps should check a message's ID to check whether or not the app has already retrieved and stored a message.

Fetching messages for Message Center

Messages are pre-fetched (for all Message Centers) when the application is first launched after installation. Thereafter, messages are refreshed at fixed intervals (currently every five minutes). If the mobile app user exits the mobile app, and then re-opens it, the SDK refreshes Message Center messages from Responsys only if it is due for a refresh.

The Push SDK stores retrieved messages locally, and they are served from the local storage on the device to your mobile app on demand.

  • To fetch the messages for Message Center, your application must call the fetchMessagesForMessageCenter method.
  • If no message center name provided, default/primary message center messages are fetched.
  • Messages and error (if errors occur while fetching the messages) are returned in the completion callback.
  • Messages are returned as an array of PIOMCMessage instances, which can be iterated through to get the details of each message. (To use PIOMCMessage, you must import PIOMCMessage.h.)
  • Messages are pre-fetched (for all message centers) when the application has configured the SDK successfully. Every fetchMessagesForMessageCenter call is fetching messages from SDK managed local storage. Once the mobile app fetches a list of messages by calling fetchMessagesForMessageCenter, the app must maintain its own storage for the fetched messages.

Example - Fetching messages: 

	[[PushIOManager sharedInstance] fetchMessagesForMessageCenter:@"Primary" CompletionHandler:^(NSError *error, NSArray *messages) {
						if (nil == error) {
						for (PIOMCMessage *mcMessage in messages) {
						NSLog(@"Message Subject: %@", mcMessage.subject);
						}
						}else{
						NSLog(@"Unable to fetch messages, reason: %@", error.description);
						}
		}];
PushIOManager.sharedInstance().fetchMessages(forMessageCenter: "Primary", completionHandler: {(error: Error?, messages: [Any]?) -> Void in
						if nil == error {
						//Load Messages
						let msgs = (messages as? [PIOMCMessage]) ?? []
						for msg in msgs {
						print(msg.debugDescription)
						}
						}
						else {
						print(error.debugDescription)
						}
		})

Using PIOMCMessage

To import PIOMCMessage, add the following:

#import <PushIOManager/PIOMCMessage.h>
import PushIOManager

PIOMCMessage is a model class contains the following properties of messages:

  • messageID: String value containing message's unique identifier.
  • subject: String value containing message's subject.
  • message: String value containing message.
  • iconURL: String value containing message's icon URL.
  • messageCenterName: String value containing message's message center name.
  • deeplinkURL: String value containing message's deep link URL.
  • richMessageHTML: String value containing message's rich message HTML.
  • richMessageURL: String value containing message's rich message URL.
  • sentTimestamp: NSDate value containing the message sent date and time.
  • expiryTimestamp: NSDate value containing the message expiry date and time.

Using the Error Codes

Different error types are returned to determine the different types of failures.

  • PIOErrorCodeNoNetwork: No network available while trying to fetch the messages.
  • PIOErrorCodeMaximumRetryReached: Maximum retrial tried to fetch the messages.
  • PIOErrorCodeInvalidURL: Invalid URL formed(can occur if app tries to fetch messages without SDK configured).
  • PIOErrorCodeInvalidPayload: Invalid fetch message response received from server.
  • PIOErrorCodeEmptyResponse: Empty response received while trying to fetch messages.
  • PIOHTTTPStatusCodeInvalidAppOrAccountToken: AppToken or AccountToken is invalid/not recognized by server.
  • PIOHTTTPStatusCodeMCDisabled: Given MessageCenter name is disabled in server.
  • PIOHTTTPStatusCodeMCFailure: Failed to fetch messages for provided message center name.

Example:

[[PushIOManager sharedInstance] fetchMessagesForMessageCenter:messageCenter CompletionHandler:^(NSError *error, NSArray *messages) {
						if (nil != error) {
						switch (error.code) {
						case PIOErrorCodeNoNetwork:
						NSLog(@"No network available to fetch messages Payload");
						break;
						case PIOErrorCodeMaximumRetryReached:
						NSLog(@"Maximum retrial reached to fetch messages");
						break;
						case PIOErrorCodeInvalidURL:
						NSLog(@"Invalid Message URL");
						break;
						case PIOErrorCodeInvalidPayload:
						NSLog(@"Invalid Message Payload");
						break;
						case PIOErrorCodeEmptyResponse:
						NSLog(@"Empty response received while fetching the messages");
						break;
						case PIOHTTTPStatusCodeInvalidAppOrAccountToken:
						NSLog(@"Provided AppToken or AccountToken is invalid. Error: %@", error.localizedDescription);
						break;
						case PIOHTTTPStatusCodeMCDisabled:
						NSLog(@"MessageCenter is disabled by server for provided message center name. Error: %@", error.localizedDescription);
						break;
						case PIOHTTTPStatusCodeMCFailure:
						NSLog(@"Failed to fetch messages for provided message center name. Error: %@", error.localizedDescription);
						break;
						default:
						NSLog(@"It requires investigation.");
						break;
						}
						}else{
						NSLog(@"Messages: %@", messages);
						}
		}];
PushIOManager.sharedInstance().fetchMessages(forMessageCenter: self.msgCenter, completionHandler: {(error: Error?, messages: [Any]?) -> Void in
						if nil != error{
						let code = (error! as NSError).code
						switch code{
						case PIOErrorCode.noNetwork.rawValue:
						print("No network available to fetch messages Payload.");
						case PIOErrorCode.maximumRetryReached.rawValue:
						print("Maximum retrial reached to fetch messages.");
						case PIOErrorCode.invalidURL.rawValue:
						print("Invalid Message URL.");
						case PIOErrorCode.invalidPayload.rawValue:
						print("Invalid Message Payload.")
						case PIOErrorCode.emptyResponse.rawValue:
						print("Empty response received while fetching the messages.");
						case Int(PIOHTTTPStatusCodeInvalidAppOrAccountToken):
						print("Provided AppToken or AccountToken is invalid.")
						case Int(PIOHTTTPStatusCodeMCDisabled):
						print("Messages are disabled by server for provided message center name.");
						case Int(PIOHTTTPStatusCodeMCFailure):
						print("Failed to fetch messages for provided message center name.");
						default:
						print("It requires investigation.")
						}
						}else{
						print("Messages: \(messages)")
		}

Fetching Rich Push content for the individual message

Your mobile app needs to fetch the rich content for the individual Rich Push message. Rich content is served only once for a message, therefore apps must store the rich content upon retrieval. Use fetchRichContent as follows:

Note:

  • This SDK feature is available only for PushIO SDK 6.37 or later.

  • Rich content can only be requested once for a message. Your mobile application must store the received rich content for further use.

[[PushIOManager sharedInstance] fetchRichContentForMessage:self.message.messageID CompletionHandler:^(NSError *error, NSString *messageID, NSString *content) {
						NSLog(@"MessageID: %@ RichContent: %@ Error: %@", messageID, content, error);
		}];
PushIOManager.sharedInstance().fetchRichContent(forMessage: "messageID") { (error, messageID, content) in
						print("MessageID: \(messageID) RichContent: \(content) Error: \(error)")
		}

Notification on fetching new Message Center messages.

Note: This API is available for the Oracle Responsys SDK 6.52 and later.

If desired, your mobile application can notify the list of Message Centers that are updated with new messages from Responsys.

[1.] Put an observer for notification constant PIOMessageCenterUpdateNotification

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(didUpdateMessageCenter:) name:PIOMessageCenterUpdateNotification object:nil];
NotificationCenter.default.addObserver(self, selector: #selector(self.didUpdateMessageCenter), name:NSNotification.Name.PIOMessageCenterUpdate, object: nil)

[2.] Fetch the list of Message Centers updated from notification's userinfo (key PIOMessageCenterUpdateNotification) and convert it into a string to use:

-(void)didUpdateMessageCenter:(NSNotification *)notification{
                        NSArray *messageCenters =  (NSArray *)[notification object];
						NSString *mcString =  [messageCenters componentsJoinedByString:@","];
						NSLog(@"MessageCenter Update Notification:List of MessageCenter %@", mcString);
		}
@objc func didUpdateMessageCenter(notification:Notification){
                    if let messageCenters = notification.object as? [String] {
                        let mcString = messageCenters.joined(separator: ", ")
                        print("MessageCenter Update Notification:List of MessageCenter \(mcString) ")
                    }
		}

Capturing Raw Response in Application

Note: The SDK makes the server request to fetch messages for all inboxes internally. So listening for the raw response in application may not provide business value for the application. Be careful if application needs to use the received raw response.

If desired, your mobile application can capture the raw messages (JSON) response received from Responsys:

[1.] Put an observer for notification constant PIOMCRawResponseCaptureNotification

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(printMCLog:) name:PIOMCRawResponseCaptureNotification object:nil];
NotificationCenter.default.addObserver(self, selector: #selector(self.printMCLog), name:NSNotification.Name.PIOMCRawResponseCapture, object: nil)

[2.] Fetch the message response from notification's userinfo (key PIOMCRawResponseValue) and convert it into a string to use:

-(void)printMCLog:(NSNotification *)notification{
						NSData *responseData = notification.userInfo[PIOMCRawResponseValue];
						NSString *response = [[NSString alloc] initWithData:responseData encoding:NSASCIIStringEncoding];
						NSLog(@"Inbox Response %@", response);
		}
func printMCLog(notification:Notification){
						if let data = notification.object as? Data {
						let response = String.init(data: data, encoding: String.Encoding.utf8)
						print("Inbox Response: \(response)")
						}
		}

App Icon Badges

The Responsys SDK update for 19B includes additional features to support badge count for messages in the message center. Badging is enabled by default in the SDK. It is the responsibility of the app developer to reset the app's badge count on certain actions if required by the app.

Prerequisites:

  • App developers must implement logic to clear the app's badge count before marketers can activate campaigns that alter the badge count for mobile apps. Otherwise your end users' apps will permanently display the Badge Count on the App Icon, resulting in a poor user experience for your app users.

  • Configure the maximum badge count in the Mobile App Config console. See [Configuring Message Centers]({{ base }}/dev-console/setup-mc) for more information.

The Responsys iOS SDK provides the following APIs to manage this functionality from the app.

[1] Set badge count from app

Typically the badge count is set by the server. But in certain cases, the badge count needs to be set explicitly. Use setBadgeCount API to set the badge count of app which will also sync this badge count value with the Responsys server. If an error occurs while syncing the badge count to the Responsys platform server, an error will be returned in the completion handler and the badge count will not be set.

Note: When setting the badge count, the value cannot be less than 0. The badge count value of 0 clears the badge icon for the app.

[[PushIOManager sharedInstance] setBadgeCount:2 completionHandler:^(NSError *error, NSString *response) {
						if (nil == error) {
						// Badge count set and synced successfully.
						} else {
						// Error occurred, unable to sync and set badge count
						// Handle error. If required you can set app badge count locally by calling iOS API [[UIApplication sharedApplication] setApplicationIconBadgeNumber:2]; 
						NSLog(@"Unable to set badge count, reason: %@", error.description);
						}
		}];
PushIOManager.sharedInstance().setBadgeCount(2, completionHandler: { (error, response) in
						if let error = error {
						// Error occurred, unable to sync and set badge count
						// Handle error. If required you can set app badge count locally by calling iOS API UIApplication.shared.applicationIconBadgeNumber = 2
						print(error.debugDescription)
						} else {
						// Badge count set and synced successfully.
						}
		})

[2] Reset the badge count

Use this API to reset and clear the badge count from the app icon. This API syncs the badge count value 0 with the server. If an error occurs while syncing the badge count to the Responsys platform server, an error will be returned in the completion handler and the app badge count will not be cleared.

Note: Using this API or setting the badge count to 0 will also clear the App notifications from the notification center.

[[PushIOManager sharedInstance] resetBadgeCountWithCompletionHandler:^(NSError *error, NSString *response) {
						if (nil == error) {
						// Badge count set and synced successfully.
						} else {
						// Error occurred, unable to sync and set badge count
						// Handle error. If required you can set app badge count locally by calling iOS app [[UIApplication sharedApplication] setApplicationIconBadgeNumber:0]; 
						NSLog(@"Unable to reset the badge count, reason: %@", error.description);
						}
		}];
PushIOManager.sharedInstance().resetBadgeCount(completionHandler: { (error, response) in
						if let error = error {
						// Error occurred, unable to sync and set badge count
						// Handle error. If required you can set app badge count locally by calling iOS app UIApplication.shared.applicationIconBadgeNumber = 0
						} else {
						// Badge count set and synced successfully.
						}
		})

[3] Get the badge count for the App

This API will return the current value of the app badge count.

int badgeCount = [[PushIOManager sharedInstance] getBadgeCount];
let badgeCount: Int = PushIOManager.sharedInstance().getBadgeCount()

Message Center Track Engagements

The Responsys SDK provides APIs to track "Message Display" and "Message Open" engagements for the Message Center.

  • Message Display engagements should be raised by the app when a Message Center message is displayed to the user in a short/preview format.

  • Message Open engagements should be raised by the app when the message is displayed in a full/detailed format.

This feature is available on SDK versions 6.45 or later.

[1] Tracking Message Display

When a message preview is displayed to the user (usually as part of a list), you must call trackMessageCenterDisplayEngagement: with a messageId for each message. You can call this API from UITableView or UICollectionView datasource or any other custom view. The following example uses UITableView.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
						//....
						[[PushIOManager sharedInstance] trackMessageCenterDisplayEngagement:mcMessage.messageID];
						//...
						}
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
						PushIOManager.sharedInstance()?.trackMessageCenterDisplayEngagement(mcMessage.messageID)
						//...
		}

This example uses the UITableView datasource. If you use a different view to display the messages, find the appropriate location where each item view is created, to place the API call.

Note:

  • trackMessageCenterDisplayEngagement() API call is asynchronous. So, it does not affect the performance of the View.

  • The messageId passed with trackMessageCenterDisplayEngagement is filtered for uniqueness. If this API is called multiple times with the same messageId in one session, it will not result in multiple Message Display engagements reported for that message.

  • For tracking the Message Display engagement, it is important to define a Message Center session using messageCenterViewWillAppear and messageCenterViewWillDisappear.

These methods should be called from UIViewController of your Message Center ViewController where these messages are being displayed. You should call these methods in UIViewController lifecycle (viewWillAppear, viewWillDisappear or other lifecycle methods depending on your specific use case). messageCenterViewWillDisappear is responsible to flush these events to responsys server and will end the session.

- (void)viewWillAppear:(BOOL)animated {
						[super viewWillAppear:animated];
						[[PushIOManager sharedInstance] messageCenterViewWillAppear];
						}
        
        
						- (void)viewWillDisappear:(BOOL)animated {
						[super viewWillDisappear:animated];
						[[PushIOManager sharedInstance] messageCenterViewWillDisappear];
  
						//In case you don't want to flush these events every time the view has disappeared, you can put a condition with `isMovingFromParentViewController/isBeingDismissed` to call this api only when the view controller is removed or dismissed.
		}
override func viewWillAppear(_ animated: Bool) {
						super.viewWillAppear(animated)
						PushIOManager.sharedInstance().messageCenterViewWillAppear()
						}
						override func viewWillDisappear(_ animated: Bool) {
						super.viewWillAppear(animated)
						PushIOManager.sharedInstance().messageCenterViewWillDisappear()
		}

[2] Tracking Message Opens

When a Message Center message is displayed in a detail view, you should call trackMessageCenterOpenEngagement: to record the engagement.

This API call is not bound to a session and should be called whenever the user opens a particular message.

[[PushIOManager sharedInstance] trackMessageCenterOpenEngagement:mcMessage.messageID];
PushIOManager.sharedInstance().trackMessageCenterOpenEngagement(mcMessage.messageID)