Thursday, December 10, 2015

AutoPebble: Be a Wearable Tech Programmer in about 15 Minutes

Due to a possible upgrade in Smartwatches (more to come, if it pans out), Shira's letting me play with her classic Pebble. My first thought was to look into Tasker integration, and I was psyched to see that there are a number of options. In doing some research, I decided to focus on AutoPebble (rather, than say, PebbleTasker). AutoPebble is written by the same developer as AutoRemote and follows the same development strategy.

The strategy goes like this: AutoRemote and AutoPebble run on your Android Phone and handle incoming messages. These messages (which main contain a payload) are automatically passed to Tasker, where you can install a handler to respond to them. It's a simple glue layer that turns out to be remarkably powerful.

In the case of handling remote requests, AutoRemote's functionality needs to do little more than what's described above. If you send your phone the message say=:=Hello World, and you've implemented a tasker handler to intercept messages that being with say= you're basically done. In the above case, it's trivial to use the Say tasker action to recite the payload ("Hello World").

AutoPebble does the same thing, but adds another layer. Consider the start screen I put together here:

Using the Up and Down buttons, you can choose which option to invoke. When you press the Middle watch button next to Capture the following screen is shown:

The above screen is implemented by AutoPebble's two main pieces of functionality. The first is that selecting Capture sends the capture_list message, just like in the AutoRemote scheme. I've got a listener setup to handle this incoming request. This listener is implemented as a standard Tasker profile, so it can do anything tasker can do. The second bit of functionality is that AutoPebble allows you to render content on your Pebble. So in response to capture_list, I invoke the AutoPebble List action, which generates a UI list on the watch itself. In this case, capture_list effectively generates a sub menu. From the Capture submenu, I'm able to choose what I'd like to capture. Invoking one of these options sends yet another message to the phone using the AutoRemote style convention.

In the case above, I arrange for specific capture requests to be in the format capture=:=SRC where SRC is defined as one of the following: FrontCamera, BackCamera, Sound. Within Tasker, I invoke tasks that correspond to these different sources, and use the AutoPebble UI capabilities to give an informative message as to what the watch is doing.

Here's another quick app I wrote. Using the Barometric Pressure code I wrote yesterday, I'm able to display this information when asked for it on the watch. Now when Shira feels like she's getting a headache and wonders what the barometric pressure is, I'm only a couple of watch presses away from getting her an answer, as well as seeing the history of data I've seen before. Check it out:

I'm positively amazed how quickly I've been able to write useful apps for the Pebble. Most of the time spent struggling on the above apps was spent figuring out Tasker quirks, more so than anything else. Once you get how AutoPebble does it magic, there's not much to it. Bottom line, AutoPebble is an absolute winner. Yes, there are times when it's a bit slow and I've seen some quirky behavior. But from a programmer's perspective it does all the hard work, so I can just focus on the fun part.

I'm not sure how long this little experiment in wearable tech will last, but so far, it's a programmer's dream. Another device I can program; whoo!

If you'd like to see any of the Tasker code that powers the above screens, let me know, and I'll publish it.

No comments:

Post a Comment

LinkWithin

Related Posts with Thumbnails