Should I really use a UITableView in this situation?

Imagine you have a view like this:

At the top, there is an UISegmentedControl with two segments. It functions like a tab. Pressing one segment will activate this particular content below that UISegmentedControl.

Below the UISegmentedControl are some switches. These modify the way how the content should be rendered.

And finally, below those switches, there's a table. Imagine a table not in sense of UITableView, but just what it really is: A table. It shows little messages like twitter messages or chat messages for example, one below the other. Like you know it from skype and other chats. Basically they're just rows with some formatting. A label, some image views, some lines, a background. Pretty basic.

The data comes from an array. No core data. The whole thing including开发者_如何学Python the segmented control and setup switches must be scrollable.

So what I did is: I put all this stuff in an UIScrollView. Now I have to make the decision if I would use a UITableView inside there for that table part, or if I would just print a lot of rows on to the scroll view (with -drawRect:).

But some problems stick in my head: Can I put a UITableView inside a UIScrollView? I assume this makes a lot of problems. I don't want that the table part is separately scrollable.

Again imagine that view: First there are some basic choice things (segmented control, switches). Then there comes the table. When you scroll, the whole thing scrolls. That's mainly because this first part with the settings can be pretty big, so you would want to scroll it away.

The next thing is: Can I customize UITableView in such a way, that it consists of two parts? One for that settings part, and one for the actual data to display?

Well, if you're going to display labels using drawRect, you'll need to be sure that you are only drawing the part of the screen that the user can see (or you waste a lot of time). Also, you'll need to handle the calculations, which isn't huge, but it's a pain.

Alternately, you could use UILabels and recycle them as they scrolled out of the screen (or you waste memory).

Then, you'll want to encasulate that in a class to keep the code clean. Also, you may want to customize the "rows" of data, either now or in the future. Better put those into a class, too.

By the time you're done, you've re written the table view class, with fewer features and harder to use.

If you don't want the table view class independently scrollable, there is a property that is something like "scrollingEnabled"

ETA:

Yes, it is easy to create different types of cells for different sections. Just return a different cell based on the indexPath.row parameter passed to cellForRow