Case Study.

android

RoadRescue

Real-time Android roadside assistance app — connects stranded motorists with nearby verified service providers via live GPS tracking, automated matching, and secure payments.

JavaFirebaseFirestoreCloud FunctionsGoogle Maps SDKOAuth 2.0AES-256Room DatabaseRetrofitFigma

Overview

RoadRescue is a native Android roadside assistance system built as my BSIT capstone at STI College Tanauan. It connects stranded motorists with nearby verified service providers in real time, with live GPS tracking, automated provider matching, and a full payment pipeline — one tap for a flat tire, dead battery, or engine breakdown instead of a phone call into the unknown.

Problem

Traditional roadside assistance in the Philippines suffers from three systemic failures:

  • Slow dispatch — providers are called manually with no real-time coordination
  • Zero visibility — motorists have no idea where help is or when it will arrive
  • No accountability — no standardized way to verify, rate, or track service providers

Tech Stack

  • Frontend: Java, XML Layouts, Android Studio, Material Design, Figma
  • Backend: Firebase Auth, Firestore NoSQL, Firebase Realtime DB, Cloud Functions for Firebase
  • APIs: Google Maps SDK, Fused Location Provider, Retrofit, FCM (push notifications)
  • Security: AES-256 encryption (local user data), OAuth 2.0 (Google Sign-In), Android Keystore, Firebase Security Rules
  • Offline: Room Database (local cache), Firestore offline persistence, SharedPreferences

Key Features

For motorists

  • One-tap service requests — towing, flat tire repair, battery jump-start, fuel delivery, lockout
  • Real-time GPS tracking with accurate ETA via Google Maps SDK
  • Flexible payments — cash and cashless with digital receipts
  • Offline mode — cached maps and emergency contacts work without internet
  • Emergency SOS — alerts emergency contacts and local authorities with precise GPS coordinates
  • Full English and Tagalog support

For service providers

  • Real-time job alerts — receive and accept nearby requests instantly
  • Route optimization — integrated navigation to reach the client fastest
  • Reputation system — build trust through verified ratings and reviews

How It Works

  1. Request — motorist selects a service type and confirms their GPS location via Fused Location Provider
  2. Matching — a Cloud Function queries Firestore for providers with available: true, calculates distance using the Haversine formula, and dispatches an FCM push notification to the nearest one
  3. Acceptance — provider accepts the job; both parties begin live tracking via Firestore onSnapshot() listeners
  4. Tracking — motorist sees the provider moving on the map in real time with a live ETA
  5. Completion — service rendered, payment processed, both parties rate the experience

Technically Interesting

Why Firebase over a custom REST backend: RoadRescue needs bidirectional real-time updates — the nearest provider must be notified the instant a request comes in, and the motorist must see the provider's GPS position update live. Firestore's onSnapshot() listeners push data to the client the moment it changes, no polling required. Building the equivalent with a custom REST API would mean standing up WebSockets or Server-Sent Events — significant backend complexity to take on for a capstone timeline.

Why Cloud Functions for matching: the matching logic (Haversine calculation, availability check, FCM dispatch) has to run server-side so a client can't manipulate it — a motorist's app has no way to fake "no nearby providers" or spoof a match. Cloud Functions run this without managing a server: the function triggers on a Firestore write and handles the full matching flow atomically.

Why AES-256 + Android Keystore: sensitive data cached on-device (name, contact number, vehicle details) is encrypted with AES-256, with the key held in Android Keystore — tying it to the device's hardware so it can't be extracted even if the device itself is physically compromised.

Result

A fully working system with the complete motorist-to-provider flow implemented end to end — request, matching, live tracking, payment, and rating — not just a UI prototype:

  • Awarded Best in Capstone
  • 72 commits across the project lifecycle, 100% native Java (no cross-platform shortcuts)
  • Built and led by a 3-person team — I owned the full technical architecture (frontend, backend, security, offline handling) while teammates handled QA/research and UI/UX wireframing
  • Signed and released as a production-ready APK

My Role

I was lead developer, responsible for the entire technical architecture:

  • Designed the Firestore data model (users, providers, requests, ratings)
  • Built the Android frontend — all screens, navigation, Maps SDK integration, real-time listeners
  • Wrote all Cloud Functions (matching algorithm, FCM dispatch, payment confirmation)
  • Implemented AES-256 encryption, OAuth 2.0, and Firebase Security Rules
  • Configured offline persistence (Room Database + Firestore cache)
  • Signed and released the production APK

Teammates: Jemimah Sumague (QA testing and research) and Winnely Mae Espinas (project management and UI/UX wireframes in Figma).

What I'd Change

  • Add automated tests — zero test coverage currently; I'd add unit tests for the matching algorithm and integration tests for the Firebase flows
  • Migrate relational data to PostgreSQL — provider ratings, transaction history, and audit logs are inherently relational; Firestore's document model made some queries awkward
  • Split motorist and provider into separate apps — the dual-role APK saves development time but creates maintenance complexity as features grow
  • Add proper error boundaries — network failures during the matching flow need more graceful handling than the current implementation provides
View on GitHub