this was really just an idea to make icsdroid even more attractive and because I didn’t know about etag support in icsdroid. I just checked and most of my feeds do, I just wrote to teamup.com support to ask if they could add it
And it came to mind for the other use-case I described (respecting the cache-timeout header if the server sends one) because per-collection sync would be a prerequisite.
Honestly, icsdroid works great for me, this is just to foster it’s position as the best tool available 8-)
(a prerequisite would be to have per-collection sync intervals.)
Then you could respect http header meta-information, e.g. when it tells you how long this resource may be cached or when its expiring (and then trigger a new sync).
This could help save bandwith and computing time on the long run if servers send correct headers.
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?
That make sense. So please consider this a feature request, as opposed to a bug report.
Using ASCII is fine for now, there are few french-speaking websites using IDN.
But there probably many arab/chineese/russian-speaking websites that do, so it may be more annoying for those users.
N.B. I’ve sent a flattr micro-donation as a gesture of support
Indeed, the concerned admin took care of it and was quite grateful for the help I could provide thanks to your replies!
The beginning of the generated .ics-files now looks like this:
As far as I understood the problem, this should keep it fixed even after the next clock change.
Thanks again for your help!
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.
No need to close, this is a forum
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.
Can you add the time of the last successful sync ?
Because right now we only know of the time of the last sync, successful or not.
It can be usefull if the server is down, and you don’t know who of you or your friends has the last updated calendar.