Getting a working mobile-SDK key from 2GIS turned out to require a
sales-mediated B2B process (Platform Manager subscription, demo keys
explicitly excluded from mobile SDK use per their own docs), not a
quick self-serve signup. Swapped to osmdroid instead: free, no API
key or account, works immediately.
CityMapView (replacing DgisMapView/DgisSdkProvider) wraps osmdroid's
View-based MapView via AndroidView, forwarding lifecycle events, with
markers for the user's location and each nearby place. Configured
required OSM tile-usage-policy user agent + app-private tile cache in
GuideCityApp. Removed the now-unused DGIS_API_KEY plumbing and the
arm64-only ABI filter (osmdroid has no heavy native libs, so it's not
needed) — APK is back down to ~19.6MB from ~69MB.
Verified: testDebugUnitTest passes, assembleDebug produces a working
APK, sent via the Telegram bot (previously blocked by its 50MB limit
with the 2GIS build).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Added the actual ru.dgis.sdk:sdk-map + compose-map dependencies (from
https://artifactory.2gis.dev/sdk-maven-release) instead of the Canvas
placeholder guess. Verified the exact API surface by downloading the
AARs directly and inspecting classes with javap (DGis.initialize,
MapOptions, MapComposableState/MapComposable, CameraPosition/GeoPoint)
rather than relying on possibly-stale docs.
DgisSdkProvider lazily calls DGis.initialize() once per process,
catching failure so a missing key doesn't crash the app; DgisMapView
renders the real MapComposable when that succeeds, falling back to
the old placeholder canvas otherwise.
Important finding: the existing DGIS_API_KEY (2GIS's public REST/JS
API key format) does NOT work with this native SDK. It requires a
separate dgissdk.key file issued per-app-package from dev.2gis.com,
placed in app/src/main/assets/ (gitignored). Documented in README.
Without it the app still runs fine on the placeholder map.
Also restricted ndk.abiFilters to arm64-v8a — the SDK's native libs
otherwise balloon the APK from ~19MB to ~190MB.
Verified: testDebugUnitTest passes, assembleDebug produces a working
(arm64-only, ~69MB) APK. Not runtime-verified against a real map key
or device — no emulator/device available in this environment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
