Safari on iOS 4.2: Accelerometer, WebSockets, SVG, AJAX2 & better HTML5 support | Hacker News Reader

Safari on iOS 4.2: Accelerometer, WebSockets, SVG, AJAX2 & better HTML5 support

mobilexweb.com

95 pointsnreece35 comments

I hate to find fault in an otherwise informative and complimentary post, but what the heck is AJAX2? XMLHttpRequest Level 2 is a revision of XMLHttpRequest, not of "AJAX", which is a fuzzy bundle of concepts referencing a style of Web application development. It has no 2.

I was interested in the "accelerationIncludingGravity" property. It seems needlessly verbose. I thought - why isn't there just isn't a separate "gravity" property to complement the "acceleration" property?

After a bit of digging around I found this:

http://lists.w3.org/Archives/Public/public-geolocation/2010A...

  > We can't use
  > acceleration & gravity in place of acceleration &
  > accelerationIncludingGravity as some devices are unable to determine
  > the acceleration without the effects of gravity - that's the
  > motivation for the property.

Apple clearly hates the web!

has this actually been a criticism of Apple in the past? the major contributor to webkit?

Yes. But if you look hard enough you can likely find a criticism for everything.

Hah! I haven't found anyone criticizing your comment yet.

...oh drat!

Actually, a sizable portion of HN thinks that Apple will start to take after Microsoft in the 90's in regards to the web. (They also seem to think Google made WebKit's inspector pane.)

A big complaint is about the -webkit prefix, despite the fact that A List Apart and Zeldman champion it as reducing the amount of browser hacks needed due to the inconsistencies in rendering. (Think how wonderful an -ie6 prefix would be. Now, think about a CSS parser that doesn't fail in specific ways allowing the dev to target it. border-top-left-radius can't be targeted to a specific render, but screws up in different browsers, so it has to be rendered through JS or conditional stylesheets.)

I can't find the actual topical discussion in google, so here's one that links to a news article about the quote in relation to Facebook:

http://news.ycombinator.com/item?id=1929796

I thought the argument was that the App Store encouraged per-website apps instead of just using "The Web"...?

Both arguments are made. Although frankly I think with Android and WP7 presenting credible threats to Apple, they aren't in a position to dictate. With this amount of competition, MS, Google, and Apple all have to fight on all fronts.

Only until one has a monopoly like position will we know their true motivations... I prefer not to know any of their motivations. :-)

I think Jobs has been repeatedly clear that iOS supports two platforms: the web, an industry standard Apple tries hard to advance to the best of its ability, and iOS, which Apple keeps proprietary and advances to the best of their ability that way. Apple is devoting significant resources to developing both (in leu of focusing 100% of engineering on either), as an experiment, if you will.

Now, if only web apps on iOS could enter into full-screen mode like native apps...

Now, if only web apps on iOS could enter into full-screen mode like native apps...

They can. You need to add some additional metadata to the header, and the user needs to save that url to their homescreens (homescreens? does that even make sense?), but once done the web app looks like a native one. You can even define a splash screen to display while the page loads.

Edit: here's the line you need (from http://raphaelcaixeta.com/blog/2010/08/13/meta-tags-to-help-...)

    <meta name="apple-mobile-web-app-capable" content="yes" />

Excellent, yes. This is what Glyphboard does.

Thanks for pasting the code & a link.

> homescreens? does that even make sense?

It's generally called Springboard.

We hate the web... we asked for a SDK when the iPhone was released ;-)

"Learn Objective-C" just fell about 5 spots in my to-do list.

I'd love for John Carmack to spend 18 months heads-down doing an HTML5 engine. Even if he failed to do anything incredible, the feedback would be invaluable.

I love the fact that with mobile devices, we all get to witness Mr. Carmack doing what he does best for a second time: pushing resource-constrained devices to their limit.

No hardware acceleration on the browser just yet and still scripted canvas so that is slower.

So until WebGL, even then, OpenGL ES will still be needed for most games/interactives/apps until we hit 2GHz and about 1GB of RAM or higher.

Then things like Flash also start to perform reasonably enough, same with html5 animation. If they were hardware rendered now then they would be reasonable but still wouldn't be compared to compiled, native apps on the device. Just like desktop now only the current mobile hardware is the desktop hardware of the late 90's.

WebSocket support, canvas, svg etc is awesome for games though.

"No hardware acceleration on the browser just yet --"

Well, Safari (including the iOS version) does support HW-accelerated CSS transitions / transforms.

Yes but still need that on canvas or svg before it will be useful in games with many sprites/vertexes.

No hardware acceleration on the browser just yet

IE9 will use GPU hardware acceleration http://blogs.msdn.com/b/ie/archive/2010/03/16/html5-hardware...

Yep, I track all this at drawlogic.com. Firefox and Chrome also have hardware acceleration in latest. Safari has it as well but only in certain cases (Apple actually made canvas and open sourced it and it is hardware accelerated in CoreGraphics).

It will still be a couple years before this is mainstream. Where on mobile OS updates and browser updates on iOS at least are faster to be adopted (about a 6 month OS adoption rate which is much better than even browser updates on desktop).

HTML5 in the mobile is definitely great. One of the best advantages of native apps is that you can get them into app store - of course, that's by design. Even with the large number of apps, app store provides a great distribution channel.

So why isn't Android innovating in this space?

Good question. Opera Mobile for Android just came out and has some interesting features (tabs, bookmark sync) and SVG support, which is oddly lacking in the stock Android browser. Firefox mobile is in beta as well, with roughly equal features as Opera, plus extension support.

I'd like to see the default browser get more frequent updates, though.

Not sure why Android gets pulled into this, however in addition to the fact that Android 2.2 has far and away class leading canvas and JavaScript performance -- the poor performance on iOS is why so many apps go native on that platform for trivial needs -- and brings virtually all of the Google Gears functionality that became the foundation of "HTML5" to Android (web databases, web workers, geolocation), the next version of Android is going to feature optional javascript access to the camera, among other improvements.

Android is innovating heavily, and your comment is way off base.

Not really "accelerometer" support, just orientation. You couldn't really build a motion sensing engine with it. WebSockets should be really cool on mobile though...

Pretty sure you can get 3-axis accelerometer data, at least according to this snippet:

    window.ondevicemotion = function(event) {
        // event.accelerationIncludingGravity.x
        // event.accelerationIncludingGravity.y
        // event.accelerationIncludingGravity.z
    }

Apple updated their documentation: http://developer.apple.com/library/safari/navigation/index.h...

Yeah, but can you upload pictures from iOS Safari?

Nope. Still inferior to Android 2.2 on this front. Pretty annoying.

Typed array feature is pretty interesting.

Mozilla has a selector, mozResponseArrayBuffer, to get an AJAX result as an ArrayBuffer. Having worked with binary data from an AJAX query I whole heartedly applaud!

I hope Webkit has a mechanism for that, and even more so, that the W3C writes a standard for it.

Nice.

On a different note, WebKit sure is dragging its feet about adapting Object.freeze. Please, for the love of JavaScript, give us immutable objects.

We're slowly adding more ES5 features to JavaScriptCore. While Object.freeze is not in yet, we do have Object.defineProperty, which you can use to make individual properties read-only and non-deletable. Once Object.preventExtensions is added, freeze and seal should be trivial.

Reply on news.ycombinator.com