Stepping up against a pandemic

When the coronavirus hit, it got our team thinking about how we could lend a helping hand in fighting the disease, how we could take a socially responsible step. Inspired by and learning from projects with similar incentives, we decided to build an app that could help us prevent infections by alerting anyone who have crossed paths with an infected person recently and helping identify hotspots to avoid, both based on infected people sharing their location history. Also, we wanted to give everyone full control over the data they share.

A team of four including our project manager was assembled at the start of quarantine to develop the project. We decided to start developing the backend and the app in parallel.

The backend

The server is a Spring application written in Kotlin which is responsible for providing REST endpoints for multiple purposes.

At the first launch of the app it uploads its install token to the server, which provides an authentication token in exchange for it. This authentication token is required for uploading infection data. Also, the install token can be used for remote push notifications, should we need them.

Another responsibility is enabling the querying and uploading of location data. Messages between the client and the server are in JSON format, and are stored in MongoDB for easy handling on the server side. Querying can be done in multiple ways, either requesting all data or specifying an area on the map to be inspected to optimize loading times and power usage of the app.

The app

The app development was started by developing an iOS module for continuous background tracking without draining the battery. This module was based on CoreLocation and was developed to be as accurate and as power efficient as possible. The periodically tracked location is stored locally using CoreData.

To fill in potential missed spots, we added the possibility of adding location data manually. It was especially important in these times when, luckily, mobile OS-es allow users for fine control of when and what their app can and cannot do. The app works even if you allow tracking when it is in the foreground, but, of course, this makes it less useful if you cannot provide the missing data manually.

Next, we needed to find a way to display available infection reports as a heatmap for our users. After much trial and error, we settled on Google Maps Platform and its utility library, which, besides working well and being free, is a platform-agnostic choice. The heatmap simply displays the last two weeks worth of anonymously shared location of everyone. The more infected people there were in a certain area, the more alarming color it gets. This lets our users determine which places to avoid, should they need to leave their homes.

To get infection data, we obviously had to allow our users to upload them. A reporting form was added to the app first with a single button, then with information about the available time frame, the possibility of selecting the diagnosis time manually and some additional inputs. The uploaded data appears on the heatmap right away.

To reduce friction, we decided to let people use the app without logging in. The app instance has an identifier provided by Firebase which is used as a pseudo credential. Upon deleting the app, it resets, protecting the identity of the user. This identifier can also be used for reaching the user from the server via push notifications, should we do any analysis on the backend.

Right now, the comparison of the user’s location history and the available infection data is done on the client side. The algorithm is scheduled to run a couple of times every day, and is also run at launch, warning the user if they have been near an infected person we know of. The algorithm compares the last two-week’s worth of tracking data, and interpolates between the recorded locations, creating a continuous track. We came to the conclusion that the detection of cases only identifiable by interpolation outweighs the problem of false positives. When the algorithm is run in the background, the results are sent to the user in the form of a local push notification.

Finishing the development, we polished some of the rough edges of the user interface by allowing to hide the heatmap, prettifying the upload form and respecting dark mode.

We started testing right from the start. We used Apple’s TestFlight service to release test versions of the app and receive reports.

Results, future

The result of our efforts is a MVP (minimum viable product) version of the app and the service, both of which work but can be further developed in various ways. Features such as automatically filtering sensitive locations, a news feed along with push notifications to provide a single place for people to get informed, an admin page for controlling such features, login possibility, instructions upon uploading a positive diagnosis, an Android version of the app, and a website with news and heatmap are possible next steps for polishing the service. Moreover, the tracking module alongside the comparison algorithm needs further testing and tweaking.

Because of strict regulations by the World Health Organisation, we could not proceed with publishing and further development yet.
Finally, another important thing to note is that this is a generalized solution – it can be used if and when other epidemics – hopefully not pandemics – occur.