A Community-Driven Compatibility Library

An hour ago, I was taken to task by somebody, for correctly pointing out that CalendarContract is only available on API Level 14 and higher.

The commenter asked about “possible work arounds” and bitched about Google (I presume) not providing a compatibility library for the calendar API.

The Android Support package does provide a “compatibility library” for some newer APIs, but it is mostly in the form of backports. If you are supporting older devices, you can use the backport; once you are only supporting newer devices, you can drop the backport. However, because Calendar is an app, installed in firmware, it is not possible to create a backport that can be tossed into the Android Support package.

That does not mean that a compatibility library is impossible. In fact, it is eminently possible for anyone to create a documented and supported compatibility library for calendar access, if they have the itch to scratch.

Accessing the calendar has long been possible, via an undocumented and unsupported ContentProvider. However, accessing that ContentProvider has never been advisable, because it changes over time and might be modified on particular devices by OEMs.

A good community-drivren compatibility library for the calender might have the following characteristics:

• It would support a superset of the classic undocumented API and the new CalendarContract API

• It would have a “capabilities” API to determine, at runtime, what particular gross features are supported by the underlying calendar implementation, to handle differences between the old and new APIs, to handle places where device manufacturer changes break the old API, etc.

• Akin to LocationManager and SensorManager, it would offer a single API to potentially multiple calendar backends, to handle both AOSP Calendar apps (old and new) and any OEM or third-party calendar apps that support some sort of API

• It would provide implicit Intent action strings that would be remapped to the actual activity implementations, for common actions like viewing the calendar, viewing an entry, editing an entry, etc., where supported by the backend calendar implementation

• It would have some semblance of documentation and support

• It would have clearly described licensing (whether open source or commercial)

Nothing in that list represents something only Google could do. Anyone who wants to could spend the time creating such a library. Then, it would be incumbent on the library author to be the support point for that library, and the library author would need to deal with any device-specific idiosyncracies and the like. The broader Android ecosystem could use the library with a stronger degree of confidence than they would in using any prior iteration of the undocumented system API.

However, AFAIK, nobody has created this library for the calendar. I might, someday, though presently it is a very small itch compared to others on my 18,000-item to-do list. With luck, somebody else who has a larger itch will scratch this.