I have had tons of problems with UIWebView in general, so much so that I've just about finished abandoning it. I've been working on a set of native UI components for Callback (that sounds weird...), so I luckily don't need the HTML display of UIWebView, so I'm currently 90% of the way to integrating SpiderMonkey with phonegap, which totally gets rid of any exec() type problems because you get to use a real ObjC<->Javascript interface.
There's another possibility for redoing the exec() stuff that doesn't use a UIWebView. The code that the whitelist stuff uses provides another avenue for communication from JS->ObjC. If you fire off an ajax request, you get a chance to deny it and see the URL, just like with the UIWebViewDelegate stuff, but it doesn't use an iframe. I'm not totally sure if this will fix your problem though. I've start to implement this ajax/URL based approach here: https://github.com/mschulkind/phonegap-iphone/tree/url_exec It's by no means complete, and based off a bit older of a phonegap tree, but it should give you a great starting point if you want to pursue this. This commit in particular has pretty much all of it: https://github.com/mschulkind/phonegap-iphone/commit/f0900c89aff63d45fea2bdfc23ac703c98b9e4df Now, here are the problems I've had: 1) Outstanding UIWebViewDelegate loadRequest... calls block cellForRow... UITableViewDelegate calls. This is a huge problem when the user is dragging a table view (or other component most likely) and the run loop turns to tracking mode, which does not execute UIWebViewDelegate calls for whatever reason. The table view delegate calls normally fire in tracking mode, as they should, but for whatever reason if there's an outstanding web view delegate call, the table view doesn't fire until the web view one runs (until the user stops dragging). This means that as long as the user is dragging the table view and there's an outstanding web view delegate call, the table view doesn't update at all. You just get background color and no rows. I worked around this by using dispatch_async() for any queue flushes in cellForRow..., which causes all sorts of other subtle UI problems. 2) Now this was the huge kicker that sent me over the edge. I've spent 2 weeks trying to track down a HUGE memory leak that I've been having in my app. My only conclusion is that some complex set of events makes the UIWebView leak memory in javascript land left and right, and only on the device, not the simulator. It leaks enough memory that my app crashes from OOM after loading 5-10 new windows. I finally switched to SpiderMonkey for my javascript and all the leaks went away, as well as the cellForRow problem. On Tue, Oct 25, 2011 at 5:46 PM, Becky Gibson <[email protected]>wrote: > On further testing it only seems to be happening on iOS 5 devices. Has > anyone else seen this? Thus, it probably isn't related to the changes to > queuing commands. But, is certainly driving me crazy! > -becky > > > On Oct 25, 2011, at 4:51 PM, Becky Gibson wrote: > > > The notorious Mobile Safari innerHTML bug seems to be rearing its ugly > head again. Jesse or Shaz implemented this type of fix in PhoneGap: > http://blog.techno-barje.fr/post/2010/10/06/UIWebView-secrets-part3-How-to-properly-call-ObjectiveC-from-Javascript > . > > > > However, I think our new queuing mechanism may have broken that. We do > create an iframe and set gap://"ready" to trigger reading the commands from > the queue. However, we always use the same iframe and don't delete and > recreate it. I'm not sure if that is the problem or if it is because we are > now "pulling" the commands from objective-C rather than "pushing" them in > through the iframe.src. > > > > This bit me because I thought some of my functionality wasn't working. > In cases where I was using innerHTML to write to the page in my success > callback I was seeing nothing. I had to debug to see that my methods were > in fact returning success (and a well placed alert in the callback helped as > well). > > > > We really need those automated UI tests to try and catch stuff like this. > > > > -becky > >
