We could also not find specification for this. Here’s our ticket about the issue for reference. So since we changed to the leading #, you might as well stay with it. However, if you want DAVdroid to be more robust, you might as well make the # optional.
DAVdroid fetches the CTag for the collection on every sync – the same request could be used to fetch color, title and description again, too.
Given that we seem to know what is going on ("#" vs no “#”) it seems that debugging is no longer required. So if possible I’d avoid having to go through the cycle.
I think this can be closed.
Thanks for the hint, closing
I’m starting to use DAVDroid and wanted to know: How is the current behavior regarding color sync? Does it still download the colors at setup time?
Does it still download the colors at setup time?
Yes: At the moment, colors are only fetched here from the PROPFIND response, then put into ServerInfo.ResourceInfo and then later used when creating the LocalCollections.
I suppose a manually triggered re-discovery of all collections would fix this issue (as well as add the ability to sync new collections). See CalDAV-Sync for what I mean.
I suppose a manually triggered re-discovery of all collections would fix this issue (as well as add the ability to sync new collections).
Please follow up in in #219 and #243 for that.
See CalDAV-Sync for what I mean.
As far as I know, CalDAV-Sync is not open-source? So unfortunately, I can’t see how it’s handled there.
As far as I know, CalDAV-Sync is not open-source? So unfortunately, I can’t see how it’s handled there.
I meant how it is implemented UI-wise: Part of collection discovery, which doesn’t happen regularly but has to be triggered manually.
I meant how it is implemented UI-wise: Part of collection discovery, which doesn’t happen regularly but has to be triggered manually.
Ah ok, this is #219. Please follow up there.
I don’t know when this will be done, at the moment I’m happy about tasks sync 
