Add "publicly-accessible" receiver

[NatKarmios]

I'm a big fan of Automate, and I (along with many others, it seems) would love to be able to use it - or Tasker, etc. - with Orgzly.

In the spirit of being the change I want to see the world, I've got to work on implementing a publicly-accessible intent receiver to this end :)

Just a few issues relevant to this (most of which are more or less already implemented):

• #299
• #373
• #435
• #784
• #844

These "endpoints" (i.e. actions) have currently been implemented, and tested to be working on an emulated Pixel 4:

• GET_BOOKS
• GET_SAVED_SEARCHES
• GET_NOTE
• ADD_NOTE
• EDIT_NOTE
• REFILE_NOTE / REFILE_NOTES
• MOVE_NOTE / MOVE_NOTES
• DELETE_NOTE / DELETE_NOTES
• ADD_SAVED_SEARCH
• EDIT_SAVED_SEARCH
• MOVE_SAVED_SEARCH
• DELETE_SAVED_SEARCH
• SEARCH (runs the same kind of query a saved search would use, and returns the result)
• GET_WIDETS
• SET_WIDGET (sets the saved search that a widget displays)

Any instance where a note or multiple notes are selected, both note IDs and book/path combos are supported.

P.S.: Might I compliment you on your implementation of the DataRepository - developing this was a breeze because of it!

[NatKarmios]

I've pushed a bunch more actions; see the edited main post

[lytex]

There isn't already a search Intent using com.orgzly.intent.extra.QUERY_STRING as mentioned in #784?

am start -a android.intent.action.MAIN -n com.orgzly/com.orgzly.android.ui.main.MainActivity \ 
--es "com.orgzly.intent.extra.QUERY_STRING" "search term" --activity-clear-task

Anyway, thank you for all the effort!

[NatKarmios]

There isn't already a search Intent using com.orgzly.intent.extra.QUERY_STRING as mentioned in #784?

am start -a android.intent.action.MAIN -n com.orgzly/com.orgzly.android.ui.main.MainActivity \ 
--es "com.orgzly.intent.extra.QUERY_STRING" "search term" --activity-clear-task

Anyway, thank you for all the effort!

Thanks for getting back to me!

R.E. queries, this is a different kind of query; the QUERY_STRING intent you refer to opens Orgzly in the foreground with the specified search (from what I understand, at least). In contrast, the query intent I've added returns all the relevant note data in JSON format via an ordered broadcast, so Automate (or Tasker, etc.) can use this data in further computation.

[TeMPOraL]

Great work, @NatKarmios! I was about to start working on this myself (I desperately need to integrate Orgzly with Tasker), so I'm grateful to see the work has already been done!

Is there any way to help to fast-track merging in these changes? This is the missing bit to make Orgzly a fully-featured Emacs companion for org-based productivity systems, allowing users to customize the workflow to individual needs, without burdening Orgzly itself with supporting a zillion switches and integrations.

[NatKarmios]

Just to bump this (@nevenz), I've rebased on master and spruced it up a little more. I'm already getting a lot of use out of it, it'd be awesome if others could too 😁

[lytex]

Hey, I would like to try this out (I've compiled the app from your branch) but I don't know how is supposed to work

For example, in this editNote function, I see there is a note id and a note content but I don't know what's that noteView.note.id. Is it the ID / CUSTOM_ID property of the note? An internal id used by orgzly?

[NatKarmios]

It's an internal ID used by Orgzly, useful if you're editing a note based on a previous query.

If you take a look at getNote(), you can specify a note in 3 ways:

• The aforementioned internal ID
• The "path" to the note; say you have a heading Inner under a heading Outer, in book MyBook, the path would be "MyBook/Outer/Inner"
• An Orgzly search query, like you'd use in saved searches; errors if more than one note is returned (though maybe this should be configurable).

[NatKarmios]

For anyone still holding their breath for these changes, I've just popped a PR for it on the orgzly-android-revived repo: https://github.com/orgzly-revived/orgzly-android-revived/pull/112