CODEWITHSUNDEEP
androideclipsecalendar
PaulP
PaulP

Reputation: 2325

Is the new Android Calendar API in ICS backward compatible?

I am learning Android and have been working on an application that will need to read and write to the user's calendar. I'm very much aware that there was no public API until Android 4.0 (ICS). But, there was 'calendar functionality' in earlier versions of Android.

My question is; now that there is an official public API, will it work only with Android 4.0 and future releases or is it now possible to access calendars on phones that run earlier versions of Android? Can the new API be included as a separate library when targeting earlier versions of Android? [I'm working in Eclipse] If so how would this be done?

I'd like to avoid using the old non-public approaches that don't conform to the official released calendar API.

Upvotes: 2

Views: 1257

Answers (1)

CommonsWare
CommonsWare

Reputation: 1007286

will it work only with Android 4.0 and future releases or is it now possible to access calendars on phones that run earlier versions of Android?

It only exists on Android 4.0+.

Can the new API be included as a separate library when targeting earlier versions of Android?

No, given your following limitation:

I'd like to avoid using the old non-public approaches that don't conform to the official released calendar API.

It is conceivable -- though far from certain -- that either:

  • CalendarContract happens to simply be the "old non-public approach", granted official status, or

  • One could take the source code to CalendarContract and, for at least a subset of the capabilities, modify it to work with older editions of the private APIs

The latter would probably work something like ActionBarSherlock, where it passes the request along to the native implementation on Android 4.0+ and uses its own implementation on earlier versions of Android.

In either case, there is still the possibility that vendors modified the Calendar app and therefore CalendarContract will not be completely compatible. In the second scenario I outline, whoever maintains this compatibility library could perhaps implement device-specific workarounds for such cases.

Upvotes: 2

Related Questions