Inspiration

The user was always at the front and center of our focus for building this mobile app:

  • What are the pain points of the regular user?

  • Could we make something which would result in daily use by the customer and increase efficiency for them?

  • What problem can we solve immediately that has long-term implications and which the FordPass app users would appreciate?

The team wanted to focus on one simple idea that we knew from both personal experience and those of close friends and family --- waking up to an empty tank and having to rush to wherever we have to be. After extensive research of the FordPass app, the team decided to build a fuel gauge alert app where a user can set a time and "distance to empty" notification.

What it does

The Fuel Alert app uses the Ford API alongside our own data to generate notifications based on a time and distance-to-empty amount the user specifies. When the fuel level in the car is below the level the user chooses, they’ll receive a notification at the time of their choosing.

How we built it

  • Coming up with an idea simple enough to implement within 3 weeks but something that the FordPass App does not already have and its users would definitely use. We decided to spend some time actually researching the current FordPass app to take into account any gaps; here is our preliminary research link. The presentation also includes our preliminary user workflow: Connected_REM Ford Hackathon

  • We wanted to use a framework that would allow for a multi-platform deployment, initially on Android and iOS and potentially on Android Automotive OS in the future.

  • We decided to go with a tech stack that many companies are moving towards for mobile development when they want one codebase cross platform: React Native for the frontend and Google Cloud Service, which included Google Cloud Functions and Firebase as our serverless execution environment on the backend.

  • Additionally, since this was the first time anyone in the team worked with React Native, we decided to use the Expo platform and framework to streamline development, as it provides ease of testing and building.

Challenges we ran into

There was a huge learning curve to overcome while getting well versed with how to use the Google Cloud platform, what the end points would look like, how it connected to the database and using the different APIs that were available. It was a little difficult integrating some of the things that were Firebase-specific because the CLI for the realtime database is in JavaScript and TypeScript, while all the coding in the Google Cloud Functions was in Python for which we had used the Pyrebase library.

A major challenge we ran into was how to implement notifications for our app. Our initial plan was to implement push notifications from the backend, notifying the user when their distance-to-empty hit the level they set.

Cloud scheduler is a really good way to manage notifications on a specific time. However, after doing research we found out that we cannot create a scheduler for dynamic time; if you want to send notifications on dynamic time, you have to poll Firebase every minute to check if it’s time to send the notification. Running the scheduler is expensive. So, we turned to the client-side option. This was also a challenge, as the app needed to be able to make an API call at a specific time. While it is possible to directly schedule times using React Native, Expo had no libraries to do so. We considered the possibility of ejecting from Expo, but given the time constraints we decided we would try and find another workaround.

The workaround we found was using two Expo libraries: Task Manager and Background Fetch. With these, we were able to schedule a task to run once the app was backgrounded, checking for the time and making the API call if it was within five minutes. Should the fuel level be low enough, then a local notification is triggered. While this isn’t the optimum solution in the long run, we believe it’s a good workaround to demonstrate the proof of concept of the idea.

React Native was new for our team, and while we spent time taking a course before diving into our project, this online class couldn’t cover every scenario. The majority of our styling was done through Google searches for the specific styles we wanted to include, which was time-consuming as we learned about each styling element.

Due to the lack of OAuth access (which we’re entirely empathetic to - we recognize that this would have to be configured for hundreds of people!), our team spent a significant amount of time devising a reasonable method to allow the user to get the proper authorization in our app to use the Ford API. While it’s not the ideal long term solution, we ended up deciding to make a screen where the user is linked to the website, and pasting the authorization from there, which helped accomplish our basic functionality even without OAuth configured.

Accomplishments that we're proud of

  • Creating a MVP in record time, and we say “record time” because we were total newbies when it came to mobile development, React Native, and the Google Cloud Platform.

  • What propelled our team to success was our combined background experiences, in conjunction with an incredible desire to learn how to work with new technologies and build a great product.

  • Implementing a workable form of notifications despite the challenges we faced.

  • The clean and stylish look of the app.

What we learned

  • While we had some prior experience with React, we had never used React Native before. Certain aspects such as State work fairly similarly, but it was an excellent and interesting experience to become familiar with the differences in components, navigation and styling.

  • Expo - Given our time limits and lack of previous experience in mobile development, Expo proved to be an invaluable tool. With the help of Expo, we were able to get a working app up and running on both emulators/simulators, as well as physical devices quickly, which sped up testing. While there are disadvantages to Expo in terms of customizability, it was an extremely valuable tool to become familiar with and to ease our path into mobile development.

  • Using the different microservices offered by the Google Cloud platform, including Firebase and Secret Manager. While the learning curve was steep, the Google Cloud platform allowed for a serverless framework, which was appropriate in our case since our app is not backend heavy.

What's next for Connected_REM

  • As finalists and with the right resources, we would prefer to implement timed push notifications, potentially at a longer interval to account for the expense.

  • We will further build-out our user interface with additional features, including accessibility to multiple vehicles.

  • As finalists, we would like to set up OAuth for our app.

Built With

Share this project:

Updates