@rfc2822 Thanks for the explanation, makes sense! If ICSDroid can’t omit downloading the whole .ics file, wouldn’t a “time limit” at least lighten the burden for creating entries in the Android calendar (and in consequence speed up any application displaying this smaller calendar)?
Subscribe to calendar fails (times out?)
While testing stuff regarding Bug 112 “Synchronization Error - Couldn’t delete local events” I’ve noticed that subscribing to calendars fails if the calendar file is a little bigger (~4MB). It keeps spinning “Validating calendar resource…” and never finishes.
When replacing the .ics file with a small dummy file (containing only one event), subscribing and then switching back to the original, lager .ics file works fine.
I suspect this issue maybe related to Bug 112 as it also seems to be dependent on the file size or number of entries?!
It just takes some time… There are almost 10.000 events in your file, this is really large and the poor mobile phone CPU has to give its best. In the emulator (which uses my PC’s CPU), it just takes a few seconds, but when the CPU is slower, it will take much longer.
I absolutely agree that 1000s of events put a heavy burden on a mobile CPU, so that’s a kind of “worst case scenario”!
Nevertheless - you might take it as enhancement request - to subscribe to a new calendar feed, only a basic check of the file should be sufficient, no need to parse all events in the whole file. Later on, when the calendar synchronized for the first time, ICSDroid would have to parse the whole file anyway.
This would enhance the user experience (quickly subscribing to new calendar feeds) without impacting the quality (a calendar file, which is fine when accessing it the first time, might get invalid over time due to remote updates anyway).
Just my two cents…
Nevertheless - you might take it as enhancement request - to subscribe to a new calendar feed, only a basic check of the file should be sufficient, no need to parse all events in the whole file.
ICSdroid uses ical4j for parsing, and ical4j doesn’t have support that (as far as I have seen).
We could only just check for “BEGIN:VCALENDAR” or something like that when adding the calendar and hope that synchronization will be OK. But maybe this would be even more confusing for users because they have added a calendar, think it will be OK and then it doesn’t synchronize. I don’t know … but this could be possible. Would you like to create a merge request?
Sounds reasonable to me to look e.g. for a “BEGIN: VCALENDAR” and a “BEGIN: EVENT” as well as for a closing “END:VEVENT” and “END:VCALENDAR” as a basic validation. I think from a user perspective this should be fine, the subscription would be fast and as it can happen at any time that a once valid resource becomes invalid (maybe due to an error while the .ics file was created, or a failed file download, or…) I don’t see a drawback in validating the whole file only when synchronizing.