Creating the Bubbl MVP

Technical implementation of a location-based network prototype

This article is a detailed technical description on how we build the Bubbl app and backend minimal viable product (MVP). A full overview of Bubbl and how we created it can be found in Bubbl – a sixth sense for chance encounters.

Early 2015 we helped kickstart the app startup Bubbl. In five weeks we turned a powerful idea into the Bubbl MVP ready to be user-tested. The aim of Bubbl is to stimulate chance encounters between friends, business relations or other people. For this we developed an app that turns people’s phone into a sixth sense for chance encounters.

Approach

As is often the case when we kickstart a product idea, Bubbl was all about designing, developing and testing the concept within a limited timeframe. Therefore all technical decisions had to facilitate our proces of ultrashort design and code iterations. In our approach to developing MVP’s this way we try to minimise the amount of components to reduce complexity. In the case of Bubbl for instance we explored an MVP setup with just apps and no need for a server or database. When selecting tools and solutions we prefer ones we are familiar with and have proven themselves for quick iterations, like Node.js. Another common aspect of our approach is that we only optimise when needed and prefer spending our time on creating new functionality. If a solution works for the selected number of test participants it is a viable solution. All in all we strive for the quickest MVP implementation that makes the concept testable on all required aspects.

Technical challenges

Because we wanted the app to function as a sixth sense it seemed important to get reliable results for detection of nearby users. And although the app is not focused on communicating exact location we wanted it to give an up-to-date feeling. Therefore the main technical challenges were:

  • Constantly check if a user it is nearby one or more other users.
  • Supply a user with up to date location information of all other users.

The iOS Core Location framework provides standard solutions for handeling location changes by a phone. The easiest solution seemed to be to send this information directly to all other phones. Something that might never really seem an option when developing an app. But, as it is the easiest solution, was the first thing we considered for this prototype. However, because high precision location updates already created the maximum acceptable battery consumption we decided to optimise the handeling of location information by outsourcing it to a server.

How the Bubbl app & backend MVP works

We used three techniques to always keep the user up-to-date:

  • Background location updates, to supply the database with up-to-date location information
  • Push notifications, to inform users when they are not using the app
  • Long polling, to inform users when they are using the app

Bubble MVP overview inline

General technical overview of the Bubbl MVP 

Background location updates
A) The app is registered for iOS background location updates. Whenever the location of a phone changes, the app is started by the system and sends the new location directly to the cloud database. The database saves the information and creates a new sequence to represent its new state.

B) The server is subscribed to the database’s changes feed, so as soon as anything changes to the database, the server receives the sequence representing the new data state, retrieves the new data.

Push notifications
C) When the server receives the new data from the cloud database (see B), the new locations are now compared. If needed (e.g. two phones are now close), the server sends a push notification request to the push notification server.
D) The push notification is displayed on the phone.

Long polling
E) When the app is started or woken up, it sends a request to the server. In this request, it includes the latest known sequence, a unique identifier that represents a state of the data in the cloud database.
F) Instead of immediately sending a response, the server compares the app’s sequence to the last one it knows about. If there is a difference, it responds with the latest data. If not, it waits with sending a response. This leaves the app waiting for new data.
The server keeps a list of all apps waiting for new data. When new data is received from the cloud database (see B), all waiting apps receive a response with the new location data.
When nothing changes to the database, the apps keep waiting for a response. To keep the apps from thinking something went wrong and giving up (i.e. getting a timeout error), when nothing changes for 30 seconds, the server sends back a response without any data, with the message ‘ping’.
G) As soon as an app receives new data, it updates its interface with this new information and restarts at step E. When a ping is received, the app also restarts at step E.