Custom In-App Templates Migration - iOS 5.0.0

With iOS version 5.0.0 we introduced several new features and improvements that caused small changes to the interfaces. We know that breaking changes are not welcomed, but supporting legacy interfaces for the custom templates would cause a lot of maintenance and stability issues.

In the next lines, we will try to cover all the necessary steps for a successful migration.

Definе action

The main changes are in the defineAction interface.
Method signature and overloads in iOS 4.1.0:

// iOS SDK 4.1.0

/**
 * @{
 * Defines new action and message types to be performed at points set up on the Leanplum dashboard.
 */
+ (void)defineAction:(NSString *)name
              ofKind:(LeanplumActionKind)kind
       withArguments:(NSArray *)args
NS_SWIFT_NAME(defineAction(name:kind:args:));

+ (void)defineAction:(NSString *)name
              ofKind:(LeanplumActionKind)kind
       withArguments:(NSArray *)args
         withOptions:(NSDictionary *)options
NS_SWIFT_NAME(defineAction(name:kind:args:options:));

+ (void)defineAction:(NSString *)name
              ofKind:(LeanplumActionKind)kind
       withArguments:(NSArray *)args
       withResponder:(nullable LeanplumActionBlock)responder
NS_SWIFT_NAME(defineAction(name:kind:args:completion:));

+ (void)defineAction:(NSString *)name
              ofKind:(LeanplumActionKind)kind
       withArguments:(NSArray *)args
         withOptions:(NSDictionary *)options
       withResponder:(nullable LeanplumActionBlock)responder
NS_SWIFT_NAME(defineAction(name:kind:args:options:completion:));
/**@}*/

Now only the following signature is available:

// iOS SDK 5.0.0

/// Defines new action and message types to be performed at points set up on the Leanplum dashboard.
+ (void)defineAction:(NSString *)name
              ofKind:(LeanplumActionKind)kind
       withArguments:(NSArray<LPActionArg *> *)args
         withOptions:(NSDictionary<NSString *, id> *)options
      presentHandler:(nullable LeanplumActionBlock)presentHandler
      dismissHandler:(nullable LeanplumActionBlock)dismissHandler
NS_SWIFT_NAME(defineAction(name:kind:args:options:present:dismiss:));

Parameter responder (withResponder, swift: completion) is renamed to presentHandler (swift: present) and a new parameter dismissHandler (swift: dismiss) is introduced.

New parameter presentHandler

It should contain the same code as the legacy responder parameter.

New parameter dismissHandler

This parameter will be called in a request to dismiss your message template.
Such occasions occur rarely, for example, when a user opens a notification that needs to present an in-app message, but your message template is already presented and it must be dismissed in order to present the notification's payload.

Action Dismissed

❗️

You must call context.actionDismissed() when your message template has been dismissed.
Check how we did it in the Confirm message implementation.

Leanplum OnAction

Leanplum.OnAction is no longer available. Use ActionManager onMessageDisplayed to execute code when a message is presented. You can get the message/action template name from the provided ActionContext parameter.

You can now also use ActionManager shouldDisplayMessage to control if a message should be presented or not.

ActionContext setActionNamedResponder

context.setActionNamedResponder is no longer available. Use ActionManager onMessageAction to execute code when an action is executed.

Message Deferral

The following methods are no longer supported:

// iOS SDK 4.1.0

/**
 * Defer message display from specified view controllers.
 * Defers all actions on those controllers unless specific action names are provided using deferMessagesWithActionNames
 * @see deferMessagesWithActionNames:
 * @param controllers The view controller classes not to display messages on
 */
+ (void)deferMessagesForViewControllers:(NSArray<Class> *)controllers
NS_SWIFT_NAME(deferMessagesForViewControllers(_:));

/**
 * Defer only specific actions
 * @param actionNames The names of the actions to defer
 */
+ (void)deferMessagesWithActionNames:(NSArray<NSString *> *)actionNames
NS_SWIFT_NAME(deferMessagesWithActionNames(_:));

You can now defer messages using ActionManager shouldDisplayMessage - decide whether to delay the message until you trigger it or delay it for a specific time.

You can use your own logic to detect which view controller is currently presented.

You can get the action name from the actionContext provided in the above handler.