Design a Ride-Sharing App (Ola / Uber)

HTTP polling fires a request every N seconds regardless of whether the driver has moved. This wastes battery, generates unnecessary network traffic, and introduces latency equal to the poll interval. WebSocket establishes a persistent connection — the server pushes updates only when the driver's position changes. The rider gets sub-second location updates with less battery and bandwidth use. Additionally, WebSocket is bi-directional, allowing the rider to send cancel or chat messages on the same connection.

The server sends a location update every ~3 seconds. If the marker teleported to the new position, the user would see it jump. Instead, use a ValueAnimator that runs for 1 second and interpolates the marker's LatLng from the previous position to the new one — creating smooth motion. Set marker.rotation = bearing on each animation frame so the car icon points in the direction of travel. If a new update arrives before the animation completes, cancel the old animator and start a new one from the current interpolated position.

Android aggressively kills background processes to save battery. A Foreground Service keeps the app process alive by showing a persistent notification. For the driver app, this is mandatory: GPS must continue sending location to the server even when the driver switches to navigation or music apps. startForeground(notifId, notification) promotes the service, making it immune to background kill. The service must request ACCESS_BACKGROUND_LOCATION permission on Android 10+ and declare foregroundServiceType="location" in the manifest.

Use a sealed class with data per state. The ViewModel exposes a StateFlow<TripState>. The Fragment collects it and renders the correct UI for each state — no conditional spaghetti. Transitions are triggered by WebSocket events: DRIVER_FOUND moves from SEARCHING to DRIVER_FOUND. Illegal transitions (e.g., jumping from IDLE to IN_TRIP) are rejected — the state only advances via a reduce(currentState, event) function, making it predictable and testable.

The WebSocketManager's onFailure callback detects the drop. The reconnect logic uses exponential backoff with jitter: 1 s, 2 s, 4 s, ... capped at 30 s. Adding random jitter (±500 ms) prevents thundering herd if thousands of riders disconnect simultaneously. On reconnect, the server sends the current trip state and last known driver location in the first frame — the client reconciles and resumes smoothly. Meanwhile, the UI shows a "Reconnecting…" overlay and the driver marker stays at its last position, freezing rather than disappearing.

Use FusedLocationProviderClient.getCurrentLocation(Priority.PRIORITY_HIGH_ACCURACY) for a one-shot location (no continuous updates needed just for pickup). After requesting the necessary permissions (ACCESS_FINE_LOCATION), this returns the last known high-accuracy fix or acquires a fresh one. Reverse-geocode the coordinates to a human-readable address using Geocoder or the Maps Geocoding API. Show a draggable pin — moving the pin updates the address in real time via reverse-geocoding on drag end.

The booking API or a separate GET /route call returns an encoded polyline string. Decode it with PolyUtil.decode(encodedPolyline) (Maps SDK utility). Draw it with map.addPolyline(PolylineOptions().addAll(points).color(Color.BLUE).width(8f)). As the driver moves, clip completed segments: find the closest polyline point to the driver's current LatLng and remove all preceding points. Update the displayed polyline with the remaining points. This shows the remaining route getting shorter as the driver approaches.

The rider's GPS serves only two purposes: (1) detect initial pickup location (one-shot), (2) optionally track if the rider walks to a different pickup spot. For real-time tracking the driver's GPS is used, not the rider's. So: (1) After confirming the ride, stop continuous GPS updates on the rider side entirely. (2) Use PRIORITY_BALANCED_POWER_ACCURACY for the pre-booking pickup pin (network/Wi-Fi location, much cheaper than GPS). (3) Only the WS connection consumes power during the trip — OkHttp keeps it alive with periodic pings, which is far cheaper than GPS polling.

Cancel is a sensitive action — accidental taps cost money (cancellation fee after driver accepts). Implement a two-step confirmation: tap "Cancel" → bottom sheet with cancellation policy + "Confirm Cancel" button. On confirm: (1) POST /cancel {tripId, reason} via Retrofit; (2) Send a CANCEL frame on the WebSocket (faster server notification); (3) Handle the server response: if cancellation fee applies, show a confirmation dialog before committing. If offline, enqueue cancellation with WorkManager — but show the user that the cancellation is pending, not confirmed.

On launch, the app checks for an active trip: GET /trips/active. If one exists, it restores the last TripState, reconnects the WebSocket with the stored tripId (persisted in SharedPreferences or Room), and navigates directly to the TripFragment — skipping the home screen. The server sends the current state and recent driver location on WS connect, so the map and ETA resume correctly. FCM push notifications also help: if the app is killed and the trip completes, the rider receives a notification with a deep link to the receipt screen.

Rider app requires only ACCESS_FINE_LOCATION (foreground) for the pickup pin. Request it contextually when the user opens the app — not on first launch. Use the Activity Result API: registerForActivityResult(RequestPermission). If denied: show a rational explanation ("We need location to detect your pickup"), then re-request. If permanently denied: deep-link to Settings. Driver app additionally requires ACCESS_BACKGROUND_LOCATION (Android 10+), which must be requested separately and after the foreground permission. Show a clear UI explaining why background access is needed before showing the system dialog.

Use OkHttp's MockWebServer with WebSocket support. Create a fake WebSocketServer that enqueues messages. In tests: (1) Start MockWebServer; (2) Call wsManager.connect(tripId); (3) Have the server send test frames (DRIVER_FOUND, LOCATION_UPDATE); (4) Assert the events SharedFlow emitted the correct TripEvent values. For reconnect tests: close the WebSocket from the server side with a non-1000 code and assert the manager re-connects after backoff. Use TestCoroutineDispatcher to control time in backoff tests.

This is primarily a server concern, but the client should defend against it too: (1) Disable the "Book" button immediately on tap and set it to a loading state — prevent double-taps. (2) If the server returns a 409 Conflict (active trip already exists), navigate to the active trip screen rather than showing an error. (3) On app launch, always check GET /trips/active — if one exists from a previous session, restore it instead of showing the booking flow. The ViewModel holds the active tripId in a StateFlow; the repository rejects new booking attempts if tripId != null.

FusedLocationProviderClient (Google Play Services) fuses GPS, Wi-Fi, cell tower, and accelerometer data to provide the most accurate location using the least power. It shares the GPS hardware across apps — if Google Maps is already using GPS, FusedLocation can piggyback on that fix for free. It also automatically selects the best provider. Raw LocationManager requires manually choosing GPS vs Network provider, handling provider availability, and doesn't benefit from Play Services optimisations. The only case to use raw LocationManager is on devices without Play Services (e.g., Chinese OEM devices, LineageOS).

SOS requires guaranteed delivery: (1) Send a SOS frame on the existing WebSocket for immediate server notification; (2) Simultaneously call POST /sos {tripId, lat, lng} via Retrofit as a backup in case WS is down; (3) Share live location with emergency contacts via SMS using SmsManager (no permission needed for pre-saved contacts); (4) Optionally deep-link to the native dialler with the emergency number pre-filled. The SOS button should be a single large tap — no confirmation dialog. However, include a 5-second countdown with a cancel option to handle accidental taps.

Arrival detection is server-side: the server compares the driver's GPS coordinates to the pickup LatLng using a geo-fence (e.g., within 50 metres). When the driver enters the geo-fence, the server transitions the trip to DRIVER_ARRIVED and pushes a WS event. The client reacts by: (1) transitioning to the ARRIVED state; (2) showing "Your driver has arrived" notification (via NotificationManager); (3) starting a 5-minute waiting timer; (4) showing the "Start Trip" button on the driver's app. Never do geo-fence detection client-side — GPS can be spoofed.

Fare split is a social coordination problem: (1) The primary rider initiates a split request with a list of contact phone numbers and their share percentage; (2) Server sends each contact a deep link (SMS/WhatsApp) to accept the split; (3) Each accepting rider authenticates and links their payment method; (4) The primary rider sees a real-time status of who has accepted (WebSocket event or polling); (5) At trip completion, the server charges each rider's method for their share. On the client: the split screen is a separate Fragment reachable during SEARCHING or DRIVER_FOUND states. The primary rider can cancel any pending split before the trip starts.

Dead reckoning is predicting the current position from the last known position + speed + heading + elapsed time, without a new GPS fix. Between WS location frames (every 3 s), you can predict where the driver is: newLat = lat + speed * cos(bearing) * dt. This makes the marker appear to move continuously even without a new server update. It's useful for Staff+ answers but has risks: if the driver stops or turns, the prediction diverges until the next real update corrects it. A simpler approach (used in production) is the smooth interpolation with ValueAnimator over the update interval — visually equivalent without the physics.

Several layers: (1) Map tile caching: pre-cache the user's city map tiles using Google Maps' offline maps feature or Mapbox offline packs. (2) Trip data caching: once a ride is booked, cache the route polyline and driver info locally in Room — the user can still see the route even offline. (3) WS reconnect with backoff: aggressively reconnect but with jitter to avoid hammering a congested cell tower. (4) Graceful UI: show the last known driver position with a timestamp ("Last updated 30s ago") rather than hiding the map. (5) SMS fallback: show the driver's phone number so the rider can call directly if the app loses connectivity.

Location spoofing (fake GPS apps) is a real fraud vector in ride-sharing. Client-side mitigations: (1) Check Location.isFromMockProvider() (API 18) — reject locations with isMock = true; (2) On API 31+, check Location.isMock; (3) Enable SafetyNet / Play Integrity API attestation — devices running mock provider apps often fail the integrity check. Server-side (more robust): (1) Speed sanity checks — if the driver "moves" 5 km in 1 second, reject the location; (2) Cross-reference with telco cell tower location — if GPS says Mumbai but cell towers say Delhi, flag as suspicious; (3) Route adherence — if the driver deviates massively from the assigned route, alert the operations team.