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 -~----------~----~----~----~------~----~------~--~---
