Improving Joe's 'Navigation' example

3 views
Skip to first unread message

Christopher Allen

unread,
Jul 9, 2007, 1:56:00 PM7/9/07
to iPhoneWebDev, Joe Hewitt, rui....@taoofmac.com
During the iPhoneDevCamp Hack-a-Thon, probably a quarter of the
iPhoneWebApps presented made use of Joe's wonderful example code at
http://www.iphonewebdev.com/examples/index.html#emulating-native-iphone

In spite of its great capabilities and effectiveness as a example,
even Joe was not really prepared for how popular it became. From his
blog http://www.joehewitt.com/blog/iphonedevcamp.php

[quote]
Another fun thing about iPhoneDevCamp was my constant surprise as I
found one project after the other using the iPhone app template that I
threw together on Thursday night. I didn't really think this bit of
code was ready for prime time, which is why I didn't even mention it
on this blog. I only posted a link to it on the iPhoneWebDev Google
Group. When I woke up the next morning it was already on Ajaxian.
Later that evening, Jeffrey Grossman launched Movies.app, which used
the template for its UI. The next morning I met Kristopher Tate of
Zooomr, who had created a Google Code project based on my code and
started using it to build a music browser. Throughout the weekend I
met one group after another using the template for their Hackathon
projects. I guess the lesson is that people are really happy to be
able to focus on their apps instead of re-inventing Apple's UI! I'm
definitely going to put some more time into it this week to clean it
up and add some more features that people asked for.
[/quote]

I was reading through my blogs this morning and read in the wonderful
TaoOfMac blog http://the.taoofmac.com/space/blog/2007/07/07 :

[quote]
I most sincerely hope that the iPhone doesn't give rise to a bunch of
Safari-centric, egotistical, incompatible, and "standards
para-compliant" applications – i.e., stuff that is formally standards
compliant (because it is, after all, HTML and JavaScript) but that
uses so many WebKit or Safari-specific idioms that ends up not working
properly (if at all) in other browsers.

Otherwise, we'll be back where we started when IE was all the rage,
and repeating all the same mistakes.

So remember: Just because you're doing it on the coolest phone on the
planet doesn't automatically make it right.

Update: For instance, I've been playing around with Joe Hewitt's
navigation sample, which is pretty neat, but only works on the iPhone
browser and on the WebKit nightlies (yes, I refuse to run Safari 3.0
anywhere but Windows until it's stable).

After doing a few simple changes, it now works in "regular" Safari
(2.0) and my Nokia. Although I haven't replaced the animation code
with "normal" jQuery effects yet, all it takes is to change the
handlers in a standard way:

$(document).ready(function() {
// Show the page corresponding to the home button link
// (we get the button's link and then the element that has that hash
as its ID)
showPage($('#' + $('#homeButton').get(0).hash.substr(1)).get(0));

// Teach all links to invoke the showPage function
$("a").click(function(){
// Show the first match for "#hash"
showPage($('#' + this.hash.substr(1)).get(0));
});

// Periodic checks for iPhone orientation
setInterval(checkOrientAndLocation, 300);

// Hide iPhone toolbar?
setTimeout(scrollTo, 0, 0, 1);
});

Nothing else was changed (except removing addEventListener from
iphonenav.js). But the rest – all the rest – looks like it can be
replaced by six to ten lines of jQuery code…

Of course the CSS is all shot due to "proprietary" WebKit stuff, but
that's fixable. If I have time, I'll post the results somewhere.
[/quote]

I've invited the TaoOfMac blogger, who is professional a cell phone
developer in Europe to join us here in iPhoneWebDev.

So maybe we should find a way to collectively make a better example,
one that works on the iPhone, but doesn't completely break other
desktop or cellphone browsers. I'd be glad to host a SVN repository,
with Joe as lead, to allow multiple people to contribute to make what
is currently the best example code we have into something even better.

Thoughts?

-- Christopher Allen

P.S. Anyone have a better name for this project?

Jack Small

unread,
Jul 9, 2007, 2:06:32 PM7/9/07
to iphone...@googlegroups.com, Christopher Allen

On Jul 9, 2007, at 10:56 AM, Christopher Allen wrote:

> So maybe we should find a way to collectively make a better example,
> one that works on the iPhone, but doesn't completely break other
> desktop or cellphone browsers. I'd be glad to host a SVN repository,
> with Joe as lead, to allow multiple people to contribute to make what
> is currently the best example code we have into something even better.
>
> Thoughts?

I think it's a fantastic idea. Joe has done a incredible job but
hardly deserves to support the whole world. Frankly, it seems to me
like Apple could post a template or a javascript or something other
than a glossy page of metrics, but I'm preaching to the choir here.

> P.S. Anyone have a better name for this project?

The iPhone Developers SDK?

More later,
Jack

Dean Hamack

unread,
Jul 9, 2007, 2:26:25 PM7/9/07
to iPhoneWebDev
On 7/9/07 10:56 AM, "Christopher Allen" <Christ...@iPhoneWebDev.com>
wrote:

> [quote]
> I most sincerely hope that the iPhone doesn't give rise to a bunch of
> Safari-centric, egotistical, incompatible, and "standards

> para-compliant" applications - i.e., stuff that is formally standards


> compliant (because it is, after all, HTML and JavaScript) but that
> uses so many WebKit or Safari-specific idioms that ends up not working
> properly (if at all) in other browsers.
>
> Otherwise, we'll be back where we started when IE was all the rage,
> and repeating all the same mistakes.
>
> So remember: Just because you're doing it on the coolest phone on the
> planet doesn't automatically make it right.

Great post Chris! Guess I should have read it before I posted my comments.

The collapsible navigation in my example works on Safari 2, FF, IE, and
Windows Mobile. It's just plain old simple js. If I can get my hands on an
iphone for testing, I can figure out why content is being duplicated and
streamline it. Then I will be happy to share it with the world.

Dean Hamack
Macromedia Certified Flash MX Designer/
Lead Web Developer
Bushido Designs
Tel:(206)523-6705
www.bushidodesigns.net


Rui Carmo

unread,
Jul 9, 2007, 3:14:19 PM7/9/07
to Christopher Allen, iPhoneWebDev, Joe Hewitt

On Jul 9, 2007, at 6:56 PM, Christopher Allen wrote:

> During the iPhoneDevCamp Hack-a-Thon, probably a quarter of the
> iPhoneWebApps presented made use of Joe's wonderful example code at
> http://www.iphonewebdev.com/examples/index.html#emulating-native-
> iphone
>

> I've invited the TaoOfMac blogger, who is professional a cell phone
> developer in Europe to join us here in iPhoneWebDev.

Erm.

(/me waves at onlookers)

Actually, I'm now in Marketing. I'm trying to forget as much of WML
and mobile browser tech as I can, but I can try to keep some of the
neurons for that around... :)

> So maybe we should find a way to collectively make a better example,
> one that works on the iPhone, but doesn't completely break other
> desktop or cellphone browsers. I'd be glad to host a SVN repository,
> with Joe as lead, to allow multiple people to contribute to make what
> is currently the best example code we have into something even better.

Well, I'd seriously recommend looking at something _like_ jQuery, if
only because using it helps (a lot) in terms of portability across
browsers.

I happen to like jQuery because it suits the way I think about the
DOM, i.e., as something I can query, filter, slice, dice, etc.

And I happen to not like Prototype because at the time I really
needed to use something like it it wasn't all that well documented...

There's a bunch of alternatives out there (I've catalogued a few over
at http://the.taoofmac.com/space/JavaScript), but nothing that lets
you manage the DOM quite like jQuery.

And since I'm guessing that a lot of people will be going for the
"all-in-one-page" approach for now, I'd think that ability to play
around with the DOM would be useful...

Anyway, besides JavaScript, I'm a bit concerned about all the -wekbit-
ness in CSS.

I think there should be some sort of "UI Library" that provided
iPhone-native widgets that degraded to something usable in other
browsers, starting with WebKit on other phones (and Safari 2.0, which
may be suitable for testing that to some extent).

Other mobile browsers out there are... Different.

NetFront on SonyEricsson devices has CSS support, but I haven't
pushed it to its limits (I'll be playing around with a new one soon,
will tell), and then there's all the Opera variants (we can leave
Opera mini to last, since it's server-side rendering and in flux
right now until they get 4.0 together).

So I'd probably order things thus:

1. iPhone Safari + Safari 3.0
2. Nokia WebKit + Safari 2.0
3. Opera for Series 60 + Opera 9.0 (desktop, Wii, etc., later Java/
mini)
4. Mobile IE + IE... 4?5?6? :)

Which gives you a nice orderly set of mobile browsers to develop for
and desktop browsers to test against, with (hopefully) a manageable
set of quirks.

(Firefox can be used as a catch-all reference for CSS stuff that the
above doesn't cover - I didn't mention it because there aren't that
many mobile browsers derived from it...).

> P.S. Anyone have a better name for this project?

Erm... "iUI" is taken, and "mobi 2.0" is kind of... weird, so I'd
stick with the current one until things settle :)

R.

Joe Hewitt

unread,
Jul 9, 2007, 4:29:55 PM7/9/07
to iPhoneWebDev
I love jQuery, but I would strongly like to avoid dependencies on any
JavaScript libraries. Every byte counts when you're developing for a
phone that downloads so incredibly slowly. When we started the Tilt
game, my teammates suggested using jQuery after I had already started
without it. When we added jQuery, the game went from loading in less
than a second, to waiting about four seconds, and this was over WiFi.
That 667mhz processor doesn't like to have to parse and interpret
large amounts of JavaScript either.

As far as standards support - I know this is politically incorrect,
but I think it's too soon to start worrying about that. Let me know
when there is another phone that is even remotely close to the
capabilities of the iPhone's browser. Those proprietary -webkit tags
allow us to do some really advanced stuff that saves a lot of
bandwidth and makes pages look great, -webkit-border-image and -webkit-
text-shadow in particular. I think it's a little too soon to start
watering down the capabilities of iPhone apps. My philosophy is that
we *should* build proprietary apps that work only on the iPhone to
motivate other companies to catch up faster.

I also really do not think you should be trying to make your iPhone
apps degrade. You should write your iPhone apps separately. The
iPhone is a dramatically different experience and you owe it to your
users to optimize for that environment instead of spending your time
trying to create a single app that morphs. Inevitably, people who go
that route are going to make compromises that hurt the iPhone
experience, and that would make me sad. Again, let me know when
there's another phone that approaches it, and then we can talk about
degrading.

Rui Carmo

unread,
Jul 9, 2007, 4:55:29 PM7/9/07
to iphone...@googlegroups.com

On Jul 9, 2007, at 9:29 PM, Joe Hewitt wrote:

> I love jQuery, but I would strongly like to avoid dependencies on any
> JavaScript libraries. Every byte counts when you're developing for a
> phone that downloads so incredibly slowly. When we started the Tilt
> game, my teammates suggested using jQuery after I had already started
> without it. When we added jQuery, the game went from loading in less
> than a second, to waiting about four seconds, and this was over WiFi.
> That 667mhz processor doesn't like to have to parse and interpret
> large amounts of JavaScript either.

Odd, since a bog standard Nokia consumer device does that just fine.
And I would suppose that would be a transient limitation until Apple
tweaks the platform.

> As far as standards support - I know this is politically incorrect,
> but I think it's too soon to start worrying about that. Let me know
> when there is another phone that is even remotely close to the
> capabilities of the iPhone's browser.

Erm... You're kidding, right? Yes, WebKit on the iPhone seems to be
pretty impressive. But I've had WebKit browsers on other devices for
a good while now, and the basic capabilities - the _core_ ones, not
the interaction/cosmetic ones - are mostly the same.

> Those proprietary -webkit tags
> allow us to do some really advanced stuff that saves a lot of
> bandwidth and makes pages look great, -webkit-border-image and -
> webkit-
> text-shadow in particular. I think it's a little too soon to start
> watering down the capabilities of iPhone apps.

It's not watering down, it's making sure you can re-use your coding
investment on something else.

> My philosophy is that
> we *should* build proprietary apps that work only on the iPhone to
> motivate other companies to catch up faster.

Okay, you lost me there. I disagree, completely.

I understand your enthusiasm, but I have gone through too many
platforms to see things that way. Sure, I use a Mac and wouldn't use
_anything_ else at home, but the world just doesn't work that way.

I am lucky enough to be able to try out pretty much every new phone
that comes out in Europe - when I have time. I have used
Blackberries, SonyEricssons, Nokias, even Windows Mobile devices of
all sorts - _at least_ a different one _per month_, and, on occasion
(when I'm asked to do solutions testing) several a week.

I have also been tied to (and am still very much aware of) what it
takes to run a mobile portal for hundreds of different mobile
devices, and believe me when I say that there are a lot more
_working_ XHTML mobile browsers out there than you may think.

Yes, the iPhone is better. There's no denying that.

But rushing headlong into a single way of doing things without caring
for either code re-use or standards compliance is not a good survival
strategy for _developers_, since you may not be able to re-use the
skills you learn when you tie yourself to a very specific platform.

So when developers go and code their nice iPhone-specific apps, they
will be limited to the (still fairly small, if not minuscule) global
footprint of iPhone users.

You can say that the iPhone will evolve (and I will agree), but
nevertheless the reality is that not everybody will have one.

And yet, the very fact that it exists and has (hopefully) workable
web applications (not just in terms of interaction and design, but
also in terms of business models) may bring about (or rather, _is_
bringing about) a renewed interest in web-based mobile applications -
for _all_ mobile phones.

The prospective market for those will expand, and with it the
opportunity for developers. And other manufacturers are sure to at
least _try_ to catch up with Apple.

And what happens when you have five or six dominant mobile devices
with decent browsers one or two years down the line (I'm personally
betting sooner), and working business models to sell those applications?

Are you going to stick to supporting _just_ the iPhone, or will you
re-code everything for each new device? And would you prefer to have
planned for that from the start, or have to do it again, and again,
and again?

_That's_ why I think there should be careful planning, standards
compliance (and forethought) when designing iPhone applications, not
just blind faith.

R.
http://the.taoofmac.com


Michael Latta

unread,
Jul 9, 2007, 4:58:59 PM7/9/07
to iphone...@googlegroups.com
I largely agree with you. In particular I mostly hear about multi-
function sites from those that have not lived with an iPhone, or
really have a different business model and are just wanting to be
compatible with its browser. Those of us that live with one all day
long have a very different motivation I think. We love the device
and can think of sooooo many things we could do with such constant
access. The difference between wearing an iPhone and having access
to a computer, is something like the difference between a traveling
salesman having a laptop and a desktop back at the office. The
frequency of access makes all the difference. Luckily there is room
for us all and we do not need to make anyone else play by our rules.

Michael

Dean Hamack

unread,
Jul 9, 2007, 5:02:01 PM7/9/07
to iPhoneWebDev
On 7/9/07 1:55 PM, "Rui Carmo" <rui....@gmail.com> wrote:

> Yes, the iPhone is better. There's no denying that.
>
> But rushing headlong into a single way of doing things without caring
> for either code re-use or standards compliance is not a good survival
> strategy for _developers_, since you may not be able to re-use the
> skills you learn when you tie yourself to a very specific platform.
>
> So when developers go and code their nice iPhone-specific apps, they
> will be limited to the (still fairly small, if not minuscule) global
> footprint of iPhone users.

Amen. And I think there's another distinction that needs to be made - the
difference between "hobbyists" and professional developers.

None of my clients are going to pay me to build an application that only
works on the iphone. But I'll bet a lot of them are going to be willing to
shell out some dough to make sure their sites still work well on it, along
with other mobile devices.

My mini-site for the tattoo convention earned me a bottle of very expensive
tequila from the organizer of the event. So it's paying off already :)

Michael Latta

unread,
Jul 9, 2007, 5:04:20 PM7/9/07
to iphone...@googlegroups.com
You make many good points. I can suggest that part of the difference
is that you are in Europe. In the US from what I have seen (limited
by your standards), the options are not nearly as good because the
carriers have such a stranglehold on the devices. This above all
else may be what we hope for from the iPhone, and in the near term
will not get. Until devices are separated from the carriers in the
US we are going to have much less choice then you in Europe.

Michael

Gerald Buckley

unread,
Jul 9, 2007, 5:10:23 PM7/9/07
to iPhoneWebDev
Agree wholeheartedly with Joe's sentiments. The attn is now on WebKit.
More dedicated apps = more widely adopted WebKit.
>

Gerald Buckley

unread,
Jul 9, 2007, 5:10:37 PM7/9/07
to iPhoneWebDev

Jeffrey903

unread,
Jul 9, 2007, 5:21:56 PM7/9/07
to iPhoneWebDev
Does anyone have a working demo of the jQuery changes that TheTaoOfMac
came up with? I'm not too familiar with jQuery (although it looks
like I'm going to be very soon), so I would like to see a demo of it
before I start implementing it in my web apps, but I think it looks
very promising.

On Jul 9, 1:56 pm, "Christopher Allen" <Christoph...@iPhoneWebDev.com>
wrote:


> During the iPhoneDevCamp Hack-a-Thon, probably a quarter of the

> iPhoneWebApps presented made use of Joe's wonderful example code athttp://www.iphonewebdev.com/examples/index.html#emulating-native-iphone


>
> In spite of its great capabilities and effectiveness as a example,
> even Joe was not really prepared for how popular it became. From his

> bloghttp://www.joehewitt.com/blog/iphonedevcamp.php


>
> [quote]
> Another fun thing about iPhoneDevCamp was my constant surprise as I
> found one project after the other using the iPhone app template that I
> threw together on Thursday night. I didn't really think this bit of
> code was ready for prime time, which is why I didn't even mention it
> on this blog. I only posted a link to it on the iPhoneWebDev Google
> Group. When I woke up the next morning it was already on Ajaxian.
> Later that evening, Jeffrey Grossman launched Movies.app, which used
> the template for its UI. The next morning I met Kristopher Tate of
> Zooomr, who had created a Google Code project based on my code and
> started using it to build a music browser. Throughout the weekend I
> met one group after another using the template for their Hackathon
> projects. I guess the lesson is that people are really happy to be
> able to focus on their apps instead of re-inventing Apple's UI! I'm
> definitely going to put some more time into it this week to clean it
> up and add some more features that people asked for.
> [/quote]
>
> I was reading through my blogs this morning and read in the wonderful

> TaoOfMac bloghttp://the.taoofmac.com/space/blog/2007/07/07:


>
> [quote]
> I most sincerely hope that the iPhone doesn't give rise to a bunch of
> Safari-centric, egotistical, incompatible, and "standards

> para-compliant" applications - i.e., stuff that is formally standards

> iphonenav.js). But the rest - all the rest - looks like it can be
> replaced by six to ten lines of jQuery code...

Joe Hewitt

unread,
Jul 9, 2007, 5:25:07 PM7/9/07
to iPhoneWebDev
> I have also been tied to (and am still very much aware of) what it
> takes to run a mobile portal for hundreds of different mobile
> devices, and believe me when I say that there are a lot more
> _working_ XHTML mobile browsers out there than you may think.

I didn't say anyone should ignore these other browsers, I'm just
saying
that for now they should build one version for iPhone and one for
other
phones. We're talking about tiny apps that run on a tiny screen and
have small feature sets - the cost of managing two UI code bases
will often be not that high.

> You can say that the iPhone will evolve (and I will agree), but
> nevertheless the reality is that not everybody will have one.

This is true, but for those users that do have an iPhone, it is wrong
to hurt their experience. In my opinion, if we start preaching
for people to continue to use the familiar "graceful degradation"
model, the result will be iPhone apps that miss their potential. At
least until Nokia and others catch up, which I hope they do soon.

The word "standard" is often used prematurely. Standards are supposed
to come from lessons learned by creating products that advance the
state of the art.
Sadly, web standards have tended to come instead from slow-moving
working groups
comprised of people who have never written a real web app in their
life.
The iPhone is a new platform just brimming with potential for new
design and interaction patterns, and in my opinion we should attempt
to
achieve those patterns through whatever means possible, and then
create
standards later based on what we learn. Frankly, I think that the web
has
been hurt badly by this standards obsession. It has given browser
makers
an excuse not to innovate - they just wait for instruction from the
W3C, which
has been asleep at the wheel. The lack of progress in browser
technology the
last 5 years has been an absolute tragedy.

A lot of what I'm saying hinges on my belief that iPhone Safari will
soon allow us
to do more multi-touch stuff with JavaScript. That's what really
separates the
iPhone from other phones, not just what browser engine they use.
Once that
happens, designing an iPhone apps means relying on gestures instead of
putting
lots of buttons and scrollbars in the UI. In my opinion, "gracefully
degraded"
web pages will probably wind up leaving lots of crud in the iPhone
apps that
don't need to be there, because it was just easier to just target the
lowest common
denominator.

Rui Carmo

unread,
Jul 9, 2007, 5:27:24 PM7/9/07
to iphone...@googlegroups.com

On Jul 9, 2007, at 10:04 PM, Michael Latta wrote:

>
> You make many good points. I can suggest that part of the difference
> is that you are in Europe.

I'm positive it is. Which, in its own twisted way, is not exactly in
my favor right now :)

> In the US from what I have seen (limited
> by your standards), the options are not nearly as good because the
> carriers have such a stranglehold on the devices. This above all
> else may be what we hope for from the iPhone, and in the near term
> will not get. Until devices are separated from the carriers in the
> US we are going to have much less choice then you in Europe.

Well, I'm yet to ascertain exactly what an European iPhone will look
like (and when it will be available, and via whom), so I wouldn't
score Europe that highly in terms of choice where it regards the
iPhone...

But I have to wonder if all the folk here in this group are US-based
or if I will be alone in trying to explain that wild abandon and
handcrafting JavaScript code will not be that good a long-term
strategy for you guys :)

Anyway, there are other options besides jQuery out there (btw,
1.1.3.1 is _fast_). And you could always consider doing an "iQuery"
with the minimum code required to ensure everyone had a good, fast
framework to build iPhone apps (increasing the chances of code re-use
inside the community) and still allow for "sidegrading" iPhone apps
to other browsers by replacing/tweaking that "iQuery".

The source code for jQuery is out there - and the uncompressed form
is pretty readable...

R.
http://the.taoofmac.com


Rui Carmo

unread,
Jul 9, 2007, 5:50:49 PM7/9/07
to iphone...@googlegroups.com

On Jul 9, 2007, at 10:21 PM, Jeffrey903 wrote:

>
> Does anyone have a working demo of the jQuery changes that TheTaoOfMac
> came up with? I'm not too familiar with jQuery (although it looks
> like I'm going to be very soon), so I would like to see a demo of it
> before I start implementing it in my web apps, but I think it looks
> very promising.

The minor changes I did are here: http://the.taoofmac.com/uaprof

I have not yet replaced the navigation there with built-in jQuery
effects, since my initial attempt was a bit hackish and didn't look
quite right.

So I started reorganizing the files into directories, etc. to make
things a bit more re-usable and familiarize myself with Joe's approach.

Hopefully I'll have time to re-visit this sometime this week (which
is not certain, since my vacation is over).

R.

Jack Small

unread,
Jul 9, 2007, 6:39:01 PM7/9/07
to iphone...@googlegroups.com

On Jul 9, 2007, at 1:55 PM, Rui Carmo wrote:

> On Jul 9, 2007, at 9:29 PM, Joe Hewitt wrote:

>> My philosophy is that
>> we *should* build proprietary apps that work only on the iPhone to
>> motivate other companies to catch up faster.
>
> Okay, you lost me there. I disagree, completely.

For me you are both right. Yes, there is a certain need for highly
optimized standards enforced browser independent web site design.
But, that has always been true.

On the other hand, it seems perfectly reasonable to start off writing
an app that works on the target device. It's kinda finicky. Not
every client wants to publish their app to the world, either.

The reason we have Joe's "example" is because he wrote for the target
device. It is excellent in that it sorta looks like an iPApp and
sorta behaves like one, oh yea and it runs.

I think the boundary here is the need to create iPhone support for a
site and the need to create apps that have a reasonable feature
parity with the existing iPhone applications. Certainly both are
reasonable specifications, but currently nobody has either wrapped up.

Last night I used Joe's example to turn a otherwise silly CGI into an
amazing "app" to wow my friends and family. They all think I'm a
genius for code I wrote a year ago and essentially rewrapped with a
very clever style sheet. Even with Joe's code it's just a hack, but
after a revision or two it could be really handy. So, I think Joe is
a genius and I say we give him plenty of room. Personally, I can't
wait for the updates!

More later.
Jack


John Resig

unread,
Jul 9, 2007, 7:56:22 PM7/9/07
to iPhoneWebDev

> Anyway, there are other options besides jQuery out there (btw,
> 1.1.3.1 is _fast_). And you could always consider doing an "iQuery"
> with the minimum code required to ensure everyone had a good, fast
> framework to build iPhone apps (increasing the chances of code re-use
> inside the community) and still allow for "sidegrading" iPhone apps
> to other browsers by replacing/tweaking that "iQuery".

I'm not sure what that side-port would be, or what what would be in it
- we already strip it down to the bare minimum of functionality that
nearly everyone uses (Ajax and Effects are usually the two areas that
some users don't, sometimes, use - but more often than not, they're
used by most people).

@Joe, et. al.: I'm not sure where most of the time is being spent -
it's certainly not in the download of the code (20k will be smaller
than most images used). So my guess is that the packed version of
jQuery is putting the processor through unnecessary strain.

I've uploaded another version of jQuery for you guys to try:
http://code.jquery.com/jquery-latest.min.js

This is minified (no time spent uncompressing) and comes in at about
35k. If this proves to drastically help you guys, I'll put some
serious effort into reducing some file size for 1.1.4 and run it
through Dojo's ShrinkSafe (which will reduce the size without adding
decompression overhead). I'd guess that the final result of that would
be around 30k, maybe slightly less.

Let me know!

--John

Alan

unread,
Jul 9, 2007, 8:41:22 PM7/9/07
to iPhoneWebDev
On 9 Lug, 19:56, "Christopher Allen" <Christoph...@iPhoneWebDev.com>
wrote:

> Nothing else was changed (except removing addEventListener from
> iphonenav.js). But the rest - all the rest - looks like it can be
> replaced by six to ten lines of jQuery code...

Here is a mootools version, which is downloadable in dependencies, and
much smaller:

window.onDomReady(function() {


// Show the page corresponding to the home button link
// (we get the button's link and then the element that has that hash
as its ID)

showPage('#' + $('homebutton').hash.substr(1));

// Teach all links to invoke the showPage function

$$('a').addEvent('click', function(){


// Show the first match for "#hash"

showPage('#' + this.hash.substr(1));
});

// Periodic checks for iPhone orientation
setInterval(checkOrientAndLocation, 300);

// Hide iPhone toolbar?
setTimeout(scrollTo, 0, 0, 1);
});

</script>

Bye

Dain

unread,
Jul 9, 2007, 8:53:15 PM7/9/07
to iPhoneWebDev
John -

Thanks! I ran some tests for you. I have a page with that's ~70k total
with images and code (huge, I know). Here's the stats over WiFi:

1.) jquery-1.1.3.1.pack.js = 4 seconds
2.) jquery-latest.min.js = 2.5 seconds
3.) no jquery = 2 seconds

I tried to test over edge, but I lost patients after a while because
a.) I can barely get a signal in my office as it is, and b.) it's so
slow horrible that I can't get any consistent results. That being
said, however, it looks like your new version is a very significant
load time improvement. The tests I did over edge seemed to be about
the same for the load times between the two versions, but I think the
bandwidth is the only bottleneck there. Thank you for the link, this
is a huge step around the bandwidth issues!

I really love jQuery, and so does Chris and some of the other guys
here at (mt) if you know 'em, but do you have to download the entire
package? I know I could go through the .js file and strip out the
functions I'm not using, but it would be nice to have a quick and easy
way to compile the jQuery js file using only that which is needed...
(kinda like mootools :-x). Just a suggestion!

On the subject of standards vs. innovation, well thats a pretty touchy
issue, and against my better judgement I'll throw in my two cents. I
believe that there is a place and time for both. We should always
strive to push each individual hardware device to it's limits,
exploiting everything we can about it in order to make a richer
experience for the user, after all the user is what matters most imho.
However, for larger applications that involve man-hours in the
hundreds, it's obviously important to create portable code that will
work on a wider range of devices with as little tweaking required as
possible. I don't think that either method is greater than the other,
in fact, I strongly believe that each method is necessary for growth.

As many of us have heard before, scalability, usability, production
time, and coolness-factor are just a few of the things that one should
take into consideration upon starting a new project. Some things may
be sacrificed on a per-project basis, but you should never lock
yourself into believing that any one of them is irrelevant.

Dain Kennison

Randy Walker

unread,
Jul 9, 2007, 9:21:40 PM7/9/07
to iphone...@googlegroups.com
I agree with Joe's take on all this as it relates only to iPhone-centric
applications. I used to work in the music industry, living in recording
studios for weeks at a time. I once asked the mixing engineer why they
spend so much money, time and effort to make sure the mixing room is a near
perfect listening environment when a huge majority of end listeners don't
have anything near as good. His reply made perfect sense. "We mix the
music in as perfect as an environment as possible to guarantee the music
sounds as good as it can under perfect conditions. This naturally lends
itself to graceful degradation to lesser optimized listening situations.
Ie.$19 in-ear headphones, 4" computer speakers and boomboxes." They do
switch between different types of speakers and check it in mono as a good
indicator of how it would 'render' over the average stereo system or am
radio etc., but the main goal is to make it sound as good as it possibly
can. Even if 60% of the listening audience is using cheap-ass in-ear
headphones that don't reproduce lower frequencies properly, they don't
compensate in the mix by pumping the bass.

I'd like to point out that as Christopher has mentioned countless times,
there are at least three different niches of programming aimed at the
iPhone. Compatible with, optimized for and made for iPhone. Those who seem
outraged that someone would even think of designing something that only
rendered properly on the iPhone are probably living in that 1st category.
That's all find and good. Each category of programming is going to have its
own rules/ideals for what is the overall good for that category. However,
for clarity and sanity, the debating of those rules/ideals needs to be
restricted to their individual categories. The thing that's going on here is
a cross category debate of rules/ideals. As soon as the 'compatible with'
camp starts telling the 'made for' camp how to do things, both camps start
spinning their wheels and chasing their tales. If 'compatible with' is your
thing, or what your client will hire you for, GREAT! I wish you all the
best. But if 'made for' is your niche, then do not hesitate to pull every
CSS trick/hack out of the book to elevate the experience of your iPhone app
as high as possible. Don't 'pump the bass' just to make it compatible with
other phones or desktop browsers as that would lessen the iPhone experience
of the app. I'm not talking in absolutes here, ie.yes, you can adjust code
so it does similar things on other devices... So don't flame me or start any
sort of device wars. That's not what this is about at all.

I know that for me, for the time being, I am concentrating on how to get the
coolest, most useful experiences out of an iPhone app. It is a non-issue
that it may not work properly on any other device/browser since that's not
what it was made for in the first place. Like DHH of Rails say's whenever
someone suggests this or that feature, "That sounds like a great idea. You
should do that." Joe's initial UI is a great start in iPhone centric apps.
The fact that someone else is tweaking it to be somewhat more cross-platform
friendly is pretty cool and an example of how the community together can
move forward. The whole pointing finger thing, telling someone to change
their creation to fit some other device is short-sighted and self-centered.
If I were Joe, I'd tell those people "That sounds like a great idea. You
should do that."

-=Randy

Rui Carmo

unread,
Jul 10, 2007, 3:35:29 AM7/10/07
to iphone...@googlegroups.com

On 10 Jul 2007, at 01:41, Alan wrote:

>
> On 9 Lug, 19:56, "Christopher Allen" <Christoph...@iPhoneWebDev.com>
> wrote:
>> Nothing else was changed (except removing addEventListener from
>> iphonenav.js). But the rest - all the rest - looks like it can be
>> replaced by six to ten lines of jQuery code...
>
> Here is a mootools version, which is downloadable in dependencies, and
> much smaller:
>

Pretty neat. Mootools has been on my radar for a while, but I never
did much testing with it. Can you do the scrolling bits with it as well?

R.

Rui Carmo

unread,
Jul 10, 2007, 3:42:05 AM7/10/07
to iphone...@googlegroups.com

On 10 Jul 2007, at 00:56, John Resig wrote:

>> Anyway, there are other options besides jQuery out there (btw,
>> 1.1.3.1 is _fast_). And you could always consider doing an "iQuery"
>> with the minimum code required to ensure everyone had a good, fast
>> framework to build iPhone apps (increasing the chances of code re-use
>> inside the community) and still allow for "sidegrading" iPhone apps
>> to other browsers by replacing/tweaking that "iQuery".
>

> This is minified (no time spent uncompressing) and comes in at about
> 35k. If this proves to drastically help you guys, I'll put some
> serious effort into reducing some file size for 1.1.4 and run it
> through Dojo's ShrinkSafe (which will reduce the size without adding
> decompression overhead). I'd guess that the final result of that would
> be around 30k, maybe slightly less.

Hmmm. Now that you mention decompression (JS decompression/parsing at
the interpreter level) I have to wonder - does the iPhone support
gzip transfer-encoding (i.e., compression within the HTTP stack)?
HTTP/1.1 pipelining?

Because I think someone should sit down and look at those and factor
them into page load/parsing times, etc.

EDGE can't be worse than GPRS in that regard, and my experience is
that tweaking the server to use gzip and pipelining considerably
improves the overall experience for mobile devices - one socket
connection, multiple requests without setting up another socket, etc...

R.


Christopher Allen

unread,
Jul 10, 2007, 3:49:13 AM7/10/07
to iphone...@googlegroups.com
On 7/10/07, Rui Carmo <rui....@gmail.com> wrote:
> Hmmm. Now that you mention decompression (JS decompression/parsing at
> the interpreter level) I have to wonder - does the iPhone support
> gzip transfer-encoding (i.e., compression within the HTTP stack)?
> HTTP/1.1 pipelining?
>
> Because I think someone should sit down and look at those and factor
> them into page load/parsing times, etc.
>
> EDGE can't be worse than GPRS in that regard, and my experience is
> that tweaking the server to use gzip and pipelining considerably
> improves the overall experience for mobile devices - one socket
> connection, multiple requests without setting up another socket, etc...

That is a good question. I vaguely heard that it did at WWDC, but I
don't recall seeing it officially on any slides or anything.

Time for me to go look up some Apache configuration docs ;-)

-- Christopher Allen

Kai Cherry

unread,
Jul 10, 2007, 4:26:51 AM7/10/07
to iphone...@googlegroups.com
I believe the code for tinybuddyaim is sent gzipped as per the
author's blog.

On Jul 10, 2007, at 3:49 AM, "Christopher Allen" <Christ...@iPhoneWebDev.com

mi...@integralearn.com

unread,
Jul 10, 2007, 5:28:20 AM7/10/07
to iPhoneWebDev
Joe,

It would appear that your 15 minutes of fame has gone into
overtime :-)

Another fan of your work that has jumpstarted development for the rest
of us. Thanks.

Mike
Seattle

Alan

unread,
Jul 10, 2007, 6:43:04 AM7/10/07
to iPhoneWebDev
> Pretty neat. Mootools has been on my radar for a while, but I never
> did much testing with it. Can you do the scrolling bits with it as well?

Yes, mootools has (obviously) full support for style animation +
transitions.
And a useful Ajax class, too.

Bye

Joe Hewitt

unread,
Jul 10, 2007, 7:14:25 AM7/10/07
to iPhoneWebDev
In case you missed it, I kicked off a new thread to talk about the new
features I added tonight to "Navigation", or "iUI" as it is now
called.

http://groups.google.com/group/iphonewebdev/browse_thread/thread/573a1d243f829db

- Joe

Kalle Alm

unread,
Jul 10, 2007, 7:59:25 AM7/10/07
to iphone...@googlegroups.com
Rui Carmo wrote:
> But I have to wonder if all the folk here in this group are US-based
> or if I will be alone in trying to explain that wild abandon and
> handcrafting JavaScript code will not be that good a long-term
> strategy for you guys :)

Most doubtless are, since the iPhone is US-only at the moment. There's
only so much you can say without actually having one and trying it out,
which thanks to Christopher Allen, I've been able to, even though I'm in
Sweden.

Someone said it pretty well here, though. There's a time and place for
both, and I think their importance will play a central role at different
times. For now, the iPhone is unique, and it makes perfect sense to
tailor code for the iPhone and ignore all other devices. For research,
or fun, or what have you. The focus of most of the people on this list
is to push the gadget to its limits, and see what is possible. It also
makes sense to write separate code for iPhones and browsers (just as
there is separate code for mobile devices versus desktop browsers
already), because the iPhone interface is inherently unique right now.
Once this is not the case, this situation should of course change, and
standards should become a central issue.

Writing apps or making sites exclusively for the iPhone (with a big
"Sorry, you need an iPhone to use this service!" banner for everybody
else) has its limitations, of course, and is downright stupid if it's
not an iPhone-specific app/site in some way (take the Tilt game for
example; not being compliant there isn't exactly an issue, as the point
of the game is based on an iPhone-specific feature).

That said, I had to install Internet Explorer 6 via Wine on my mother's
linux computer yesterday, because some web site she needed to access
only supported IE. Believe me when I say that I believe standards are
extremely important and necessary.

-Kalle.

Rui Carmo

unread,
Jul 10, 2007, 3:34:04 PM7/10/07
to iphone...@googlegroups.com
On 10 Jul 2007, at 12:14, Joe Hewitt wrote:

>
> In case you missed it, I kicked off a new thread to talk about the new
> features I added tonight to "Navigation", or "iUI" as it is now
> called.

Erm... What about this:

http://code.google.com/p/iui/

?

It's a bit confusing (since it has Prototype in the source tree), but
predates your e-mail by a few days.

R.


Joe Hewitt

unread,
Jul 10, 2007, 4:09:20 PM7/10/07
to iPhoneWebDev
I know it's a bit confusing, but that is actually the same project.
Kristopher Tate took the first version of my code, massaged it a bit,
and created the iUI project. I didn't check my newest stuff in there
until I asked him if it's ok for me to commit over his modified
version, and he gave the thumbs up. So, there is only one iUI and I
will be committing all changes there from now on.


Joe Hewitt

unread,
Jul 10, 2007, 4:10:04 PM7/10/07
to iPhoneWebDev
Also, the Prototype stuff in there was added by Kristopher because he
was going to use it in his project, but it has no relation to iUI
itself.

Rui Carmo

unread,
Jul 10, 2007, 4:23:58 PM7/10/07
to iphone...@googlegroups.com

Ah, so we do have a standard library, then :)

R.

Reply all
Reply to author
Forward
0 new messages