I can’t deny there was some excitement in the office when we first received a call from Mark Rober asking for help with his Glitter Bomb project. In case you didn’t know, Mark Rober is a well-known YouTuber who produces videos on popular science—everything from Snowball Machine Guns to Magic Bowling Balls that give you an automatic strike. In December 2018, Mark produced a video showing his latest project: a Glitter Bomb bait package designed to trick thieves who were stealing parcels from his doorstep.
Excerpt from the 2019 video, Porch Pirate vs. Glitter Bomb Trap 2.0
With millions of views, the video was an overnight hit and quickly gained the attention of news media. Given the success of the first Glitter Bomb video, Mark decided to create a new video for 2019. For that he needed a new and improved Glitter Bomb package.
You might be wondering how a mobile app development company could help with such a project, and so were we.
The Initial Problem
It turned out the Glitter Bomb package contained four Android smartphones running an app that captures video footage and uploads it to a server. In addition to the custom built Android app, there was a server application with a web interface that allowed Mark and his team to track the location of the phones and view the video footage. There was an existing codebase for both the app and the server, but Mark and his team were running into some serious issues during their testing and knew they needed help to get everything working reliably. They had a short (three week) timeframe to resolve these problems before they began their efforts to deploy Glitter Bomb packages and collect video footage for their 2019 YouTube video.
I was in a bind, and I sent out requests for quote to 3 different companies.
mobileforming's approach was thoughtful and thorough from the start. They asked all the right questions and in the end, it was a really easy decision. Their execution lived up to and even exceeded my high expectations.
There would be significantly less biodegradable glitter in the carpet of porch pirates across the country if they didn’t come in and save the day with their work on the app and server.
One of the first decisions we had to make was whether to use the existing codebase or start from scratch. Mark was open to either option as long as he had working software once the project was complete. Based on our analysis, we decided to move forward with the existing codebase. Although there were some areas that needed major rework, we felt that it was good enough to get the job done.
Given that the main value of the project is the video footage captured by the Glitter Bomb packages, we decided to first focus our efforts on getting video capture and upload to work reliably. We knew that there were some performance and scaling issues with the server that were affecting the video upload; and since we had little information about the hardware the server was currently running on, we decided to deploy the server on our own EC2 instance where we had more visibility and control. We also wanted to decouple any performance bottlenecks on the server from video upload, so we set up an Amazon S3 bucket to store the video files and reduce the load on the Glitter Bomb server.
When we looked into the app codebase to understand how video upload was handled, we found a couple of bottlenecks that were impacting video upload. For example, there were some failing network calls that would constantly retry and block the thread that uploads the video footage. Once we had resolved these app problems and migrated the video upload to S3, things started to look much better: the video upload was much more reliable and performant.
With video upload greatly improved, our attention then switched to the stability of the app. Mark had reported that the app was crashing frequently when the USB keyboard was disconnected. This was particularly egregious when it happened while video was being recorded. You might be wondering where the USB keyboard comes into play, so let me explain. The heart of the Glitter Bomb is an Arduino device that manages the hardware of the bomb. In order to communicate with the four phones, it would send keyboard commands via a USB-C connection to the phones. So, for example, "a" starts recording video, and "d" tells the app to store its location. The "USB disconnected" event that leads to the app crashing on the phone, is actually triggered by the Arduino.
As app developers, we take crashes seriously. It’s never a good user experience to have the app suddenly stop when you’re in the middle of doing something. However, in most cases when an app crashes, the user can restart it straight away and continue where they left off. In the case of the Glitter Bomb app, the device is encased in a box without any direct human interaction—only the keystrokes coming from the Arduino. When you consider this, you can perhaps understand why this crash is a real showstopper. Fortunately, we were able to diagnose and resolve the issue fairly quickly. It required a quick manifest change so that the Android Activity did not restart on configuration changes such as orientation change or USB disconnect.
After video upload, the next main function of the app is location tracking. When the package is placed on a porch, ready to tempt the porch pirate, its initial location is stored and a geofence is set up. Once it is picked up by a package thief, the app starts to send frequent location updates to the server. With this information, the admin console can display a map showing the path of the package so that it can be recovered after it’s been stolen.
Mark reported that there were problems with displaying the path on the map in the admin console. We weren’t sure whether these problems were due to flaws in the app code or the server code. To diagnose the problem, we used one of our favorite tools, Charles Proxy, to look at the http traffic between the app and the server. Straight away, we could see that there was a bug in the app preventing the location information from being sent to the server. We quickly fixed the bug and ran some tests to confirm that the server was now receiving location information. In our initial tests, we used an app that allowed us to fake the movement of the device. Once we felt pretty confident things were working well, we took the devices out for a drive to simulate the scenario where a package is stolen. With features like location finding that work differently on a cellular connection, it’s always a good idea to test without wifi. Our testing uncovered some server side issues, mostly related to the display of the map on the admin console, so we still had some more work to do before we could call the location tracking work complete.
Besides these main areas of functionality, we were presented with many unique challenges while working on the Glitter Bomb project. We don’t usually work on apps running on devices concealed in a box, so we had to think carefully about how to test the app. We had to ensure that the app responded correctly to keystrokes and that we understood the order in which the keystrokes would typically be executed. One of Mark’s YouTube collaborators, Sean Hodgins, provided a test jig that allowed us to connect four devices simultaneously to an Arduino and execute a couple of different keystroke test sequences without the risk of being showered with glitter! This tool was valuable in helping us to understand how the four devices would work together inside the Glitter Bomb package.
The Test Jig
Battery life was another challenge we faced. The devices were turned on and the app was running while the package waited on the porch to be stolen. To help with battery drain, we turned down the screen brightness to three percent. This wouldn’t normally be recommended for apps that users are directly interacting with; but since the device was inside a package, this became a viable option. If we had more time for implementation, we might have considered using a service running in the background, with the screen off, to avoid the battery drain from the screen. However, since this problem arose while Mark and his team were testing the app, we had to come up with a solution that could be implemented and tested quickly.
On all of our projects at mobileforming, we value retrospectives. During these meetings, the team gets together to discuss what’s going well and what needs to be improved. Getting into the habit of holding retrospectives has helped us to drive steady improvement in our process, our team, and our technology. Although the Glitter Bomb project was short, we were keen to understand what we could have done better and how that could be applied to other projects.
On some of our projects, we don’t have the luxury of well-documented requirements. So we’ve learned to ask the right questions and dig through code to get an understanding of how things should work. The Glitter Bomb project elicited even more questions. Not only did we have to learn how the app and server worked together, but we also had to understand how they were used operationally: how are the glitter bomb packages set up before they are placed on the porch; what configuration is required on the server; and how are Mark and his team using the server app when the boxes are stolen?
The user interfaces for both the app and the server were unintuitive—making the investigation more difficult. We learned the hard way about some of the nuances of the server application—like naming conventions for devices (no apostrophes allowed!). Of course, Mark was able to provide answers to many of our questions and we gained an understanding of how the server application was used as we worked through the issues that arose during testing. But we all agreed that it would have been a good idea to set up a War Room in the beginning to really speed up the discovery process and maximize communication between all the team members. This would have helped to ensure we were all on the same page about how the app and server were used together and how we should test. We’ve used the War Room concept in other scenarios, and it has been a useful tool in accelerating progress.
Despite the many challenges we faced and the short timeline, the team agreed that this was a fun project and we derived a lot of satisfaction from seeing the end result. I’ve often found that projects like these, with time pressure and some interesting technical challenges, can be bonding experiences for the team. We’re forced to rely on each other to deliver a result that the client is happy with. We certainly gained a new understanding of the level of effort that Mark Rober puts into producing his YouTube videos and look forward to seeing his future projects.