The CommonsBlog

From Wear to Pebble

Initially, when wearables debuted, I was dubious. I had little doubt that some people would find them to be useful, but I did not expect that I would be among them.

Then, around late 2020, my team at MIRROR needed to add Android Wear/Wear OS support to our fitness mirror. So, I bought a few Wear devices for testing. I quickly determined that Wear 2 devices were less than completely useful, with CPUs that reminded me of Android phones from 2009 coupled with an OS that needed more than that. But, the Samsung Watch with Wear OS 3 was nice, and I took to it as a “daily driver” wearable.

Over the years, I moved from that Samsung to a Mobvoi TicWatch, then later to a Pixel Watch 3. Increasingly, I found Wear OS to be annoying, but I stuck with it. More recently, after a botched attempt to move my daily driver phone to GrapheneOS, I lost a lot of watch functionality, as I could never get it re-connected fully to my pre-GrapheneOS phone. 🤷🏻

When rePebble appeared on the scene last year, I took notice. I had never owned a Pebble, but I remembered their Kickstarter era. Plus, the TicWatch used an eInk/e-paper screen for its always-on experience (dual-layered with a classic touchscreen), and I appreciated the low power draw.

So, I took the plunge and bought a Pebble Time 2. A few weeks later, my Pixel Watch 3 is up for sale on eBay.

Is Pebble OS as powerful as Wear OS? No. Is the Time 2 as powerful as the Pixel Watch 3? Ha ha ha ha ha ha… no. But I don’t really need that kind of power, which mostly seemed to be there to make for snazzy animations, even if the underlying apps were less than completely stable. 🧐

What I wanted was something that was less-Googly, required fewer charges, had an open source foundation, and had a developer ecosystem. The Pebble qualifies on all those fronts.

I’ll be writing some Pebble apps and contributing to others. I am not going to turn this into a Pebble blog 😅, but I’ll mention my Pebble work from time to time.

After nearly 20 years of freelance developer advocacy for Android, between Pebble and my Kotlin Multiplatform projects, it’s kinda nice to be thinking about different platforms for some stuff.

—Aug 08, 2026

29 July 2026 Artifact Wave

We got five new-to-us artifacts this week:

androidx.concurrent:concurrent
androidx.ink:ink-storage-iosarm64
androidx.ink:ink-storage-iossimulatorarm64
androidx.ink:ink-strokes-iosarm64
androidx.ink:ink-strokes-iossimulatorarm64

Overall, there were over 600 new artifact versions this week!

—Jul 29, 2026

22 July 2026 Artifact Wave

Media3 is up to 1.11.0-rc01, after just a single beta release:

androidx.gradle:gradle-version-catalog:2026.07.01
androidx.gradle:gradle-version-catalog-alpha:2026.07.01
androidx.gradle:gradle-version-catalog-beta:2026.07.01
androidx.media3:media3-cast:1.11.0-rc01
androidx.media3:media3-common:1.11.0-rc01
androidx.media3:media3-common-ktx:1.11.0-rc01
androidx.media3:media3-container:1.11.0-rc01
androidx.media3:media3-database:1.11.0-rc01
androidx.media3:media3-datasource:1.11.0-rc01
androidx.media3:media3-datasource-cronet:1.11.0-rc01
androidx.media3:media3-datasource-ktor:1.11.0-rc01
androidx.media3:media3-datasource-okhttp:1.11.0-rc01
androidx.media3:media3-datasource-rtmp:1.11.0-rc01
androidx.media3:media3-decoder:1.11.0-rc01
androidx.media3:media3-effect:1.11.0-rc01
androidx.media3:media3-effect-lottie:1.11.0-rc01
androidx.media3:media3-exoplayer:1.11.0-rc01
androidx.media3:media3-exoplayer-dash:1.11.0-rc01
androidx.media3:media3-exoplayer-hls:1.11.0-rc01
androidx.media3:media3-exoplayer-ima:1.11.0-rc01
androidx.media3:media3-exoplayer-midi:1.11.0-rc01
androidx.media3:media3-exoplayer-rtsp:1.11.0-rc01
androidx.media3:media3-exoplayer-smoothstreaming:1.11.0-rc01
androidx.media3:media3-exoplayer-workmanager:1.11.0-rc01
androidx.media3:media3-extractor:1.11.0-rc01
androidx.media3:media3-inspector:1.11.0-rc01
androidx.media3:media3-inspector-frame:1.11.0-rc01
androidx.media3:media3-muxer:1.11.0-rc01
androidx.media3:media3-session:1.11.0-rc01
androidx.media3:media3-test-utils:1.11.0-rc01
androidx.media3:media3-test-utils-robolectric:1.11.0-rc01
androidx.media3:media3-transformer:1.11.0-rc01
androidx.media3:media3-ui:1.11.0-rc01
androidx.media3:media3-ui-compose:1.11.0-rc01
androidx.media3:media3-ui-compose-material3:1.11.0-rc01
androidx.media3:media3-ui-leanback:1.11.0-rc01

—Jul 22, 2026

Goodbye, cw-json! Hello, kPointer!

I have supplanted cw-json, replacing it with a new library, kPointer. The concept is the same, and porting from cw-json to kPointer is fairly straightforward. However, I realized that I made a key mistake when I started cw-json: thinking that I was only dealing with JSON.

(naming things is hard)

More Object Types

kPointer not only supports extracting values from JSON by means of JSON Pointer paths, as cw-json did. kPointer also supports YAML (by way of yamlkt) and HTML/XML (by way of Ksoup).

All get wrapped by an adapter-style abstraction layer, and you can make custom adapters to support other object tree structures. Part of the reason for supporting YAML, HTML, and XML was to exercise the abstraction layer. I am a firm believer in the “rule of 3” when it comes to APIs, frameworks, and abstraction layers: you need at least 3 separate implementations to feel comfortable that what you have will be able to handle more beyond those 3.

If you happen to want to adapt other structures, there is a conformance test suite that you can leverage as the basis for your own tests to see if your implementation covers all the cases. Personally, I am anticipating adding support for other data structures in the not-too-distant future.

A Better “Dot Notation” Option

The final release of cw-json, 0.4.0, introduced support for an ad-hoc sort of “dot notation” syntax, alongside JSON Pointer and its kin (relative JSON Pointer, JSON Pointer fragment syntax). “Dot notation” was aiming at the syntax that you see in template languages like Handlebars or Mustache, such as foo.bar.goo, to navigate into an object graph.

kPointer replaces that ad-hoc dot notation with… well, OK, a better ad-hoc dot notation, what I’m calling JavaScript access path notation. This is pretty much a clean superset of the original dot notation, but also supports bracket syntax (e.g., foo['bar'] or foo[0]).

Porting Support

Since I am anticipating porting kPointer to other languages in the future, I have a fairly extensive conformance suite, as part of broader support for porting kPointer.

kPointer comes with a CLI designed for running the conformance suite, and ports could create their own workalike CLI to assist in testing.

A Dedicated Site

Whereas cw-json had a long README and not much more, kPointer has a dedicated site, with lots of information on using the libraries and more.

What’s Next?

As I mentioned earlier, I expect to be adding support for more data format parsers, covering more data formats. For example, I expect to be adding support for CSV and similar delimited file formats.

It’s possible that I will add more pointer syntaxes besides the flavors of JSON Pointer and JavaScript access paths. I do not have any current plans in that area, but, hey, plans change.

—Jul 22, 2026