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.
@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)?
It seems that the location provided does not work. Maybe some kind of weird redirect or so. Also keep in mind that Google answers very slow on some .ics requests - I had this once myself. Maybe just try again?
@mnalis you're welcome!
Thanks for sharing your solution. It is always good to write it here so other are pointed to a possible solution. However we've not had a similar one yet (afaik). Maybe the Android storage was somehow broken, and was re-initialized. At least you found a way how it works again
If you're looking for a real sync solution you may try our app DAVdroid. You need to set up a CalDAV server first. Then you will be able to synchronize your calendars in two way. DAVdroid is open source and it published under GPL and we also sell it in the Google Play store, because it was and is very hard work to write and maintain it.
first of all, thanks for creating (and especially maintaining) all of these applications here. Good to see quality products from an Austrian company.
I am using ICSdroid to sync calendars from teamup which is working just fine. However, once a day one of the ical feeds fail to synchronize properly (which is non reproducable), so basically there's just a error notification without any real impact. A suggestion to improve that would be
a) automatically close a notification if the repeated attempt succeeds
b) add an option, to just show a notification after X failed attempts. So for X=3, it should not show an error after the first or second attempt, but after the third failed attempt. It would add some delay in case of a real error, but it would prevent random non-reproducable errors.
Seems like the URL property is not used as a general-purpose field, but its purpose is:
This property may be used to convey a location where a more dynamic rendition of the calendar information can be found.
(RFC 7986 5.5 URL property)
Interesting - I think Office 365 had some sort of tempoprary export bug, as the appointments have all corrected themselves, and the TZID has changed for all appointments:
DTSTART;TZID=AUS Eastern Standard Time:20160714T120000
DTEND;TZID=AUS Eastern Standard Time:20160714T130000
Thanks @kralo for checking the iCalendar. The default type of DTSTART is indeed DATE-TIME, so @a3nm if you want to specify a DATE, use VALUE=DATE. If you didn't generate the iCalendar yourself, please contact the one who generated it (and provide this thread as reference).