Data Layer low complexity mobile
0
Dependencies
1
Dependents
0
Entities
0
Integrations

Description

A local-storage repository that persists partial transcription results incrementally during a dictation session so that a crash or interruption does not cause the user to lose dictated content. Stores partials keyed by field ID and activity draft ID, and exposes recovery APIs so the UI can restore in-progress text after an unexpected app restart.

Feature: Speech-to-Text Input

partial-transcription-repository

Summaries

The Partial Transcription Repository eliminates the risk of users losing dictated report content due to app crashes, phone calls, or accidental backgrounding — a failure mode that would directly undermine trust among visually impaired volunteers who rely on voice input as their primary method of completing activity reports. Losing dictated content mid-session is a high-frustration event that can cause volunteers to abandon the reporting workflow entirely, resulting in incomplete records for the organization. By automatically persisting transcription progress in the background, this component makes the dictation experience feel reliable and professional, which is essential for sustaining volunteer engagement and ensuring the organization receives accurate activity data from every session.

Low complexity with no external dependencies, this component is straightforward to build and test in isolation. The key implementation detail to validate early is the choice of local storage backend — encrypted shared preferences or SQLite — which affects both security review and test setup. Testing must cover crash-recovery scenarios (simulate process kill mid-dictation and verify restore on relaunch), TTL expiry (confirm stale records are pruned), and the commit-and-clear flow (verify no data leaks after successful submission). The `activity_draft` data model dependency means this component's integration tests must be coordinated with whatever team owns draft lifecycle.

Budget for one extra day to write reliable crash-simulation tests on both iOS and Android, as these behave differently.

Partial Transcription Repository is a local persistence layer keyed on a composite `(draftId, fieldId)` tuple, mapping to the latest partial text string. The storage backend should be an encrypted key-value store (e.g., `flutter_secure_storage` or a dedicated SQLite table) to protect sensitive dictated content at rest. `savePartial()` is called on every emission from the speech engine — it must be synchronous-safe and non-blocking to avoid interrupting the audio pipeline. `getPartial()` is called at app resume to hydrate the UI field.

`commitAndClear()` is called after the final transcription result is accepted by the user and written to the `activity_draft` model. `pruneExpired(Duration ttl)` should run at app startup, not inline, to avoid blocking cold-start. Consider a write-debounce of ~200ms on `savePartial()` to reduce I/O pressure during fast partial emissions without meaningful data-loss risk.

Responsibilities

  • Persist each partial transcription emission to local storage immediately
  • Retrieve the last persisted partial for a given field and draft combination
  • Clear persisted partials once the final transcription has been committed to the report
  • Expire and clean up stale partial records older than a configurable TTL

Interfaces

savePartial(String draftId, String fieldId, String text)
getPartial(String draftId, String fieldId)
commitAndClear(String draftId, String fieldId)
clearAll(String draftId)
pruneExpired(Duration ttl)

Relationships

Dependents (1)

Components that depend on this component

API Contract

View full contract →
REST /api/v1/partial-transcriptions 7 endpoints
GET /api/v1/partial-transcriptions
GET /api/v1/partial-transcriptions/:id
POST /api/v1/partial-transcriptions
PUT /api/v1/partial-transcriptions/:id
DELETE /api/v1/partial-transcriptions/:id
POST /api/v1/partial-transcriptions/commit
+1 more