August 27, 2017

Google Summer of Code: Wrapping Up

Photograph of the app I developed running on a smartphone, with the bluetooth beacons it uses around it

Today marks the end of the coding period of Google Summer of Code 2017. As part of this program, I have worked with the Physical Web team to design and build a Content Management System for museums & galleries utilizing Physical Web and Web Bluetooth technologies.

The idea is that an employee of a museum, gallery or other space installs the app and then in-app: enrolls the beacons and creates an exhibit. This allows them to associate multimedia content with each beacon, the sum of which is displayed when to visitors on their smartphones when in proximity to a beacon. If they have the client app installed, it will even show them the content specifically for nearest beacon as they walk around the space.

My work has been centered around 3 Github repositories I created for this project:

  1. Android app to set up exhibits and configure beacons
  2. Python program to fetch exhibit contents and process them into HTML pages
  3. Android app to display beacon content to visitors, updating as they move around

All code in these repositories, with the exception of the code in util package in the first repo, was developed as part of my Google Summer of Code 2017 project.

A timeline of the development process can be found here.


Of the original goals set out in the proposal, we have been able to fulfill all the outcomes, including one out of the two stretch goals.

I enjoyed learning about new technologies over the course of the project: I was introduced to ORM frameworks and used one for the first time, instead of writing plain SQL queries. Bluetooth Low Energy is surpringly capable, more than I had expected.

This project is the most ambitious, most complex I’ve attempted in my career. The project utilizes Java, Python, and HTML/CSS/Javascript and comes in at just over 15,000 lines of code and markup; I am quite satisfied with how well all these components function togather to work as an end-to-end solution.


Working with hardware devices was a unique challenge I had not experienced before. Sometimes the Bluetooth connection is flaky, sometimes they run out of battery and often they are real-life black boxes. I managed to overcome these challenges, but they were not something I had to deal with in the past, working on purely-software projects.

Another challenge was syncing with Google Drive. As far as I could tell, the Google Drive API for Android only facilitates uploads and downloads of individual files - I had to write a recursive algorithim to sync folders, resolving conflicts on the way.

I also learned that writing tests is not always practical, as some functionality is hard to unit test - and integration tests end up being flakey, espicially as I was developing internet-enabled code on a poor network connection.

I also had to work around a number of bugs in Android. The diversity of hardware is a strength of the platform, but also a pitfall.

Future Efforts

Once the Web Bluetooth scanning API is implemented in major browsers, the Android app for visitors will no longer be required, as what it does could be replaced with a simple javascript file. So that would definitely be an avenue for improvement for the future.

Perhaps the programs could be extended to use storage backends other than Google Drive, for users who would prefer the content uploaded to say, an FTP server. This shouldn’t be too difficult as I’ve aimed to write reasonably decoupled code.

Previous post
Google Summer of Code: the Application I recently received news that my Google Summer of Code 2017 proposal has been accepted. So I thought I should write a series of posts as this summer