Code quality: split oversized Android files to improve security and performance reviewability

[tigercraft4]

Summary

Several Android Kotlin files are very large and mix UI, BLE, analytics orchestration, persistence, and state-management concerns. This makes targeted security/performance review harder and increases regression risk.

Evidence

Approximate file sizes from wc -l:

• android/app/src/main/java/com/noop/ui/TodayScreen.kt: 6,826 lines.
• android/app/src/main/java/com/noop/ble/WhoopBleClient.kt: 6,516 lines.
• android/app/src/main/java/com/noop/ui/SleepScreen.kt: 4,234 lines.
• android/app/src/main/java/com/noop/ui/SettingsScreen.kt: 3,110 lines.
• android/app/src/main/java/com/noop/ui/HealthScreen.kt: 2,656 lines.
• android/app/src/main/java/com/noop/ui/AppViewModel.kt: 2,444 lines.

Risk

Large files hide ownership boundaries and make it easier for security, privacy, lifecycle, and performance bugs to slip through review. They also make future audits expensive because unrelated behaviors are interleaved.

Suggested fix

• Split large UI files into feature-scoped composables and pure presenter/state helpers.
• Split BLE client responsibilities into connection lifecycle, protocol/offload, persistence, Health Connect writeback, and diagnostics modules.
• Move pure logic into testable package-level helpers with focused tests.
• Add complexity or file-size guidance to contribution docs if this repo wants to prevent the pattern from growing.

Audit context

Found during a static code-quality/performance audit. This is a maintainability risk, not a single behavioral bug.

[ryanbr]

Agreed this is worth doing, and the tree is actually well-positioned for it: most of these files already have a large body of pure, package-level, already-tested helpers sitting next to the UI — so a lot of the win is mechanical extraction with zero behavior change, not a rewrite. Here's a concrete, incremental plan with the seams mapped.

Guiding principles

• One file, one concern, one PR. No mega-PR. Each extraction is independently compile- and test-verifiable.
• Two phases per screen, safest first:
  • Phase 1 — pure logic → sibling files. The internal fun helpers and sealed/data classes are already module-visible and pinned by existing tests, so moving them to a new file in the same package needs no visibility change, no test change, no behavior change. Proven by compileFullDebugKotlin + the named tests below. This is essentially risk-free and should go first everywhere.
  • Phase 2 — composable clusters → feature files. Move cohesive groups of private @Composable into feature-scoped files, flipping private → internal. Slightly more review surface (watch recomposition scopes / remembered state that some helpers close over), still no hardware and still compile-verified.
• Pure-Kotlin reorg only — no iOS twin needed. This is file organization, not a change to any analytics formula, stored value, or wire format, so the Swift/Kotlin parity contract is untouched.
• android.yml is disabled, so each PR is validated locally with ./gradlew compileFullDebugKotlin testFullDebugUnitTest and the relevant --tests filter.

Recommended order (risk ascending)

1. TodayScreen.kt (6,844 → target ~2.5k across files)

Mapped seams:

• Phase 1 (logic, ~600–800 lines out):
  • TodayDayNav.kt — launchDayOffset, dayNav{Older,Newer,CanGoNewer,SwipeTarget} — pinned by DayNavTest, TodayLaunchLandTest, LandTargetDayStartTest.
  • TodayScoring.kt — recoveryCalibrationNights, recoveryChargeDrivers, chargeConfidenceTier, lastScoredRecoveryDay, isCarryStale, freshRestScore, carriedCaption, ScoreState/scoreStateForToday, RecordingState/recordingStateFor, restStageLowConfidence, buildingHint — pinned by RecoveryCalibrationTest, TodayExplainabilityTest, TodayChargeTapCollapseTest, TodayResolverEffortScaleTest.
  • TodayProvenance.kt — dayOwnerSource, provenance*, heroSourceLabel, scoreHeroSourceLabel, todayPullToSyncEnabled, provenanceLabelTint, syncedFromSummary, readinessWord.
  • TodayMetricsLogic.kt — hrWindowKeeps, lastWorkoutsFeed, latestWeightKg, stepsForDay, weightTile — pinned by HrWindowTest, LastWorkoutsFeedTest, TodayMetricTilesTest, StepsReadingsMergeTest.
• Phase 2 (UI clusters): TodayHero.kt (ScoreHeroRow, HeroRingColumn, HeroScoreVessel, SynthesisHeroCard, hero rows), TodayYourCards.kt (YourCardsSection, DashboardCardRow, dashboard-card helpers + editor dialog), TodayReorder.kt (TodaySectionDragState, TodayReorderableSection, TodayLayoutEditorDialog), TodayDrivers.kt (ChargeBreakdownSheet, RecoveryDriversSection, ContributorBar), TodayHrChart.kt (HeartRateTrendCard, OverviewHRChart, axis/marker helpers), TodayMetricGrid.kt (MetricGrid, LiquidKeyTile, HR-window pills). The TodayScreen composable itself stays as the thin assembler.

2. SleepScreen.kt (4,266) & HealthScreen.kt (2,656)

Same two-phase pattern. Sleep has rich logic coverage already (SleepStageSegmentsTest, StageDisplaySmoothingTest, StageTimelineIntervalsTest, MainSleepSpanTest, SleepEditRescoreTest) → Phase 1 pulls the stage/segment/onset math into SleepStageLogic.kt etc.; Phase 2 splits hypnogram, stage timeline, and the sleep-edit sheet into feature files. Health mirrors this with VitalRangeGatingTest / VitalReadingsTableTest / HrvSnapshotHelpersTest pinning the logic.

3. SettingsScreen.kt (3,121)

Different shape — only ~8 composables, so it's a few enormous section composables, not many small ones. Split is pure UI decomposition: one file per settings section (Profile, Devices, Data/Backup, Experimental, About/Diagnostics). Little pure logic to extract; SettingsDisclosurePrefsTest / MoreSectionPrefsTest guard the prefs helpers that do exist.

4. AppViewModel.kt (2,457) — different kind of split

Not UI: 19 suspend orchestration functions over shared mutable state. Rather than moving code to sibling files, extract feature-scoped collaborators the VM owns (e.g. SyncOrchestrator, DaySelectionController, LiveSessionController, JournalController), each with a focused responsibility and its own tests. Higher care than a UI move (shared state, lifecycle), but no hardware — do it after the screens, in small vertical slices.

5. WhoopBleClient.kt (6,516) — last, and cautiously

The ble/ test suite (40+ files) shows most pure BLE logic is already extracted into helpers; the residual 6.5k lines is largely the live-connection orchestration, which per CLAUDE.md cannot be CI- or Linux-tested and must be validated on a real strap. So this is the highest-risk file despite good unit coverage. Approach: only peel off the clearly-separable, non-connection pieces first (frame/offload decode assembly, diagnostics/log formatting, Health Connect write-back) into modules with their existing tests; leave the connection lifecycle state machine intact until someone can bench it on hardware. No connection-path split lands without an on-strap sync + reconnect check.

Docs

Rather than a hard CI line-count cap (it would fail loudly on the entire existing tree and add noise), I'd add a soft note to docs/CONTRIBUTING.md: prefer feature-scoped composables and pull pure logic into testable package-level helpers; new files should aim to stay well under ~800 lines. Guidance, not a gate.

Net

Phase-1 logic extraction across the four UI/VM files is the safe, high-value opening move — several hundred lines out of each, fully proven by the tests that already exist, zero behavior change. Happy to start there one PR at a time whenever we want to pick it up.