BroadcastSos

I have lost folks to road accidents. Report shouts more than 400 deaths a day in India. Most of these deaths could be averted if quick action is taken. Good thing is that it is quite possible.

Comment

Inspiration

There is a personal reason for me to work on this project. I have lost a few friends and family members to road accidents. Indian government report shows that number of deaths caused due to road accident alone is more than 150K per year (https://ncrb.gov.in/sites/default/files/Chapter-1A-Traffic-Accidents_2019.pdf). This is more than 400 deaths a day. Experts and doctors opine that most of these deaths could be averted if quick action is taken. And the good thing is that with today's technology, it is quite possible.

The project is about developing an SOS system. The ‘SOS system’ is a system aimed at delivering SOS via every routes possible using every technology that is possible and present as of today. The system would be intelligent enough to take care of sending SOS whenever the end user is in distress.

The scope of the system is huge as I’ll need to make it as inclusive as possible, available for a range of technological landscapes, handling significant amount of corner-cases. So, to begin with, I have defined the scope for this project to be limited to Android users. The MVP would be a very light-weight Android app capable of detecting distress and sending out SOS on twitter through a number of ways. Of course, this thrives on Twitter API v2.

What it does

It is an app which sends SOS whenever it detects a major physical crash.

SOS is sent in the following ways:

  1. broadcasted in the form of tweet
  2. twitter DMs to a list of selected people (let’s call this list as ‘emergency list’)

Of course, following could be configured by the user:

  1. if they want to have the SOS broadcasted as tweet or not,
  2. if they want twitter DMs to be sent to the emergency list
  3. who should be included in the emergency list

The content of the tweet and/or the DMs are configurable as well:

  1. the text message
  2. whether to send current location or not.

In case of every crash, the user gets a notification if they want to rollback the tweet and the sent DMs. If it happens to be a false crash (e.g. the phone just dropped on the floor), the user could just un-tweet by clicking on the notification. The time to initiate rollback is also configurable by the user.

How I built it

The app is developed using Android SDK.

OAuth

The app uses PIN based 3-legged authorization. I chose this approach because I did not want to maintain a separate backend server. However, for development beyond the MVP, I feel I cannot escape this limit. OAuth is needed because the app will be calling write-type APIs of Twitter (e.g. posting tweet, sending DMs etc.) on behalf of the user.

Background service

The app needs to detect the distress signal every moment; even when the app itself is killed. The way to do this is to spawn a background service when the app is launched and it should not get killed even when the parent process gets killed.

Twitter API

I used 6 Twitter APIs (5 were v2):

  1. sendTweet:
    1. v2 (POST /2/tweets)
    2. To send tweets.
    3. It is used to send SOS tweets.
  2. deleteTweet:
    1. v2 (DELETE /2/tweets/${tweetId})
    2. To delete tweets.
    3. It is used to un-tweet in case of false crashes.
  3. getBroadcastSosTweets:
    1. v2 (GET /2/tweets/search/recent?query=from%3A${userId}%20has%3Ahashtags%20%22BroadcastSOS%22&sort_order=recency)
    2. To get all tweets that were sent for SOS purpose.
    3. It is used to detect which is the SOS tweet that needs to be deleted in case of false crashes.
  4. getFollowers:
    1. v2 (GET /2/users/${userId}/followers)
    2. To get the user’s followers.
    3. It is used to suggest the user who all to add in the emergency list.
  5. sendDM:
    1. v1.1 (POST /1.1/direct_messages/events/new.json)
    2. To send DM.
    3. It is used to send DMs to the people in the emergency list.
  6. getMe:
    1. v2 (GET /2/users/${userId}?user.fields=name,profile_image_url,username)
    2. To get the user’s profile.
    3. It is used for basic UI for the app.

UI

The app has a basic 2-fragment UI:

  1. Dashboard fragment
  2. Settings fragment

Challenges I ran into

Spawning a never-dying background process was a bit tricky; Android doesn’t really provide a simple way.

Accomplishments that I’m proud of

I was able to build a working prototype in a matter of few days (could check my commit history: started on 9 Jul 2022 and last commit was on 14 Jul 2022). I started testing the prototype with my friends and it worked as expected.

What I learned

I learned about Twitter API and that they are really powerful when it comes to building utility solution on top of them; just like this project.

What's next for BroadcastSos

As mentioned in the beginning, I see this as an SOS system and is not limited to only Twitter and Android. I intend to expand it by supporting more platforms and using development support from other IM and social media platforms.

Built With

Share this project:

Updates