With Android SDK version 6.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 necessary steps for a successful migration.

Definition of custom templates

There are two ways to define a custom template in your application:

1. Using Leanplum.defineAction method
2. Implementing MessageTemplate interface and calling MessageTemplates.registerTemplate

Migration of Leanplum.defineAction method

Lets compare 5.10.4 and 6.0.0 version of the method:

// Method signature in SDK 5.10.4

public static void defineAction(
  String name,
  int kind,
  ActionArgs args,
  ActionCallback responder
)


// Method signature in SDK 6.0.0

public static void defineAction(
  String name,
  int kind,
  ActionArgs args,
  ActionCallback presentHandler,
  ActionCallback dismissHandler
)

Parameter responder is renamed to presentHandler and a new parameter dismissHandler is introduced.

New parameter presentHandler

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

New parameter dismissHandler

This callback parameter will be called in a request to dismiss your message template.
Such occasions occur when user clicks on a notification that needs to present in-app message, but your message template is already presented and it must be dismissed in order to present the notification's payload. Another case is when activities are being switched by using deep links and your message template must be dismissed to avoid object leaks and to keep consistent application behaviour.

❗️

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

Migration of MessateTemplate implementations

Lets compare 5.10.4 and 6.0.0 version of the MessageTemplate interface:

// MessageTemplate interface in 5.10.4

interface MessageTemplate {
  String getName();
  ActionArgs createActionArgs(Context context);
  void handleAction(ActionContext context);
  boolean waitFilesAndVariables();
}


// MessageTemplate interface in 6.0.0

interface MessageTemplate {
  String getName();
  ActionArgs createActionArgs(Context context);
  boolean present(ActionContext context);
  boolean dismiss(ActionContext context);
}

Method handleAction is renamed to present and a return type is changed from void to boolean.
Method waitFilesAndVariables is removed and not necessary any more, you can delete your implementation.
New method dismiss is introduced.

New method present

It should contain the same code as the legacy method handleAction, but you should return value of true when message is presented successfully and false otherwise.

New method dismiss

This method will be called in a request to dismiss your message template.
Such occasions occur when user clicks on a notification that needs to present in-app message, but your message template is already presented and it must be dismissed in order to present the notification's payload. Another case is when activities are being switched by using deep links and your message template must be dismissed to avoid object leaks and to keep consistent application behaviour.

❗️

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

Migration of Leanplum.onAction

Leanplum.OnAction is no longer available. Use MessageDisplayListener.onMessageDisplayed(check IAM Handlers) 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 MessageDisplayController.shouldDisplayMessage to control if a message should be presented or not.

Migration of ActionContext.setActionNamedHandler

ActionContext.setActionNamedHandler is no longer available. Use MessageDisplayListener.onActionExecuted(check IAM Handlers) to execute code when an action is executed.

Migration of deferMessagesForActivities

LeanplumActivityHelper.deferMessagesForActivities is no longer available. You can now defer messages using MessageDisplayController.shouldDisplayMessage(check IAM Handlers) - 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 activity is currently presented.

You can get the action name from the ActionContext provided in the above callback.