Google brings Chrome apps to Android and iOS(thenextweb.com)
thenextweb.com
Google brings Chrome apps to Android and iOS
http://thenextweb.com/google/2014/01/28/google-brings-chrome-apps-android-ios-lets-developers-submit-google-play-apples-app-store/#!tE8F0
17 comments
The 'hybrid' silver bullet approach is easier said than done, although if anyone should take a crack at it, I guess Google's as good a bet as anybody. I've tried every single hybrid approach known to man thus far, and they've all felt awkward and forced. Still gonna write native code until I'm blown away by something.
Is it possible to make the hybrid approach pleasant? I mean, many apps involve heavily leveraging native components, but many of them are simple location-aware mobile-friendly CRUD apps.
For the simple cases - a data-capture app and the like, how well do things like Cordova measure up? Does it still suffer from the "non-native feel" problem even though we're mostly seeing textboxes and dropdowns?
For the simple cases - a data-capture app and the like, how well do things like Cordova measure up? Does it still suffer from the "non-native feel" problem even though we're mostly seeing textboxes and dropdowns?
I find that for simple apps, a lot of the hybrid frameworks can get you 95% of the way there in terms of user experience. And if you don't plan on using any native UI stuff, then you might be fine. But then you'll run into some weird CSS issue or something that breaks your heart (and your design).
I tried AppGyver's Steroids offering (which is based on Cordova) and was quite impressed, but ultimately decided it wasn't quite up to snuff, which sucked because I really wanted it to be.
I tried AppGyver's Steroids offering (which is based on Cordova) and was quite impressed, but ultimately decided it wasn't quite up to snuff, which sucked because I really wanted it to be.
I am trying to build an app with AppGyver(cordova with lot's of native UI and really cool workflow - like trying the app on device immediately OTA) however I must say it's very limiting and if you say you would skip the native UI and build everything by your own, the app feels not-so-snappy.
I should really buy a Mac and code native, this WebviewUI approach just doesn't cut it.
I should really buy a Mac and code native, this WebviewUI approach just doesn't cut it.
How is this different/better than what you could already do with Cordova (aka PhoneGap)?
(Not trolling... this is an honest question.)
(Not trolling... this is an honest question.)
There's almost nothing that you can do with Cordova that you couldn't do with mobile Chrome apps, since, under the hood, they are Cordova apps.
In fact, the plugins themselves have all been available for some time on the Cordova plugin registry (I think Andrew announced this at PhoneGapDay in Amsterdam last year), and you can use them on standalone Cordova projects.
Much of this project is about getting Chrome packaged apps to run as Cordova apps -- that is, single-page apps, with a manifest file, background scripts, and the chrome.* APIs. The goal is that you could take an existing packaged app, build it with this tool, and have an Android and an iOS version running in a couple of minutes. (There are obviously a lot of caveats in that statement; mobile devices are different from desktop in a lot of ways)
There's no intention of being "better" than Cordova -- We've been a big part of the team that has been building Cordova for the last couple of years. If anything, it's a testament to how powerful the Cordova platform is, that we've been able to build this framework on top of it.
In fact, the plugins themselves have all been available for some time on the Cordova plugin registry (I think Andrew announced this at PhoneGapDay in Amsterdam last year), and you can use them on standalone Cordova projects.
Much of this project is about getting Chrome packaged apps to run as Cordova apps -- that is, single-page apps, with a manifest file, background scripts, and the chrome.* APIs. The goal is that you could take an existing packaged app, build it with this tool, and have an Android and an iOS version running in a couple of minutes. (There are obviously a lot of caveats in that statement; mobile devices are different from desktop in a lot of ways)
There's no intention of being "better" than Cordova -- We've been a big part of the team that has been building Cordova for the last couple of years. If anything, it's a testament to how powerful the Cordova platform is, that we've been able to build this framework on top of it.
This is just Cordova with Chrome App APIs. It doesn't run on top of Chrome or anything like that. So the only difference is you can now have API compatibility between your real Chrome App, and your "fake" Cordova-powered "Chrome App"
[deleted]
Unless you're using Android KitKat, then the web view is actually chrome.
Not sure, but maybe there's something in the noted upcoming 'toolchain' that might be interesting? Personally, I'm not holding my breath.
Nothing, they just aliased existing PhoneGap APIs to the chrome.* equivalents.
This is rather disappointing implementation. This doesn't solve the problem is making web apps first-party apps on the platform, as this is still running on top of Java. They need to do something to allow non-Java runtimes to have the same access to system APIs that Davlik has.
It would be interesting to see how this plays out but it is indeed disappointing for an alpha. Regardless of the platform apps need to work with data. Packaged apps do not have access to websql, and you are pretty much forced to use IndexedDB, which apparently isn't even a high priority for the alpha. With Cordova if there isn't an API for something native you want you can write or find a plugin to do so, e.g. Sqlite, so to me this was sort of a step backwards given that it's based on Cordova. Of course, if there is some way to use Java plugins then it might be a different story.
WebSQL has been deprecated for a few years now, you should go ahead and pick an IndexedDB library and start using it.
I already use IndexedDB for Chrome packaged apps, you're basically forced to use it. The fact that there are Chrome-specific APIs means that there could have been one for SQLite but the NoSQL agenda is pretty strong.
This just feels like it's all over the place because they seem to hint at being able to use the Cordova plugins from Chrome Apps (restrictive), so I don't get the write-once-run-almost-everywhere vision. It seems like you will have to write a Chrome App then write a Chrome Mobile App. This whole thing is just a weird marriage.
This just feels like it's all over the place because they seem to hint at being able to use the Cordova plugins from Chrome Apps (restrictive), so I don't get the write-once-run-almost-everywhere vision. It seems like you will have to write a Chrome App then write a Chrome Mobile App. This whole thing is just a weird marriage.
Sounds like you really like SQLite. WebSQL is dead and never coming back. It doesn't make sense for the Chrome developers to maintain an old API that's not part of the web platform just because some people don't like the alternative. Eventually someone will create a library that lets you do SQL with IndexedDB (if they haven't already) and you'll get the best of both worlds.
By the way, Mozilla was the primary party that objected to WebSQL and it wasn't because of an NoSQL agenda, it's because they didn't want to tie a web API to 1 specific implementation (SQLite).
By the way, Mozilla was the primary party that objected to WebSQL and it wasn't because of an NoSQL agenda, it's because they didn't want to tie a web API to 1 specific implementation (SQLite).
I don't really care either way, my point is that they pushed out this announcement without any clear indication about handling data in apps. That might be intentional. IndexedDB is fine for certain apps but for more complex apps with non-trivial data relationships it doesn't work. I also don't care about WebSQL per se. The thing is that they didn't put a SQL database under the chrome APIs, like they have for chrome.storage. To me the whole thing is silly because iOS, Android, and WP8 provide SQLite natively and you can access it via Cordova.
This is not about WebSQL vs. IndexedDB, it's about Chrome Apps not having access to a SQL database. Btw Chrome itself supports WebSQL, but it was removed in Chrome Apps.
Packaged Chrome Apps: IndexedDB Cordova: anything that's supported - SQLite (not WebSQL), IndexedDB, w/e Packaged Chrome Apps + Cordova (the subject of this whole thread): ???
This is not about WebSQL vs. IndexedDB, it's about Chrome Apps not having access to a SQL database. Btw Chrome itself supports WebSQL, but it was removed in Chrome Apps.
Packaged Chrome Apps: IndexedDB Cordova: anything that's supported - SQLite (not WebSQL), IndexedDB, w/e Packaged Chrome Apps + Cordova (the subject of this whole thread): ???
[deleted]
I was excited when I seen the headline about Chrome apps, thinking mobile was getting the same kind of in-browser apps that are available on the desktop Chrome Store. Mainly because that would give us the ability to write apps without an Apple Developer Account and we could publish outside of the App Store to users who aren't jailbroken. Seems like that's never going to happen.
In the documentation it says it supports Android 4.x+, but will it still run on the default WebView instead of Chrome on versions below KitKat 4.4? Cos then you would have to adapt your CHROME APPS for android 4.1 or 4.0, and if you look at caniuse.com HTML5 and CSS3 support for default android browsers its a huge step back. Or am I wrong?
This could change a lot, especially for smaller developers that knows javascript really well.
The one thing it would lack in the end is native performance.
Even with mozillas latest JS magic asm.js: http://i.imgur.com/46hCFEJ.png
The one thing it would lack in the end is native performance.
Even with mozillas latest JS magic asm.js: http://i.imgur.com/46hCFEJ.png
It's amazing that Dhrystone is still used in 2014. Some things just never know when to die [1].
[1]: http://en.wikipedia.org/wiki/Dhrystone#Shortcomings
[1]: http://en.wikipedia.org/wiki/Dhrystone#Shortcomings
> The one thing it would lack in the end is native performance.
I'm gonna wait before I make a judgement on that one. Certainly at the moment HTML/JS solutions lack performance, but who knows what Chrome/OS/fancy pants integration Google will come up with eventually.
I'm gonna wait before I make a judgement on that one. Certainly at the moment HTML/JS solutions lack performance, but who knows what Chrome/OS/fancy pants integration Google will come up with eventually.
> Today’s announcement builds on...
Where's the link to the actual announcement?
Where's the link to the actual announcement?
Might Apple take issue with this under rule 2.25?
>Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected.
I don't see a world where this could ever replace a native icon/app on an iPhone, but if it did I'd imagine Apple would bring down the hammer on this.
edit: I didn't realize that these would be wrapped in a shell so they can be submitted to the app store. I incorrectly thought they'd be run from the Chrome app
>Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected.
I don't see a world where this could ever replace a native icon/app on an iPhone, but if it did I'd imagine Apple would bring down the hammer on this.
edit: I didn't realize that these would be wrapped in a shell so they can be submitted to the app store. I incorrectly thought they'd be run from the Chrome app
Web browsers are allowed all kinds of leeway with the Official Rules. A prime example is making payments via browsers. Limiting which parts of the actual web a browser can access would be a detriment to even Apple's walled garden.
This is based on Cordova, which Phonegap is also based on. There are tons of Phonegap apps in the App Store already.
From a users' point of view, I am enthusiastic about the chrome apps. Having been using my phone and tablet way more than my PC, I am now used to the simplicity and ergonomy of mobile apps. Chrome apps allows me to find back almost the same experience on a PC.
From a developer's point of view, I would also say "so what? Cordova has been here for a while" but it is not a technological improvement, it's about releasing your apps to a broader audience.
From a developer's point of view, I would also say "so what? Cordova has been here for a while" but it is not a technological improvement, it's about releasing your apps to a broader audience.
Anyone know when it's going to be released for all developers?
I'd like to start playing around with this as soon as possible.
It's available to everyone right now; go ahead and clone it from GitHub, or install the cca package from npm -- it's a "developer preview" right now because some of the APIs are still changing; I wouldn't consider it stable enough to ship an app to users just yet. We're definitely looking for people to try it out, though -- we want to know what's working, what's missing, and what's just more difficult than it could be.
> more difficult than it could be
Installing cca. Can't seem to pass the cca checkenv test, because of Xcode command line tools (I don't want the full Xcode). Problem:
Xcode appears to be installed, but no version is selected (fix this with xcodeselect)
No solution with xcode-select. Maybe some better docs could help out frustrated devs like me?
Installing cca. Can't seem to pass the cca checkenv test, because of Xcode command line tools (I don't want the full Xcode). Problem:
Xcode appears to be installed, but no version is selected (fix this with xcodeselect)
No solution with xcode-select. Maybe some better docs could help out frustrated devs like me?
That's not a configuration we'd come across in testing, but I'll check it out.
Can you raise an issue on https://github.com/MobileChromeApps/mobile-chrome-apps for this?
Can you raise an issue on https://github.com/MobileChromeApps/mobile-chrome-apps for this?
They need to do the opposite, and allow Android apps to work on Chrome
We've been reinventing the same widgets all over in every new platform. HTML showed us the true direction for universality. Then XML came along. All we need to do is design a standard for widgets based in xml and a standard for object and platform communication.
I, as a developer, would like a universal platform for developmnet, be it html, xml, svg, or whatever comes next.
Call it AXIS, Application Xtended Interface Standard.
I, as a developer, would like a universal platform for developmnet, be it html, xml, svg, or whatever comes next.
Call it AXIS, Application Xtended Interface Standard.
What you're looking for is web components / shadow Dom. It's a method of defining widgets in HTML, and then invoking those widgets as if they were a single element. No need to develop yet another specification for ui
well f. it i'll wait for firefox to do the same. don't want another MS in town.
firefox can do this since about 1 year ago.
Look at this https://marketplace.firefox.com/
just found this in the Windows version:
Internet Explorer 9 or newer is required.
Couldn't help but laugh.
Internet Explorer 9 or newer is required.
Couldn't help but laugh.
(TNW needs to lift their game on making sources more obvious)
EDIT: My source was http://www.theverge.com/2014/1/28/5355064/chrome-apps-are-co...