MimiSDK 10.0.0 Migration Guide

This document outlines the various changes required to migrate to MSDK 10.0.0 from an MSDK 9.x.x version.

What is new?

This major release contains significant improvements and simplifications the Mimi Processing API which require migration.

Required Migrations

MimiConfiguration naming changes

For clarity, some properties of the MimiConfiguration class have been renamed.

Before MSDK 10.0.0	MSDK 10.0.0
mimiPersonalizationConfiguration as MimiPersonalizationConfiguration	mimiProfilePersonalizationConfiguration as MimiProfilePersonalizationConfiguration
mimiOnboardingConfiguration as MimiOnboardingConfiguration	mimiProfileOnboardingConfiguration as MimiProfileOnboardingConfiguration

ProcessingSession activation changes

The ProcessingSession activation now requires a MimiProcessingConfiguration instance to be passed to the activate function.

MimiProcessingConfiguration is a new class that will grow to encapsulate the configuration for the ProcessingSession, but currently only contains the replacement for the presetDataSource parameter. This is explained in the Processing guide.

When migrating, you will need to create a corresponding PersonalizationModeConfiguration to define the presetDataSource.

Before MSDK 10.0.0	MSDK 10.0.0
MimiPresetParameterDataSourceConfiguration.UpDown	PersonalizationModeConfiguration.FineTuning
MimiPresetParameterDataSourceConfiguration.Default	PersonalizationModeConfiguration.SinglePreset
"Group mode" with MimiPresetParameterDataSourceConfiguration.Default	PersonalizationModeConfiguration.Group

Example

Before:

val presetDataSource = MimiCore.personalizationController(
    .createPresetParameterDataSource(MimiPresetParameterDataSourceConfiguration.UpDown(fitting)))
val session = MimiCore.processingController.activateSession(presetDataSource)

After:

val mimiProcessingConfiguration = MimiProcessingConfiguration(
    personalization = PersonalizationConfiguration(
        mode = PersonalizationModeConfiguration.FineTuning(fitting))
)
val session = MimiCore.processingController.activateSession(mimiProcessingConfiguration)

MimiProcessingParameter replaces ProcessingParameter and FetchedProcessingParameter

We have simplified the type hierarchy by encompassing all Processing Parameters under a single type: MimiProcessingParameter.

If you were previously referencing ProcessingParameter or FetchedProcessingParameter in your code, you should now use MimiProcessingParameter instead.

As a consequence, there are a few related changes to the API:

Before MSDK 10.0.0	MSDK 10.0.0
synchronize()	Now named synchronizeApplicators()
observe()	Now takes a single (ProcessingParameterState) -> Unit callback argument
fetch() from MimiFetchedProcessingParameter	Now named load() in MimiProcessingParameter

Processing Applicator apply() now requires a MimiApplicatorResult return type

The apply() function of an Applicator now requires a io.mimi.sdk.core.controller.processing.MimiApplicatorResult return type.

Previously, the apply function returned Unit, but this was confusing as it would not be clear whether the function completed successfully or not.

In addition:

• The applyTimeout argument now takes a kotlin.time.Duration for clarity.
• The function argument ordering has also been changed to allow for a trailing lambda argument.

Example

An explicit return type allows a clearer indication of the Applicator's result.

Before:

val applicator = isEnabledParam.addApplicator(
        isEnabledApplicator::canApply,
        isEnabledApplicator::apply,
        1000L
)

After:

val applicator = isEnabledParam.addApplicator(
        1.toDuration(DurationUnit.SECONDS), // as kotlin.time.Duration
        isEnabledApplicator::apply, // modify your `apply` to return a `MimiApplicatorResult`
)

Tip

If you were previously throwing an exception from your apply function, you should now return MimiApplicatorResult.Failure.

Unexpected exceptions thrown from apply will continue to be caught by the MSDK and handled as a MimiApplicatorResult.Failure.

Removal of canApply validation function for Processing Applicators

The canApply check used in the Mimi Processing value application sequence has been removed.

This was done as the canApply check was essentially redundant, as any such check could be performed in the apply function itself and having two separate functions for this was confusing.

This affects the following:

• The ProcessingParameter addApplicator function no longer takes a canApply function argument.
• The ProcessingParameterApplicatorRefusedException has been removed, as it is longer required.

Tip

If you were previously using canApply to check if a value could be applied, you should now perform this check in your apply function implementation.

However, performing such checks is not strictly necessary and can be removed. as the Mimi Processing will only ever call the apply function with valid values.

Example

You should remove the canApply argument from your all your addApplicator calls:

Before:

val applicator = isEnabledParam.addApplicator(
        { isEnabledApplicator.canApply() },
        isEnabledApplicator::apply,
        APPLY_TIMEOUT
)

After:

val applicator = isEnabledParam.addApplicator(
        APPLY_TIMEOUT, // as kotlin.time.Duration
        isEnabledApplicator::apply
)

Repeat this for the intensity and preset parameters.

Removal of ParameterDeliveryMode for MimiProcessingParameter

In previous versions, the ParameterDeliveryMode was used to control how the MimiProcessingParameter value was received and propagated to the Applicator.

This has been removed from the MimiProcessingParameter, as it was considered to be an unnecessary complication of the API, as it was largely used to deal with debouncing requests made by the Mimi Profile UI.

Instead, the behavior can now be controlled by the uiControlDebounceBehavior property of the MimiProfilePersonalizationConfiguration configuration given to the MimiCore.start() function.

Note

MimiProfilePersonalizationConfiguration was previously named MimiProfileConfiguration.

There are two possible values for uiControlDebounceBehavior:

• Debounce - This will debounce the value changes from the UI, and only apply the value after the given delay. This is the equivalent of the previous DeliveryMode.Discrete.
• None - This will apply the value immediately, without any debouncing. This is the equivalent of the previous DeliveryMode.Continuous.

For MSDK 10.0.0:

Example

For example, to debounce the UI control value changes by 1000ms, you would configure the MimiProfilePersonalizationConfiguration as follows:

val profilePersonalizationConfig = MimiProfilePersonalizationConfiguration(
    // ... other configuration
    uiControlDebounceBehavior = UiControlDebounceBehavior.Debounce(1.toDuration(DurationUnit.SECONDS))
)

Alteratively, to have no debouncing, you would configure the MimiProfilePersonalizationConfiguration as follows:

val profilePersonalizationConfig = MimiProfilePersonalizationConfiguration(
    // ... other configuration
    uiControlDebounceBehavior = UiControlDebounceBehavior.None
)

Then, when starting the MimiCore, you would pass this configuration to the MimiConfiguration:

val mimiConfiguration = MimiConfiguration(
    // ... other configuration
    mimiProfilePersonalizationConfiguration = profilePersonalizationConfig
)

MimiCore.start(
    // ... other parameters
    mimiConfiguration
)

The default behavior is to use no debouncing (None).

Note

If you have a custom UI implementation which controls the MimiProcessingParameters, then you will need to implement your own debouncing mechanism to suit your integration.

Removal of ProcessingParameter addApplicator with value overload

The ability to add an applicator to a ProcessingParameter with a value has been removed.

This was because this convenience API doesn't reflect typical usage of the Mimi Processing and did not justify its own API.

Example

To migrate existing usage, you should split it into two separate addApplicator and apply calls:

Before:

val currentApplicatorValue = false
val (applicator, result) = parameter.addApplicator(currentApplicatorValue, 
        { isEnabledApplicator.canApply() },
        isEnabledApplicator::apply,
        APPLY_TIMEOUT)

After:

val currentApplicatorValue = false
val applicator = parameter.addApplicator(APPLY_TIMEOUT, isEnabledApplicator::apply) // No longer takes a value (or canApply)
val result = applicator.apply(currentApplicatorValue)

Note

In most standard integrations, it should not be necessary to do this when adding an Applicator. The ProcessingParameter should be considered the source of truth for the value of the parameter.

PersonalizationPreset class changes

The class io.mimi.sdk.core.model.personalization.Personalization.PersonalizationPreset has been changed to more closely assign with the iOS MSDK definition.

• isValid has been removed, as preset validity is assumed within the MSDK.
• md5 has been removed. If you were previously using this to check for changes in the preset, you should now use the id property instead.

ProcessingSession property presetDataSource is now nullable.

To support future Personalization Mode configurations, the presetDataSource property of the ProcessingSession has been made nullable.

You should update your code to handle this property accordingly.

Note

Most standard integrations should not need to handle this property directly.

Removal of deprecated userAccountPortalUrl() on UserController

userAccountPortalUrl() has been removed from the UserController as it was deprecated in MSDK 9.1.0. loadUserAccountPortalUrl() should be used instead.

Also accountPortalUrl has been removed from Environment.

Before:

val url = MimiCore.userController.userAccountPortalUrl()

After:

val url = MimiCore.userController.loadUserAccountPortalUrl()

Note

In most standard integrations, doing this should not be necessary as the Mimi Profile UI manages it.