Carrying that a bit further the following code is not very elegant but
quickly builds a table with a large number of rows.
function updateContent( ) {
if(xmlhttp.readyState == 4 && xmlhttp.status == 200) {
var xml = xmlhttp.responseXML;
if (xmlhttp.responseXML != null) {
//alert("use xml");
} else {
// out = "#media";
// alert("xmlhttprequest is null");
responseText = xmlhttp.responseText;
var ul = document.getElementById(out.substr(1));
ul.innerHTML ="";
ul.innerHTML = responseText;
return;
If you look at the video of our UI here, mooncatventures.blogspot.com,
the large table of media elements is built with simple code similar to
the above, the smaller resultsets are built interatively from the xml
returned in the responseXML. string.
for(var i=0;i<folders.length;i++){
textNodeArray[i] = folders[i].getAttribute("name");
type = folders[i].getAttribute("type");
hrefTargetArray[i] = "#" + folders[i].getAttribute("type") +
"@" +
folders[i].getAttribute("target") + "?" +
folders[i].getAttribute("ItemId");
}
resTargetArray[0] = "#" + tickets[0].getAttribute("type") +
"@" +
tickets[0].getAttribute("target") + "?" +
tickets[0].getAttribute("ItemId")
addToContentLists(textNodeArray,
hrefTargetArray,resTargetArray ,type ,
tickets[0].getAttribute("rcount"));
}
On Sep 4, 11: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 -- 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
-~----------~----~----~----~------~----~------~--~---
