There's multiple ways in which I can imagine this working on Android.

1. We could query the system for share targets, fill the AlternativesModel with the results and use the existing Qt Quick UI
2. We create a new ShareDialog thing that opens the native share dialog on Android or our own implementation otherwise

1. has the advantage of more flexibility. It could also power the widgets-based menu or custom implementations
2. is a more ready-made solution that is more aligned with what other Android apps have. Also it could support other platform that have native share dialog

Those options are not mutually exclusive though

Proof of concept for 2): https://invent.kde.org/nicolasfella/sharetest

I'm usure where to put it. It's on a higher abstraction level than purpose. On Android Purpose isn't used at all in it and with the current dependencies Purpose is a pain to build on Android. Therefore I'd like to avoid needing to build purpose when building it for Android. One way to do this is having it in the purpose repo and ifdefing everything else out on Android. Another possibility would be having it in another (new?) repo

Isn't this exactly the platform abstraction vs. platform implementation conflict? Ie. can (or should) Purpose cover both sides of this? If not, we probably want something separate doing the platform abstraction, with Purpose providing the implementation on the Plasma platform (and others not having their own implementation, probably).

One way to do this is having it in the purpose repo and ifdefing everything else out on Android.

I think this would be the way forward. We should probably also deprecate most of the existing QML public API (and move it to a private internal api) and instead abstract everything inside a QQC2.Action and QQC2.MenuItem, similarly to how this is done in the QtWidget part of Purpose.

This would make it possible to have an unified handling for sharing stuff from QML and also very easy to use. Instead of that we currently have, that is depending on the app very different. I started working on the action-based approach here: https://invent.kde.org/graphics/koko/-/merge_requests/103. It doesn't include yet the Android part but from an API user point of view, this is very easy to use.

One 'disadvantage' is that this makes Purpose depend on Kirigami and KNotifications on Linux. I'm not sure this is a real problem considering the current state dependency wise of Purpose.

One 'disadvantage' is that this makes Purpose depend on Kirigami and KNotifications on Linux. I'm not sure this is a real problem considering the current state dependency wise of Purpose.

Purpose already directly depends on KNotifications and Kirigami

One idea that came up in the past was a Job-based API, i.e. something like ShareFileJob. This way the API would be agnostic of the actual UI and implementation. We could still have an action-based UI on top of that. We also could allow to customize the UI parts that are done as part of the execution using the UIDelegate pattern we have e.g. in KIO jobs

> One 'disadvantage' is that this makes Purpose depend on Kirigami and KNotifications on Linux. I'm not sure this is a real problem considering the current state dependency wise of Purpose.

Purpose already directly depends on KNotifications and Kirigami

Oh nice, not sure why I was under the impression Purpose wasn't using Kirigami yet.

One idea that came up in the past was a Job-based API, i.e. something like ShareFileJob. This way the API would be agnostic of the actual UI and implementation. We could still have an action-based UI on top of that. We also could allow to customize the UI parts that are done as part of the execution using the UIDelegate pattern we have e.g. in KIO jobs

I'm not sure having a UI agnostic job is a good idea. A Job+UIDelegate sounds like something hard to represent as a Kirigami.Action with sub-actions since we need the model. This pattern sounds more adapted to poping a dialog. Shall I try to move my code from Koko to purpose, add the android support using your POC and then open the corresponding MRs for NeoChat and Koko. It's probably easier to review APIs in a MR.

Before we further discuss API for this I would like to discuss https://invent.kde.org/frameworks/purpose/-/issues/1