Accepting the limitations of my social distancing App and fighting against feature creep
Tags: android, java, opensource, github
Published: 2020-04-11 22:12:01

# The Inspiration
After several days of observing almost nobody at my work heeding any mind to the comparatively easy protocol of social distancing, I couldn't help but think: How nice would it would be to simply have an alert, a simple beep, that would be just enough to make them at least consciously think and choose to break protocol if nothing else. For some reason it took some time to realize this could be brought to fruition in the real world in any sense but eventually I did the unthinkable and forced my computer to open Android Studio

#The Goal
Quite simply, make an app that can detect other instances of itself running on nearby devices. At a certain distance a warning tone plays, at a shorter distance (2m most likely) an alarm plays

Yes, similar apps exist but almost all rely on a stable data connection and uploading your location to a database rather than inter-device communication

#The Result

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/17eq8ym06iswsz04yns0.png)

Today the app IS functional and [available for download](https://github.com/iatenine/Social-Distancing-App) but rather than the initial vision of hyper-accurate distance measurements and 2-tiered alarm system plus an "all-clear state", its functionality has been limited to playing 2 tones:
 - Warning Tone: Alerts that you MAY be approaching or even within the 2m threshold of another device
 - All Clear Tone: A quick chirp to let you know the app is now confident the nearest active compatible device is almost certainly far enough away

Perhaps not the product initially envisioned but rather the result of accepting and designing around limitations that would've otherwise indefinitely halted production

#Limitations

###\#1: Sonar wasn't practical. Yes, really
This was legitimately the original plan: Make an inaudible tone every second, on the second and per my calculation, if another device heard a tone between .0001 - .0055 sec of a tick on a perfectly accurate clock, it must've come from another device too close

I didn't expect to get as far as I did, but in fact Audacity is perfectly capable of producing these tones and despite the fact I couldn't hear it, they could be played between the computer speakers and a USB mic recording to show a measurable difference in amplitude between room noise and the "silent" tone

Great! What an easy app to develop! Well, actually this had 2 problems:
 - Turns out both speaker and microphone manufacturers have to make sacrifices and design decisions so the amount of "sound" preserved was unreliable at best but more importantly:
 - Response times weren't instantaneous. Pick up a sound and process it .01 secs later seems totally fine but that's 100 milliseconds. Effectively usesless

This is a technique I may investigate at a future date now that a certain level of imprecision is baked into the app but at the time it was a dealbreaker, especially because of the app's second limitation:

###\#2: Short shelf-life
I'm not gonna call the Titanic unsinkable, say the War will be over by Christmas or declare social distancing apps to be of no use in 2021 but let's all hope that latter statement ages the best. Either way, every epidemic and pandemic so far has had an end date

Why does this change the design? Well, it means I have to work with the tools at hand and do some cost-benefit analysis on time invested learning a new library vs creating my own custom stuff

Luckily, Google's [Nearby Messages API](https://developers.google.com/nearby/messages/overview) was a decent fit and didn't cause TOO many headaches

The time this saved proved invaluable as it was desperately needed just to learn how to develop for Android in the first place

###\#3: GPS drift is a thing
I've spent more than enough time yelling at Google Maps to justify having an attorney on retainer just in case it becomes litigious but something that never seems to be an issue is precision. Many odometers have concurred with its assessment of my distance to any given turn. Problem is you don't drive in 2 meter increments

Having only sold half my soul by tapping into GPS data but not uploading the location to a database, the phones were still acting unpredictably: Alerts going off on opposite ends of the apartment, stopping next to each other and switching states without either one moving it was clear I needed some output on how far they THOUGHT they were

More seasoned Android devs verified there's always a drift of 5-10 meters that can even reach 1-2km at times

Realizing even Google hasn't cracked the level of precision on their phones I was trying to leverage, this truly felt like a deathblow

#Acceptances

###\#1: Nobody is coming into the jungle to save you

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hr0y7era4wh28r4ko0j1.png)

This app was my first foray into mobile development and the tendency to replace clear, ubiquitous words like "Element," "Page" and "State" with the most abstract synonyms possible like "View," "Activity" and "Context" was only one of the earliest stumbling blocks

Somehow I managed to get pinned between complications regarding permissions, notification channels, multi-threading and foreground service complications all at once in the final stretch

I'd make frequent pleas for help in Discord servers, forums, Reddit basically anywhere that would allow it and was likely to be populated by experienced Android developers. Each post was something along the lines of: "So close but so confused, please help"

Not one helpful response. In fact, most included references to documentation I'd *clearly* followed, accusations of blindly copy and pasting code and, in some cases, both(?)

But with Android being the Ikea of software documentation, the 1-4 missing pieces of information on each page were more likely to exacerbate the problem than solve it

Sometimes these garnered a little more attention by disclosing the intentions of the project but only by *guessing* as to what could be the issue and posting code snippets could I gather small albeit useful data that could later be coalesced into a greater understanding of what was wrong and how to fix it

But all the coding prowess in the world wouldn't help without a second epiphany:

###\#2: You can't change the hardware
After reeling from the blow of discovering how large the GPS drift was, I decided to ask a non-developer buddy how he would handle this riddle of creating a program that needs precision greater than its margin of error. Without hesitation he responded "increase the distance"

'It doesn't work like that, you idiot!' 

A knee-jerk reaction of a thought that even I didn't immediately recognize as directed toward myself but he was right... it *doesn't* work like that, you idiot

The hardware is what it is, the **design** needed to be changed and with just a few tweaks, the project went from hopelessly useless to production-ready