Shortcuts.app integration

[adam-jan-82]

Hi,

I would like to suggest having Keka use app intents. This would allow for seamless integration with Shortcuts.app on both MacOS and iOS as well as with Siri, and potentially even in Spotlight search. I believe this would be great as it would significantly extend the use of Keka into many different types of automation.

I know there is a GitHub Issue about this already (#1267), but I thought it would be more appropriate to continue the discussion here. On MacOs there is an option to use CLI commands. However, it is not working seamlessly in Shortcuts.app on MacOS and is completely impossible on iOS (no way to run binaries directly).

@aonez, is that something that realistically could be added to this already fantastic project to make it even better?

[aonez]

Hi @adam-jan-82,

I took the day to investigate this issue. Lots to do still, but I have a concept already working both on iOS and macOS. Note on macOS will be implemented in the new version of Keka, with a beta release date still TBD.

I'm glad to see this will be way easier than the current Actions that are already available for iOS.

[adam-jan-82]

This is brilliant! Thank you very much for taking the interest and making this effort. As always, the UI looks terrific!

I agree that integration with Shortcuts has much bigger customization potential than the current Actions. Especially, when the shortcut has "Show in Share Sheet" enabled, as this makes it directly visible in any app where the "Share" action is available.

I have been thinking about the automation a little more and realized that the Shortcuts.app has a memory and time limits when running sub-tasks within a shortcut. It is likely that compression/decompression of large files might result in the "The operation took too long to complete" error or even crash the Shortcuts.app (on iOS). A potential workaround might be to expose x-callback urls for Keka. This could work like this:

1. In Shortcuts, the Open X-Callback URL action points to Keka via an url - e.g. keka://folder/filename.ext?action=compress&format=7z&password=123
2. This switches focus of the automation to Keka completely preventing termination of the Shortcuts task. Now Keka can take as much time and memory as needed to complete the task.
3. When invoking the Open X-Callback URL action the Shortcuts.app (or any other app supporting the x-callback scheme) also sends three callback urls: "x-success", "x-error", and "x-cancel". Depending on the outcome, Keka should call a specific url when it stops or completes its task.
4. All of these urls switch the focus back to the Shorcuts.app. Subsequent execution of any further actions in the shortcut can be made dependent on the outcome of the task done by Keka. It would be even possible for Keka to send back some additional relevant info by adding parameters to the callback url - just a nice addition that can be added at some later stage.

Along with the app intents, support for thex-callback urls would complete everything anyone can ever want from an app on MacOS/iOS. Keka is already a true Swiss Army knife of archiving apps, but this would make its utility endless through direct integrations with more than a hundred of other apps that support x-callbacks (list here and another one). It would also allow for direct passing of very finely tailored settings to Keka without additional UI as well as alleviate with any time/memory limits of the Shortcuts.app

I do realize that it would most probably take some serious code changes. Just an idea 😉

[aonez]

Sounds very interesting. Keka for iOS already has the keka:// handler (without any actions but open it), feels right to implement the actions using this protocol.

[aonez]

@adam-jan-82 I'm doing some test with X-Callback. Using Shortcuts on iOS I'm unable to pass the file path, do you have any experience on that one? File Path does not send a proper path. The same does not happen on macOS.

[adam-jan-82]

Apologies for a late reply. You are right that file paths on iOS are quite peculiar. This is because of the global sandboxing that limits access to folders other than the local folder of each app. Luckily, the limitations are not as tight as they used to be several iOS versions ago.

For "File" and "Select File" the Shortcuts.app returns "On my iPhone" or "On my iPad" instead of the actual full path. What is more, it does not return the file extension! One has to add it as a separate variable of the File > File extension type. To make things even more complicated, for .txt files the "File" action (as well as input from the Share Sheet) returns file contents instead of the path. Apparently, it is a well known bug in more recent iOS versions that for some reason does not happen if "Select File" action is used.

For all these reasons, some app developers came up with independent ways of solving the path problem:

1. Actions.app (https://github.com/sindresorhus/Actions)
   Adds a bunch of actions to the Shortcuts.app, including the Get File Path action which exposes the full path, e.g. /private/var/mobile/Containers/.... It is open source and I tired to quickly scan the source, but did not manage to find relevant code last weekend. I am sure it is somewhere there.

2. Scriptable.app (https://scriptable.app/)
   Uses so called "bookmarks" to get and store the filepath. It has a Shortcuts.app action called Create File Bookmark that manages an internal (inside the app) dictionary of full paths to solve this very problem. If using Scriptable, the easiest way to get the full path, and an alternative to the Create File Bokkmark action, is to include a Shortcut.app action Run Inline Script that copies the path to clipboard:

   let files = await DocumentPicker.open(); Pasteboard.copyString(files[0]);

I wish I could provide more info, but unfortunately my knowledge of Swift is very basic. However, Sindre Sorhus (Actions) and Simon Støvring (Scriptable) are both fantastic developers who might be able to offer some additional insights. From my experience, it is often easier to access files inside the local folder of each app and iCloud/Dropbox/etc. folders than the internal file system. I do realize that ideally we should be able to use the automation for all files, not only ones in these folders. This is why, long term, you may want to implement own Shortcuts.app action to simply get the full file path. Also, I suppose, it it is important to do it dynamically because the UUIDs inside the file path are refreshed by the iOS from time to time.

[aonez]

Thanks a lot for all the info Adam, very helpful.

the Get File Path action which exposes the full path

That's a good workaround. Most probably will stick with this for now and probably will implement the URL encoding on it so there's one less step. Still will need to figure out file access issues though.