Skip to main content

Set Up Firebase Collections for the Taxi App

The Taxi app needs Firestore data for car categories, riders, drivers, trip requests, ride status updates, and driver availability. Configure this data before testing real rider and driver flows.

Quick Answer​

Enable Firebase Auth and Firestore, replace the app's Firebase config files, create the taxi_car_categories collection, create at least one driver user, add required driver fields, deploy rules/indexes/functions if included, then request a ride from the rider app and accept it from the driver app.

Required Firebase Services​

The Taxi app commonly uses:

ServicePurpose
Firebase AuthRider and driver accounts.
Cloud FirestoreUsers, car categories, ride requests, trip status, driver state.
Firebase FunctionsOptional trip dispatch, push notifications, and backend workflows.
Firebase Cloud MessagingRider and driver notifications, if enabled.
Maps/location providerAddress search, map display, route and location features.

Start with:

Car Categories​

Create a Firestore collection for the ride categories shown to riders.

Common collection name:

taxi_car_categories

Example document:

{
  id: 'standard',
  title: 'Standard',
  description: 'Affordable everyday rides',
  photo: 'https://example.com/standard-car.png',
  baseFare: 5,
  pricePerKm: 1.5,
  order: 1
}

Exact fields can vary by package version. Search the app source before changing collection names or field names:

rg "taxi_car_categories|carCategories|car category|trips" src firebase

If you rename the collection, update every source, rule, index, and backend reference that uses the old name.

Driver Users​

Drivers are authenticated users with additional fields in Firestore.

  1. Create a driver account from the driver app.
  2. Open Firebase Console > Firestore Database.
  3. Find the driver document in the users collection.
  4. Add the driver fields expected by your package.

Example:

{
  role: 'driver',
  inProgressOrderID: null,
  carNumber: '7WFXAS',
  carName: 'Tesla Model 3',
  carPictureURL: 'https://example.com/car.png',
  active: true
}

Some packages also require current location, heading, availability, or rating fields. Search the source for required values:

rg "role.*driver|carNumber|carName|inProgressOrderID|active|driverLocation" src firebase

For dispatch testing, create at least one rider, one available driver, one car category, and the location fields expected by the trip request flow. If your app package includes seed data, import only the data required for the flow you are testing and review it before production use.

Trip Request Verification​

After car categories and driver users exist:

  1. sign in as a rider;
  2. allow location permissions;
  3. choose pickup and destination;
  4. select a car category;
  5. request a ride;
  6. sign in as the driver;
  7. accept the ride;
  8. update trip status;
  9. confirm rider app receives status updates.

Use real devices for final testing because maps, location permissions, and push notifications behave differently on simulators.

Security and Cost Notes​

Before production:

  • limit reads to required rider/driver documents;
  • restrict driver updates to assigned rides;
  • prevent riders from writing driver-only status fields;
  • add query limits to nearby driver lookups;
  • monitor Firestore reads from location screens;
  • keep maps API keys restricted by platform and bundle/package id.

Troubleshooting​

ProblemFix
Rider cannot see car categoriesCheck taxi_car_categories, field names, Firestore rules, and app config.
Driver still sees rider UIVerify the driver's role field and sign out/in again.
Ride request never reaches driverCheck driver availability, location data, Functions logs, and push tokens.
Map does not loadCheck maps API key, platform restrictions, billing, and native configuration.
Location is staleCheck permissions, simulator location settings, and background/location behavior.

Next Steps​