Three UX fixes:
1. The placeholder map was always rendered with userLocation=null and
places=emptyList() — MapScreen never passed the actually-resolved
location/nearby list to DgisMapView, so it only ever showed the
"waiting for location" placeholder text. MapViewModel now exposes
resolvedLocation and nearbyPlaces, wired through to the map. (Note:
this is still the Canvas-based placeholder, not the real 2GIS SDK —
that integration is still pending, as flagged since the skeleton
was first built.)
2. GuideScreen's Tinder-style pager only showed one card at a time,
which read as "it only found one place" even with 5 nearby. Swapped
it for a plain scrollable list (auto-scrolls to the active/narrating
item); tapping an item opens PlaceDetailScreen, which now owns the
swipe-between-places interaction instead. PlaceDetailViewModel
fetches the same nearby-ordered list GuideViewModel uses (falling
back to a single non-swipeable place when opened from
Favorites/search for something outside that list).
3. Narration now leads with the place's name and distance from the
user before the body text (util/Narration.kt), in both the guide
list and the detail swipe view.
Verified: testDebugUnitTest passes, assembleDebug produces a working
APK, sent to Telegram.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
After resolving location, the map screen now checks how many places
are nearby (same server-side iterative radius expansion the guide
screen uses) and shows "Found N places within Rm" with a Start button,
instead of jumping straight into narration. The search cap is raised
to 10km (was 5km) — if nothing turns up within that, a "nothing found"
message is shown instead.
This also addresses a UX report: the guide screen's Tinder-style card
stack only shows one card at a time by design, which read as "it only
found one place" even when 5 were actually there. Added a "1 / 5"
position indicator to the card stack so it's clear there's more to
swipe through, and the new summary screen surfaces the real count
upfront regardless.
Verified: ./gradlew testDebugUnitTest passes, :app:assembleDebug
produces a working APK, sent to Telegram.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two bugs combined to cause this: (1) Android blocks plain-HTTP traffic
by default since API 28, so every call to our HTTP-only local backend
was throwing and being silently swallowed; (2) GuideViewModel's
loadNearby() returned early on that exception without ever setting
isLoading = false, so the spinner never cleared and no error showed.
Fix: debug-only manifest override (src/debug/AndroidManifest.xml)
enables cleartext traffic for local dev against the Docker backend;
GuideViewModel now always resolves isLoading and surfaces a
errorMessage + retry() the UI can act on instead of hanging forever.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Full app scaffold wired to the backend: onboarding, content-length
picker, map screen (permission flow + text-search fallback), guide
screen with a swipeable place-card stack driven by on-device TTS
narration and a 60s re-scan loop, place detail screen with
mute/favorite controls, favorites (Room-backed), and settings.
Hilt for DI, Retrofit+kotlinx.serialization for the API client,
DataStore for onboarding/content-length prefs, FusedLocationProviderClient
for location. The 2GIS MapKit integration is isolated behind
map/DgisMapView.kt (currently a placeholder) since its exact Maven
coordinates need confirming from the 2GIS developer portal.
Verified by actually building it: installed a minimal Android SDK
(platform 34 + build-tools, no emulator) and JDK 17 locally, then ran
:app:compileDebugKotlin, :app:assembleDebug (produced a real debug
APK), and :app:lintDebug (0 errors, 44 non-blocking warnings, mostly
"newer dependency version available"). Caught and fixed two real bugs
this way: a wrong Maven artifact for the Retrofit kotlinx.serialization
converter, and missing ExperimentalMaterial3Api opt-in.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
