
Instapaper's Bookmarklet API request for Mobile Safari - aaronbrethorst
http://www.marco.org/1288715399
======
msbarnett
The absolute simplest way to get the Instapaper "Read Later" bookmark into
Mobile Safari is to add it to Safari on your desktop and then have iTunes sync
your bookmarks across to your iOS device.

~~~
twsted
I was suggesting the same thing. This is the way I have automagically found
the "Read Later" bookmarklet on my iOS devices.

------
mhw
"The best way to solve this problem is to eliminate the need for hacky
bookmarklets entirely: Add a proper registry of apps that can accept URLs from
Safari"

I disagree that this is the best way to solve the problem: it would restrict
availability of integration with Safari to native apps, leaving pure web-
hosted apps at a disadvantage. Why should every web-hosted app that handles
URLs have to produce an iPhone app just to lower the user-experience hurdle?
And bear in mind that the app won't have access to cookies set in Safari, so
the user will need to authenticate themselves twice - once in Safari, once in
the app.

I think the best solution would be one completely within Safari -
window.external.AddFavorite or something similar.

~~~
masklinn
> I think the best solution would be one completely within Safari -
> window.external.AddFavorite or something similar.

But then, what of native applications? And what if you _actually_ just want to
send a URL to an other native application? Also, AddFavorite (terrific casing
from the MSIE team here) with arbitrary JS?

Also, if the registry/send to method works with offline web applications, then
there is no restriction, the site "just" need to bundle a small offline webapp
able to handle the information (not sure if there is any specified way for the
OS/shell to send data to offline web applications though)

------
buddydvd
They can improve their current procedure by using this technique:
<http://joemaller.com/___>

1\. Append bookmarklet as suffix to a short URL 2\. Tell user to visit that
page and bookmark that URL 3\. Instruct user to edit that bookmark and delete
the prefix of that URL

This removes the step of asking user to copy the URL from a textbox. Plus, if
the user misses the step of removing the prefix portion of the URL, clicking
that bookmark will direct them to the instruction page.

But yeah, the process still stinks.

------
luigi
Two other solutions:

1\. Support Safari extensions in Mobile Safari. Users install it from the
gallery, get a nice little icon to tap in the toolbar.

2\. Support an HTML tag in the head, like web browsers do to detect feeds
today. Something like <link rel="bookmarklet
href="javascript:location.href...">. The browser would detect this, display
some sort of notification icon in the address bar, and give the user the
option to install it upon tap.

------
zacharypinter
This is the type of thing that concerned me about Mobile Safari and Flash.
It's not that I care so much about Flash being on the iPhone/iPad (it'd be
nice if it could work well though), it's that they're preventing all browser
plugins and extensions. HTML5 is great, but standards tend to become standards
by adopting the innovative third-party addons. Mobile Safari seems far too
locked down at this point.

Same goes for the iPad's Mail App. I'd love to use it, but until I can add my
own Archive button (I use MailActOn with OS X), it's far too tedious for
managing my inbox (just use it for skimming).

~~~
cmelbye
4.2 in November should include an "Archive" button for Gmail accounts.

~~~
zacharypinter
That's great news. Any idea if it'll work for IMAP/Exchange accounts that have
an Archive folder? For Gmail, I just use the web iPad interface (which, in my
opinion, is nicer than the Mail app).

------
dabeeeenster
"The best way to solve this problem is to eliminate the need for hacky
bookmarklets entirely:

Add a proper registry of apps that can accept URLs from Safari, recognized by
an Info.plist key, and add a “Share” or “Send To” panel to Safari that allows
users to easily send the current page’s URL to any capable apps."

This is what Android has been doing for a while. When I switched from the
iPhone to Android I realised how much this sort of message passing between
apps can improve the productivity of the device.

~~~
masklinn
> When I switched from the iPhone to Android I realised how much this sort of
> message passing between apps can improve the productivity of the device.

iPhone has always[0] supported message passing between apps, based on URI
schemes.

What it doesn't support is Safari sending URLs to third-party applications
registered against the `http` scheme (a `redispatch` feature, basically).

[0] Or for a very long time anyway, but I think it's been there since the
release of the original SDK.

------
aaronbrethorst
After I read this, I submitted a new enhancement request to Apple citing my
reasons for needing this feature and pointing them to Marco's blog post for
specific examples. Please do the same if you need this feature!

------
mcritz
How would dishonest people exploit Marco's proposed solution?

~~~
masklinn
Well Marco proposed a lot of solutions so:

# Add a proper registry of apps that can accept URLs from Safari, recognized
by an Info.plist key, and add a “Share” or “Send To” panel to Safari that
allows users to easily send the current page’s URL to any capable apps.

Not exploitable as far as I can see, this is a mecanism which already exists
through the scheme-based dispatch iOS already has (and uses). Safari would
simply be extended to dispatch to third-party applications registered against
the `http` scheme. Worst thing that can happen is boatloads of applications
claiming to handle `http` making for a piss-poor user experience.

As far as I'm concerned this would be the best solution by far (for that
issue): it only requires pretty minor changes (technically speaking, the UI/UX
issues are bigger), uses existing and well-understood mechanisms, and only
touches Safari.

# Add a public iOS API method for apps to prompt users to add a bookmark to
Mobile Safari [or] add a Safari-handled URL scheme that apps can invoke to
prompt users to add a bookmark

Would be OS-protected APIs, probably with some kind of warnings. Of course
users don't read warnings, but the exploitability level would still be pretty
low. This is also in-app, with mostly trusted stuff.

# A less-desirable (but still helpful) alternative would be to make the
Address field editable in the Add Bookmark sheet for new, unsaved bookmarks.
Currently, it’s only editable on edits of existing bookmarks, necessitating
many extra steps in this process.

Not exploitable, simply avoids wasting time but clutters the UI.

# Alternately, allowing window.location.href to be set to a javascript: URL,
and then having that be the logical URL added when someone taps Add Bookmark

Small privacy issue: because the user has no way to know whether what was
bookmarked was a regular URL or a bookmarklet, it can be any arbitrary
bookmarklet at any time and let the originally bookmarked site know what the
active page was when it got activated.

# window.external.AddFavorite(url, title)

From reading on the API, it seems fairly well protected (only accepts http,
https or ftp schemes, title is cleaned up thoroughly before registration) and
it prompts for addition instead of adding straight. I don't really see how you
could exploit that, on the other hand in that state it's useless for Marco's
purposes (can't set javascript:) and it lets you spam the user with infinite
requests for favs. Annoying but not downright dangerous.

Did I miss anything?

