How An Open System Helps Us Build A Closed One
Or, why the Barnes Wearable Project chose Android
When Shelley Bernstein first came to HappyFunCorp to talk about building a wearable future for the Barnes Foundation, there was one app that she couldn’t stop talking about: The New York Times’ Apple Watch app. Indeed, The New York Times watch app is considered one of the best for its focus on short “stories” digestible in just a few seconds. Shelley’s challenge to us: could we create a wearable experience that could utilize wireless beacons to know where a user is, and deliver them NYT-like notifications based on their location?
Our first question: is the Apple Watch — the most ubiquitous of smartwatches — up to the task?
Behind what seems like a simple prompt is a non-trivial list of hardware and software needs:
- Pair multiple watches to a single phone
- Access the internet without carrying a phone
- Keep users from opening other apps
- Use bluetooth beacons to locate the user in the galleries
Now, as any self-respecting Apple Nerd will tell you, this is a tall order for the Apple Watch. It’s widely understood that in order to ensure that the Apple Watch had an all-day battery, Apple made a number of compromises, the largest of which was the watch’s dependency on an iPhone to do much of its networking and processing.
But most crucially, while the Apple Watch has Bluetooth transmitter inside, Apple’s design of watchOS prevents software developers like us from accessing it to use with its iBeacon technology. It may sound surprising that Apple would purposefully limit the capabilities of their devices, but sacrificing general usefulness for the good of a greater design goal (in this case, battery life) is what many of us in tech would call “A Very Apple Thing To Do.”
So, while Apple’s closed system may be best for an everyday consumer, as a commercial user who has a very specific purpose for the device, we are left out in the cold.
And so we turned to Android Wear. Android Wear is exactly what it sounds like — Google’s answer to the Apple Watch. Android has always been known to give more freedom to developers and Android Wear is no exception. Among the features Android Wear makes available that Apple Watch does not are:
- Installing apps directly onto the watch
- Functioning on Wifi without being paired to a phone
- Access to Bluetooth location technology via beacons
- Complete customizability of the app experience
Looking at a list like that, it’s hard to say it was even a contest. While the Apple Watch is an incredible device built for a very specific use case, Android Wear is the best option for a single-use device like the one we’re building for The Barnes Foundation.
Which isn’t to say that Android hasn’t been without folly. While the version of Android that runs on phones allows a number of options to edit system-level features — like allowing for an app to be ‘kiosked’, preventing users from using any function of the phone other than your app — Android Wear isn’t quite as flexible. Even though kiosk mode is in theory present on Android Wear, the admin privileges needed to activate it don’t exist.
However, the flexbility of Android still allows us a workaround. In order to work around the lack of a kiosk mode on Android Wear, we’re able to prevent the user from leaving the app using any default gesture (normally a swipe right), as well as forcing the system to relaunch the app in the case that the user leaves it by pressing the home button.
All things considered, we’re pleased with our decision to build the Barnes Wearable Project on top of Android, and in fact couldn’t have built what we wanted without it.
The Barnes Foundation wearable digital prototype is funded by the Barra Foundation as part of their Catalyst Fund. Read more about the Barnes Wearable on Medium.
