Generic/pluggable task provider support (like CalendarContract/ContactsContract, but for tasks)

[timofurrer]

For calendars and contacts, DAVx5 syncs into Android's own providers (CalendarContract, ContactsContract). Since those are shared OS-level stores, any app can read the synced data just by asking for READ_CALENDAR/READ_CONTACTS. It doesn't matter which calendar or contacts app someone runs, and a new one doesn't need any cooperation from DAVx5 to work.

Tasks don't have an OS-level provider like that, so DAVx5 writes into a specific app's own content provider instead. Right now that list is hardcoded to three apps: OpenTasks, tasks.org and jtx Board. As far as I can tell, getting onto that list basically means working directly with the DAVx5 team (which is how jtx Board got added).

I'd like to build a small task app that syncs VTODO through DAVx5, but I don't want to require installing one of those three apps as a go-between, and I don't really want to have to coordinate a one-off addition just to get recognized either.

Would it be possible to make task provider detection more open, so any app implementing the existing TaskContract-style interface (or some documented permission/manifest declaration) gets picked up automatically, similar to how calendar apps just work through CalendarContract without being named anywhere in DAVx5's code?

Not sure how much work this would be given how provider compatibility is currently checked (permission-based vs an actual allowlist of packages), but happy to help test or talk through options if it's something you'd consider. Also saw #55 touches on related limitations in how task/journal providers are picked, might be worth looking at together.

[rfc2822]

From a DAVx⁵ perspective, it would be the best to come with its own tasks provider. Then any tasks that wants to support it could access it. (Or a simple UI could even be in-app, but currently we don't have that in scope.)

However that's all much work and requires a lot of internal changes – currently we're busy with doing important rewrites to bring the architecture to a point where we can finally think about new features.

For your use case, you could

• expose the dmfs TasksContract as supported by OpenTasks and tasks.org,
• or expose the jtx Board contract, and then
• fork DAVx5 and add your app to the TaskProvider list yourself (shouldn't be that much work).

(If you want your own contract for the content provider, it would be much more work in DAVx5 (new synctools storage + mapping implementations).)

You could then also create a PR for DAVx5 to add your app to the list.

[timofurrer]

@rfc2822 thanks for the quick response!

currently we're busy with doing important rewrites to bring the architecture to a point where we can finally think about new features.

Are you saying that this is a hard requirements to start implementing a tasks provider in DAVx⁵. I'm weighing my options here and especially if it's worth for me to contribute this.

I actually thought about the other options - what I didn't like (and stopped there) was that DAVx⁵ prompted me to install one of the supported apps right away then selecting them.

I'm also not really eager to implement yet another direct app support into DAVx⁵ - I think my time would be spent wiser on (helping to) implementing the tasks provider in DAVx⁵ directly.

[timofurrer]

FWIW: I've implemented a TasksProvider in the current main branch: #2750. It's a prototype, but working. I mostly wanted to verify how it could work and integrate with an app (I implemented a test app that uses the built-in tasks provider).