mirror of
https://github.com/meshtastic/Meshtastic-Android.git
synced 2026-09-21 11:15:18 -04:00
James RichandClaude Sonnet 5
49bd33c53e
core:ui is the first UI-layer module in this effort -- 204 Kotlin files, the substrate every feature module depends on. Every one of its own dependencies (core/*, coil3, jetbrains:markdown, qrcode-kotlin, every compose-multiplatform-*/jetbrains-* artifact) already publishes a wasmJs variant, so this was mostly a platform-seam problem, not a dependency problem: 6 commonMain files carry expect/actual declarations (an initial survey found 3; a second sweep before writing any code found 3 more), and the other 198 files needed zero changes. PlatformUtils.kt's ~23 members are mostly Android-system-settings concepts (NFC/Bluetooth/Wi-Fi/location/app settings deep-links, ahead-of-time permission-state checks, native file/document pickers) with no browser equivalent -- these mirror iOS's own NoopStubs.kt exactly, the established precedent in this codebase for "the platform doesn't have this concept, don't block the UI on it." Two exceptions get real implementations instead: rememberOpenUrl opens the URL via window.open, and KeepScreenOn is backed by the real Screen Wake Lock API (hand-declared external binding, kotlinx-browser has none) with its acquire/release lifecycle kept in one coroutine via awaitCancellation()/finally so a fast dispose can never race ahead of an in-flight request and leak the lock. createClipEntry (ClipboardUtils.kt) upgrades to ClipEntry.withPlainText -- verified against Compose Multiplatform's own wasmJs klib metadata that this is the only factory available on this target, with the actual Clipboard API access handled inside Compose Multiplatform's own setClipEntry() implementation, not something this module needs to wire itself. annotatedStringFromHtml (HtmlUtils.kt) keeps the plain-text fallback that the JVM/desktop actual already uses -- matching this codebase's own established fidelity bar for HTML rendering off Android, not a regression introduced here. dynamicColorScheme, SetScreenBrightness, and DropDownPreference's enum-reflection helpers (found in the second sweep) all get honest no-ops matching the JVM/iOS actuals already in place, each documented with why no better browser answer exists. 3 of 27 commonTest files (the ones depending on core:testing, which has no wasmJs target -- the same gap every prior module's test suite has hit) move to a new nonWebTest source set; a vestigial, actually-unused libs.junit dependency moves with them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>