mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-05 19:28:25 +00:00
Claude
a33942f2a2
Wave 1 of building the Android app for JVM/desktop: a screen cannot move to
commonsUI while its labels come from amethyst/src/main/res.
Compose resources has no blocking, Context-free accessor - outside composition
getString() is suspend - so the 458 `stringRes(context, R.string.x)` call sites
had to be converted before any key could move. Deferring them was not an option:
only 167 of 1,912 keys are used exclusively at composable call sites, and a key
can only live in one resource system.
No runBlocking bridge, per maintainer decision. By scope:
264 @Composable -> drop the context argument
46 already inside launch { } -> loadStringRes(id)
~80 plain fn, caller in a coroutine -> the function becomes suspend
~68 plain fn, no coroutine in reach -> label hoisted into composition
The notification stack (NotificationCategory, NotificationUtils, CallNotifier,
the four notifiers, RelayPurposeSummary, ConversationShortcuts) went suspend as
one component; its public entry points already were. That rippled into
NotificationChannels.Entry and the notification settings screen, which now
drives them from repeatOnLifecycle + produceState. FlowProgressForegroundService
.render is suspend, so are the POW-mining and Blossom-sync services.
ScheduledPostNotifier went suspend on both implementations (its only driver is
CoroutineWorker.doWork, and ScheduledPostPublisher's callbacks were already
suspend, so desktop is unaffected). PowDuration needed a @Composable pair and a
suspend pair - it is read from three screens and from the mining service.
TimeAgoFormatter became @Composable and lost its context parameter entirely.
Catalog: 1,906 keys moved, 67,275 elements across 57 locale dirs.
amethyst/res 2,051 -> 143 keys; commonsUI 3,016 -> 4,926. Four keys referenced
from AndroidManifest/res-xml (app_name, save, rename, block_hide_user) are
copied rather than moved; two that already existed in commons had their app-side
duplicates dropped. Nine keys using bare %d/%s were made positional across 480
elements - positional form is valid for Android too, so behaviour is unchanged.
tools/strings-migrate/migrate.py: the %% literal was read as a bare conversion
(the second % of `%1$d%% of all` started a fresh match and the space flag let
`% o` look like one), and a bulk @keyfile mode replaces ~110k per-key file
rewrites with one pass per file. Verified byte-identical to the old path on a
40-key sample across all 57 locale dirs.
StringResourceCache.kt keeps only painterRes - drawables are still Android
resources. The R.string overloads and the LruCache behind them are gone with the
last R.string reference; compose-resources caches each locale file itself.
Verified:
- zero R.string / R.plurals references left in Kotlin
- all 6,883 Res.string/Res.plurals references resolve to real catalog keys,
no string-vs-plurals kind mismatches
- .claude/hooks/orphan_strings_check.py passes; all 58 XML files parse
- a per-key per-file reference guard confirms no key was lost (it caught a
real bug: a Context-detector that matched any two-argument call ate the key
in `stringRes(Res.string.x, arg)`, 344 references - the detector now uses an
allowlist of expressions that are genuinely a Context)
NOT verified - this has never compiled. The container's shared egress IP is
rate-limited by Maven Central (~50% of requests answer 429) and Gradle disables
a repository on the first failure, so :amethyst:compileFdroidDebugKotlin could
not be driven to completion. Still needing a compiler: the scope classifications
(a stringRes(id) inside a non-composable lambda and a loadStringRes(id) outside
a coroutine are both compile errors), the 98 Int -> StringResource retypings,
and unused imports/vals left by the hoisting. Next: compile-fix loop,
spotlessApply, then lintFdroidBenchmark for ExtraTranslation.
Rationale and the per-file decisions are in
commons/plans/2026-09-22-strings-to-compose-resources.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AXvKXakvup4inNFfAhhr4L
strings-migrate
Moves string keys from the Android app's res/ into commons Compose
resources (commonsUI/src/commonMain/composeResources) across all
locales in one shot, preserving each element byte-for-byte so Crowdin
sees a pure move. Both trees are Crowdin-managed with the same android
layout (see crowdin.yml), so a migrated key keeps its translations.
tools/strings-migrate/migrate.py copy_to_clipboard relay_info
After migrating, repoint the code: R.string.key becomes Res.string.key
(com.vitorpamplona.amethyst.commons.resources), and the composable keeps
calling stringRes(...) via the commons bridge
(com.vitorpamplona.amethyst.commons.ui.stringRes).
The tool refuses keys whose value uses bare %s/%d: compose-resources
only formats positional %1$s args. Rewrite those keys (code and every
locale) first.