Shared Commute App
Context
This app was created during my master’s program in Telecom Engineering, as part of a mobile programming class in 2020. I used the opportunity to go beyond prototyping and build a complete, working app.
Ride connects passengers and drivers for shared commutes. A passenger can request a ride. A driver can accept it. The app manages the interaction between both sides, tracks the trip on a map, and suggests a price based on distance.
Goal
Design and build an app that:
- Allows login and signup with role selection
- Handles ride requests and status updates
- Shows live location of users
- Works across devices using Flutter
- Uses Firebase to manage authentication and database
The system had to be clear, functional, and responsive for both roles.
Users can sign up as a passenger or driver. After signup, the app redirects them to the correct panel. The signup form includes validation, role selection, and error feedback. Once submitted, user data is saved on Firebase and the app redirects based on user type.
When the app starts, it checks if the passenger already has an active request. If not, they can input a destination. A confirmation dialog checks the parsed address before sending the request. The panel shows current location and a destination input. After confirmation, the app enters waiting mode. The passenger stays updated while waiting for a driver.
The driver sees a list of ride requests with “waiting” status. After accepting a ride, the screen updates through three steps:
- Arriving: shows map with driver and passenger markers
- Riding: tracks route in real time
- Finished: sets end location and shows a suggested price
Each ride stage updates the interface using location data. Transitions are handled by functions that change state and redraw map focus. Markers and titles guide both users through the ride.
Firebase Structure
- Users: stores name, email, and role. Each user has a unique ID.
- Requests: stores ride requests with status (e.g., waiting, accepted).
- Active requests: separated by user type to simplify backend reads during rides.
Reflections
Flutter allowed me to build and test a complete mobile system with a consistent interface. I appreciated how components could be structured by state and reused across panels. Firebase made authentication and real-time updates easier to manage without writing a custom backend.
This was my first time connecting UI decisions with real product behavior. It helped me understand how to manage screens, user roles, and transitions with more precision.
What I Learned
- How to structure logic for two distinct user types
- How to manage ride state transitions with live data
- How to design with real feedback loops using location and request status
- The value of building UI flows from backend logic, not the other way around
Final Notes
Ride is a functioning MVP that simulates a core ride-sharing experience. It tracks a user’s state from login to trip completion, using live location, structured UI updates, and a clear division between user roles.
It taught me how to think about state as interaction, not just logic. And how to use a single toolkit to move from an idea to a working result.
.svg)