I’ll start by saying that I think NextCloud is a VERY polished system. It’s clear that a lot of thought went into the product, and I’m eager to use it more (and hopefully wean myself off of a few more Big Tech services).
I want to be extremely sensitive with asking this question for a few reasons:
I’m new to NextCloud and have only really played with it, at this point
I’ve only ever compiled (not written - just tweaked and compiled) a single Android app
I’m sure this has been asked before. Even though I searched, I couldn’t find where someone had
That said, why is the contact sync so convoluted? I have used dozens of apps that want to sync my contacts with their service (even though I never let them) such as Facebook, LinkedIn, Snapchat, Twitter, and even Signal. However, with NextCloud, I have to install DAVx5, it asks me to install another app called Tasks, I need to balance my phone on my chin for precisely 27 seconds, and if all goes well, it will sync my contacts. What on earth . . . ?
The only reason I can think of for the app to work this way is perhaps because part of the ethos of NextCloud is to be agnostic of things like Google services. While I respect this, I think it should also be an option for those who want it. At the very least, it certainly increases user adoption. Even as a highly-technical user, I was bummed to discover that contacts weren’t automatically synced via the app, and I can’t really recommend NextCloud to friends and family as-is. This should really be a checkbox in the app to enable the feature, not a multi-step, multi-app process.
Is there something I’m missing or a different reason to explain why everything else is so polished but this function is just . . . ick?
I’m not really sure what you want to tell us, that setting-up the Nextcloud synchronization is to complicated? Nextcloud relies on the CardDAV standard, which is used by many application and devices.
Unfortunately Android doesn’t support this protocol out-of-the-box, which is the reason why you need a 3rd-party app to handle the data in an open way on your phone. This guaranties that they’re not kept in a separate eco-system, like Facebook, and can be used in all apps on your device as if they are natively stored there.
Essentially, yes - that’s what I’m telling you (though I tried to be tactful about it). For the average user running the most dominant mobile platform in the world (which comprises 50-86% of all mobile devices depending on the source), the process will likely make them turn up their nose and give up. In all honesty, I spent a good 15 minutes fiddling with it, couldn’t get it to work, and shelved the whole thing. I have a BS in computer science and a MS in information systems, so if it was enough to frustrate me, it will absolutely frustrate the average user.
While I understand and appreciate that CardDAV is a standard used by many applications and devices including Nextcloud, I’d submit that for the sake of user adoption, perhaps a compromise, alternative, or simplification should be considered.
Again, I understand that Android doesn’t support CardDAV out-of-the-box, but it certainly does provide a contacts API that is used by every other app for Android. Sure, it’s proprietary, and many privacy-focused users prefer to avoid Google Play Services, but again - user adoption.
For the same reason that Nextcloud provides a fairly seamless integration for things like Outlook, I think it makes sense to provide support for something as basic as contact synchronization for Android. I don’t think this should be an “either/or” feature but rather a “both/and” compromise - for users that want to use CardDAV with the existing integration, provide that option, but for users who just want it to work seamlessly, perhaps consider what would be required to make that happen. Insisting that everything must be open source at the expense of usability and user adoption is the reason why GNU Hurd still doesn’t have a stable release after nearly 30 years of development, after all. Don’t be like GNU Hurd.
This is something that I have found as well. The ios app and andorid app should at least have simple settings that would set this up for the end user. Because it is not simple for a normal user to work that out on their own.
Before someone comes back with the inevitable response, “DAVx5 IS the connector app,” that’s not what the user is implying. They are suggesting that a connector app should exist that utilizes the Android/iOS contact APIs, stores contacts in the Android/iOS contact backend, and seamlessly syncs this info with Nextcloud without all of the additional steps of downloading something like DAVx5, setting it up, and trying to get it to work. For me, I could only get the single contact I created via Nextcloud and the Nextcloud app to sync - I couldn’t get all of the contacts in my core Android contact storage to sync. I’m sure I could figure it out, but it was a massive pain and would certainly turn off the average user in short order.
I did a little research. Unless I’m mistaken, the standard mechanism for accomplishing this on Android is using a SyncAdapter. Looking at the source, it looks like Nextcloud already uses SyncAdapter services for syncing files. It also uses the ContactsContract API call to map between the Android data store and the vCard format (part of the DAVx5 CardDAV bridge, I assume). Since these calls are already part of the app, I can’t imagine that there is any “it’s not FOSS” argument against using them.
Here’s a suggestion. It’s a bit gross, but it would work, it would support both standard CardDAV AND native Android syncing, and it would be more straightforward for the average user:
Implement an option in the app for using native SyncAdapter + ContactsContract + Authenticator services/API calls for users who wish to use it.
Add a server-side receiver to Nextcloud to communicate with the SyncAdapter implementation in the app (could be part of the Nextcloud core or as an app/extension).
Aside from communicating with the SyncAdapter, the server-side receiver would serve two purposes:
it would convert data from the SyncAdapter to vCard format and vice-versa.
it would provide a CardDAV client for communicating with the Nextcloud instance via localhost. (Suggestion: https://github.com/christian-putzke/CardDAV-PHP - it has been tested against ownCloud and SabreDAV according to the README).
There are several advantages to this approach:
Since Android doesn’t implement native CardDAV functionality, the complexity of implementing this protocol on Android (and/or relying on a third-party app to do so) and converting the data to vCard format is removed and offloaded server-side (where there are plenty of CardDAV libraries and clients available).
Support for native, vanilla CardDAV is maintained.
Support for native Android contact syncing is provided for those who want to use it and without breaking existing functionality of Nextcloud.
Thoughts? I think it’s a pretty reasonable compromise. I know I’m over here making demands from my high-horse without providing much in the way of development assistance, but again . . . I’ve only ever compiled a single Android app. I’m more of a sys-admin, not a developer.
I’d love to spin it up and try it . . . but my phone uses USB C, and I can’t find my USB C to USB A cable. Regardless, this app + a server-side receiver + a CardDAV client running server-side and connected to Nextcloud via localhost should be the basis for a proof-of-concept.
I’d like to point your attention on some issues:
A significant part of Nextcloud users would not use this possibility because they do not want to use Google services. Did you have a look at the recurring criticism of Nextcloud Talk android app, that depends from Google services for the notifications? This means that notifications are not available from users that download the app from F-Droid…
Another part of Nextcloud users are linked to big installations, so either they do not use the app or they have an internal help-desk that helps solving the one time issue
Nextcloud android apps try to be modular (main app for files, DAVx5, Nextcloud Talk, Nextcloud Notes, Bookmarks, Deck) and / or to support the standards to allow other apps to function
I do not want to say that the above points make your proposal wrong, yet maybe they make the issue less problematic and more cumbersome to solve.
Consider for example if the revised app that you propose should include some components that are not allowed in the F-droid repository; this would mean either to have two different app versions in parallel or to lose F-droid as a distribution channel. I suspect that the Nextcloud android app has a lot of downloads via F-droid
All good points, and I appreciate the feedback and constructive criticism.
From my perspective, there’s a pretty big flaw in your argument: “A significant part of Nextcloud users would not use this possibility because they do not want to use Google services.” Right - CURRENT Nextcloud users. Would it be reasonable to suggest that Nextcloud might attract and gain users if it leveraged Google services (very selectively and with the option disabled by default) in order to make the service more accessible?
With very few exceptions, every Android phone that is sold in stores comes with Google’s services installed by default, and a very small percentage of people are privacy-aware enough to either install a custom ROM or disable the services as much as possible. Most people use the services without question. Many people are beginning to distrust Google and are searching for alternatives, but they are likely not tech-savvy enough to want to go through the hassles required to get something as simple as contact syncing set up. For those people (and I’d submit that there are a lot of them), this sort of functionality would be incredibly beneficial and would likely help increase user adoption and retention.
*EDIT: Just to reemphasize, I’m not suggesting that the current integration be REPLACED by native Android contact syncing. Rather, I’m suggesting that both options should exist and be made available. Both/and, not either/or.
I had a few other thoughts in response to the previous comment. I don’t think that my proposed solution would cause problems for F-Droid or users wanting to avoid Google services because the required APIs (ContactsContract, SyncAdapter, and Authenticator) are all already part of the core Nextcloud app. Unless those APIs are already violating some F-Droid or FOSS policy, adding this as an optional feature/functionality alongside CardDAV support shouldn’t be a problem.
I tried to get the ContactsDemo app I mentioned previously to build and work. While I managed to make it build and run, I couldn’t figure out how the SyncAdapter works (nor where it was supposed to be sending contact data so I could build a server-side listener). I tried a few other apps but had no real success. Server-side PHP is my thing, and I’d be happy to help with that, but Android apps are outside of my expertise.
To recap, my proposed solution would be as follows:
Implement an optional ContactsContract + SyncAdapter + Authenticator functionality in the Android app.
Add a server-side endpoint to:
Communicate with the SyncAdapter
Convert data from the SyncAdapter to vCard/CardDAV format (and vice-versa)
Provide a CardDAV client to communicate with the Nextcloud instance via localhost
Thoughts? Does anyone have the necessary Android experience to help set up a PoC since my efforts to do so were a little less than successful?
DAVx5 already uses the standard Android contact (and calendar) backend, it just stores it under a separate account and addressbook from the Google contacts. You have to move the contacts from the google addressbook to the Nextcloud addressbook in order to get it to sync (edit the contact and select the DAVx5 nextcloud account). This is the standard workflow in Android and Cardav addressbooks, Is it convenient? not really but that’s how they are designed.
Perhaps you could request the DAVx5 devs add a sync between addressbooks option?
I doubt the Nextcloud devs will want to integrate dav functionality into the android app as if you look at the DAVx5 development it’s actually very complicated work. As for easy set-up a way to have it automatically set-up an account in DAVx5 from the Nextcloud app would be a nice addition.
Perhaps I misunderstand how SyncAdapters work (probably). Are they not two way? How does the Outlook integration provided by Nextcloud work? I would suspect that it syncs contacts back to the phone when they are updated in Outlook. Maybe the Nextcloud Outlook integration doesn’t update the Android contact store, but I’d have to bet that other apps that provide Outlook integrations are two-way between Outlook and Android’s native contact store.
My assumption was that the SyncAdapter would send changes to a registered server endpoint, and the endpoint would make changes to its data store. If the server’s data changed, it would send them to the client, and the client SyncAdapter would update the data. Is that not how that works?
I missed the Outlook part, are you talking about the Outlook email app or the desktop application? Because on android there is no integration outside the system contact sharing.
For the android application Outlook may just be storing you contacts separately from the android contact store
To use only the Outlook Contacts you need to go into Contacts Setting on the phone and Check the box to show only the Exchange Contacts. They will show up in Android Contacts and also in Outlook when you click the Person Icon. You can not edit or delete Contacts on the phone and have it sync to the desktop to my knowledge, this needs to be fixed.
For the desktop application you may find it’s just pointing to the wrong addressbook have a poke in the settings and see where it’s looking for contacts, I know when I used it a few years ago you could specify an addressbook. Also keep in mind the auto-type contacts in Outlook are not *real* contacts and won’t be synced. You need to register a new contact specifically to get it synced
It is two way and should sync, but as Dav is a pull service there is always a delay in changes made, there is no method to notify your phone of changes short of triggering a sync. I think DAVx5 defaults to once every 2 hours to save battery power. Outlook desktop should sync immediately on changes though
Interesting. So, Outlook makes a copy of the Android contacts for its internal address book on the device and then syncs using that? I’m sure there are reasons for that, but it seems . . . odd. I have a hard time believing that the only apps that sync with and update the Android contact store are Google apps. I just checked, and there are CRUD APIs for the Android contact store. Even if an app needed to make its own copy of the address book for ease of use, is there any reason that an app couldn’t make updates to the main Android contact store based on changes as a result of a SyncAdapter?
If I’m not on the same page (or in a totally different chapter), my apologies.
A quick google search shows the Outlook app has several issues syncing contacts properly, all with separate proposed fixes/workarounds. I have lots of non-google apps that play nicely with DAVx5 such as whatsapp, signal, facebook, K9 email and so on, sync between all of them is instantaneous.
Sorry sounds very much like you’ve hit a bug in the outlook app
I don’t want to hold up Outlook as a “good” example - any integration with Outlook has been pretty terrible, historically. I was just using it as “an” example.
Let’s use K9. Does it reference the Android contact store to pull and manage contacts?
Yep K9 uses the contact store flawlessly. I won’t lie it’s a bit ugly, I’ve been meaning to look at fairmail witch looks to be a fork of k9 that’s had a fair amount of ux work done on it. Might be worth a look
My understanding is that DAVx5 is a syncadapter and is what “adapts” webdav communications into an android addressbook device side.
Nextcloud strictly serves the addressbook through the webdav communication standard using saberdav. The android address book is a storage implementation not a communication method. As you can see from the diagram below doing it this way keeps the Nextcloud server standard and generic where as individual clients are expected to adapt the data as needed. The same happens with the desktop Outlook plugin, it syncs using webdav and adapts the data to be stored in Outlook.
Instead of reinventing the wheel you could also run a Z-Push server that interacts with your Nextcloud server and provides ActiveSync support for all kinds of clients that support this (Android and Outlook have native support for it for example). Here is a short howto on how to set it up:
