Android: redesign Explore metric selector as ExposedDropdownMenuBox

[ujix]

What this PR does

Executive summary: Replaces the horizontal chip row on the Explore screen with a full ExposedDropdownMenuBox metric picker and enables tap/drag chart inspection on the hero line chart.

Details:

Explore screen

• Updated: Metric selector redesigned as an ExposedDropdownMenuBox with category headers, an accent dot per metric, a selected-item checkmark, and dividers between groups — replaces the horizontal scrolling chip row that clipped on narrow displays
• Added: selectionEnabled = true on the hero LineChart — users can tap or drag to read exact values at any point on the trend

Validation: :app:assembleFullDebug, testFullDebugUnitTest, and testDemoDebugUnitTest all green.

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation
• CI / tooling

How it was tested

Android 16. Real Samsung device. WHOOP 4.0. Tested: dropdown opens/closes, all metric groups visible with correct accent dots, checkmark tracks selection, chart drag reads correct values, screen rotation.

Checklist

• Swift package tests pass for any package I touched (swift test in Packages/<name>)
• Android unit tests pass if I touched android/ (./gradlew testFullDebugUnitTest)
• No new build warnings introduced
• UI changes use only StrandDesign tokens — no hardcoded colors, fonts, or spacing
• No hardcoded hex frame bytes; protocol facts live in the schema / decoders
• Follows the conventions in docs/CONTRIBUTING.md
• I did not commit generated output (Strand.xcodeproj/) or any secrets/keystores

Related issues

[NoopApp]

Two things here. First, a real bug: in the dropdown trigger row the if/else returns the same Icons.Filled.ArrowDropDown in both branches (~line 89), so the chevron never actually rotates between open and closed — only the tint changes. Likely a copy-paste slip.

Second, the bigger picture: this flips Explore's whole interaction model. iOS/macOS Explore is a grouped browse→detail list (NavigationLink rows in MetricExplorerView); this turns Android into an in-detail dropdown picker. Adopting it faithfully would mean redesigning the two-level navigation across platforms, which is a direction call rather than a like-for-like port.

So: not adopting as-written. If the dropdown direction gets the nod and the arrow-icon bug is fixed, we'll revisit happily. Holding open — thanks for pushing on the Explore UX. (The chart tap/drag inspection you bundled in here is good, by the way — that part already landed via the Today HR chart in #254.)

[ujix]

Thanks for the thorough review! Fixed both issues:

• Chevron bug: the trigger icon now correctly uses Icons.Filled.ArrowDropUp when expanded and Icons.Filled.ArrowDropDown when collapsed — was a copy-paste slip where both branches returned the same icon.
• The chart tap/drag note is appreciated — understood it already landed via Android: HeartRateTrendCard — interactive chart, Y/X axis labels, HH:mm fix #254.

Branch updated and force-pushed.

[NoopApp]

The arrow fix looks right (ArrowDropUp expanded / ArrowDropDown collapsed) — thanks, that clears the bug half. The remaining question is the bigger one I flagged: whether Explore should move from the grouped browse→detail list (how iOS/macOS work today) to an in-detail dropdown picker. That's a cross-platform UX-direction call for the maintainer rather than anything wrong with the code — so I'm keeping this open pending that decision, not because of the implementation. Appreciate the quick turnaround.

[ujix]

Appreciate you keeping it open and framing it clearly as a direction call — makes sense.

Here's our thinking on why the dropdown fits Android better than the horizontal browse:

Screen real estate is the core difference. On macOS/iOS, the grouped browse works well because you have wide NavigationLink rows laid out vertically — the user can see all available metrics at a glance and tap directly into the one they want. On Android's narrower portrait screens, the horizontal chip/scroll row means options are hidden off-screen by default. A user who hasn't explored yet has no way of knowing how many metrics exist or what they're called without swiping through the entire list — it's effectively a horizontal scroll trap.

Discovery is broken on small screens. With the browse model ported naively to Android, a metric like 'Respiratory Rate' sitting at position 8 in the row is invisible until the user has swiped past the first 7. The dropdown flips this: the full list is immediately visible the moment it opens, which is the same affordance a Spinner or ExposedDropdownMenuBox gives in standard Android Material Design guidance.

Precedent in Material Design. Android's own guidelines recommend ExposedDropdownMenuBox (which is exactly what this PR uses) for exactly this scenario — selecting one item from a moderately-sized list where a full-screen picker would feel heavy. The grouped browse model is a great fit for platforms where the list lives in a persistent sidebar or a navigation column; on Android portrait it becomes a horizontal carousel that fights the native UX.

A possible middle path (if it helps the cross-platform parity concern): the dropdown could be Android-only, keeping iOS/macOS on the grouped browse, since Compose Multiplatform already has the per-platform flexibility to diverge here. The data layer and chart rendering are identical — only the metric-selection UI adapts to the form factor. That way neither platform regresses.

Happy to adjust the implementation in any direction you land on.

[NoopApp]

This is a genuinely strong case, and the Android-only middle path is the part that resolves my concern: keeping iOS/macOS on the grouped browse while Android's selector adapts to the narrower form factor is exactly the kind of platform-appropriate divergence that's fine — the data and chart layers stay identical, only the picker changes. The portrait-discovery argument is fair too, and ExposedDropdownMenuBox is the idiomatic Material choice for it.

I'm inclined toward that — Android-only dropdown, other platforms unchanged. I'll keep it in the flagged-for-the-maintainer bucket since it's still a UX call, but with that recommendation attached now. Thanks for laying it out so clearly — and the arrow-icon fix already cleared the one actual bug.

[NoopApp]

Adopted ✅ — shipped in v2.9.0 as an Android-only platform-appropriate Explore picker (the arrow-icon fix was in your diff). Thanks @ujix! Closing as adopted.