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?
As an Android dev I can tell you this isn't happening in the next 5 years. They may add Chrome apps to Android, but it will be a niche option that won't be used by anybody.
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, ...).
That's possible today - there are apps, that are basically web apps. But they usually offer inferior user experience. It's cheaper, but for the price of being worse than a native app.
It's possible they will add support for other languages besides Java. Android is stuck with Java 6, which sucks...
That language will be web, I suspect. Perhaps Google will offer prerolled components specifically for Android? I strongly suspect that Chrome is the platform Google wants to push for client development now, with Android essentially as a shell for it. While web may arguably be "worse" on Android now, Google has a very large, talented engineering team who could change that relatively fast. Java is a dead end at this point for them I think as far as pushing client development forward. My personal preference would be Android development via Go lang, but I don't think there's much of a chance of that.
I am not a web developer BTW, I am primarily an iOS dev who has done ~6 months of Android work.
Web is a platform, so they would need to rewrite half of Android, I don't think it would be worth it, I don't see real benefits of that for users or devs...
I think that Java 8 is a great language, I like it a lot more than Javascript. Go would be great too.
In all seriousness, I just want a C API. I like different languages for different purposes, but C is still the lingua franca. You can have your Go, I can have my C++, the next guy can have his Python.
As-is, native code on Android is a cluster, and even for games it's pretty uncomfortable and filled with Java shims. Kinda gross.
One guy calls the web a language, now someone calls Go a mobile application development framework. Come on, guys, we're programmers, let's call things by their right names. Go is a programming language, and technicalities like goroutines aside, you'd want it pretty much for the same reason why you'd want Java, Objective-C, JavaScript or, Heaven deliver us from the Symbian days, C++: some people think it's a nice language.
I think of Go as being a language and runtime as opposed to a "development framework", but why wouldn't you have it as a mobile OS language, particularly when compared to Java?
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.
Word on the street has it that Android and Chrome are two highly separate fiefdoms within Google which are somewhat antagonistic (fighting over company priority). There is unlikely to be a high level of cooperation between the two teams without significant internal restructuring. As far as I remember, chrome isn't even Android's default browser.
> There is unlikely to be a high level of cooperation... without significant internal restructuring
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).
Because, as an Android dev, I understand that both platforms have different strengths. Merge of the android and chrome/web platform, that would keep the strenths of both, is basically impossible. So the only possible scenario is making interative improvements to the chrome/web platform. But:
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.
They would basically need to recreate the Android API in the browser if they wanted Chrome apps to be as good as native Android apps. So Chrome OS would become a virtual machine emulating the Android platform.
Right now, it's quite easy to package a web app into an Android app. But users generally dislike that.
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.
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.
> 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.
> 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.
But there are also apps that are pretty slick and that's more and more common. It's quite easy to make sure your app will have 60 FPS most of the time on modern devices.
Why? I'd rather see them push Android as a increasingly more mature OS alternative to Windows. And you'll be able to run Chrome on Android anyway.
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.
> What exactly are you expecting to get from the mythical "ChromeOS and Android merger", when you already have Chrome for Android?
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.
This applies to all of the talk of platform convergence in general, including what MS has been attempting with Windows. I just don't understand this desire to merge lots of different platforms and applications together.
People must be playing too much Katamari Damacy or something.
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.
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 (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
The one thing it's notably lacking is a large ecosystem which I'm hoping will improve after v1.0's release.
Smalltalk? meets very few of those points, whilst it has inspired a number of languages it's not a real-world choice itself for developing complex web apps. Dart's closest language is JavaScript (which it also transpiles to) of which it presents a compelling option and holds a number of advantages over - esp. for maintaining large web apps.
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.
> - Provides a familiar language with clean semantics and low ceremony
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.
Provides a familiar language with clean semantics and low ceremony
> Smaltalk had it.
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.
There are several languages that intersect most of those traits. Clojure is possibly the closest and it also has many other things Dart can never hope to get.
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.
So another hook for always positively identifying Google's always listening data-collection network.
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 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.
"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.
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.
A WebView in a native app always seemed like a really hacky way of doing it, so a proper Chrome App functionality would be fantastic. Just like how Firefox does it (even on Android, in the Aurora builds)
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.
But in that case you're both drawing attention to the fact that your app is HTML5 (which thanks to Facebook is associated with a low quality experience) and also that the user has to download a separate library in order to run it. You'll likely get a significant portion of bad reviews solely motivated by this, just as with apps that require the user to download Adobe AIR separately.
In my case, I happen to be doing something completely different with AOSP. I'm not looking to build a webapp for the Play store. We are embedding AOSP on our own hardware.
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.
Actually, it's just what I was looking for in this announcement from Google. We currently deploy our internal apps on phonegap, and I want the snappy and the APIs that Chrome offers over the stock webview.
This would be a strange step considering that Google spent so much time, energy and money to convince developers to use a very specific design language and application flow to give users a unified experience of Android across many apps.
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.
That actually makes a lot of sense given their Android KitKat tagline which is "It's our goal with Android KitKat to make an amazing Android experience available for everybody." Google has used Play Services to update Android in the background. Since they also own Chrome, the more apps that live within Chrome the more apps are up to date and out of reach of other companies who would use Android for them, notably Amazon, Samsung and Facebook
That kitkat tagline could mean absolutely anything. It could be a kid-friendly set of features, or a more efficient OS so that cheap devices can run well so people in 3rd-world countries can have Android too. It could also mean cat-friendly interface with paw-sized touch targets.
It also means that many of these apps won't be usable by anyone running Android pre-4.0. Chrome launched with GoogleTV on Android 3, and that version doesn't auto-update, so it won't get apps.
Yeah, someone is always quick to point out that someone is going to left behind. It doesn't matter. Mobile hardware and software is evolving quite fast. There will be a billion 4.0+ devices in a couple of years. People that aren't interested in newer devices probably aren't as interested in apps either.
What about Dart? It might play a role here, it's not likely to go far outside the Google ecosystem and I'm not convinced Google ever thought otherwise.
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 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.)
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.
Chrome packaged apps give the same api in the browser as in chrome OS.
The whole trick of packaged apps, is to get the same API on all OS. And along the way, google gets apps for chrome OS. I guess it's some kind of chicken and egg problem, to use the OS you need apps, but developers only develop if there are users. By having apps working on various OS the entice developers to create stuff that will also work in Chrome OS.
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).
They do work in the browser, but also do have some issues in Windows (especially XP). I provided bug information and offered any assistance possible, but got nowhere. We ended up rolling with a Qt WebView wrapper and I rewrote the USB calls. Haven't had any issues since.
they will be free to copy the API.
much of HTML5 is standardizing stuff already existing in various browsers (ironically, a lot of IE stuff).
Firefox is already working on an API for USB for example.
Firefox has made stubs for web apps that can be launched directly from the desktop since Firefox 16 (https://wiki.mozilla.org/Apps/WebRT). I guess the difference here is more (Chrome-specific) APIs and better support for running offline?
Chrome has had that particular feature for just as long (look for "Create Application Launcher" in the menu; or right-click a regular chrome app, set its presentation to "Window", and click "Create Shortcuts".) This is a separate feature, about creating apps that don't appear to be "from" the web.
For me the exciting bit is being able to access devices from them.
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.
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.
Well, Activex was windows only. At least you can run in three big platforms now. And probably Android later. This is not activex, perhaps Adobe AIR is kind of similar, but it was not web centric.
It would be nice if the apps they recommended (wunderlist) actually worked. I have attempted 5 times to "sign up" for the wunderlist app, every time I hit the button the app freezes on the load screen. Not once has it made it past. I also have not received one email verifying my attempt to sign up. My first experience with app launcher and one of the apps would be horrible. Better get on the ball if you really wanna change the web in such a dramatic way.
Just and FYI, if anybody is having this same issue, if you go to the website (not using the app on your desktop) you can sign up there, then you will be able to sign in.
This is, effectively, bringing a ChromeOS-like app interface to Windows (and soon other platforms). The new app launcher looks just like it does on ChromeOS, putting Chrome Web Store apps on an equal footing with native apps started from a Start menu or equivalent.
Chrome/Android.. What about Chrome/Windows. Notice that every new advancement in Chrome squeezes out the need for Windows.
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.
I gave it a try on my Pixel and found that the touch didn't always seem to work as expected - for instance, when I rotate the globe, it would always try to center Africa on my finger and I couldn't tap on cities. I'd prefer if the game defaulted to fullscreen and allowed me to zoom out more - I assume this is because it was originally designed for smaller screens.
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?
> 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.
Prices have been annoying, yes. We ended up geoip-ing to guess the applicable tax and pray that Wallet made the same guess.
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.
I've been hacking on a Chrome App for the past few weeks and have been wondering how to open a tab instead of a new window. That announcement leaves me confused: what's new exactly? Is it even possible that the new stuff has been in the docs for months?
Chrome is a resource hog. I don't want that on my phone, which barely lasts 4 hours idling in my pocket. Thanks but no thanks. On my Mac, Chrome with 20 open tabs is always using most of my memory and CPU.
Firefox uses less resources in Windows 7 than Chrome does, it runs more tabs, and it is much more stable.
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....
With same tabs open for the same amount of time, Firefox uses significantly less. I hate to say this, but Safari beats Firefox, which makes it the most efficient browser on OS X.
I was hoping this was away to wrap a webpage in chrome and distribute that, but it seems to require me to distribute it through there webstore. Given that they don't have a default monopoly on selling things over the web (unlike, say Android, where they have most of the users), why would I want to do that?
The technology is certainly interesting, if a bit limiting.
Its really awesome to see Google taking the web seriously by giving it more access to hardware, but it would be nice with some indication of where these APIs are headed.
Are they "forking off the web" or just experimenting before standardising?
How do I get my app to be in "for your desktop" category? It's not on the developer page of my app. It's a media player app that matches most of the requirements of the new apps.
Google says that "packaged apps are written in HTML5, JavaScript, and CSS" but the first one they show, Pixlr Touch Up, is actually written in Flash. New breed, eh?
Err, I guess was testing the Pixlr version in the Chrome Web Store, which I assumed would be the same thing as the “desktop” version. Is it possible that one would be Flash and the other would be something else?
Whatever runs in Chrome. Wunderlist uses javascript, while Cracking Sands uses NaCl. Though the apps run in their own windows, opening chrome://inspect in the main Chrome window lets you examine the various open apps.
The new breed of chrome apps has a lot of flaws after I tried to convert my app over:
-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.
I remember from a talk at IO13 that the point of the new Chrome Apps is that they truly behave and feel like what we think of as "native" apps. Therefore, no Chrome tabs or other browser-like stuff. I'd have to look at the talk again but if I remember right they limit how and when JS can be used in order to let you safely do things you can't do in a standard webpage.
> -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.
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
Even the older breed of chrome apps had annoying flaws, IMO, when I was playing around with their APIs to get a feel for them about 6 months ago.
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.
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.
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.
Chrome is now a serious security risk for me. it's just waiting to happen.
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.
All this functionality sounds like an increased attack surface, and it is. But when the comparison is Firefox, it's far outweighed by the fact that Chrome has a very good process sandbox, while Firefox has none. It will be years before Firefox can match Chrome's level of security.
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?