Campus Escort

Have you ever been studying late at WM and wanted a safe ride back to your dorm (or Wawa)? Then Campus Escort has you covered!

Comment 1

Inspiration

Alpha Phi Omega's (APO) Campus Escort program has been a fixture of the William & Mary community for many years, yet they still take ride requests via a landline phone. This system was slow, inefficient, and required the brothers to spend a lot of time filling out paperwork. APO approached DSC this winter for a better solution.

What it does

This cross platform App consolidates all of the Campus Escort functionality into a single, easy-to-use package. It allows students to request rides, notifies APO's drivers about those rides, allows either party to cancel at any time, and records important ride info for APO's records.

How we built it

The App is built using Google Flutter platform. With Firebase handling the Authentication and data storage.

What we worked on during the Hackathon

Google Sheets Integration

APO needs a record of all of the rides that they give. In order to streamline that process, we created a Google Sheet with an attached App Script that our flutter app was able to connect to and send ride information to that document.

Driver verification

We also used Firebase's Realtime Database to import a list of all the APO's driver's emails. Then we can read that list during the authentication process and verify that those logging into are actually authorized to drive for APO.

Automatic Logout

Since Campus Escort only operates at night, and the App considers all logged in users as active and able to give rides, it was necessary to have the program automatically log users out 6 hours after they log in. That way, drivers that forget to log out manually are not still considered active. We achieved this with a timer from Dart's async library.

Ride Rejection by Driver

If a driver decides they want to reject the ride (removing the ride request for all drivers) instead of accepting (performing the ride) or canceling (choosing not to perform the ride but allowing other drivers to view the request), they are able to do so by clicking "reject". This brings them to a pop-up asking them to verify that they would like to reject, as that is a more serious and irreversible action (it would require the rider to send a request all over again). If, upon being asked "Are you sure you want to reject? It will be removed from the list of ride requests for all drivers" the driver chooses "YES", then it will take them to another screen (passing in the Ride instance with information about the driver, rider, and ride itself) in which they leave a note via a TextFormField to send to (1) the rider and (2) to APO, explaining the rejection to both parties.

Misc

Added the rider's destination to the initial request form

Challenges we ran into

Our preferred database Firestore did not allow data to be imported from a JSON, we had to use Firebase's other database (Realtime Database) to import the list of authorized APO drivers.

Accomplishments that we're proud of

Going into the Hackathon with the core driver/rider interactions already completed.

What we learned

How to juggle data input and output to multiple 3rd party sources

What's next for Campus Escort

Next we're going to focus on push notifications and improving the UI

Built With

Share this project:

Updates