Hacker News Reader

Comment by davesims | Hacker News Reader

Linking is one of the things that I think Android got right over iOS. Google -- web company that they are -- smartly realized that their mobile OS platform needed to borrow metaphors from the web and attempted to do this with their Intent/Activity architecture.

The challenge here is the execution -- it's Java-heavy and unwieldy compared to <a href=...>, but the basic structure is there and allows for interesting interleaving of Activities from one app into another. I haven't yet seen a lot of discussion or adoption of Open Intents, but I think it's an interesting approach. It does, again, seem to suffer from an inheritance of Java's heaviness, and that may be a fatal flaw.

http://www.openintents.org/en/intentstable

Whether this approach succeeds in sustaining rich-client apps as web apps mature remains to be seen, but I do think it points to the fact that OP's criticism was a concern in the minds of Android's developers at the earliest stages.

View on HN

While linking to other apps in Android is absolutely trivial and mostly painless (even considering it's java), the more tedious part is to implement the intent service itself. The "<a href=" example is the wrong one, since the call itself is practically a one-liner in java, whereas implementing the equivalent of a "Hello {{name}}, how are you since {{last-visit}}?" response would cause a hell of a lot more headache.

The API is solid though, the linking is done at a very low level, and to be honest when you get the hang of it, it's hard to let go of that awesome feature of the OS. I strongly support the use of RESTful IntentServices and ContentProviders, even if you don't open them to other apps, it's specifically the part that the Android OS got right. Opening them up for other apps to link to is a one-liner config change afterwards.

Agreed with most of your points except "mostly painless." Consider that an anchor tag is both presentation and event handler -- basically all necessary application logic -- in one line, and intuitively understood in its integration with URLs. The "one line" to start Intents in Android (usually at least two, and likely more, depending on how much other data you need to put in the Bundle or Extras or URL objects) is only the execution part, usually buried in the event handler which itself is attached to a View object which itself was defined in a layout.xml or some other visual declaration.

Heavy.

It isn't a fair comparison, linking from one app to another is (as far as I can think of) completely useless if the other app can't call back with data. That is adding a significant layer of necessary complexity that simply isn't possible to do at all with <a>.

Besides, you can put html code in textviews, webviews and their ilk, make the links clickable and the app will silently create the corresponding intents.

The only aspects I can think of right now that are lost in the translation are webpage roots and local # anchors. There might be a lot more, though.

Not sure I follow -- I was isolating the case of simply launching an external Activity, analogous to clicking a hyperlink to a separate webpage. Just adding data to an Intent (similar to the way you'd add arguments on URL params) can require several extra lines, plus, again the fact that you still haven't accounted for setting up the event handlers, the View object that responds to the click, etc.

I'm not knocking Android -- I'm an Android dev. The point I'm trying to make is that building out an ecosystem of interconnected links is hard. The web accomplished this by making the markup for those links very very simple. The total amount of code and setup for one Android application to launch another is far more complex than writing one anchor tag. This is at least a barrier to more widespread adoption of something like Open Intents, etc.

I didn't mean to imply that you thought Android web intents were poor, I just don't think that <a> is a relevant analog. My point is that the nature of links are not the same. There is no way for a website to pass data back to you and the links are completely static. Generally if the links have url params then they link is generated by some serverside template renderer and its disingenuous to compare just the output from that program to the source from another program.

XHR requests are much more of an analog to Intents than <a> links are, and they are a similar order of complexity.

90% of my use cases when I launch an external Activity (email, maps, sharing, etc.) I don't get data back, so I guess from my POV anchors are good analogies.

And how is Ajax not precisely an example of a website passing data back? It's all just servers responding with json or xml or html, whether it's a GET from an anchor tag or data from an Ajax call. I just don't make that distinction -- it's all HTTP to me.

My point was that Ajax (XHR) is pretty much the same thing as launching an Intent, and it is pretty much as complicated as launching an Intent.

I would hesitate to say that Ajax and Intents are precisely the same since with Intents app gets paused and waits, with Ajax the user will often expect the website to still be functional while the Ajax call is still working. If you click the up arrow on a comment you wouldn't expect the Reply button to not work until the Ajax request has called back.

That said, I never meant to indicate that there was a big difference between an XHR request and launching an intent; I was merely trying to point out that an <a> tag is notably different in functionality than both a ajax request or an intent launch.

Not useless, certainly. It's routine for an app to fire up a web page or document viewer. Or if you're an app with some form of content generation you can hook the "share" intents to push to facebook/google+/etc... without the need for feedback.

Obviously feedback is an important feature, but one-way links are very useful low hanging fruit.

"Opening a URL in a given app" isn't all linking provides.

Linking also lets me take whatever content an app is displaying, isolate the URL, and share that externally from the app.

Current apps are link roach motels: your links check in (o hai 4sqr), but they never check out.

This, I think, is the biggest advantage of the web, and why things on the web can go "viral" more than anything else.

No installed/downloaded app can go viral in the same way a web app can. The barrier to entry is vastly different between the two.

Angry birds?

Viral has a meaning distinct from extremely popular.

Yes, it means it spread through social contact such as word of mouth, and people mentioning it on social networks, or just seeing others use the product and becoming interested.

This is how angry birds became extremely popular.

You can link apps in iOS too. You can do a simple test: open safari and type fb://feed and it will open the facebook app and go to your wall.

More: http://wiki.akosma.com/IPhone_URL_Schemes#Registering_your_o...

How does iOS handle multiple apps registering for the same type of URL? In Android, I get a popup asking which app I want to use for this action, and an option to make that the default for future actions. Is there something similar on iOS?

You get a popup asking which app to use. I don't think there is a "save as default" because that would necessitate a way to manage those defaults, which would expose the underlying mechanism to users, something Apple is generally averse to doing.

The reality is that it doesn't get used a whole lot. Browsers, Dropbox, and other apps of that nature tend to provide the data while miscellaneous apps consume it.

Sure, you can open other apps and target applications with different link types, but you can't interleave functionality with nearly as much ease as in Android.

Any time you click a web link from an email, or a YouTube link from Safari you see this: the current app is backgrounded and there's no simple way for the two workflows to interact. This is a major difference between the two OS's and one advantage for Android, imo.

Also possible on Android is for apps to register themselves as link targets for certain domains. For example http://www.github.com addresses can optionally open in the github app.

You can specify your app as a receiver for as many authorities as you'd like, by the way, or even register your own schema. You can also declare your app as a content provider, which means that your app/service becomes a data source, just as the contact list, or the photo repository, and make that data available to others, defining your own private permissions, etc.

My app FairyPreview for instance (https://market.android.com/details?id=com.fairyteller.linkpr...), is registered as an authority for the myriad link minimizers out there, so whenever you click on a minimized link in the Twitter app or anywhere apart from a browser, it will suggest my app for a faster preview instead of taking hours to load a webpage designed for a desktop browser hiding behind an unknown bit.ly link, itself disguised as a t.co, for example.

It's not perfect and it's very old, the code is from 2009, my very first attempt at playing with the cross-app link system, but it works pretty well still. I'm strongly thinking about opening the source code, since I don't make any money out of it (free, no ad, maybe 50 downloads :P), and there's plenty of improvements I'd love to do but don't have the time these days.

Looks like a useful app. I'll give it a whirl. How many nested url shorteners does it follow to get to the real content?

I never tested this in particular, but since it uses HttpURLConnection, the following of redirections is done under the hood - I guess it would be the same limit as the default browser?

Wow! FairyPreview is cool and almost exactly what I want when previewing links from Twitter.

I'm just sad there isn't a Share option (so I can send the link to ReadItLater, Gmail, ...). If you do open the source, I'd love to help with it.

I'm definitely glad you like it, it means I'm not the only one ;) I'll see what I can do about the share button & opening the source. There's definitely tons of improvements to be made.

Reply on news.ycombinator.com