Add on-device transcription history, and an opt-in clipboard fallback - #173
Open
js-commit wants to merge 1 commit into
Open
Add on-device transcription history, and an opt-in clipboard fallback#173js-commit wants to merge 1 commit into
js-commit wants to merge 1 commit into
Conversation
The ACTION_RECOGNIZE_SPEECH contract has no way to report that a keyboard dropped the result: when an insert is lost, the transcription is destroyed with no error anywhere and the user simply redictates. Both additions here exist to give that failure a floor. Transcription history (on by default, no popups): the last 20 transcriptions are kept on-device as JSON in the existing DataStore, newest first, with a settings screen to read them, tap one to copy, or clear the lot. Written under NonCancellable because sendResult may finish the activity immediately after, which would otherwise cancel the write. Nothing leaves the device and nothing is shown during dictation - this is the silent option. Clipboard fallback (OFF by default): copies each final result so it can be pasted by hand. Deliberately opt-in rather than on: Android 13+ shows an unsuppressable system clipboard popup on every write, which is intrusive once per dictation, and it also overwrites whatever the user last copied. Both caveats are stated in the setting's subtitle. It runs before sendResult, since after that the app may no longer be foreground and setPrimaryClip is silently ignored on Android 10+. Clipboard failures are swallowed so they can never take down the far more important result delivery. The two are independent; either can be dropped without touching the other.
|
Please sign our contributor license agreement at https://cla.futo.tech |
|
Please sign our contributor license agreement at https://cla.futo.tech |
|
Please sign our contributor license agreement at https://cla.futo.tech |
1 similar comment
|
Please sign our contributor license agreement at https://cla.futo.tech |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You said in #170:
Fair, and I'm not going to pretend either is a fix — #171 is where the actual bug lives. Re-raising because I think the framing there was wrong rather than the idea, and the two halves deserve separate verdicts. Close it if the answer is still no; no hard feelings.
The argument
ACTION_RECOGNIZE_SPEECHhas no failure channel. When a keyboard drops the result, the transcription is destroyed — no error, no signal, nothing this app can even detect. The user just redictates and hopes. That's true regardless of whose bug caused the drop, and it stays true after #171 for any keyboard nobody has traced yet.This isn't proposed as a substitute for fixing delivery. It's a floor under the case where delivery fails anyway.
What changed since #170
Last time I led with the clipboard, on by default. That was the wrong call — Android 13+ shows an unsuppressable system popup on every clipboard write, which is genuinely intrusive once per dictation, and it stomps whatever the user last copied. So:
Transcription history — on by default, completely silent. Last 20 transcriptions kept on-device as JSON in the existing DataStore, with a settings screen to read them, tap to copy, or clear. No popups, no UI during dictation, nothing leaves the device. Written under
NonCancellablebecausesendResultmay finish the activity immediately after, which would otherwise cancel the write.Clipboard fallback — off by default, opt-in. Both caveats above are stated plainly in the setting's subtitle so nobody enables it by accident. Runs before
sendResult, since after that the app may not be foreground andsetPrimaryClipis silently ignored on Android 10+. Failures are swallowed so a clipboard problem can never take down result delivery.If only one of these is palatable, it's the history — it's the silent one, and it's the one that actually recovers a lost dictation without side effects. The clipboard half can be dropped from this branch without touching the rest.
Notes
assemblePlayStoreDebug). Adds one settings screen and two setting keys; no changes to the recognition or delivery paths beyond two calls inRecognizerView.finished().CLA: signing is on me, will sort before you spend review time.