Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new breed of Chrome Apps

chrome.blogspot.com

Post reply on HN
Print view View original

111–120 of 169 posts

Re: A new breed of Chrome Apps

#111

Post by jrockway »

kevingadd wrote: post #70
jrockway wrote: post #38

One thing that I think is really cool about Chrome Apps is that you can write USB drivers in Javascript that will run on any platform that runs Chrome or Chromium. This means that if you want to make a hardware device that syncs with the cloud, all you have to do is write what is essentially a web app, and anyone with Windows, OS X, Linux, or Chrome OS can use your thing. I'm personally working on a Chrome SDR app fo…

The documentation says chrome.usb only works on Chrome OS, are you sure it works in the actual browser? Last time I looked into this stuff it's nontrivial to let arbitrary user-mode applications manipulate arbitrary USB devices on Windows, so I'd be impressed if they got it working in a secure fashion and deployed it to the open web.

I only have linux machines, but yes, I'm sure it works on Linux.

Re: A new breed of Chrome Apps

#112

Post by zenocon »

jaxytee wrote: post #34
walexander wrote: post #16

Earlier quoted context omitted.

I don't know if the convergence will happen, but they certainly need to fix WebView in Android to at least allow migration. It's still using the old Android Browser and is severely outdated (no WebSockets, etc). My guess is that Chrome Packaged apps will be the replacement for WebViews on Android. Anyone who wants a stop gap though, should check this out: https://github.com/pwnall/chromeview

From the ChromeView github page: "Attempting to scroll the view (by swiping a finger across the screen) does not update the displayed image. However, internally, the view is scrolled. This can be seen by displaying a stack of buttons and trying to click on the topmost one. This issue makes ChromeView mostly unusable in production" Have you used ChromeView successfully in a production application? This seems like a de…

I forked ChromeView, and then the more time I spent with the Chromium build and codebase, I realized the content shell was a better starting point, so I created a similar project that uses different chromium artifacts as a base: https://github.com/davisford/android-chromium-view; scrolling has no issues at all. There are a few quirks, and myself and a few other people are discovering them and finding ways around them -- since we all want to use Chromium for our various projects.

Re: A new breed of Chrome Apps

#113

Post by zenocon »

kllrnohj wrote: post #88
walexander wrote: post #16

Earlier quoted context omitted.

I don't know if the convergence will happen, but they certainly need to fix WebView in Android to at least allow migration. It's still using the old Android Browser and is severely outdated (no WebSockets, etc). My guess is that Chrome Packaged apps will be the replacement for WebViews on Android. Anyone who wants a stop gap though, should check this out: https://github.com/pwnall/chromeview

> Anyone who wants a stop gap though, should check this out: https://github.com/pwnall/chromeview A stop gap that adds at least 30mb to your application is a really shitty solution.

This isn't 100% true. The majority of that is the native shared library and binary resources. These could be hosted centrally and loaded from an APK. It isn't totally necessary to package them in an APK.

Re: A new breed of Chrome Apps

#114

Post by coldtea »

jonknee wrote: post #68
fidotron wrote: post #48

Earlier quoted context omitted.

That's really not too different from what it takes to package HTML5 code into Android apps already, with the same result of apps with UIs that feel foreign to the system. The trend is not towards HTML5, but actually away from it. Quite honestly the Chrome Mobile team are swimming against the tide on this.

> The trend is not towards HTML5, but actually away from it. Quite honestly the Chrome Mobile team are swimming against the tide on this. That's quite a statement. The average Android app is already a UI nightmare that feels foreign to the system, I don't see how HTML is going to be somehow worse (especially when there would be a full set of HTML5 components to use).

>The average Android app is already a UI nightmare that feels foreign to the system, I don't see how HTML is going to be somehow worse

Well, it's gonna be worse by being even more foreign, feeling even more foreign (what's with custom components re-created for HTML5) and slower.

Actually, it's not a hypothetical: you can already check "wrapped in native" HTML5 apps and proper native apps, and the former do feel inferior, unless the developers have put tons of effort in them (and still, they are not able to do cpu-intensive things that native apps do, from live video filters to audio stuff).

Of course that might still be OK for simple apps, todo lists, glorified web clients, etc. But those are not what will drive mobile forward, it's just the lowest common denominator.

Re: A new breed of Chrome Apps

#115

Post by coldtea »

pjmlp wrote: post #84
mythz wrote: post #81

Earlier quoted context omitted.

I like Dart, it's the most productive language/environment I've ever used and if it's unable to gain any traction on its core objective building of client-side complex web apps, it will still have a compelling server-side story ala (node.js) after v1.0 is released and the ecosystem catches up with it.

Server side is already too crowded, there is nothing that Dart brings to the table. The only way Dart will have any future is if Google makes a requirement to use it somewhere.

>Server side is already too crowded, there is nothing that Dart brings to the table.

People could have said the same thing about Go, and yet it's catching up quite nicely.

It doesn't have to bring something "new", just a coherent offer, and that it does.

Re: A new breed of Chrome Apps

#116

Post by coldtea »

pjmlp wrote: post #92
mythz wrote: post #86

Earlier quoted context omitted.

Having developed several server-side projects in Dart, the language/environment brings a hell of a lot to the table optimized for reducing complexity and improving productivity which: - Provides a familiar language with clean semantics and low ceremony - Provides the fastest dev iteration times (there's no compile step, just edit + run in Dart VM/Dartium) - Provides ~10x faster start-up times than JS with snapshots (…

Most of your points were already covered by Smaltalk, and we all know where it is nowadays. Sorry, but I lost count of the languages I have used since 1986 and just don't believe in Dart ever taking off unless Google makes it so.

>Most of your points were already covered by Smaltalk, and we all know where it is nowadays.

And less points were covered by Java, and still it got to the top of the language pile.

Re: A new breed of Chrome Apps

#118

Post by krasin »

krasin wrote: post #109
nraynaud wrote: post #50

Earlier quoted context omitted.

yeah, same here, I'm writing a CNC controller, the UI is a google chrome packaged app talking on USB. it's a pain to use, with all the restriction, the buggy API (it doesn't crash, it just hangs, you can't investigate) and the browser bugs (I have to use a canary for development, I'm really far from a release).

any links to your code?

upd. I found it. https://github.com/nraynaud/webgcode

Re: A new breed of Chrome Apps

#119

Post by asifsignupfor »

jonknee wrote: post #72
Spearchucker wrote: post #43

Earlier quoted context omitted.

More like ActiveX components reborn, because these things will only run in Chrome. Much like ActiveX only ran in IE.

They run "on" Chrome, not in it. A separate icon, window, etc. You need to have Chrome installed, but it's different from ActiveX in that you're not going to see "plug-in missing" in the middle of a page somewhere.

Great, phonegap for the desktop :(

Re: A new breed of Chrome Apps

#120

Post by kllrnohj »

zenocon wrote: post #113
kllrnohj wrote: post #88

Earlier quoted context omitted.

> Anyone who wants a stop gap though, should check this out: https://github.com/pwnall/chromeview A stop gap that adds at least 30mb to your application is a really shitty solution.

This isn't 100% true. The majority of that is the native shared library and binary resources. These could be hosted centrally and loaded from an APK. It isn't totally necessary to package them in an APK.

You still have to download the library at some point, and the library has to end up in your app's private libs folder. Android doesn't do dependencies or inter-app shared libraries outside of those that are part of the platform.
Post reply on HN