Android video search SDK: Kotlin, URI uploads and Compose
The Android video search SDK connects a Kotlin application to indexed media without supplying its own interface. Version v2.0.3 is the reference for this guide. It explains the Gradle dependency, coroutine ownership, Android content URI uploads and the image stage behind a Compose result grid. Keep the complete operation examples in the tagged repository alongside your evaluation.
Updated:
Set up the Android video search SDK with Gradle
The release build declares the Maven coordinates com.vmodal:vmodal-sdk-android and version 2.0.3. Its Kotlin toolchain targets JDK 17. Use the dependency line below in the application’s existing Gradle dependency block, with repository resolution configured for your project. Check the tagged build and example settings before changing Android Gradle Plugin or Kotlin versions across an established application.
This guide intentionally stops at the verified dependency declaration for code. A full Kotlin operation should ship only after compilation with the intended JDK and Android project configuration. The tagged starter and search examples provide the next source to read. Keeping that boundary explicit avoids a plausible-looking snippet that compiles against neither the selected SDK nor the app’s coroutine setup.
implementation("com.vmodal:vmodal-sdk-android:2.0.3")Reference: v2.0.3 build.gradle.kts, mavenPublishing coordinates and version
Own search coroutines in the application lifecycle
The SDK is UI-free: Kotlin coroutines, Compose, Views and application state remain your choices. Put a request in a lifecycle owner that can cancel it and decide whether its completion still belongs on screen. Retain the selected collection context with the request. A response arriving after a user changes collections must not be relabeled as a result for the new selection.
Begin with collection discovery and a known searchable recording. The pinned Android README describes fixed image-semantic search, so do not advertise arbitrary search-source selection just because another platform shows it. Choose the documented request contract for v2.0.3. Show loading and empty results explicitly, and preserve a source reference and time context for every candidate that the user may open.
Stream content URI uploads from Android pickers
Android media pickers often return a content:// URI rather than an ordinary filesystem path. The release describes streaming URI support and upload progress through a cold Flow, with callback UploadHandle compatibility. Use the documented URI source path rather than attempting to convert every picked item into a guessed local filename or loading an entire video into memory.
Your application must keep the selected media readable for the lifetime of the upload. Decide how work is owned when a screen closes, and consult the examples for CoroutineWorker-based tasks that need a longer lifetime. Upload completion and index readiness are separate milestones. Keep the resulting asset identity so a later indexing or search error can be investigated without starting another unnecessary transfer.
Resolve frame URLs in bulk before drawing a result grid
A search result contains information needed to locate a moment; the image displayed by a tile is a subsequent resource lookup. The example flows describe bulk image resolution after search. Keep the collection and stream coupling intact during that step, then pass the resolved image locations into the application’s image-loading layer. Avoid triggering a new network operation each time Compose recomposes a tile.
Treat image failure separately from search failure. A broken or expired image location should not erase the source identifier and timestamp already returned. Follow the pinned image API to refresh a location where appropriate. Check a result by opening its source moment and surrounding footage. A candidate image alone cannot establish that the natural-language query has been correctly satisfied.
Represent Compose states without losing request identity
A Compose screen benefits from explicit loading, empty, results and error states, with the selected scope attached to each request. Keep SDK session ownership outside transient drawing code. A stable state holder can reject late completions when a query changes and can cancel dependent frame work when a user leaves the result screen. The SDK does not impose a navigation system or a login view.
For progress display, collect the documented upload stream under the intended lifecycle and ensure the cancel action reaches the underlying operation. If work moves to a worker, make that ownership visible in the UI. Test rotation or a background transition during transfer, then return to the screen and verify that its status describes the same operation rather than starting a duplicate.
Validate Kotlin integration one stage at a time
Use the starter examples to isolate configuration, authentication, collection access, upload, index readiness, search and image rendering. A successful health request does not prove that the active identity can access a particular collection. Likewise, an accepted upload does not prove that its frames are searchable. Record the failing stage and its scope before changing unrelated network or UI settings.
A useful acceptance run includes an expected scene, an irrelevant query, cancellation and a collection switch during an active search. Confirm that source playback opens the intended time and that stale frames never attach to a new query. Keep the v2.0.3 tag in the report. Compile the actual application integration with JDK 17 before using its code as a reusable example for another Android project.