Skip to content

fix(settings): stop wiping user settings on data re-extraction (DasherCore v0.2.10) - #29

Merged
willwade merged 2 commits into
mainfrom
fix/settings-wiped-on-update
Aug 30, 2026
Merged

fix(settings): stop wiping user settings on data re-extraction (DasherCore v0.2.10)#29
willwade merged 2 commits into
mainfrom
fix/settings-wiped-on-update

Conversation

@willwade

Copy link
Copy Markdown
Contributor

Summary

Fixes the Android side of the user report: "the input filter doesn't remember your choice — every time I start Dasher I have to switch to stylus mode."

Root cause

The bundled data directory was passed as both data_dir and user_dir to the engine, and DataInstaller deleteRecursively()s that directory on every DATA_VERSION bump — which accompanies every DasherCore pin bump. So every app update destroyed dasher_settings.xml: input filter, speed, alphabet, everything. This violates DasherCore's CAPI contract, which explicitly keeps the read-only data directory and the user-writable directory (settings, training deltas) distinct.

Changes

  • DataInstaller.userDir(context) — dedicated filesDir/dasher_user that re-extraction can never touch. Both engine creation sites (MainActivity, DasherImeService) now pass it as the user dir.
  • One-time migrationmigrateUserArtifacts copies dasher_settings.xml and root-level user training_*.txt files out of the old shared dir before any wipe. Context-free (pure file operations) so it's unit-testable without Robolectric.
  • TestsDataInstallerMigrationTest: migration moves settings + user training but not bundled training-subdir files; no-op cases for missing/empty state.
  • DasherCore → v0.2.10 — picks up the paragraph-newline alphabet fix (fix(alphabets): paragraph symbol outputs newline, not the pilcrow DasherCore#66), the other half of the same user-report batch ("return just shows a paragraph symbol").

Verification

  • :app:testDebugUnitTest green (3 new migration tests)
  • :app:assembleDebug green

Known follow-up (not fixed here)

The Activity and IME service each hold an engine instance against the same settings file with whole-file immediate saves — whichever saves last wins with its possibly-stale values. A stale-instance clobber window remains when both are alive simultaneously. Needs either a dasher_reload_settings CAPI or single-engine routing; tracked separately.

Type of change

  • Bug fix

Definition of Done

  • Build + unit tests green
  • Commits signed off (DCO)

…rCore v0.2.10)

User report: 'the input filter doesn't remember your choice' (Android side). The bundled data dir was passed as BOTH data_dir and user_dir to the engine, and DataInstaller.deleteRecursively()s that dir on every DATA_VERSION bump - which accompanies every DasherCore pin bump. Every app update destroyed dasher_settings.xml: input filter, speed, alphabet, everything.

Fix: dedicated filesDir/dasher_user user dir that re-extraction never touches, matching DasherCore's CAPI contract of separating read-only data from user-writable state. One-time migration copies dasher_settings.xml and root-level user training files out of the old shared dir. Context-free migration is unit-tested without Robolectric.

Also bumps DasherCore to v0.2.10, picking up the paragraph-newline alphabet fix.

Known follow-up (not fixed here): the Activity and IME service each hold an engine instance against the same settings file with whole-file immediate saves - whichever saves last wins with its possibly-stale values. Filed for a follow-up.

Signed-off-by: will wade <willwade@gmail.com>
@willwade
willwade merged commit 9005578 into main Aug 30, 2026
2 checks passed
@willwade
willwade deleted the fix/settings-wiped-on-update branch August 30, 2026 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant