Migration Guide: 0.1.x to 0.2.0-alpha¶

This guide covers migration from the handler/builder runtime model to the generated processor + typed return model introduced in 0.2.0-alpha.

What Changed¶

• DeeplinkHandler was removed.
• DeeplinkProcessor.Builder was removed.
• DeeplinkProcessorImpl was removed.
• Runtime flow is now:
• generate specs/params/processor from .deeplinks.yml,
• call generated <ModuleName>DeeplinkProcessor.match(uri),
• handle typed params in caller code.

1. Remove Builder + Handler Wiring¶

Before:

val processor = DeeplinkProcessor.Builder()
    .register(OpenSeriesDeeplinkSpecs /*, handler */)
    .build()

After:

// Generated by DeepMatch plugin
// Example for module "app": AppDeeplinkProcessor

Use the generated object directly:

val params = AppDeeplinkProcessor.match(uri)

2. Move Handling Logic to the Caller¶

Before, deeplink side effects were handler-based.
After, do caller-side branching:

when (val params = AppDeeplinkProcessor.match(uri) as? AppDeeplinkParams) {
    is OpenSeriesDeeplinkParams -> {
        // navigate to series
    }
    is OpenProfileDeeplinkParams -> {
        // navigate to profile
    }
    null -> {
        // no deeplink match
    }
}

3. Use Generated Sealed Params for Exhaustive Branching¶

The plugin generates a sealed interface named from your module:

• module app -> AppDeeplinkParams
• module feature-media -> FeatureMediaDeeplinkParams

All generated params classes implement this interface, enabling exhaustive when checks.

4. Testing Updates¶

• Remove tests focused on builder registration and handler dispatch.
• Add assertions around match(uri) return values and typed params extraction.
• Use a fake processor that stubs match via a configure { ... } lambda when needed.

5. Optional: Validate with Sample App¶

See samples/android-app/README.md for:

• composite-build local plugin resolution,
• generated manifest validation,
• real deeplink smoke tests via adb.