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

131–140 of 169 posts

Re: A new breed of Chrome Apps

#131

Post by weland »

moystard wrote: post #102
RivieraKid wrote: post #64

Earlier quoted context omitted.

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.

Why would you have Go on a mobile OS as a mobile application development framework?

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.

Frankly, I'd trade Java for Go any day.

Re: A new breed of Chrome Apps

#132

Post by the_mitsuhiko »

platinum1 wrote: post #124
the_mitsuhiko wrote: post #37

Our game RAD Soldiers is featured up on the games page: https://chrome.google.com/webstore/detail/rad-soldiers/dkiah... You can cross play with the iOS version, feel free to leave feedback :-)

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, brig…

> 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.

Re: A new breed of Chrome Apps

#133

Post by RivieraKid »

moystard wrote: post #102
RivieraKid wrote: post #64

Earlier quoted context omitted.

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.

Why would you have Go on a mobile OS as a mobile application development framework?

I probably wouldn't switch from Java but lots of people want to use Go to make Android apps.

Re: A new breed of Chrome Apps

#134

Post by RivieraKid »

rorrr2 wrote: post #96
RivieraKid wrote: post #25

Earlier quoted context omitted.

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 /…

There are thousands of PhoneGap apps out there, pretty much disproving your point.

Yes, but they suck.

Re: A new breed of Chrome Apps

#135

Post by RivieraKid »

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).

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.

Re: A new breed of Chrome Apps

#136

Post by crassus »

alexbell wrote: post #55
RivieraKid wrote: post #41

Earlier quoted context omitted.

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 po…

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.

Re: A new breed of Chrome Apps

#137

Post by georgemcbay »

moystard wrote: post #102
RivieraKid wrote: post #64

Earlier quoted context omitted.

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.

Why would you have Go on a mobile OS as a mobile application development framework?

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 JavaJNICGOGo would result in something very horrible.

Re: A new breed of Chrome Apps

#138

Post by lucian1900 »

mythz wrote: post #86
pjmlp wrote: post #84

Earlier quoted context omitted.

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.

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 (…

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.

Re: A new breed of Chrome Apps

#139

Post by lucian1900 »

justincormack wrote: post #27
daleharvey wrote: post #22

Earlier quoted context omitted.

> -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,…

Synchronous local storage on a phone would be a real problem due to lags, on desktop it might be OK...

It's terrible on a desktop as well, even with an SSD. It fsyncs, which blocks the entire page.

Re: A new breed of Chrome Apps

#140

Post by lucian1900 »

the_mitsuhiko wrote: post #132
platinum1 wrote: post #124

Earlier quoted context omitted.

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, brig…

> 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…

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.

Post reply on HN