At OSCON this year, I did a demo of something that I just hacked up hours prior, and it worked...while I was on stage.
During the presentaion about Third-Party WebViews, I showed the power of a third-party webview by deploying Cordova 4.x on the Samsung Gear Live watch running Android Wear. This initially worked, and I was able to do Chrome Debugging on the watch itself without any ill effects. However, since I presented on the last day of the conference, I had to quickly grab my stuff, hop into my car in the basement of the Oregon Convention Centre and head back to Vancouver. That's where we start running into problems.
I've been dogfooding the Samsung Gear Live for a week, and I have to say that Android Wear is alpha at best. Apparently this is what they said at Google IO, but they didn't say this to anyone who actually purchased one. Luckily, this was purchased to see if we could get Cordova on the device, so it served its purpose. So, when stuck in traffic on the I5 in Seattle, I check my watch, and the screen is dead.
WTF? What Happened
Turns out that running a WebView or anything else that takes a lot of memory causes Android Wear itself to force quit. I got a notification saying that Android Wear had stopped and a "Cancel" and "OK" screen when I tapped the screen. I eventually was able to restart the watch at a rest stop, but it's clear the reason that Google removed WebView from Android for Android Wear was the huge memory footprint. The question now is, what has a bigger footprint? Chromium or ANT? I'm certain that Crosswalk was never meant to be put on a phone, but if there was a stripped-down version of Chromium that made sense, or even better, a way to run a watch that's based on a Web-Only OS, we could do some interesting things.
So, no Cordova on Wear?
The demo was literally that, just a demo. Good demos exist to show what's possible, to get people to think about new things and to get people excited about working on cool stuff. I'm hoping that my demo did that, but that was in no way any production code. I do not recommend shoving Crosswalk onto a watch. I also think that Android Wear is extremely buggy, and hard to develop for, but is still the most interesting thing to happen in the Wearable Space since FitBit first started tracking steps. Actually being able to develop software for wearables is much better than just buying a closed microcontroller encased in epoxy and rubber and strapping it to a body part.
Last weekend I replaced my FitBit Force with a Garmin Vivofit. This week, I'm going to be going back to MEC to return my Garmin Vivofit. There's nothing wrong with the hardware, it's just that the software is so totally unusable and ugly that the user experience of actually syncing the data that this has collected is terrible.
For those of you who don't know, I've had problems with the FitBit line of trackers, namely the fact that I've lost three of them. I've owned two FitBit Ultra trackers, and a FitBit One. The ultra wasn't a bad tracker, but I did lose one a month after I had it. The FitBit One I had for a whole 24 hours before the belt clip caused it to hop off and go down Commercial Drive. After that point, I decided to not buy a FitBit until there was a FitBit with a display for steps and time that could go on my wrist.
I then bought the Force when it came out and I initially liked it, except for this super funky smell that came from the strap. I never showered with it, and I washed it a bit. It was clear that there was something wrong with the material. A friend of mine later showed me her FitBit rash and then I was on the lookout for it. Eventually, I started to get the FitBit rash and I decided to not let it all get disgusting and I filed for my refund. I think that if I wore the device in the shower, I'd probably end up with full-blown FitBit rash.
After the Force Rash thing, I decided to see what else was out there that fit my requirements, and I found the Garmin had their Vivofit. Here's a breakdown of the good and the bad.The Good:
- Always-On Display
- Plastic strap does not smell bad
- No need to charge the deice
- Swappable wrist straps
- Does not track sleep
- Only syncs manually
- Does not have any light for reading in the dark
- Garmin Connect has poor UI
- Garmin Connect clearly uses OAuth, but poorly
- Garmin Connect Bluetooth LE code is buggy, requiring the phone to be restarted before it works again
I know that Android BLE is not exactly easy, but the fact is that you should be able to close your connections and not end up with your BLE just failing if your sync process is 100% manual. I had very high expectations for this, since Garmin is a big name when it comes to GPS and Fitness Equipment, but this really fell flat. I think at this point, I should just wait until after Google IO and see if the Moto360 will kill fitness trackers by integrating them into the watch hardware.
I'll probably talk about Hardware and Industrial Design more, since it's interesting to see how hardware startups have to make sure to have their hardware and software work well enough for the user. I ahven't seen anyone get this balanced right yet.
Android 4.4.3 is rolling out to the stock devices, as well as to the Moto X/G/E phones, and it comes with Chromium 33, instead of the earlier Chrome 30. This is a good thing, since there are many fixes. While it's extremely disappointing that Google hasn't at least partially decoupled Chromium from the Android update process and made it work more like Google Play Services, it's good to see yet another WebView be available.
So far from what I see, the main change is that the File Input field has been fixed. It doesn't fully work in Cordova yet, but I'm hoping that we can get this to work properly soon. Since 4.4.3 is a minor update, I'm also hoping for more adoption than a major version, but it's entirely possible that both CR-30 and CR-33 will be living out in the wild for a long time, which makes Third Party WebViews even more relevant.