Information for Developers to Make Their Apps Linkable (API Requirements for Compatibility with Hook)

This web page is for wise app-developers: those who would like their customers to be able to link the data of your app to anything they want.

Background information

Hook works with apps which have persistent documents, resources, or contexts which can be saved and opened or restored.

Hook works “out of the box” with many apps, using Hook’s default integration scripts. For other apps, we create “integration scripts” that communicate with the app.

Hook needs to be able to get the name of your app’s current resource, and a URL/ID for it. It needs to be able to open this resource using that URL/ID. We do not expect Hook to be able to get the name or URL/ID of an unsaved document.

API Requirements

Hook merely needs your app to provide an API to do the following.

Please note: Hook does not specify the specific API for you. You just need to provide the API. It could be via x-callback-url, AppleScript / JavaScript, a command line interface or something else that is generally available.

Using your API, Hook or its enthusiastic automation community will create software integration scripts that enable users, via Hook, to link the data of your apps with your API.

We just need:

  1. An API to get the URL or ID of the current resource. This API could also return the name of the resource.
  2. An API to get the name of the current resource. This could be the overloaded into the previous API.
  3. A means of opening a resource, given a URL or ID
  4. A way of creating a new resource in your app, given a particular name — for apps that enable creation of items.

1. Getting the current item’s URL(s) or identifier

Hook needs a method to get the URL(s) (address(s)) or ID of the current item. Depending on your app, “current item” (aka, “current resource”) may mean different things, such as the currently open document or object; or the currently selected item (object or file) in a list.

  • If your app transacts directly with files and the files can be accessed directly via the Finder Finder, then you should provide a method that returns the pathname, even if your app also has its own URL scheme.
  • If your app provides its own URL scheme for items, then provide a method to get the URL of the currently open item.
  • If your app has its own ID mechanism but not URL scheme, then at least provide a method that returns the ID of the current item. See opening items, below

The ID and URL must uniquely identify the resource, and it should be persistent. If the resource is renamed or moved, it shouldn’t affect the identifier or break the URL.

If the resources of your app have two different addresses (typically: a file path and a proprietary URL), then you can provide both addresses in a method that returns a complex return; or you may provide too different methods, one for each resource. The former is better in case there’s a delay between the method calls.

It is preferable for the API for getting the address(es) of the current item to also returns the name of the item, as described next.

1.1 Deep PDF linking

If yours is a PDF app, then it is very helpful to provide an API for getting the currently presented or selected page, and the top x and y coordinates of the selection (if any). The API should also specify the output parameter for the case where there is no selection. For instance, the x coordinate might be -1 in that case.

This information can be combined with the overall “get address” method. Or a separate API may be provided for it.

If your apps manage its own URLs, it is important to document your URL format such that apps like Hook can tell that two URLs refer to the same document, except that one URL has one set of in-file addresses, whereas the other refers to the same document but with different or no in-file parameters.

For examples of deep-linking of PDF APIs, see Deep PDF Links Take You Right Where You Need to Focus – Hook.

Douglas Englebart referred to this as “in-file addressability”.

1.2 Deep links in other apps

If your app represents data hierarchically, you may provide an API for other forms of deep linking. Ideally, for document-style apps, your URL scheme distinguishes the document from the address within the document (as web URLs typically do, with the # symbol indicating a fragment). Please clearly document your URL scheme and API.

2. Getting the current’ item’s name

You should also provide a method to get the name of the current item, as defined above.

As mentioned above, it is preferable if this is one of potentially many results of the same method as is used to get the address of the item (e.g., returning a markdown link). But it can be its own method.

3. Opening the resource based on its address or ID

Obviously, it must be possible to open or restore the resource with the URL or identifier your app returned, per above. If your app already has an existing URL scheme and the URL can just be opened, then you don’t need to do anything more.

If your app uses IDs rather than URLs or pathnames, then you may simply provide a method or x-callback-url to open the item given the ID.

3.1 Opening deep links

If your app supports deep links, then please provide an API for accessing the page and x/y coordinates on that page. This could be a separate method to scroll to the particular page number and x/y parameters on that page, or it could be built-into the URL or method for opening the entire document.

4. Creating new items

If your application supports the creation of new items and those items are files exposed on the Finder, then CogSci Apps (and other developers) can automatically create new documents as long as we have a copy of a blank template and we know its filename extension(s). No API is required for such app.

If your application supports the creation of other types of items, then please provide an API for creating new items. The API should normally accept a name as an input parameter. It should return the name of the created item, following the addressing guidelines above,, and optionally the name of the item (in case your app has modified the name due to some of its rules).

By returning the address of the new item, it will be possible for users to enjoy the tremendous benefits of the Hook to New function, where in one go Hook creates a new item and bidirectionally hooks it to a contextual item, while also bookmarking and potentially tagging both items.

You get extra points if your API also enables automation to:

  1. insert hypertext in the new item. Hook would then optionally insert a hyperlink back to the source directly into the new item (as it does for Apple Notes, Craft and Drafts, for example) or in the new item’s note field (e.g., as it does for OmniFocus).
  2. apply a tag to the new item (as Hook can optionally do with DEVONthink, Finder files and OmniFocus, for example).

Additional notes about URLs

If your software exposes the same data via a local app and via a web browser, it is important to ensure that third-party software can translate the URL received in the context of the app to the URL received in the context of a web browser. Using universal links may help.

It is important therefore for your web interface to expose in the address bar the URL of the current item. If the data is hierarchical, this should be reflected in the URL scheme or via an API, such that software can gauge the containment hierarchy. This will support deep-linking.

General API guidelines

Like any good API, your API should document any specific usage, parameter or condition restrictions. Please also document possible error conditions and their meaning. For instance , your “getAddress” API would have an error condition for the case where no item is currently open or selected. That information (error code) can then be passed on (translated) by Hook to the user.

Examples

For examples of how other apps have been integrated with Hook, and how Hook integration happens you can peruse the integration scripts in Hook itself. We recommend looking in particular at Hook’s integration with Craft , Drafts, OmniFocus and BBEdit.

We like showcasing great apps that integrate well with Hook, in our release notes, emails to customers, on our blog, on the Hook productivity forum, on social media and elsewhere.

Please don’t hesitate to contact us (hook@cogsciapps.com) if you have any questions. You can also ask questions directly on the Hook Productivity Forum to get our community talking about using your app with Hook.

What’s a Linkable App and Why Does Linkability Matter?

That question is addressed here.

We have mentioned AppleScript a lot in this document. However, an app can be linkable without supporting AppleScript. Hook can work with other APIs than AppleScript. For instance, the app might provide a command line interface for linking, which Hook could leverage. The key question is whether the app is truly linkable, which require automation for hyperlink described here.

By making your app linkable, you will be in the company of other great Linkable Mac Apps, and be better positioned to compete with them.

In this day and age. Consumers purchase many apps, and they need to be able to link their apps’ data to other apps. Otherwise, they will choose your competitor. And who can blame them?

Help Contents

Help > Integration :


00-integration-info-for-devs.txt –>

Hook Productivity App Newsletter

Sign-up to receive emails about Hook productivity app. Our emails sometimes include coupons for discounts on great Hook-linkable apps made by other developers.





 Marketing permission: I give my consent to to be in touch with me via email using the information I have provided in this form for the purpose of news, updates and marketing.

What to expect: If you wish to withdraw your consent and stop hearing from us, simply click the unsubscribe link at the bottom of every email we send or contact us at support@cogsciapps.com. We value and respect your personal data and privacy. To view our privacy policy, please visit our website. By submitting this form, you agree that we may process your information in accordance with these terms.