App Widgets as Wearable UIs
Since I am attending Wearables DevCon here in scenic Burlingame (no, really, the walk along the bay is quite nice), this seemed to be a good time for me to grouse about developing apps for wearables.
Wearable devices — particularly those that run Android — are not that hard to adapt an Android app to. You have to deal with different screen sizes, be more judicious about your gestures, worry all the more about power consumption, and so on. But, at the end of the day, it’s still an Android app.
Where things start to get messy is with wearable accessories, where your app does not run on the wearable itself, but instead runs on a tethered phone or tablet. You use some manufacturer-supplied API to render a GUI and respond to touch input.
The reason why this is messy is two-fold:
The people who design those manufacturer-supplied APIs do not necessarily think about what is going to garner the most adoption of those APIs
Each manufacturer rolls their own, meaning that developers have several such APIs to mess with, if not today, then tomorrow
Now, in some cases, the wearable really does need a distinctive API, because the UI you would want to create is itself distinctive. Augmented spectacles, like Google Glass, would be one such example. However, writing an app for one wrist wearable should not be radically different than writing an app for another wrist wearable, at least for basic apps.
What makes this all the more grating is that wearable manufacturers have a perfectly good API already in Android that they could be using: app widgets.
A home screen app widget has three characteristics in common with wrist wearables UIs:
The UI is small
The UI does not support much in the way of touch events (taps, plus swipes on select widgets like
The information shown there is stuff that is supposed to be for ready access at any point
App widgets have been around since 2009. There are tens of thousands of Android apps out on the Play Store with app widgets, and many (if not most) of them would be right at home as an app on a wearable.
For a wearable accessory, the mediation app supplied by the manufacturer that
runs on the phone or tablet would serve as an
AppWidgetHost. Rather than
render the app widgets on the phone or tablet screen, though, it would render
them to a
Canvas, sending the bitmap over to the wearable
for display. Touch events would be handled either by forwarding them along to
View hierarchy of the app widget (e.g., for swipes on a
by triggering the
PendingIntent associated with a tap. From the standpoint
of the app widget developer, everything would look just as if the device’s
home screen were the one hosting the app widget.
And that’s the point.
Every line of code needed custom for a wearable is a barrier to adoption. Developers are not necessarily going to run and jump on every wearable that comes down the pike. By using an existing framework, one that is (reasonably) well-documented and in use elsewhere, wearables can get more app support more quickly with less proprietary stuff.
Now, the app widget API was not designed with wearables in mind, in all likelihood.
There may be things that the wearable can do that go beyond the app widget.
How much of that could be shoehorned into an extended version of the app
widget framework (e.g.,
WearableWidgetProvider subclass of
AppWidgetProvider supporting additional broadcasts and methods) would depend
up on the wearable. And offering a complete proprietary API as an alternative
to using app widgets, for developers who want to deeply integrate with the
wearable, is similarly reasonable.
Wearables are still a fringe technology in 2014, compared to their phone and tablet brethren. If wearable manufacturers want a lot of apps quickly, using app widgets would seem to be the route to go. The wearable needs to adapt to the developers, not the other way around. Or, as the saying goes, “If the mountain won’t come to Muhammad then Muhammad must go to the mountain.”