In a previous post about KDE Itinerary I mentioned Android platform calendar support for the KCalendarCore framework. This is meanwhile functional (code), and here are some more details about it.

Features

KCalendarCore not too long ago got a plugin interface for abstracting access to platform calendaring solutions. For this we now have an implementation for the Android platform calendaring API.

This allows:

  • Listing of platform calendars and their access permissions.
  • Listing all events or retrieving an event by a known id from a given calendar.
  • Listing all events in a given time range, including considering recurrence rules.
  • Adding a new event, updating or deleting existing events.

Limitations

However, as with any attempt to abstract cross-platform features, there are a number or limitations to be aware of.

Android’s platform calendar only supports events, while KCalendarCore implements the full iCalendar specification and also covers todos and journals. The corresponding KCalendarCore API is therefore non-functional on Android. Support for todos might be possible eventually, e.g. by building on top of the OpenTasks content provider.

Android’s event data model is only a subset of the iCalendar model. For properties beyond that there is a dedicated “extended properties” table, but that can only be written to by sync providers, not by regular applications, and it uses data formats specific to the sync provider. We can so far at least read the format of DAVx⁵ (which is used to access Nextcloud calendars for example), but writing events with properties outside the supported subset isn’t possible. Event attachments are also not supported.

Another aspect still missing is change monitoring (ie. being notified about calendar changes), it’s however unclear to what extend that is provided by the platform at all.

And finally, access to the calendar needs special permission on Android. This is something the application needs to take care of itself, as that’s an asynchronous process that can involve user interaction, which is hard to hide behind the synchronous KCalendarCore API.

Use cases

Given all these limitations, what can we actually do with this? It’s obviously not the best choice when trying to build a fully featured calendar application and hoping for a perfect platform abstraction. Neither will any KCalendarCore-based software just magically work on Android with this.

If access to calendar events or the creation of calendar events with limited complexity is needed for a secondary/extra feature of an application though, like it is in the case of KDE Itinerary, this is sufficient and makes it straightforward to access the corresponding platform calendar with (mostly) the same code.

Outlook

Right now the code lives in KDE Itinerary’s repository still, which isn’t ideal and isn’t really benefiting anyone else yet. So a few things still need to happen going forward:

  • KAndroidExtras, the JNI wrapping library this is built on top of needs to be extracted and turned into a separate framework.
  • The Android platform calendar plugin then can move to KCalendarCore, alongside the corresponding plugin loader class.
  • We need at least also an Akonadi plugin to cover Linux, otherwise there’s not much platform abstraction here (work in progress).

Testing beyond a DAVx⁵/Nextcloud setup would be interesting as well, we might need support for more extended event property formats there.