Posts tagged with "iOS"

View Mac App Store Links On iOS→

I don’t like how iOS devices can’t preview the contents of an iTunes link for a Mac App Store app (shown in the screenshot above on the left). While I (partially) understand the limitation from an infrastructure standpoint, I still think “incompatible” App Store pages should at least display text, screenshots, and a link back to the developer’s website without a Buy button.

There are solutions to preview a Mac App Store link on iOS. As far as browsers go, you can “Request Desktop Site” in Chrome for iOS and choose a different user agent in iCab Mobile (my two favorite third-party browsers). Chrome is my go-to browser these days, and I like how the feature is limited to single tabs, rather than the entire app.

Thanks to @AppleSpotlight, I’ve also found a non-browser app to achieve the same functionality and also a bit more. Desktop Apps lets you browse the Mac App Store from an iPhone or iPad (the app is Universal and free with ads). You can view the Top Free/Paid/Grossing apps, categories, and you can search for a specific app. You can open an app’s page, view screenshots, share a link via Email, Twitter, or Facebook (with native iOS integration), and even select text displayed as a description. Unfortunately, the app doesn’t fetch additional information like Developer Website, ratings and reviews, and there’s no URL scheme to easily turn itunes.apple.com links into URLs for the app (like Documents does for Safari).

Desktop Apps’ graphics aren’t entirely Retina-ready: the app is optimized for the iPhone 5, and two out of five tab bar icons are Retina-ready, but three of them aren’t – just like the icons of the Mac App Store apps. It’s a strange mix of fuzzy and crisp graphics. Desktop Apps has a $0.99 in-app purchase to remove ads; if you’re really into the idea of browsing the Mac App Store from iOS, go ahead and unlock it. Otherwise, I think you’ll be fine using the free version alongside Google Chrome.

Permalink

iOS Automation and Workflows with Drafts

The latest update to Drafts – a “quick note capturing” app that I’ve covered several times on MacStories – adds a series of features aimed at increasing the possibilities of workflows automation on iOS devices. Obviously, this is something I’m interested in.

It seems like enabling users to save time while using apps has been a common thread in the past few months. The success of Launch Center Pro probably “raised awareness” in regards to the whole concept of URL schemes, but it’s been the increased adoption of x-callback-url and interest in automated workflows that proves better inter-app communication is something that (at least) third-party developers are thinking about. Google included a powerful URL scheme in Google Maps and Google Chrome; more recently, Mr. Reader showed how to enable a “services menu” by requiring users to mix URL schemes from other apps with parameters for an article’s title or selected text. These aren’t ideal solutions, but it’s all we have for now.

Greg Pierce, creator of the x-callback-url specification, has improved Drafts in ways that not only make the app more useful to get text onto other services, but also broaden the possibilities for automation through the use of URL schemes.

There are three main new features in the new Drafts: Dropbox actions, URL actions, and an improved URL scheme with support for callbacks and action triggers. I am going to explain how they work and include various actions and bookmarklets to demonstrate different use cases. Read more

Due Clipper For Google Chrome

When there are no actual news or notable app releases, I prefer investing my time in creating something for other people.

Continuing my ongoing series of tips on iOS URL schemes, here’s an adaptation of my existing Due bookmarklet to work better with Google Chrome for iOS (which, as I’ve pointed out several times, has a very nice URL scheme). The following code (to install it, simply copy it and paste the entire string into a bookmark) grabs a webpage’s title and URL and sends them to Due (also powered by a great URL scheme). Read more

Chrome for iOS: Send A Webpage Back To Safari Via Bookmarklet

Sort of. Here’s a fun experiment.

Today, I wanted to quickly send a URL from Chrome for iOS – my default browser – back to Safari. I know there are ways to do Safari-to-Chrome, but I wanted the opposite: from Chrome back to Safari. I needed to install some custom Mr. Reader actions, and Chrome was giving an error when tapping on the downloadable files. I figured I could make a bookmarklet to take the current webpage in Chrome and send it to Safari.

Not so fast. There’s no documented URL scheme on iOS for opening web links in Safari, except, well, the http:// scheme itself. In testing various bookmarklet ideas, I thought that replacing googlechrome with http in Jon Abrams’ bookmarklet would force Chrome to send a link to Safari. But as It Turns Out™, doing this sort of trick in Chrome for iOS:

javascript:window.open('http'+location.href.substring(4));

…simply opens a new tab in Chrome.

What I ended up using is a hack – and a very curious one – to leverage Chrome’s support for x-callback-url to open a link back into Safari. I was inspired by Cormac Relf’s script, which I discovered yesterday when he showed me another script he made for Pythonista.

javascript:window.location='googlechrome-x-callback://x-callback-url/open/?url='+encodeURIComponent(location.href)+'&x-source=Safari&x-success='+encodeURIComponent(location.href);

As you can see above, we’re telling Chrome to open a new tab using…itself. The trick, at least theoretically, is to use an encoded location.href string to call back Safari, which is registered for the http:// scheme that Chrome, in this case, opens “externally”. Displaying x-source is needed per Google’s URL scheme specification; the name you give to x-source will be displayed as a “back” button in Chrome (as shown in the image above).

This is a profoundly inelegant and ultimately flawed solution. To make this “work” you have to:

  • Type the bookmarklet’s name, because Chrome has no bookmarks bar;
  • Nothing will happen.
  • Close Chrome;
  • Re-open it;
  • A wild new tab appears!
  • Tap the Safari button. It’s super-effective.
  • Safari will launch the link, closing the additional tab Chrome decided to open.

What is going on, exactly? Via JavaScript, we’ve forced Chrome to open a tab in itself, but doing so with x-callback-url inside a bookmarklet creates, for some reason, quite a strange behavior: the tab isn’t opened unless you close and re-open Chrome, therefore partially defeating the whole purpose of this bookmarklet, which is to quickly open a webpage in Safari. But, in spite of the clunky process, a new tab with a “Safari button” is created nevertheless, allowing you to tap it to launch Safari and close Chrome’s extra tab.

My conclusion is that we have three solutions: a) it’s not possible to create a straightforward Chrome-to-Safari bookmarklet; b) it’s possible in another way that I haven’t explored; or c) it’s possible with the x-callback-url hack, but in a different way.

If you have ideas, ping me on Twitter.