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>
Verified reachable end-to-end (health/nearby endpoints respond
correctly through the reverse proxy) and set as the preferred
API_BASE_URL for testing from a physical device on any network,
ahead of the LAN-IP and emulator-loopback fallbacks.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Log.d/i/w/e calls covering location resolution, TTS lifecycle and
errors, nearby/search network calls and their failure paths, and
screen-level state transitions. OkHttp's logging interceptor now
routes through Log (tag "OkHttp") instead of println for consistent
filtering. Enabled testOptions.unitTests.isReturnDefaultValues so
android.util.Log calls don't crash plain JVM unit tests.
Added mockk + kotlinx-coroutines-test and a GuideViewModelTest suite
covering the load-success, load-failure, and retry paths — including
a regression test for the infinite-spinner bug (isLoading must clear
and errorMessage must be set on a failed nearby-search call, not left
hanging). Verified: ./gradlew testDebugUnitTest passes (4/4).
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>
The api service already binds 0.0.0.0:8000 via docker-compose, so it's
reachable from other devices on the same network without extra config.
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>
