A new breed of Chrome Apps
chrome.blogspot.com
chrome.blogspot.com
The much-anticipated convergence of Android and Chrome is near. These new Chrome apps are the programming model for the upcoming native Android webapps
The next milestone I expect to see is V8 added alongside Dalvik as a first-class runtime for Android. Maybe in Android KitKat?
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
"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 deal killer.
A stop gap that adds at least 30mb to your application is a really shitty solution.
For example: https://www.google.com/search?q="requires+adobe+air"+bloatwa...
Also, I don't care what Facebook says.
My utopic wish is a new open platform that will combine strengths of the web and of operating systems (Windows, Android):
- Web: Great for documents, which it was originally designed for. Automatic updates. No installation. You can "fork" an app / document by middle clicking a link.
- Operating systems: Great for apps. Speed. More low level access to the hardware. Much richer platform than the web (window mnagment, human interface guidelines, ...).
1) That would break backwards compatibility with Android apps. They would basically have to kill Android and replace it with Chrome OS Mobile.
2) Chrome OS platform is far, far behind Android (and operating systems in general) in many aspects.
Why do you say that? Add some APIs to the Android browser, allow it to open apps full-screen... there doesn't seem to be much more to it than that.
Right now, it's quite easy to package a web app into an Android app. But users generally dislike that.
The trend is not towards HTML5, but actually away from it. Quite honestly the Chrome Mobile team are swimming against the tide on this.
I'd argue that is because the functionality isn't there to make it competitive. So the Chrome Mobile team isn't really swimming against the tide, they're... whatever you do when you put things in the sea to adjust tidal flow.
Mozilla, too. I have a Firefox OS phone on my desk and while it's far from ready for end users, it is an impressive showcase of what you can achieve with HTML.
That statement right there is the single biggest problem that web faces. You still have to qualify it with impressive for HTML. Because the bar for HTML is just so, sooooo low compared to native. On desktop it kind of works because performance really isn't a problem - you've got boatloads of CPU & RAM to just throw at it and nobody expects 60fps. On mobile it's the exact opposite.
Web isn't a viable platform for app development until people start saying "that's impressive" without the "for HTML" qualifier. And that isn't going to happen anytime soon.
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).
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.
I have a feeling they will add more and more Android device APIs to whatever is coming, until it has just as many as the Java APIs.
I've thought for the past year or so that there is no way the future of Android app development is Java/Dalvik.
It's possible they will add support for other languages besides Java. Android is stuck with Java 6, which sucks...
I am not a web developer BTW, I am primarily an iOS dev who has done ~6 months of Android work.
I think that Java 8 is a great language, I like it a lot more than Javascript. Go would be great too.
As-is, native code on Android is a cluster, and even for games it's pretty uncomfortable and filled with Java shims. Kinda gross.
Frankly, I'd trade Java for Go any day.
I'd love to see Go on Android. I doubt it will happen anytime soon though because it would require an entirely new runtime library environment to really be Go-like, just bridging Go to the existing Android Java APIs via Java<->JNI<->CGO<->Go would result in something very horrible.
Internal restructuring like, say, Andy Rubin beyond deposed as head of Android and replaced by the guy in charge of Chrome (Sundar Pichai), who now oversees both Chrome and Android? Because that happened in March.
(Chrome is the default browser in nexus devices. Whether it's the default in non-nexus devices is up to the manufacturer & carrier, who usually choose to use the AOSP browser - an unbranded front end of the system webkit - because they can control and customise it, which they obviously can't with chrome as a branded google app that's updated through the play store).
What exactly are you expecting to get from the mythical "ChromeOS and Android merger", when you already have Chrome for Android?
The only major things I see ChromeOS has over Chrome for Android is the security model, which will be impossible in Android, since you need native apps, too, while ChromeOS will only ever work with "web apps". Changing that could mean its security model will suffer.
And the second one is the upgrade process, for all Chromebooks, coming straight from Google, every few weeks. That's ideal, but I doubt we'll see anything like that for Android even this decade.
Seriously. I don't get this knee-jerk desire to have ChromeOS and Android become some sort of weird hybrid. They're two different platforms. Their combination isn't necessarily greater than the sum of the parts.
People must be playing too much Katamari Damacy or something.
Something needs to change, since the Oracle lawsuit, Java/Dalvik features have been frozen without any new update being officially communicated.
The only way Dart will have any future is if Google makes a requirement to use it somewhere.
- 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 (Dart VM)
- Provides faster run-time performance, that's predictable and can take
advantage of real integers and SIMD instructions (VM Only)
- Provides a unified object model so all classes from all libraries are interoperable
- Providing a rich, well-defined, consistent API, real collections, removing JS WATs,
smoothing over browser quirks
- Provides a unified and composable IO model: Futures and Streams (repeating events)
- Provides a new powerful way to develop client apps with Web UI (Polymer/WebComponents)
offering unprecedented levels of encapsulation and reusability
- Provides optimal dev and deployment options, you never have to worry about choosing
the smallest libs as tree-shaking ensures only code used is compiled and minified
- Providing "full-stack" dev environment, e.g. same language on client and server
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.
I've also used a number of languages in the last 15 years, and I've personally found Dart to be overall be the most productive which has become my go-to language whenever I need to something quick done. It's missing an ecosystem of mature libs which popularity helps most with - but Google has a ton of investment behind Dart which is developing the entire platform (language/libs/toolchain) giving it its best chance to succeed - if it fails to gain any traction it wont be for technical reasons. It looks like it will take over and be the preferred to succeed GWT and Closure Library, with internal usage it should see continued investment for years to come.
Smaltalk had it.
> - Provides the fastest dev iteration times (there's no compile step, just edit + run in Dart VM/Dartium)
Smaltalk had it.
> - Provides ~10x faster start-up times than JS with snapshots (Dart VM)
Smaltalk VMs, actually Self, were where the first usuable JIT compilers were developed.
> - Provides faster run-time performance, that's predictable and can take advantage of real integers and SIMD instructions (VM Only)
Self and StrongTalk were quite performant. SIMD was not available back then.
> - Provides a unified object model so all classes from all libraries are interoperable
Smaltalk had it.
> - Providing a rich, well-defined, consistent API, real collections, removing JS WATs, smoothing over browser quirks
Smaltalk had real collections.
> - Provides a unified and composable IO model: Futures and Streams (repeating events)
Smalltalk has streams.
> - Provides a new powerful way to develop client apps with Web UI (Polymer/WebComponents) offering unprecedented levels of encapsulation and reusability
Fare enough regarding WebUI, as the web did not exist back then. However Smaltalk is responsible for the MVC concept.
> - Provides optimal dev and deployment options, you never have to worry about choosing the smallest libs as tree-shaking ensures only code used is compiled and minified
VM pruning in Smaltalk environments for deployment.
> - Providing "full-stack" dev environment, e.g. same language on client and server
This is only true when using Dartium. Transpiling to JavaScript does not count.
Smalltalk's syntax is anything but familiar, which for programming languages means C-inspired syntax.
> Smaltalk VMs, actually Self, were where the first usuable JIT compilers were developed. > Smaltalk had it. > Self and StrongTalk were quite performant. SIMD was not available back then.
Where are the benchmarks? Alan Kay wanted to kill Smalltalk in the 70's because the way they done things like reflection was done and performed poorly. The computer language shootout shows Dart outperforming Smalltalk by several factors for most things and their still working hard on improving performance with v1.0 of Dart not even released yet: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Note: many of the VM team that were originally on the StrongTalk VM team are working on the Dart VM now who have a heavy influenced on how Dart is designed to ensure it retains a great balance of productivity and performance.
> - Provides a unified object model so all classes from all libraries are interoperable > Smaltalk had it.
Not a coincidence either, Dart's object model was inspired from Smalltalk as many of Dart engineers were from Smalltalk heritage.
> - Providing a rich, well-defined, consistent API, real collections, removing JS WATs, smoothing over browser quirks > Smaltalk had real collections.
But does nothing to simplify web programming, which was the point of this.
> - Provides a unified and composable IO model: Futures and Streams (repeating events) > Smalltalk has streams.
Dart is single-threaded and uses Future's for composing async operations for all non-blocking operations which is the default. Like most languages Smalltalk IO is mostly blocking and multi-threading and has poor support for non-blocking operations.
> Fare enough regarding WebUI, as the web did not exist back then. However Smaltalk is responsible for the MVC concept.
Right, but because its effectively non-existent for web programming we'll never see proper support for web technology like Web Components or tooling like TreeShaking, bundling.
> VM pruning in Smaltalk environments for deployment.
Which means nothing for web deployment and is less useful on the server where size is less of a factor.
> This is only true when using Dartium. Transpiling to JavaScript does not count.
Transpiling to JS does count, Dart has great source-maps support letting you debug Dart code from inside browsers running Dart2JS. But in terms of Native VM not running any JS, then yes Dartium now, Chrome in future and possibly Opera by virtue of Blink.
And less points were covered by Java, and still it got to the top of the language pile.
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.
Yes, in a few places that get lots of up-votes in HN.
In the real Fortune 500 world, it is all about JVM and .NET languages.
although in that article, they also claim chrome apps are going to come to iOS including availablity in the iOS app store, which sounds really really unlikely.
If they would do this we'd have a new set of apps that behaved and felt very differently which would probably cause a lot of confusion among users.
What I could imagine is some kind of framework that makes it easier to share data and state between a Chrome app on the desktop and Android apps on mobile.
P.S. while trying to add this new type of app, I was tricked into signing into my chrome account, which I had managed to avoid all this time.
I've started jumping the Google ecosystem. I'm now more often than not, not signed into a Google-account, to the point where I can go a week without signing in at all.
No way I'm joining a program which requires me to reverse on that.
I'm personally working on a Chrome SDR app for the Funcube Dongle, so you can just install an app from the Web Store, plug the thing in, and start listening to any radio transmission from .5MHz to 2GHz. (The only snag is that the HTML5 audio API doesn't give you 192kHz sound samples, so I think I'm going to have to read them directly via USB. Fun.)
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).
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.
...you can equip that device with one of the many standard, open protocols already in ubiquitous use.
Browser-based hardware drivers in JavaScript? Seriously?
Why implement low-level hardware handshaking via JavaScript in the browser, if all you want to do is sync application data?
If Google waits for other browsers to offer the APIs it needs, Chrome apps won't happen for a long, long time.
- Launch chrome apps directly from the desktop - Run chrome apps with out any of the browser toolbars
Everything else is already possible in a regular chrome app.. Right?
The execution was awful, but still.
http://developer.chrome.com/apps/app_hardware.html
NPAPI has been available for awhile, too.. Not sure if that's what they're referring to when they say shell access.
E.g. I've been waiting for this for a while because you can write an app which communicates directly with an Arduino or any other serial device.
This means that a lot of special purpose desktop apps communicating with custom hardware can be written as Chrome apps and take advantage of the speed/ ease of UI development of web apps.
For one of the apps I maintain this will reduce the time it takes to make UI improvements from several days to several hours.
http://developer.chrome.com/apps/app_hardware.html
A quick google search shows: https://github.com/BertHartm/Chromeduino
They need to improve the APIs for developers though, a Visual Studio 6 for Chrome platform development, probably the high point in softees history. Really tie together web with more traditional native api development. No-one has cracked that yet.
You can cross play with the iOS version, feel free to leave feedback :-)
Also the game was capturing the ChromeOS volume, brightness, maximize keys (probably as F1-F10 keys) and discarding them.
Past issues specific to the packaged app - great game! Very polished. I love X-Com and this is right up my alley.
As one of the few who have actually used it, can you give us your perspective on the highlights and limitations of the packaged apps API?
Considering we're a game there is actually very few things that we need to consider from the APIs. We have our own UI and the integration with the OS is quite limited.
The reason we were interested in the Chrome version is that we're essentially a play by mail game in multiplayer so the push notifications are crucial. Unfortunately the way the push works on Chrome is a bit iffy, way less polished than it works on Android and iOS but it's not too bad.
Since we're free to play there are some optional in app microtransactions to monetize the game. These all use the new Google wallet API for packaged apps and they work reasonably well. Since we allow cross play between iOS and Chrome we need to be careful with how we set the prizes and making prize matching between iOS and Chrome is hard due to differences in how tax is handled.
There is on way to query the final prize for an in-app purchase through the API which makes things like "-50%" badges hard to implement. The way the game gets around it is by guessing what the final prize will be. I wish there was a nicer way but I can see why it's done that way.
There are also some (temporary) limitations with the NaCl runtime (no, it's not PNaCl, at least not yet).
For example, fullscreen on OS X is quite broken. Keys that shouldn't get captured, in particular the one to cancel fullscreen. That (and other small issues) is likely why packaged apps with NaCl aren't yet officially supported there.
They might have been afraid that if they left this prime piece of desktop real estate, Google might take it.
I usually have more than 50 tabs open in Firefox and often go over 60 before having a tidy up. Firefox can survive that for a couple of weeks whereas Chrome would often crash in less than a day. (Flash would crash even more often.)
YMMV, but I switched back to Firefox a couple of months ago and no longer have Chrome installed....
The technology is certainly interesting, if a bit limiting.
Are they "forking off the web" or just experimenting before standardising?
-Previous installed chrome app matches the HTML5 api, the new chrome apps has a lot of restriction where you have to totally rewrite you code in terms of storage. i.e. Chrome.storage instead of localStorage; All chrome storage is async.
-The new window format for apps are a huge UI flaw. You can not open an Chrome app in a tab anymore. Basically, you now have an extra window whenever you open a chrome app. This is very annoying since when you click on the existing window the app is hidden in the back, you have to flip through your windows on the mac to find the app you just opened again.
-Javascript execution permissions are very strict, and no longer follows that of a normal webpage.
The result is, you can no longer build an HTML5 app and prepare it for the chrome store, you have to specifically change the code to package it. This makes it less ubiquitous and creates extra work for developers.
This session explains it all: https://developers.google.com/events/io/sessions/326973874
I was mostly surprised how it felt that in many ways you were actually more restricted than you were with just a normal web app. Also the documentation was trash and confusing in a lot of ways because even prior to these changes they had made a lot of other changes via deprecating APIs and their documentation was poorly managed to the point where it was really difficult to determine which APIs were deprecated or not without trying to use them in the latest Chrome and having them fail on you. Also, there wasn't a clear roadmap as to what APIs you could expect to be pretty stable and what ones they might suddenly deprecate, breaking your app.
Hearing that the "new breed" has some of these same flaws and some new ones makes me very disinclined to bother checking in with the current technology.
I belive this is only localStorage right? (indexedDB is still available afaik)
Firefox OS had mentions of disabling localStorage, its been a huge problem due to its synchronous API, I dont think it did end up being disabled though, I would really like to see localStorage being (slowly) deprecated and an async api (possibly even just a helper for idb) being promoted as an alternative full web standard as opposed to chrome specific API's coming in here
However thats fine when you are building your own apps, but I meant as a long term solution to the web platform, if localStorage needs disabled on one platform in favour of a propietary API, maybe its best to replace it with a non proprietary web api
So a proprietary HTML-based format then? Yay Google for promoting the open web!</s>
With Google going down south, we need Firefox OS to get traction, and we need it now.
for now on, it will be used as the remote debugger for android browsers (until we have something native). just like i have a spare mac for running xcode for the same reason.
firefox serves me well. and will not make me worry much.