Have organice show up as a share target on Android

[branch14]

...preferably while also using a Capture Template.

Here is a blog post that explains Android share targets in WPAs in some detail:

https://chodounsky.net/2019/03/24/progressive-web-application-as-a-share-option-in-android/

[munen]

@branch14 That sounds like a great thing! I did it for iOS (using the shortcuts app). Since I don't have an Android phone and cannot test, I'd be the wrong person to do this. Would you be interested in taking up this issue?

[branch14]

Sure... given that I find time to do so. :)

[munen]

Sweet!

So I’ll assign it to you and add a low prio tag. It’s mostly up to you when/if this comes(;

[dotcs]

@munen I have tried to add support for webshare. Please see #138 for the current implementation.

In principle webshare does work. Sharing the GitHub repository website to organice does currently end up in the following page:

I wanted to ask how I can proceed from here. I do have a proposal and would kindly ask you to think it through:

I think we could store the information from the webshare dialog in memory and give the user an UI element to add the content to a org document. The logic could be create a new sibling with the content from the webshare memory. We could then use the renderShare() function to just copy the content to the memory. It would serve as a middleware to copy the content to memory. After that we just redirect the user to the normal workflow, which would for example open the last file in which the user was active. If the webshare memory is not empty we should show an UI element that adds a sibling to the currently selected item (or if none is selected place a new item at the bottom).

If available I would use title as the headline, text and link as the description. If title is not available I would use text or link as the title or we could fallback to a default title such as "Shared element" or so. Currently Chrome does send URLs as text which is a known issue. We have to see if this is problematic and requires some logic on our side.

Since you know organice best I would kindly ask for help. Can you give me some hints how you would do it and where to continue from here? Thanks in advance!

[munen]

Hi @dotcs

Thank you for picking up this issue! @branch14 is very happy^^

As for the UX on how to proceed, I see two valid options:

1. Since it duplicates functionality of bookmarklets, do it analogous to how bookmarklets work. (Of course the UX of native share is much better than the manual integration of bookmarklets!)
2. Open a capture dialog analogous to a capture template

Here's doc on how bookmarklets work atm:

• Prose and code example: https://github.com/200ok-ch/organice#bookmarklets
• Screencast: https://github.com/200ok-ch/organice/wiki#bookmarklets-demo

[dotcs]

@munen Thanks for your feedback and the reference to #142. I'm quite sure that I don't find the time to continue my work on this issue over Christmas. But I'll continue to work on it as soon as I find some time. I think the feedback you gave will boost the work, so thanks again.

Merry Christmas to everybody! :)

[munen]

@dotcs Merry Christmas to you, too :christmas_tree: :santa:

Have a great time and enjoy the holidays^^

[aspiers]

I've looked into this a bit, and I think @munen's option 2 (Open a capture dialog analogous to a capture template) is probably the best way to go.

In fact I'm not sure option 1 is even feasible, since each bookmarklet specifies a capture template, whereas even if the Web Share Target API allows multiple share targets, we'd need one for each capture template. And since capture templates are determined at run-time by the user, that would mean we'd need a dynamically changing PWA manifest. This is theoretically possible, e.g.

• https://stackoverflow.com/questions/57022591/how-to-create-pwa-manifest-json-dynamic
• https://medium.com/@alshakero/how-to-setup-your-web-app-manifest-dynamically-using-javascript-f7fbee899a61
• https://medium.com/@rajathans/dynamic-pwa-manifest-using-javascript-and-rest-api-a23d132de7d6

but I don't know how reliable it is - e.g. when would it get refreshed on the device? Could we force a refresh every time the user adds / deletes / modifies a capture template?

In any case, if the user had 10 capture templates, having a share target for each would really clutter the share popup, so I think it's better to have a single target which directs to a route in the app which prompts for which template to use. One extra tap seems worth the usability trade-off to me. Thoughts?

If we're agreed, I can take a stab at this. The next question would be - do we really need a dedicated capture modal just for this, or can we just reuse the existing one when the user taps on the plus icon at the bottom right?

[munen]

Thoughts?

Sounds completely reasonable! It's the way that Emacs does it (I accidentally have the theoretical 10 capture templates that you mentioned^^) and I see all the reasons you mentioned why it should work 'the same' in organice.

If we're agreed, I can take a stab at this.

That would be great!

The next question would be - do we really need a dedicated capture modal just for this, or can we just reuse the existing one when the user taps on the plus icon at the bottom right?

If possible, it would be great to re-use the existing ones. If I'd be working on this, I'd think about adding routing capabilities to these modals, so that they can be easily linked to from different parts of the app. I don't know if that's strictly necessary to re-use them, likely it's not, but it might make things easier. I've done the same with quite a few other views that I've touched in the past (agenda, settings, etc). At some point, it would be great if all views would be routable (https://github.com/200ok-ch/organice/issues/26). But I'm deviating.

To reiterate, unless you see a blocker, I'd try reusing the existing modals. If they don't work (for some reason), then maybe a new kind of generic modal is required that replaces the current ones.

In any case, looking forward to this feature^^ Good luck and enjoy working on it!

[aspiers]

Thanks for the quick reply! In this case the existing modal does need to be routable, since the share target in the manifest is defined as a URL path (and obviously knows nothing about React state). I'm imagining that should be fairly easy to do.

[munen]

Maybe a quick heads-up on the current implementation:

1. In the root component App.js, the application checks if there's a captureTemplateName in the URL (which would be provided from the bookmarklet).

• If it's set, then a global marker in redux is set to remember it
• The code is here: https://github.com/200ok-ch/organice/blob/master/src/App.js#L91-L116

2. When the OrgFile component is rendered, it's checked if this global marker is set (code: https://github.com/200ok-ch/organice/blob/master/src/components/OrgFile/index.js#L119-L121)

• If it is, then the relevant action is triggered

Tbh, it's probably not the most idiomatic way - and it wouldn't scale well if more stuff would be put in the URL like that.

Adding proper routing would likely be a huge benefit here(;

[munen]

Ah, I forgot the pro: The bookmarklets work through query parameters already - so they are triggered by the URL. Some 'kind of routing' is in place(;

[schoettl]

I'm happy to see progress here! I stumbled upon a kind-of use case yesterday:

I want to convince my colleague to use Orgmode as his task planner. What's missing for him is the ability to get sketches (i.e. drawings) from his iPad linked to a task.

Of course, it depends on the app he is using for sketches/notes. Maybe his app allows to share a URL (to see the sketch online) or the URI to the file. In the latter case, the capture template could [[...]]-link to the URI and we could later implement an open mechanism for URIs that start an (Android) intent to open the original app. Just my thoughts :)

[aspiers]

In case it's relevant, it looks like How Chrome handles updates to the web app manifest has some useful info, and maybe Document how other browsers handle web app manifest updates · Issue #4038 · GoogleChrome/web.dev will accumulate some too.

[aspiers]

FWIW, someone has hacked up similar functionality using the following flow: Autoshare -> Tasker -> Termux -> Org Protocol -> Org Capture.

[munen]

@aspiers Thanks for the link and thanks for getting involved in the reddit thread with a link to organice :pray: :rocket: