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
presentHandler
It should contain the same code as the legacy responder
parameter.
New parameter dismissHandler
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.