feat(settings): add custom SMS scan start date

[saadaltabari]

Summary

Adds a Custom date option to Settings → SMS Scan Period so users can scan SMS messages from a chosen start date through today. Scan logic, backup/restore, and the transactions limited-data banner were updated to respect the custom range, with unit tests for the new behavior.

Type of change

• feat: New feature
• test: Add/update tests

How to test

1. Open Settings → SMS Scan Period and select Custom date.
2. Pick a start date in the past and confirm the setting shows “Scan from <date> to today”.
3. Trigger an SMS scan and verify transactions are imported from the selected date onward (including today).
4. Export and restore a backup; confirm sms_scan_use_custom_date and sms_scan_custom_date are preserved.
5. Run ./gradlew :app:testStandardDebugUnitTest --tests "com.pennywiseai.tracker.data.manager.SmsScanParamsCalculatorTest" --tests "com.pennywiseai.tracker.data.backup.BackupModelsTest".

Breaking changes

• No breaking changes

Checklist

• Focused PR (single purpose)
• Tests added/updated
• Targeted unit tests pass locally
• Follows existing code style and patterns

Made with Cursor

[greptile-apps]

Greptile Summary

This PR adds a "Custom date" option to the SMS Scan Period setting, letting users scan from a chosen start date through today. The scan logic, backup/restore, and the limited-data banner in the transactions screen are all updated to respect the new mode, with a new SmsScanParamsCalculator object centralising the scan-window computation.

• SmsScanParamsCalculator (new file) extracts and formalises all scan-start-time logic — including full-scan detection for mode transitions — and is covered by a comprehensive unit test suite.
• Backup/restore correctly round-trips the two new preference keys (sms_scan_use_custom_date, sms_scan_custom_date) with safe backward-compatible defaults.
• TransactionsViewModel.getSmsScanStartDate() returns null when smsScanUseCustomDate = true but smsScanCustomDate = null, causing isShowingLimitedData() to silently return false; this is reachable during the brief window between the two separate DataStore writes in SettingsViewModel.updateSmsScanCustomDate.

Confidence Score: 4/5

Safe to merge after addressing the banner logic in TransactionsViewModel; no data loss or scan correctness issues were found.

The core scan logic in SmsScanParamsCalculator is well-factored and thoroughly tested. The main concern is in TransactionsViewModel: getSmsScanStartDate() returns null when the custom-date flag is set but the date value hasn't been written yet, which silently suppresses the limited-data banner. The scan worker itself handles the null gracefully via a fallback, so no transactions are missed; the issue is purely in the banner display.

TransactionsViewModel.kt (getSmsScanStartDate null-return path) and SettingsViewModel.kt (non-atomic DataStore writes in updateSmsScanCustomDate)

Important Files Changed

Filename	Overview
app/src/main/java/com/pennywiseai/tracker/data/manager/SmsScanParamsCalculator.kt	New file extracting scan-param logic into a testable pure object; handles all three scan modes (months, all-time, custom date) correctly with proper full-scan trigger detection.
app/src/main/java/com/pennywiseai/tracker/presentation/transactions/TransactionsViewModel.kt	Adds custom-date StateFlows and updates isShowingLimitedData(); getSmsScanStartDate() returns null when smsScanUseCustomDate=true but smsScanCustomDate=null, incorrectly suppressing the limited-data banner.
app/src/main/java/com/pennywiseai/tracker/ui/screens/settings/SettingsViewModel.kt	Adds updateSmsScanCustomDate() with correct full-scan heuristic; three non-atomic DataStore writes create a brief inconsistent state window between useCustomDate=true and the actual date being written.
app/src/main/java/com/pennywiseai/tracker/ui/screens/settings/SettingsScreen.kt	Adds custom-date option with DatePickerDialog and updated subtitle/trailing text; the when(months) click logic is duplicated verbatim in both Row.clickable and RadioButton.onClick.
app/src/main/java/com/pennywiseai/tracker/worker/OptimizedSmsReaderWorker.kt	computeScanParams refactored to delegate to SmsScanParamsCalculator; resolveLastScanPeriod now handles the custom-date sentinel correctly.
app/src/main/java/com/pennywiseai/tracker/data/backup/BackupExporter.kt	Correctly adds smsScanUseCustomDate and smsScanCustomDate to the exported preferences snapshot using existing suspend-function pattern.
app/src/main/java/com/pennywiseai/tracker/data/backup/BackupImporter.kt	Restores smsScanUseCustomDate unconditionally and smsScanCustomDate via ?.let — leaves DataStore key absent when backup date is null, contributing to the null-date edge case.
app/src/test/java/com/pennywiseai/tracker/data/manager/SmsScanParamsCalculatorTest.kt	Good deterministic test suite covering all mode transitions and the normalizePickerDateToLocalStartOfDay conversion.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    actor User
    participant SettingsScreen
    participant SettingsViewModel
    participant UserPrefsRepo
    participant DataStore
    participant Worker as OptimizedSmsReaderWorker
    participant Calculator as SmsScanParamsCalculator

    User->>SettingsScreen: Select "Custom date"
    SettingsScreen->>SettingsScreen: "showSmsScanDatePicker = true"
    User->>SettingsScreen: "Pick date & confirm"
    SettingsScreen->>SettingsViewModel: updateSmsScanCustomDate(millis)
    SettingsViewModel->>Calculator: normalizePickerDateToLocalStartOfDay(millis)
    Calculator-->>SettingsViewModel: localMidnightMillis
    SettingsViewModel->>UserPrefsRepo: setLastScanTimestamp(0L)
    SettingsViewModel->>UserPrefsRepo: updateSmsScanAllTime(false)
    SettingsViewModel->>UserPrefsRepo: updateSmsScanUseCustomDate(true)
    Note over UserPrefsRepo,DataStore: DataStore emits — useCustomDate=true but date=null window
    SettingsViewModel->>UserPrefsRepo: updateSmsScanCustomDate(localMidnightMillis)
    UserPrefsRepo->>DataStore: all three keys written sequentially
    Worker->>UserPrefsRepo: getSmsScanUseCustomDate()
    Worker->>UserPrefsRepo: getSmsScanCustomDate()
    Worker->>Calculator: compute(SmsScanParamsInput(...))
    Calculator-->>Worker: "SmsScanParams(scanStartTime, needsFullScan=true)"
    Worker->>UserPrefsRepo: setLastScanPeriod(SCAN_PERIOD_CUSTOM_DATE)

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    actor User
    participant SettingsScreen
    participant SettingsViewModel
    participant UserPrefsRepo
    participant DataStore
    participant Worker as OptimizedSmsReaderWorker
    participant Calculator as SmsScanParamsCalculator

    User->>SettingsScreen: Select "Custom date"
    SettingsScreen->>SettingsScreen: "showSmsScanDatePicker = true"
    User->>SettingsScreen: "Pick date & confirm"
    SettingsScreen->>SettingsViewModel: updateSmsScanCustomDate(millis)
    SettingsViewModel->>Calculator: normalizePickerDateToLocalStartOfDay(millis)
    Calculator-->>SettingsViewModel: localMidnightMillis
    SettingsViewModel->>UserPrefsRepo: setLastScanTimestamp(0L)
    SettingsViewModel->>UserPrefsRepo: updateSmsScanAllTime(false)
    SettingsViewModel->>UserPrefsRepo: updateSmsScanUseCustomDate(true)
    Note over UserPrefsRepo,DataStore: DataStore emits — useCustomDate=true but date=null window
    SettingsViewModel->>UserPrefsRepo: updateSmsScanCustomDate(localMidnightMillis)
    UserPrefsRepo->>DataStore: all three keys written sequentially
    Worker->>UserPrefsRepo: getSmsScanUseCustomDate()
    Worker->>UserPrefsRepo: getSmsScanCustomDate()
    Worker->>Calculator: compute(SmsScanParamsInput(...))
    Calculator-->>Worker: "SmsScanParams(scanStartTime, needsFullScan=true)"
    Worker->>UserPrefsRepo: setLastScanPeriod(SCAN_PERIOD_CUSTOM_DATE)

Loading

Comments Outside Diff (1)

1. app/src/main/java/com/pennywiseai/tracker/ui/screens/settings/SettingsScreen.kt, line 395-451 (link)

   Duplicate click-handler blocks risk silent divergence

   The when (months) branching logic is copy-pasted verbatim into both the Row.clickable modifier and the RadioButton.onClick lambda. If one branch is updated in the future (e.g., a new scan mode is added), the other copy is easy to miss and will silently produce different behavior depending on where the user taps (text area vs. the radio button itself). Extracting a local lambda or a small helper function would eliminate the duplication.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "feat(settings): add custom SMS scan star..." | Re-trigger Greptile}

[greptile-apps]

Banner incorrectly hidden when custom-date state is partially written

getSmsScanStartDate() returns null when smsScanUseCustomDate.value = true but smsScanCustomDate.value = null, which causes isShowingLimitedData() to return false and suppress the limited-data banner. This state is reachable in two ways: (1) the two separate DataStore writes in SettingsViewModel.updateSmsScanCustomDate — after updateSmsScanUseCustomDate(true) completes but before updateSmsScanCustomDate(normalizedDate) is written, DataStore emits the update and the active StateFlow flips smsScanUseCustomDate to true while smsScanCustomDate is still null; (2) a backup restored with smsScanUseCustomDate = true but a missing smsScanCustomDate field (the ?.let { } skip in BackupImporter leaves the DataStore key absent).

Consider returning a sensible default scan start (e.g., falling back to the month-based date) instead of null when the custom date has not been written yet.

[greptile-apps]

Three non-atomic DataStore writes can expose inconsistent intermediate state

updateSmsScanCustomDate issues updateSmsScanAllTime(false), updateSmsScanUseCustomDate(true), and updateSmsScanCustomDate(normalizedDate) as three separate sequential suspend calls. Each write causes DataStore to emit to any active collectors immediately. If OptimizedSmsReaderWorker starts between writes 2 and 3, it sees smsScanUseCustomDate = true but smsScanCustomDate = null; scanPeriodStartTime then silently falls back to the month-based boundary instead of the user-chosen date, producing a subtly wrong scan range without any error signal. Grouping all three mutations into a single DataStore.edit { } block would make the transition atomic.

[sarim2000]

Thanks! SmsScanParamsCalculator is well-factored. One issue: TransactionsViewModel.getSmsScanStartDate() returns null when smsScanUseCustomDate = true but smsScanCustomDate is still null` (reachable in the window between the two separate DataStore writes), which silently suppresses the limited-data banner. The scan worker handles the null gracefully so no transactions are missed — it's purely the banner. Please guard that case.

[sarim2000]

Thanks @saadaltabari — the scan-start-date logic is well-factored and nicely tested (Greptile 4/5). It flagged one display-only issue: getSmsScanStartDate() returns null when the custom-date flag is set but the date hasn't been written yet, which suppresses the limited-data banner (the worker handles the null fine, so no transactions are missed). Also a non-atomic DataStore write in updateSmsScanCustomDate worth tightening.

It's behind main with conflicts now — could you rebase when you get a chance? That'll refresh the Greptile review too.

Soft housekeeping note: if it's quiet for ~another week we may close it just for tidiness — not a rejection, reopen/ping anytime. 🙏