Not getElementById... :) getElementsByClassName goes through all of the elements in the DOM with a certain classname and puts them into an array. It's built into the prototype javascript library. I then traverse through the array, doing things to each element. ie.reset any little delete circles in my "favorites" edit page if someone decides to jump directly to another section without hitting the done button. When everything is via AJAX, you have to think in terms of states and to check from time to time that an illegal state doesn't happen.
getElementsByClassName is instantaneous on the desktop and at least 5 seconds on the iPhone. Javascript execution is indeed s l o w, but not just getElementsByClassName. There have been plenty of discussions here re:js speed. getElementById seems ok on the phone though, you are right. -=Randy On Sep 4, 2007, at 8:02 PM, shelly <[EMAIL PROTECTED]> wrote: > > Javascript doesn't seem to run any slower than a desktop browser, I > use getelementbyId a lot not by class but I doubt if that makes a > difference. > For really long lists innerHtml works better than building lists on > the fly from json or xml. I can't beleive how quickly a 300 row table > paints on the device. > > > > On Sep 4, 5:08 pm, Randy Walker <[EMAIL PROTECTED]> wrote: >> There are already inconsistancies in iPhone UI with the built in >> apps. We can only do what we can do, no? That's why I mentioned the >> scolling products on the apple site, something we can easily >> accomplish. I've had my phone for 4 days now & I am flabbergasted at >> how slow javascript really is. I was trying to cut down the amount >> of >> page loads, opting for AJAX & javascript routines running in the >> browser. Forget things like getElementsByClassName. My app would >> sit >> there thinking for about 5 seconds and then come back to life. Ugh. >> I think I have a better way of doing that task that will be instant, >> but geesh! I wonder if they can get safari to run js any faster, or >> is this just the way it's always going to be? >> >> -=Randy >> >> On Sep 4, 2007, at 1:14 PM, rich_wagner <[EMAIL PROTECTED]> >> wrote: >> >> >> >> >> >>> True, but that raises unfortunate design dilemma for >>> iPhoneWebDevers - >>> do you introduce a UI concept like Coverflow in iPhone Safari that >>> provides only partial functionality of the "real thing"? Or does >>> that >>> partial implementation only confuse users who will expect to be able >>> to scroll and flick with their fingers just like they can in the >>> iPod >>> app? >> >>> On Sep 4, 2:47 pm, Randy Walker <[EMAIL PROTECTED]> wrote: >>>> Even with coverflow on iTunes there are left/right buttons to click >>>> on, or click directly on a graphic element that isn't in the center >>>> to >>>> cause movement. It may not be coverflow exactly, but something >>>> similar would be ok with me. Maybe something new and cool for UI >>>> not >>>> seen yet? I like how the products slide left/right on the Apple >>>> website as well. >> >>>> -=Randy >> >>>> On Sep 4, 2007, at 11:16 AM, rich_wagner >>>> <[EMAIL PROTECTED]> >>>> wrote: >> >>>>> Randy/Shelly, >> >>>>>>> Speaking of coverflow, I'm sure we can grab the code used in the >>>>>>> new iPhoto >>>>>>> online galleries that sort of mimics coverflow and use that >>>>>>> somehow. >> >>>>> I'd absolutely love to be able to implement Coverflow, but I don't >>>>> see >>>>> any way that iPhone Safari would allow us to do so since we can't >>>>> trap >>>>> for dragging or flicking. (Relatedly: When viewing a new iPhoto >>>>> gallery with an iPhone, I never see any Coverflow option at all.) >> >>>>> One JavaScript implementation of Coverflow is intriguing (http:// >>>>> www.se51.net/devnull/cover-flow/), though the animation for that >>>>> initial version anyway is jerky on the iPhone. However, even with >>>>> that >>>>> visual emulation, it just supports clicking, not the dragging or >>>>> flicking movement that one would really want and need for a true >>>>> emulation. >> >>>>> In the end, greater touch input event trapping (such as >>>>> onfingerflick, >>>>> etc.) is one of the top 2-3 needs we have to be able to deliver >>>>> robust >>>>> iPhone apps in a Safari environment. >> >>>>> - Rich >> >>>>> On Sep 3, 2:40 pm, Randy Walker <[EMAIL PROTECTED]> wrote: >>>>>> Speaking of coverflow, I'm sure we can grab the code used in the >>>>>> new iPhoto >>>>>> online galleries that sort of mimics coverflow and use that >>>>>> somehow. >>>>>> -=R >> >>>>>> On 9/3/07 10:30 AM, "shelly" <[EMAIL PROTECTED]> wrote: >> >>>>>>> I agree, but is iui , which is basically a clone of the youtube >>>>>>> interface the best interface for media, I think other designs >>>>>>> need >>>>>>> to >>>>>>> be explored before we start talking standard ui designs. >>>>>>> Coverflow >>>>>>> comes to mind. >> >>>>>>> On the other had iui is the easiest to implement and it looks >>>>>>> good. >> >>>>>>> On Sep 2, 2:17 am, rich_wagner <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>>> Here's some thoughts for new developers just starting out with >>>>>>>> iPhone >>>>>>>> app design... >> >>>>>>>> Because the underlying guts of iPhone apps are based on Web >>>>>>>> technologies (CSS, XHMTML, JS, Ajax, etc.), it is tempting >>>>>>>> for a >>>>>>>> Web >>>>>>>> developer to come to the iPhone platform and consider the apps >>>>>>>> that >>>>>>>> they create as a special, customized breed of Web app. After >>>>>>>> all, >>>>>>>> from >>>>>>>> a technology perspective, that is exactly what they are. >> >>>>>>>> However, we need to look beyond implementation. We should have >>>>>>>> the >>>>>>>> mindset that we are creating iPhone applications, not Web >>>>>>>> applications >>>>>>>> that run on the iPhone. The difference is significant-no, not >>>>>>>> from a >>>>>>>> technology standpoint, but definitely from a UI design >>>>>>>> perspective. >> >>>>>>>> On the Web, users expect every Web site/app design to be >>>>>>>> unique. >>>>>>>> Developers naturally have embraced that freedom. However, when >>>>>>>> working >>>>>>>> on a platform, the user expectations are far different. That's >>>>>>>> why, in >>>>>>>> many ways, I would suggest that iPhone applications are far >>>>>>>> more >>>>>>>> like >>>>>>>> Mac or Windows desktop applications than Web apps. Like on >>>>>>>> their >>>>>>>> desktop, users will come to expect a common look and feel- >>>>>>>> whether >>>>>>>> they >>>>>>>> work with a built-in Apple app or a third-party Web app. >>>>>>>> Since we >>>>>>>> do >>>>>>>> not have an API that we have to write to, it is up to the >>>>>>>> developer to >>>>>>>> understand the unique design needs of the platform and build an >>>>>>>> application based upon it. (That's why frameworks like iUI >>>>>>>> can be >>>>>>>> so >>>>>>>> helpful.) >> >>>>>>>> - Rich- Hide quoted text - >> >> - Show quoted text - > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en -~----------~----~----~----~------~----~------~--~---
