Our inspiration is the current status of the world right now!

What it does

With the COVID-19 pandemic in full force, one of the biggest obstacles to recovery is the lack of information. Our goal is to fill this gap by alerting users in real time to locations with confirmed cases, so that they can avoid them. Additionally, we display locations that may be potential spreading grounds because they have a large amount of visitors. Our method of contact tracing differs from the person to person Bluetooth app made by Google and Apple that failed because we allow users to make a conscious choice to avoid COVID-19 infected locations instead of ineffectively alerting them to potential COVID-19 contact weeks afterwards.

How I built it

This was built in two parts. The iOS app was written in Swift, and the main frameworks used were Core Location, Radar, and Firebase. The database used to store the data was Cloud Firestore, while the UI elements were from MapKit and UIKit. The Firebase queries were done in a background thread to avoid UI lag. We made GPX files on XCode to simulate location and test our app features. As for the website, the design process first started with initializing a database and login/signup authentication via Firebase. After creating the UI for the login/signup page, wiring it up to Firebase's cloud firestore allowed us to create a collection of users and update their information using CoreLocation features on the iOS app. This allowed us to project that data on the website view since the data was stored account-wide. The ML layer of kNN was designed to indicate the necessary, precautionary steps for infected/non-infected users to take for the general welfare of the public and them.

Challenges I ran into

Creating a networking, geo-locating iOS app is one thing but syncing all that data with an accountwide database required a lot of researching, understanding, and debugging. Firebase's cloud firestore was very tedious when it came to pulling data from our collection of users. When rendering the data on most graphical user interfaces, the data would become undefined and cause errors in the program. We solved this by syncing the data with the realtime database and using documents to get values.

What's next for Hotspot

Although self-reporting has its benefits such as accuracy and confirmation from users, what would be next for Hotspot are features that automatically assess the health status of our users. This can possibly be done by implementing HR (heart rate) data, sleep REM cycles, step counts, and other possible bio-metric datatypes. Ultimately, this data can better medical understanding of database while also providing more automation for Hotspot.

Share this project: