- YMMV with iui, if you use it out of the box, you can create a generic application quickly, if you want to change how it works, you have to continue from there onwards. animation is done by tweaking the style and can lead to less-than-smooth transitions. even Joe changed the technique in the FB app to use window scrolling instead
- yes, it's a pain to clone data, just to put it side by side, but it was necessary to get where I have got to. the DOM has a method for cloning elements which works quickly. - the processor in today's iPhone is, if memory serves, a 400Mhz chip, so anything you try to do with regards to Javascript is going to slow your application down. my advice is, the less Javascript, the better - render as much as HTML on the server and dish it up. - GWT is all about Javascript, or at least what I am doing with it (google for "gwt feed reader" for a good example). I chose to generate my UI completely in Javascript, which is necessary in some parts, but otherwise is a choice I'm living with elsewhere. ultimately, it means you have to tread carefully, not be too processor intensive, and build things in the background wherever possible. - use an event model wherever possible. your UI will be unresponsive while processing Javascript. split this up into chunks and implement a command scheduler. /dave On Jan 18, 8:46 am, "Steve Finkelstein" <[EMAIL PROTECTED]> wrote: > Hi David, > > Thank you for the elaborate reply. It is quite annoying that the execution > of JavaScript randomly does not occur. It's gotten to the point where I have > to re-design/re-prototype my entire application because I couldn't figure > out why it was happening. I'm going to try this time around with iUI, > although I see you mentioned in your post it was an issue with iUI as well. > The code GWT is producing seems to be more responsive on your application? > Basically your solution sounds like making a double of every div that you > plan on sliding in and out... ouch. That seems a bit bloated, even though it > might work, I would really like to avoid that as it is a semantic headache. > > I'll be trying to re-create my application with iUI and see if anything > happens. I really wish I did have some solid test cases to report to Apple > about random javascript instances never being invoked by the browser. I > cannot replicate any of these symptoms on desktop browsers, eg > webkit,safari,ff. Only on mobile safari does this become an issue. > > Thanks for the reply, I'll see if I can come up with any other solution. > > - sf > > On 1/12/08, davidroe <[EMAIL PROTECTED]> wrote: > > > > > On Dec 28 2007, 8:09am, "Steve Finkelstein" <[EMAIL PROTECTED]> > > wrote: > > > > It's almost as if the JavaScript never gets called. I slide a hidden div > > into view, > > > and make an XHR call to draw my HTML. I'd say 7 out of 10 times, it will > > draw > > > the rest of the div. At least 3 times no POST request is made. Really > > > disappointing. :-( > > > I have spent a long time trying to get around some strange behaviour > > regarding sliding and Javascript execution. To cut a long story short, > > I would see perfect behaviour most of the time, but then sometimes the > > Javascript interpreter would be unresponsive (although it would come > > back to life if I scrolled the screen). > > > Chances are, the only thing our problems have in common is the levels > > of frustration they are causing and the amount of hair-pulling, but > > nevertheless, this is what I have finally decided is the cause of it > > all - large amounts of off-screen content. > > > To further explain, you know when you scroll a long web page on Safari > > on the iPhone/iPod Touch, you have to wait for parts of the display to > > paint, I presume because the device only holds a certain part of the > > rendered content in memory and otherwise has to go and build the rest > > before being able to display it. Well, I think that problems arise > > when you invoke the Javascript interpreter to scroll content around > > the display, yet part of this content is buffered and part is not. I > > don't exactly know what is going on here, but I've been messing around > > with my particular problem for long enough, running different tests, > > trying to make any sense of it, and this is the only thing that seems > > to fit. > > > I'm able to say this because I have half a solution in place and am > > unable to reproduce the problem - I can slide (in one direction, so > > far) to my hearts content without seeing anything hang. I did this by > > cloning the div currently displayed, cloning the div that is about to > > slide in, put each one in a container div with height 480px, overflow > > hidden, to ensure that displayed content is kept to a minimum, place > > these two divs side by side and perform the slide, finally putting > > everything back in place when it is done. And, to be a little more > > specific, I am sliding using setScroll(), rather than manipulating the > > div's left style, and am using GWT, not IUI, as my toolkit. > > > I hope this helps, in one way or another. I also hope I'm not posting > > again tomorrow, saying that the problem has returned. I have already > > wasted plenty of time on this, and I have already thought that the > > problem had been solved, only to find it turn up again with different > > content. > > > Good luck, > > /dave --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
