Google Summer of Code: Wrapping Up
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:
- Android app to set up exhibits and configure beacons
- Python program to fetch exhibit contents and process them into HTML pages
- 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.
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.
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.