search

SufficientlySecure / calendar-import-export

Import/export your Android calendars as ics files without using the Google cloud
https://www.schuermann.eu/android/
GNU General Public License v3.0
80 stars 27 forks source link

Share code with ICSDroid? #26

Closed dschuermann closed 8 years ago

dschuermann commented 9 years ago

ICSDroid allows to subscribe to ics calendars online: https://f-droid.org/repository/browse/?fdfilter=ics&fdid=at.bitfire.icsdroid&fdpage=2

They developed there own android wrapper with ical4j at https://gitlab.com/bitfireAT/ical4android/tree/master

Maybe we could use ical4android , but I am not sure about this.

jgriffiths commented 9 years ago

Some technical thoughts:

This app currently does not do syncing but conversion.

Syncing generally requires trying to keep all data from the upstream calendar and reflecting changes back to it. In Android that means e.g. using the extra sync columns to hide information that enables the sync to occur, tracking which items are dirty, etc. The upstream calendar is considered the "true" source of the data and the local version is just another way to view or perhaps edit it. ICSDroid is this kind of sync app (albeit one-way).

Contrast this with conversion. Conversion means trying to accurately reflect the calendar details using the available object model. So when importing an ics file it is converted to the android data model and some details are lost (e.g. descriptions in alarms) because the source and destination object models differ. Here we don't keep sync information to try and capture the details that have been lost. The app currently fits this model.

The choice of whether to do sync, conversion or both affects the way the code is structured. Sync requires more code to try to save the details needed to update the calendar upstream. In the case of their wrapper, they have produced a layer of abstraction so that disparate sync sources can be treated the same. This level of abstraction is useful for syncing (you can treat many disparate sources/sinks in the same way). But it is unwarranted when converting because the it adds no value - the Android calendar and iCalendar files are the fixed inputs/outputs and an abstraction between them can only make mapping between them harder/more inaccurate.

Whether the app should do conversion or syncing is a topic we could discuss separately. I started hacking on this project because it is offline and I have un-entangled Google services from my phone. My phone calendar is my primary calendar now, and I need to be able to back it up. So at least to me, lack of sync is not really a problem :-)

I think there is a set of code that could be shared between the two code bases. While its not clear to me yet how that sharing would look, my first thought is that we don't want to introduce their abstraction at this point. There is some stuff that we could use that they clearly do better/do at all (e.g. attendees, probably TZ handling etc). Then there are some changes/features that should probably be upstreamed to them (e.g. back-compat, trigger code).

My inclination is to continue with the restructuring of this app with a view to sharing code in the future. That means continuing to trim the UI/processing code and then splitting our conversion code from it. Once its separate and a bit more evolved we should be able to find the commonality more easily and revisit this.

dschuermann commented 9 years ago

My inclination is to continue with the restructuring of this app with a view to sharing code in the future. That means continuing to trim the UI/processing code and then splitting our conversion code from it. Once its separate and a bit more evolved we should be able to find the commonality more easily and revisit this.

ACK