I use Carddav, caldav sync only if it support oneway sync from server to device.
I had already that often the problem that some apps change contact information and with two way sync all this changes will done also on the server without any real control. For example some apps like whatsup change the contact picture to an picture the user uploaded but this picture is often didn’t show the persons portrait. So I use a carddav and caldav server and change this information only through the webpage of this server. Then I regulary let a carddav, caldav sync tool download all information to my Android device. This way I will never get an destroid contact database.
May I ask you whether your sync tool will support one way sync as an option in the future? How does your tool sync contact pictures? Will they also synced in high quality?
DAVdroid synchronization is working fine, when I add a DAVdroid account by manually enter the URL and the user name (second option). I’d really like to profit from the automatic service discovery (only enter e-mail and password and let’s go!), but unfortunately this is not working.
I set up a radicale server behind and apache wsgi “proxy” and I set up correctly the SRV and TXT record for automatic discovery. the caldav and carddav url in my case is for now https://radicalewebserver/cal/. accessing the caldav server with curl works as expected. current-user-principal is https://radicalewebserver/cal/user/.
It seems to me that the automatic service discovery by only entering the email and password doesn’t do a preemptive authentication, but in my scenario the user needs to authenticate for successfully accessing https://radicalewebserver/cal/, what i need to get a valid current-user-principal.
https://tools.ietf.org/html/rfc6764#page-5 says To facilitate “context paths” that might differ from user to user, the server MAY require authentication when a client tries to access the “.well-known” URI (i.e., the server would return a 401 status response to the unauthenticated request from the client, then return the redirect response only after a successful authentication by the client).
So isn’t that something which should be implemented? Or am I doing something wrong?
Owncloud and Contact/carddav is really a sad story:
Beginning as a good alternative to Google/Apple Cloud it started a spiral downward after the maintainer of the contact app had left Owncloud community in April 2014. Some people from OC Core takes the pain to keep this worn-out horse more or less standing in the fast changing OC environment in the following months.
But in February 2015, when Owncloud version 8 was born, this old horse was outsourced and separated from the OC Core.
In Summer 2015 with contactplus a fresh alternative with long missed new features was entering the ballroom.
With the old contact app as a pain in the neck the prima ballerina contactplus was even nominated as a official replacement of the dead horse in autumn 2015. But it was a short dance as the maintainer of contactplus stepped out quite suddenly in November 2015.
So everybody with Owncloud is still “riding” on this worn-out horse called contact app - and desperately waiting for the carddav interface to be reintegrated again into the Core of OC. World premiere is expected for March 2016 with OC 9.0.
Why I write this long story in a DAVDroid forum?
Because during the last month DAVDroid suffer from this home-made problems of the OC carddav interface, especially with the new release of DAVDroid pointing out all the bugs of the OC Contact app. But it is always the bearer of bad news to be blamed with the problems.
So did I too, because it takes some time to realize the above mentioned OC context.
But nevertheless - and with regard to the subject of this forum item: I am still in favour of Owncloud!
It takes a lot of pain to find the correct patches for the current OC Contact App, but right now my OC Server is running very smoothly in combination with DAVDroid on several Android Clients syncing different address books of different users.
And with regard to the future of the OC carddav interface: there is a light at the end of the tunnel - ups - meaning the dawn…
Interesting idea. Does ownCloud generate such event summaries per language?
I do not know for sure…
I think owncloud persists soe meta data for the birthday event. But the VEVENT is generated for every request.
This way the calendar entries in the web are always shown in the locale of the page (browser locale)
Is it only for birthdays?
As far as I can tell: Yes
But owncloud is an open framework and even ‘contacts’ is an app now.
So there may well be other apps around, that do similar things 😞
I have been using DAVdroid for a long time (thanks for developing this very useful tool!), but I recently noticed that synchronization with my server had stopped working for over 2 months without any warning. The underlying issue was entirely my fault (the caldav server software was no longer up), but I was surprised that I didn’t have any warning from DAVdroid about the fact that sync had been broken for so long. You can notice this in the setting (which gives the date of the last successful sync), but you have to look for it to make sure.
I think it would be nice if DAVdroid notified the user if sync has been unable to complete since a long time (say, 1 week, but ideally a configurable delay).
DAVdroid is a really brilliant app, thank you for your outstanding work! This was the reason, why I didn’t hesitate to pay for the app (usually I use freeware).
I have a request for a little improvement:
I use DAVdroid to have more privacy and to keep all my contacts and my appointments on my own server.
The server is only accessible internally, so it woulde be a useful feature to have a triggered synchronisation when I am in my own LAN (triggered by the name of the WLAN).
We can’t update the F-Droid repository. That’s the job of F-Droid people. We don’t have any influence on that.
What we can do is to help the F-Droid people to get up-to-date information about the source code location etc.
Yes, of course I can put the organisation name in the right field, but this is not the point. Let’s asume I want to rename a displayname of contact to “AAA some name” or “ZZZ some name” to have it in my contact list where I want it. Another example: normally the persons in my contact list are named “firstname lastname” but for some contacts I decide to name them “lastname, firstname” to have them all in one place in the list. There is and will not be a contacts manager which could handle that without changing the displayname.
So the point is: this featurerequest is not for changing the displayname but for keep it like I want it and to get a workaround for Androids “feature” to change the dispayname for the rawContact (and contact).
To 2nd: I did not found one, but I’m open for suggestions.
So I have to disagree with you for your conclusion, that handling of the displayname is (only) in the scope of the contacts editor. Yes you are right, changing it is a editor thing, but keeping it is also a synchronising thing. (Because of Androids feature, to change it after every change).
Maybe I had to clearify, that there are TWO displayname fields, the one in the “data”-table (structuredName) and the one in the rawContacts-table. The one in the data-table would be synced fine by davDroid BUT the one in the rawContacts-table would be changed after the sync (by Android) and not restored / overwritten by DAVdroid.
In order to give you an update on this matter. We’re in contact with the Mirakel developers and sent them some suggestions that are needed to integrate sync compatibility into DAVdroid. So it will still take some time…
I know the source is on GitHub, but is there an issue tracker or any other development documentation for people who are interested in contributing?
You’re welcome discuss about issues here in the forum. At the moment, there’s no issue tracker because it has been (mis)used as a discussion and support platform (which clearly is not the purpose of an issue tracker). Also, we’ll probably move to another git hosting platform (Gitlab).
Unfortunately, there’s not much development documentation, but I try to add Javadoc (and tests) constantly.