Resizing large UITable grinds app to a halt - iphone

Question

I have a UIViewController that contains a UIScrollView which itself contains both a UITableView and another UIScrollView. Inside the nested UIScrollView is another UITableView.
When the in ViewDidAppear of the UIViewController I calculate how big the tables should be (much bigger than the screen) and set their sizes and then set the content size of the UIScrollView to match the tables they contain (the UIScrollView will provide the scrolling rather than the table itself). This all works fine in the simulator, but on an actual device, it grinds to a halt, pegging the processor at ~100% for tens of seconds. This is obviously unacceptable. Does anybody have any idea why? Or how I can work around it?
The code looks something like this:
OuterScrollView.ContentSize = new SizeF (View.Frame.Width, tableHeight);
InnerScrollView.ContentSize = new SizeF (InnerTable.Frame.Width, tableHeight);
InnerScrollView.Frame = new RectangleF(InnerScrollView.Frame.Location,
new SizeF(InnerScrollView.Frame.Width, tableHeight));
// So far so good
OuterTable.Frame = new RectangleF(OuterTable.Frame.Location,
new SizeF(OuterTable.Frame.Width, tableHeight)); // this slows everything down!!
InnerTable.Frame = new RectangleF(InnerTable.Frame.Location,
new SizeF(InnerTable.Frame.Width, tableHeight)); // and so does this
Removing both of the table .Frame setting statements and everything works quickly enough, but with them in it's very slow. And the slowness doesn't come directly here, but somewhere after the call to the base ViewDidAppear.
Update: I had an epiphany and thought if resizing the table is the problem, just make the tables big enough that they don't need resizing. In the setup I have, the scrolling is being handled by the scroll view not the table itself, so I could just set the table as really big and let the scroll views ContentSize take care of clipping the blank part of the table. This works, in the sense that it displays how I want it to, but it's actually even slower! So my conclusion is that it's not the table resize that is the problem, but rather the presence of really long (in this case I set the height to 4,000 - the resize was setting it to 2,354) tables.
Background: To add a little more to what I'm trying to do. Since Apple, in their wisdom, decided that nobody needs a grid like control, I'm trying to set up a situation where I have a grid-like view where the left most columns stay in place, but you can horizontally scroll the right-most columns, and, when you scroll vertically, everything will stay in sync. After some searching, I came across a solution (sorry, can't remember exactly where), which with a little tweaking works (in the simulator). Basically, you embed tables in a scroll view so that the scroll view can handle the scrolling. The layout looks something like this:
+-------------------------Outer Scroll-------------------------+
| +---------------Inner Scroll---------------+|
|+--Fixed Table--+ |+---------Scrolling Table----------------+||
|| | || |||
|| | || |||
|| | || |||
|| | || |||
|| | || |||
|| | || |||
|+---------------+ |+----------------------------------------+||
| +------------------------------------------+|
+--------------------------------------------------------------+
The fixed table has a custom cell with a couple of columns while the scrolling table has another custom cell (wider than the screen) with the rest of the columns. You can scroll the scrolling table horizontally (thanks to the inner scroll view) and you can scroll everything vertically thanks to the outer scroll view.
Another Update: So it seems the problem is with the table not reusing cells when you set it large. I guess the cell reuse logic only extends to determining if the cell is within the frame of the table and not if that part of the table is actually visible. So with 50 items, instead of displaying 6-7 and then re-using those cells, it creates all 50 regardless. So I abandoned my earlier attempt and tried to synchronize the scrolling between two tables like this:
OuterTable.Scrolled += (sender, arg) =>
{
InnerTable.ContentOffset = new PointF(InnerTable.ContentOffset.X,
OuterTable.ContentOffset.Y);
};
InnerTable.Scrolled += (sender, arg) =>
{
OuterTable.ContentOffset = new PointF(0, InnerTable.ContentOffset.Y);
};
This almost works, except iOS doesn't like horizontal scrolling for tables, so the inner table still needs to be wrapped in a scroll view (set with the ContentSize to cover the width I need to scroll). At this point it almost works. It will usually keep seemlessly in sync, but with a bit of messing around you can get, for example, the inner table to scroll diagonally (despite setting direction lock on everybody) and in some cases it's possible to get them out-of-sync, which looks really stupid. So it doesn't quite work as well visually, but at least it doesn't hang up the UI thread as badly.

Answer 1

Have you tried doing this with autolayout? There you are not responsible for when the views actually get resized, just setup the constraints in viewDidLoad and let the rest be taken care of by the system.
But in the terms of manual layout - I don't see why this would actually happen. When you profiled it with Instruments, what was the slow portion in Time Profiler?

Answer 2

From the documentation:
Important: You should not embed UIWebView or UITableView objects in
UIScrollView objects. If you do so, unexpected behavior can result
because touch events for the two objects can be mixed up and wrongly
handled.
Your interface might appear slow because touch events are getting handled by the wrong objects. This can make scroll views appear to jump around, act laggy, or not respond at all.
Can you describe the behavior you're going for? Can you achieve what you want using only a UITableView with a UIScrollView in it, or perhaps a UICollectionView?

Answer 3

It appears that the only way for your proposed implementation to work is to load ALL the UI at initialization, which eliminates the performance benefit of using a UITableView at all. It will be considerably more efficient (from a memory perspective) for you to have a top level UITableView that scrolls normally, and contain a horizontally scrolling UIScrollview within each cell.
+-------------------------Table View---------------------------+
|+-----------------------Table View Cell---------------------+|
||+--Fixed Section--+ +---------Synched Scroll View---------+||
||| | | |||
||| | | |||
||+-----------------+ +-------------------------------------+||
|+-----------------------------------------------------------+|
|+-----------------------Table View Cell---------------------+|
||+--Fixed Section--+ +---------Synched Scroll View---------+||
||| | | |||
||| | | |||
||+-----------------+ +-------------------------------------+||
|+-----------------------------------------------------------+|
|+-----------------------Table View Cell---------------------+|
||+--Fixed Section--+ +---------Synched Scroll View---------+||
||| | | |||
||| | | |||
||+-----------------+ +-------------------------------------+||
|+-----------------------------------------------------------+|
+--------------------------------------------------------------+
The important step is synching the horizontal scroll views, which you can do by sending NSNotifications or custom delegate messages on -scrollViewDidScroll:
It may feel wasteful to be creating 10+ scrollviews within table view cells, but in practice it ends up being fairly efficient.