jim

jim

One of the problems with the UIKit at the moment is an issue embedding a UIWebView within a table,...

One of the problems with the UIKit at the moment is an issue embedding a UIWebView within a table, or indeed any type of scroll view which isn’t the web view itself. When displaying small amounts of data everything is fine; you can scroll with impunity. However, with larger amounts you will find that, after scrolling a certain way down, the content of the web view will not be rendered— instead you’ll find a dark grey background in its place. The issue here is that UIWebView contains a scrolling view, which is a private class (you can see it mentioned in the UIWebView headers: it’s called UIWebDocumentView). This private class handles the scrolling and tile-based drawing of the web frame itself, ultimately meaning that if you set the bounds of the web view to the computed size of its content and place it within another scroll view, then only the first few tiles of content will be rendered inside it. Alas, there is no way to make it redraw using only the public APIs. However, the desired effect can be obtained by calling two unpublished methods. One returns the internal document view, the other tells it that it needs to display some more WebFrame content: [[myEmbeddedWebView _documentView] _webCoreNeedsDisplay]; The basic idea is that your view controller (for the table or other kind of scroll view) sets itself as the scroll view’s delegate— if you’re a UITableViewController subclass, this is done for you already. You then implement two UIScrollViewDelegate functions: -scrollViewDidEndDragging:willDecelerate: -scrollViewDidEndDecelerating: These functions can then call the method defined above to have the web frame drawn properly as the view comes to a stop. For a full snippet showing all the necessary code, you can look at this gist on github.

April 22 2009, 9:46pm from alanquatermain.net