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.
I’d like to ask if you could add some more intervals for syncing. The 1st hour should have more steps to choose, e.g. 5, 10, 15, 30, 45 minutes.
Please find attached a patch. I didn’t compile it and did it in theory.
Thanks a lot for considering it.
Unfortunately, I don’t have Facebook and don’t know anything about it. Can you please post two .ics files, one with the event and one without the (removed) event?
Did you upgrade from ICSdroid 0.9 to 0.9.9? You may have to remove and add the calendar again.
@armadillo Synchronizing events (and tasks) is a very complicated task and it’s not done with simple copy operations. All the complex operations and requirements are best covered by a separate protocol – as CalDAV.
we’ve made good progress with our new lib ical4android and are proud to announce that ICSdroid is using the latest version of it now!
New in version 0.9.9:
allow to subscribe local files via file:/// URLs (use a file manager to open .ics files with “subscribe calendar (ICSdroid)” or enter the file URL manually)
don’t allow installation on SD card (causes removal of calendars sometimes)
update libical4android (better handling of VEVENTs without UID and recurring event exceptions)
small related UI changes and bug fixes
Version 0.9.9 has already been uploaded to Play Store. The source code is available on Gitlab. Binaries should be available in F-Droid soon, too.
If you have feedback, please do not hesitate to write us :-)!
Thanks for your report.
ICSdroid is a sync adapter which must not be moved to the SD card: Otherwise, it’s possible that the application is not loaded somewhen. At this time, the Android account manager sees orphaned accounts (belonging to the ICSdroid package that is not available [because it’s not loaded]).
I have now added android:installLocation="internalOnly" to the AndroidManifest which should fix that problem.
[taken from issue tracker]
Concerning the onCreateView in the AddCalendarDetailsFragment.java:
Some Outlook calendar-exports feature a X-WR-CALNAME property (as e.g. Link ) and if parsed, this could be a reasonable suggestion for the title of the calendar.