Comments (2)
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.
from calendar-import-export.
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
from calendar-import-export.
Related Issues (20)
- Export error: range start must be before range end
- No file created HOT 1
- Calender import of all day events fails with 'Invalid int: "T0"'
- Export error : "A recurrence rule MUST contain a FREQ rule part" HOT 4
- Translation in Transifex not imported
- Range start must be before range end
- Add feature to delete calenders manually
- UID contains this string : @sufficientlysecure.org HOT 1
- Can't import a file
- Can't export a file
- Import error
- Error attempt to invoke virtual method HOT 1
- Error getTime()
- Imported events are "readonly"? HOT 1
- Re-import: Delete existing calendar content, then import ical file. HOT 1
- Crash when importing ics file exported from calendar-import-export HOT 18
- Crash when exporting a local calendar HOT 10
- Attempt to invoke virtual method crash when exporting HOT 10
- [feature request] automatically import and export an android calendar to and from a pre-specified ics file. HOT 2
- "Error: Property [ORGANIZER] must be specified once" when exporting offline calendars from Etar HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from calendar-import-export.