On average when you call 911, it takes them 90 seconds just to get your basic information, before they even dispatch the police.
The goal is to provide a mobile “Blue Light Callbox”, essentially a safety button. If you have your thumb held down on the app and it comes off, you have 20 seconds to “disarm” the phone, otherwise the call center is notified. If you do not respond to their call with your disarm code, the police will be dispatched.
The first app ran into “trolling” issues, since it did not require phone number verification. Teenagers were signing up as their friends with their friends’ phone numbers and then activate a distress alert which would result in the friend getting a call from the Police making sure they were OK.
Our solution to this on Android was easy: extract the phone number. iOS does not allow this. So our solution was to require users to verify their phone number by sending a verification code via SMS that we extract on our server to verify it is valid. We developed an app in Twilio to achieve this workflow.
There is a centralized call center for all Organizations. Some Universities would rather their University Police be directly in-charge of the incoming distress alerts, so there is a “Self-Service” portal, in which campus police monitor for any distress alerts happening on campus.
The portal uses socket.io for real-time reactive data.
Utilizing Parse’s APIs, we allow for authorities to send out a Push Notifications to all users of the app or all users within a geofenced location.
Using all the data collected, we are able to provide in-depth analytics on high-use place and times and predict when and where people might feel unsafe. We are then able to analyze this data for local police, allowing them to increase staffing in high-risk areas (e.g. certain bars at 2am). Not only is location data important in this aspect, but time correlation is just as important too.
What good is having a lightning fast back-end if the app developers need to look at the source code while they develop? How can you easily stay in sync when API changes are made? Documentation is King.
The lowest common denominator for all APIs is the documentation; that’s where everything begins. Often it starts as a simple draft of what you’re about to build, later evolving with development to the interface developers will use to implement the API. The documentation becomes the most exposed part of the work. It even serves to help the non-developers on the project to understand the app’s internal workings.