Live data from Hacker News

Introducing Chrome for Android

googleblog.blogspot.com

161–170 of 240 posts

Re: Introducing Chrome for Android

#161
post #150

My initial perception is that all the Chrome features are great, primarily the data syncing with my desktop browsers. But the rendering is flawed; it doesn't render like the standard Android browser, doesn't render like desktop Chrome, and doesn't seem to even render consistent to itself. For example, a few screenshots comparing the standard Browser view of this comment page and the way Chrome beta views it: Browser:…

It's apparently a feature: "An issue that often pops up for mobile browsers is that text on the website may be too small to read properly. Where the Android Browser employs a text reflow algorithm to clarify the situation, Chrome for Android features a technique which we’ve called Font Boosting. It uses an algorithm to increase font sizes when necessary, aiming to make the text readable regardless of the zoom level."…

While it's indeed imperfect and inconsistent, in the 10 minutes I've spent playing with it, it does seem much, much easier to read and click links without zooming, which is quite a bit more important to me than it being slightly ugly. I'll definitely be using it over the stock browser.

Re: Introducing Chrome for Android

#162
This is unusable on the Galaxy Nexus due to its mysterious tendency to make fonts microscopic for random sections of the page. Guess it never occured to anyone to test their flagship browser on their flagship phone? It doesn't even resize the page to fit the screen when you pinch zoom (which the stock browser does)

Also, it has a persistent address/menu bar that takes up the top 10% of the screen, no doubt thanks to ICS' lack of a dedicated menu button. Once again, proof that removing said button was a pure stroke of idiocy.

Re: Introducing Chrome for Android

#165

I think is the death knell for ChromeOS. Android browser has always sucked, it was the primary reason I haven't bought an Android device. Google had the resources to make Chrome on Android a long time ago, so I presume they were dragging their feet in a "wait and see" approach for whether ChromeOS had any chance on its own.

I don't believe so, for both your statements :) First off, this took so long because Chrome was built using a "normal" devel framework (gcc, make, etc) with a few added tools (repo, gyp). The UX for Chrome is provided via OS-specific graphical APIs, like X.org, Cocoa, and Win32. Android uses a Java framework, which in turn contains the code that manages all rendering and UX, so not only did Chrome UX needed to be por…

That's exactly the same market android tablets target. The market for ChromeOS is rapidly evaporating.

Re: Introducing Chrome for Android

#166
post #6

So what have we been using up till now on Android? Is this just a re-branding and overhaul of the Android WebKit browser?

well i've been using dolphin hd

Dolphin HD is just a reskinned version of the stock WebKit view that comes on every Android device/OS.

Re: Introducing Chrome for Android

#167
post #120

Earlier quoted context omitted.

I've never seen any chart or graph where Firefox Mobile even shows up. Usually when something has http://gs.statcounter.com/#mobile_browser-ww-monthly-201101-... http://www.netmarketshare.com/mobile-market-share

It's still not nobody. And having Firefox playing a significant role will prevent situation which existed in the past where many sites were "IE only". We don't need "WebKit only" sites.

There is a difference between "WebKit only", which means you have to support some N number of standards (CSS 1/2/3 for example) and "IE only" sites, where you have to run Windows and support ActiveX.

Re: Introducing Chrome for Android

#168
post #120

Earlier quoted context omitted.

It's still not nobody. And having Firefox playing a significant role will prevent situation which existed in the past where many sites were "IE only". We don't need "WebKit only" sites.

There is a difference between "WebKit only", which means you have to support some N number of standards (CSS 1/2/3 for example) and "IE only" sites, where you have to run Windows and support ActiveX.

There are enough WebKit browsers specific things which are not standard to make "WebKit only" situation a problem. In general, well balanced browsers representation makes web developers think better and be more responsible.

Re: Introducing Chrome for Android

#169
post #157

Earlier quoted context omitted.

Oh yeah? Let me know when I can get Siri on an iPhone 4 without resorting to some sketchy hacks.

This false equivalence is tiresome. The inability to run a handful of hardware dependent features on iOS is not even in the same ballpark as the complete lack of timely updates for over 95% of Android users.

Hardware dependant? Siri was shown running on pre-4s devices (3g if I recall correctly) before apple bought them.

Re: Introducing Chrome for Android

#170

Earlier quoted context omitted.

Unfortunately, because of shortsightedness from both Google and HTC (HTC mostly), phones back then only had like 450 MB internal storage, and from that only 250 MB were for the OS itself. This means an ICS install would be severely limited by the hardware (I think a full ICS install is significantly bigger). Modders might be able to put ICS on it by cutting apps and features, or doing other kinds of hacks to extend t…

Is it HTC or Google's responsibility to provide future-proof reference designs and specs?

HTC

"Future Proofing" a phone is difficult, because a manufacture needs to overspec the phone whilst still keeping it at a reasonable price.

HTC is notorious for underspecing storage on their phones. Other manufactures do not have the same problem.

Post reply on HN