There is a fine line between controlling and safety—many location-sharing apps tend to cross that line. Our app, NestNotifications, provides an alternative that allows for independence among adolescents and more privacy for all users.
Our app takes any given address and a specified travel time frame given by the user, then it also constantly monitors the user's location. Once the user is outside of the specified travel distance from the address (the “nest”), a text message is sent which notifies any contact number given by the user. Our intent was for users to input their home address and notify friends and family when they are far from home for safety. However, given the generalized parameters accepted by our implementation, this app lends itself to anyone who wishes to specify a location they would like to stay near. We have also considered privacy: our user’s location is unknown to the connected contact until they are outside of the ring, which separates us from other location-sharing apps.
Our mobile app runs on a Flask backend and Flutter frontend. While Flutter would let us code logic and make API calls itself (and it doesn’t need a proxy for CORS since it is a mobile app), we still decided to abstract away most of the processing into Flask. For one, we did this because most of the team was more comfortable with Python… Secondly, by having most of the calculations on Flask, our system design allows the dynamic use of our API in other applications. Along with Inrix APIs—specifically the Drive Time Polygons service which gave us the ability to construct a 2D area—we used the Google Maps Flutter support API to visualize our location with respect to the area. Furthermore, in the backend, we used geospatial analysis algorithms from the Shapely library to detect point inclusivity in the objects generated by the Inrix API, which would be difficult to code ourselves especially given the timeframe and the non-uniformly shaped convex/concave features. If the calculation finds that the user is outside the zone, a Twilio API call is used to message the specified contact.
During the beginning phase of the project, we had difficulties communicating our workflow together and deciding what implementations were most important to work on to get our product off the ground. Eventually, we were able to streamline our process by making coordinated git commits and abstracting away each of our independent focuses. Toward the end of the project, we had difficulties combining the frontend and the backend. We were able to overcome this obstacle when we considered the underlying Internet of Things logic given the multi-platform nature of our product—specifically, the differing local hosts on our computers and phones had to be aligned in order to communicate between the backend and frontend.
Along with the large-scale challenges listed above, we often got stuck on minor obstacles along the way to creating our vision. However, we are proud that we were able to learn new packages and solutions to accomplish our goals. Overall, we are happy that we stayed committed to finishing our project even when the solutions were not clear.
It was the entire team's first hackathon, so it was a great learning experience for group dynamics in coding. Specifically, we learned version control, turning Flask into a RESTful API for our teammates to use, JSON parsing, and the ins-and-outs that come with accessing real-world API’s including call limits and expiring tokens.
Given more time, we would like to implement the Inrix routing API to give the users themselves the best way to travel back after a notification is sent and send the route to contacts. A curfew setting where the polygon next is only applicable for a certain time of day was also in planning, but could not be accomplished given our 24 hours. Similarly, we would like a feature that deactivates the tracking when near the contact anyway. It would also be effective if the app could continue to track the user for the contact if they leave the area, then message if they return back to the nest. Additionally, given the same proximity calculating features, it may be possible to create a location-based smart reminders app to keep users further responsible.