KmpPdfLauncher

Android implementation of the imperative launcher. Each open(...) builds an Intent targeting KmpPdfViewerHostActivity, stuffs the payload into either a primitive extra (URI / small byte arrays) or a KmpPdfLauncherRegistry token, serialises the KmpPdfLaunchOptions bundle into Intent extras alongside it, and starts the activity using the application context the library captured at startup via ViewerContextInitializer.

FLAG_ACTIVITY_NEW_TASK is set unconditionally — the captured context is the application context, not an activity, so a fresh task is the only legal launch mode. Apps that want the viewer to sit in their existing task should use the KmpPdfViewer composable inside their own navigation graph instead.

Imperative counterpart of KmpPdfViewer.

Use this when you need to open the viewer from outside a @Composable scope — a click handler, a LaunchedEffect, a suspend function, a notification tap, etc. The launcher hosts KmpPdfViewer inside a platform-native shell:

• Android — opens a translucent full-screen Activity shipped by the library. The activity inherits your application theme and finishes itself when the user taps back.

• iOS — presents a UIViewController (full-screen modal) built around ComposeUIViewController. Dismisses on back tap.

The launcher reads the host's process-global context (set up by the library's :pdfkmp-viewer:internal:ViewerContextInitializer App Startup provider on Android, or the key window's root view controller on iOS), so callers don't have to thread an Activity or UIViewController reference through their domain code:

Button(onClick = {
    scope.launch {
        val pdf = pdfAsync { … }
        KmpPdfLauncher.open(pdf, title = "Invoice")
    }
})

Every overload accepts the same configuration knobs that KmpPdfViewer does — visibility toggles, zoom and gesture switches, the iOS-only backLabel string next to the chevron, and the numeric renderDensity / maxZoom. Compose-typed parameters (background colour, padding, page spacing) are intentionally not exposed here; reach for the KmpPdfViewer composable when you need that level of theming control.

When to prefer the composable KmpPdfViewer — when you're already inside a Compose-based navigation graph (NavHost / Voyager / Decompose). The composable form integrates with the host's back stack and theming directly, no Intent / presentViewController ceremony.

The per-function parameter docs on the individual open(...) overloads spell out the meaning of each flag — they mirror the companion options on KmpPdfViewer one-to-one.

iOS implementation of the imperative launcher.

Each open(...) builds a ComposeUIViewController around KmpPdfViewer, walks the topmost presented view-controller from the current key window, and fires presentViewController(animated: true) against it. The hosted view-controller dismisses itself when the user taps back (onBack calls dismissViewControllerAnimated:).

Payload routing mirrors the Android launcher: URI strings travel by value (resolved to a PdfSource.auto), raw bytes wrap to PdfSource.Bytes, and PdfDocuments wrap to PdfSource.of so captured text runs / hyperlinks survive the Compose-controller boundary intact.

JVM / Desktop implementation of the imperative launcher.

Where Android opens an Activity and iOS presents a UIViewController, Desktop opens a Swing JFrame hosting a Compose ComposePanel. A panel (rather than application { Window { … } }) is used deliberately: it can be shown imperatively from any call site without owning the process event loop, so a single click handler can open the viewer the same way it does on mobile. The window disposes itself when the user taps back or closes it.

Payload routing mirrors the other platforms: URI strings resolve through PdfSource.auto, raw bytes wrap to PdfSource.Bytes, and PdfDocuments wrap to PdfSource.of so captured text runs and hyperlinks survive.