Yes, but the button is is appealing too. On https://icsdroid.bitfire.at/ the “Get it on Google Play” looks a bit lonely on the large gray square. On https://icsdroid.bitfire.at/download/ it is so far “below the fold” and in a different layout that I didn’t notice it. Hence that these buttons, with the same styling, give users of all stores in one quick look all they need to know on what stores this app is available. Understandable that you want a disclaimer since it is a build you don’t do yourself. However, it is a build that is monitored very strictly and openly, so I think you can list it proudly.
@max Synchronizing calendars in both directions is a very complex task, and it takes more than just downloading and uploading a single .ics file per calendar. If you have a look at CalDAV and which problems it solves, you will see what the problems are. You will also need a hierarchy: just think about the case that one .ics file contains a certain event, and the other doesn’t. So, does it mean that it has been deleted by the user and should be deleted from the one .ics file, too, or has it just been added and should be added to the other .ics file?
This is a conceptual idea: after a sync, show a message bar indicator (for calendars selected beforehand), that X events updates, Y added, Z deleted. Then you can tap on this notification and get a more complete summary where it says “EVENT TITLE updated, EVENT TITLE deleted/added”, etc.
ok, I would have expected that events with the same UID get “merged”. Whats would be the sense of the UID anyway ? Only to identify one event within one subscription file ?
You’re right, theroretically the UID should be “globally unique”. However, the Android Calendar Provider doesn’t work that way. It just has calendars (which are stored in database tables, after the Calendar Provider abstraction layer), and events (which are stored in another table, and have a n:1 to relation to the calendars).
So, the only possibility to merge duplicate events would be in the Calendar app which shows the events. You might suggest/implement this for open-source calendar apps like Etar or even for AOSP calendar (but chances that it will be accepted are low)…
I understand, however, that this is not a bug within icsdroid then, so feel free to close this.
It could be good t have an Export (or Backup) button, to be able to save existing subscritions. At the moment, we can’t even select subscriptions address to be able to save them to a file. In case it is a shared calendar, we have to ask ics address again.