Hacker News Reader

Comment by Curious42 | Hacker News Reader

As an Android developer, I'm most excited about instant apps. If it works as marketed, you won't have to hold on to the apps which you use maybe once or twice a week. Instead, you'll be able to download the required feature/activity/view or whatever else on the fly.

I'm not sure I did justice to instant apps, because there's a language barrier playing in. But here's an example: I use the Amazon app maybe once every 2 weeks, and yet it's one of the apps consuming most amount of memory on my phone due to background services. After Amazon integrates instant apps, I'll be able to delete the app, and just google search for the product through my phone. The Google search will then download the required page as an app, giving me the experience of an app, whilst not even having it on the phone.

View on HN

This is going to sound really naive... Isn't that just a website?

Here's a really good overview: https://www.youtube.com/watch?v=cosqlfqrpFA

Also, to answer your question, not it's not the same as a website because it will be a native Android app with the ability to communicate with the Android OS, like any other Android app.

The possibility of things — in terms of improved UX — that you can accomplish with instant apps are infinite. It all comes down to how you want to use it.

BTW You can do this kind of thing now, with classloading. I'm doing developmemt on my phone, and it's far faster to load new class versions than install a new app version. Google will have a framework around this.

Full OS access could mean permissions per page - could be awkward or ok. Much of the app vs. webpage debate here is the same as always - though offline advantage is gome.

Never looked into Classloader until now. Very interesting. Can a loaded class also be an extension of a view or an activity?

I'm loading a GLSurfaceView, which extends SurfaceView, which extends View. So, yeah.

There shouldn't be any problem classloading an Activity, use reflection to instantiate, and treat as you would a runtime Activity (as opposed to being declared in AndroidManifest.xml). But I haven't actually done this; could be some gotchas in incorporating runtime a Activity into the GUI.

IIRC google had a few hits on classloading Activities.

I watched the video and honestly, this is terrible.

If I'm clicking on a link I want to open it with my browser, not with some app. I find this extremely annoying with facebook and even the news carousel already.

I can't open new tabs, copy the url, switch to other tabs like I would in the normal browser. This is extremely confusing and I don't how this benefits me in any way.

I couldn't agree more. I'm excited about the idea of streaming apps, but the execution here is terrible. How do you control which url opens which app? If somebody sends you a reddit or hn link, which app does it run? There are dozens out there for both! The whole point of the app is not to have to manage these things, but the only way I can see this working is if you have yet another area in settings to manage which apps open for which links.

A better implementation would have been to have a popup with a list of compatible apps to run, including an option to run it in a browser like any normal link.

I really hope the NFC bit is opt-in by default. I don't want to have to manually disable it every time I get a new phone. In fact, even if I've opted into having the SF Park app run when I'm near a parking meter, I want the option to "reject" it just like I do when I get an incoming phone call.

> How do you control which url opens which app?

The website itself specifies which app should be used by publishing a Digital Asset Links file. (https://developer.android.com/training/app-links/index.html)

I like that even less. If you haven't manually added an app association, it defaults to opening the app specified in the digital assets file without any notification to the user. This is the opposite of a sane default. The first time an app wants to run, it should always let the user decide whether they want to run the app or continue using the browser. Otherwise, this is a recipe for malware.

The malware developers are DEFINITELY looking forward to this capability.

ActiveX for Android

I'm curious about the "just a website" bit as well. It's slow going, but new features like service workers, web workers, web sockets, webrtc, seem to be closing the gap between "website" and app.

Is there some point where websites start to significantly displace apps?

> Is there some point where websites start to significantly displace apps?

Yes. It happened about ten years ago.

Ah, yes. Guess I should have said iphone / android native apps, especially ones that depend on network data such that the native app wouldn't be any faster than a web site.

I don't get the appeal, for example, of native apps for things like airlines, amazon, ebay, etc.

Speed, responsiveness and the ability to work offline. These things sort of work for webapps on the desktop because desktops aren't cpu and memory restricted. Phones are. As a result, webapps are just too damned slow and frustrating to use on a phone.

"Is there some point where websites start to significantly displace apps?"

It seems to me that this is already slowly happening and this instant app thing is the reaction. After all, Google would lost the control if everybody started to use the browser.

It's still a native app, you just don't have to explicitly download it, or download the whole thing. It still runs native code and can take advantage of Android-specific features.

so we're back to applets

Reply on news.ycombinator.com