Saturday, June 23rd, 2007

iPhone and Ajax: onpinch(), mac simulator, and Cringely

Category: GWT, iPhone, Mobile

The iPhone Ajax buzz continues. Joe Hewitt (Firebug) writes about the new multi-touch events that he hopes show up:

I’ve read lots of people, while arguing for why iPhone web apps are lame, assert that web apps won’t be able to take advantage of the iPhone’s multi-touch screen. This is nonsense. I completely expect Apple to have extended Safari with new DOM events that allow any web page can respond to the variety of gestures the user can make with the touch screen and accelerometer.

Won’t it be fun to handle “ontilt” for when the user turns the phone from portrait to landscape mode, or “onpinch” for when the user pinches the page with multi-touch? Should the “onscroll” event include details about how fast the user dragged her finger, to indicate the speed to scroll? Developers are going to have a field day with this stuff. I am sure Apple has thought these things through and won’t let us down.

Robert Cringely has his opinion on iPhone and Ajax:

The iPhone absolutely needs AJAX applications for the phone to be a success on AT&T’s EDGE network. By pushing more functional logic into the browser, the bandwidth consumed per http round-trip is significantly reduced, making the phone apps faster and helping to justify that big price tag. The problem with this is that AJAX apps don’t always work the same (or at all) on every browser. The iPhone has real browser support, which is good, but remember AJAX is based on JavaScript, which in this case is not so good. JavaScript isn’t statically typed and each browser has its own version of JavaScript. Developers are typically forced to hand-code different versions of their AJAX apps for different browsers. With the AJAX economy dictating that browsers with big market share like IE and Firefox get most of the effort, that leaves Safari as a second-class browser and, potentially, a liability for the iPhone.

Bandwidth is one piece of the puzzle, but what about the cost of connections? If a connection across the network is painful (and I think it is!) then Ajax isn’t going to necessarily help, and can in fact become a hinderance if abused. Will the apps be so good to make you frustrated at the EDGE?

To get testing applications you can download iPhoney and simulate away. This is a Mac piece of software, but you can use the JavaScript version too.

Posted by Dion Almaer at 8:57 am
13 Comments

+++--
3.5 rating from 17 votes

13 Comments »

Comments feed TrackBack URI

“… a connection across the network is painful (and I think it is!) …”

Don’t they have keep alive these days?

Comment by Pablo Cabrera — June 23, 2007

Help!!! I can’t figure out how to use the iPhone, Anyone else having trouble???

http://tinyurl.com/2r7cu4
It’s here already!!! The iPhone and at great prices!!

Comment by CEB — June 23, 2007

Last time a browser vendor extended W3C standards there was a huge outcry.

Comment by Maarten Manders — June 23, 2007

From the article:
“With the AJAX economy dictating that browsers with big market share like IE and Firefox get most of the effort, that leaves Safari as a second-class browser and, potentially, a liability for the iPhone.”

I don’t know who Cringely been talking to, but it’s just not that hard to make a product work on Safari/Opera/Firefox its getting to to work on IE thats the problem. And yes the economics, do force you to make it work in IE. But that doesn’t for a moment make you not want to make it work on every other browser. All of our AJAX products work on ALL modern browsers, I am pretty sure we’re aren’t alone.

Comment by Ben Smith — June 23, 2007

Sorry to say it, but every ajax return call that I implement in Safari that tries to return an array (evalScripts=true), crashes Safari!!! This is a Safari only issue, so don’t say IE is harder. I spend most of my hair pulling time trouble shooting Safarit, not IE. Like This:
1. Firefox (so easy with firebug)
2. IE (cause it throws an error and atleast tells me what line the error occured on)
3. Safari (cause with ajax calls, at least 2 out of the last 4 projects I’ve made, the program just shuts down. Is an array with 130 stuctures that hard??? Apparently!)

I use prototype and return things as arrays often, and Safari has honestly been the biggest headache, where as IE is a headache, but at least tells you the line number!

P.S. I have enabled Safarie JS Logging, and their messages are useless!!! So any responders, don’t treat me like I’m retarded, cause I’m just mad at Safari’s array handling in ajax returns that evalute the code and let us add new arrays to the doc via ajax.

Is Safari thie loser here? Yes, cause crashing just plain sucks!!!

-Chad

Comment by Chad — June 24, 2007

Ain’t Safari open source? A quick look at the source should tell us what events are supported.

Comment by Jordan — June 24, 2007

@Chad:

I don’t know what you’re talking about. Returning an array from an ajax call works fine in both Safari 2.0.4 and Safari 3b. I just made a test script (using latest Prototype as you mentioned you use it) to confirm. No crashity.

Main page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<script type="text/javascript" src="prototype.js"></script>
<title>Arrays over ajax in Safari</title>
<style type="text/css">
a { cursor: pointer; text-decoration: underline; color: blue; background: transparent; }
</style>
</head>

<body>
<div id="div1">
<a id="clickme">Click me</a>
</div>
<div id="div2">
<ul id="ul1"></ul>
</div>

<script type="text/javascript">
updateArr = function() {
var a = new Ajax.Updater(
'div2',
'./ajax.html',
{
method: 'get',
evalScripts: true,
onComplete: function() {
if(!$('ul1')) {
var ul1 = document.createElement('ul');
ul1.id = 'ul1';
$('div2').appendChild(ul1);
}
// For some reason, Safari is recognizing the presence
// of the array, but not evaluating it just yet.
if(typeof arr != 'object') {
updateArr();
}
for(var i = 0; i < arr.length; i++) {
var lia = document.createElement('li');
lia.innerHTML = arr[i];
lia.id = 'li' + i;
$('ul1').appendChild(lia);
}
}
}
);
}
Event.observe('clickme', 'click', updateArr, true);
</script>
</body>
</html>

In ajax.html:

<script type="text/javascript">
arr = new Array();
arr[0] = 'foo';
arr[1] = 'bar';
arr[2] = 'bat';
</script>
Loading array 'arr';

Comment by Trevor — June 24, 2007

We’ll now I have my answer, apparently Cringely has been talking to Chad

Comment by Ben Smith — June 24, 2007

Im unsure as to why someone is saying that making these applications is going to be hard, or even that it needs multibrowsers support. These Iphone applications need only work in safari. ANd like the above said, its IE that causes problems.

Comment by Kyle — June 24, 2007

“The iPhone has real browser support, which is good, but remember AJAX is based on JavaScript, which in this case is not so good.”

Spoken like a true Javascript coder! Or not! Safari actually has a quite good Javascript implementation — buggy in spots, but then that’s the same for every interpreter. All round I think it’s pretty good.

“JavaScript isn’t statically typed”

True and totally irrelevant.

“and each browser has its own version of JavaScript.”

* sigh
No, they all interpret the same version of Javascript. The differences lie in the browser not the language.

“Developers are typically forced to hand-code different versions of their AJAX apps for different browsers.”

No. Developers are usually forced to accommodate IE, which has a buggy JS implementation. This doesn’t involve creating different versions of the app, that’s what libraries are for. They smooth over the differences for you.

“With the AJAX economy dictating that browsers with big market share like IE and Firefox get most of the effort, that leaves Safari as a second-class browser and, potentially, a liability for the iPhone. ”

This makes no sense at all. Users won’t blame the phone, they will blame the site. It’s not 1999 anymore! There is no excuse for supporting only one or two browsers in any public facing site. It’s actually not that hard and by and large most developers achieve good cross-browser support.

Check it out Robert, if you make a site that works in Firefox, there is 99% chance it’ll work perfectly in Safari. If not any differences are likely to be minor. ZOMG!

Robert Cringley clearly doesn’t understand the issues intimately. Instead we get a list of non-issues subtly angled to critisise the iPhone. Blah!

Comment by Mr eel — June 24, 2007

I’ve already written javascript to detect when the screen rotates. It’s simple, just watch for the window size to change ;-) and display different content.

Comment by Court Kizer — June 24, 2007

> Bandwidth is one piece of the puzzle, but what about the cost of
> connections? If a connection across the network is painful (and I think it
> is!) then Ajax isn’t going to necessarily help, and can in fact become a
> hinderance if abused.

Unless the phone has some sort of inherently degraded network capabilities (i.e. no persistent connections) I don’t understand why this is a factor. The browser should re-use connections, regardless if it’s running on a iPhone or a Mac. What am I missing?

Comment by Chris — June 28, 2007

I am trying to develop an online app for the iPhone using AJAX (Sajax Wrapper) and I am running into problems with Safari displaying the information in the div tag. For instance, I have a list of 20 names. When the name is clicked then a form is displayed in the div tag. But, if I scroll down and click a name then the browser freezes and tries to display the form over the list of names. It works flawlessly in Firefox but not Safari. I’ve had experiences in the past with Safari and its bugginess with JavaScript. I just wish they could build a solid browser like Firefox.

Comment by Rob — July 6, 2007

Leave a comment

You must be logged in to post a comment.