Yoyo, wear it with Android
I’m Tariq and I joined the Mobile team at Yoyo Wallet early this year, working on our consumer Android and iOS apps.
At Yoyo Wallet we’re all about making payments and loyalty easier. The next logical step is to let you pay and collect rewards with your watch. We have now released version 3.6.0 of our Yoyo Wallet app, with Android Wear. Here, I’ll just run through some of my thoughts and discoveries in the process of building our Wear app.
The Android Wear SDK was first released by Google alongside KitKat with 4.4W almost a year ago. At the time I’d been working more on iOS so I never really had the chance to play around with Wear until just a few weeks ago. Having spent some time working on our Apple Watch app, I was able to discover a few key differences between WatchKit and Wear. So what did I find?
Wear is a big OS in itself.
Unlike Apple’s WatchKit, Android Wear is fully capable of running an entire app on its own.
- Google have provided Wear with almost all of the APIs available in the core Android SDKs
- Wearable apps do not need a functional handheld counterpart, but they do need to be packaged within one — but of course, that’s not what it’s built for.
With WatchKit, we do not have access to UIKit components, but instead use Interfaces, which do not have a layer property for us to animate with. As such, in order to animate on the Watch, we essentially have to rapidly cycle through several images.
With full access to APIs on Wear, however, any custom UI and animations will work just like they do on a handheld.
The Wearable Data Layer is a good guy
Two-way communication and a shared data layer makes life a lot easier. WatchKit requires the app extension to request data from the main app; it doesn’t provide straightforward APIs to push directly to the watch.
The Wearable Data Layer API provides a few messaging options between wear and handheld. The important detail here is that for messaging to work, both the wearable and the handheld app must have the same application id.
The MessageApi is great for fire-and-forget messaging such as push notifications.
The DataApi, however, is where it really counts. This provides a persistent data layer shared between wearable and handheld, using simple key-value stores, so your wearable will always be in sync with the handheld.
Packaging Wear apps can be a pain in the real world
In theory, packaging a wearable app is as simple as adding wearApp project(‘:wear’) in your mobile module’s dependencies. Unfortunately, I ended up wasting a lot of time trying to get this to work with multiple build types and product flavors. Since then, I found two solutions, manually packaging the signed wearable APK in the handheld’s raw or assets directory, and more recently — though I have yet to test this — to add the configurationparameter, as such: [flavor]WearApp project(path: ‘:wear’, configuration: ‘Foo’).
The first method also requires adding some metadata to the handheld’s manifest, which states the wearable’s application id, version name and version code. This can become quite cumbersome when pushing out multiple releases, but I found a nice little Gradle script to automate this here.
Final thoughts
Overall, I’ve felt Wear is pretty solid and gives you all of the flexibility of Android without much of a learning curve. Views adapt very easily to both square and round screens, so the whole process is fairly straightforward and makes developing for Wear just as simple as developing for handhelds.
If you have any questions or want to let us know your experiences with Android Wear, let us know below, or tweet us @yoyoengineering
