In my app I should create a view with a loto of informations; these informations are divided in 4 section, every section can contain text, images lists ecc...
this is a brutal example...
Now I'm dubious to what type of solution to adopt.
In a my fast opinion a big scrollview is difficult to organize. And a big tableview with section is complicated to organize with code... What are your ideas?
UITableView manages the basic appearance of the table, but your app provides the cells ( UITableViewCell objects) that display the actual content. The standard cell configurations display a simple combination of text and images, but you can define custom cells that display any content you want.
UITableView is a subclass of UIScrollView that allows users to scroll the table vertically (the closely-related UICollectionView class allows for horizontal scrolling and complex two-dimensional layouts).
The TableViewController provides the tableview property to access the tableview in the storyboard. It conforms to the UITableViewDelegate and UITableViewDatasource protocol by default. The subclass overrides the delegate and DataSource methods to provide the tableview implementation.
UITableView
is optimized for "reusable" cells, which is appropriate for scrolling in long lists.
Another benefit of using an UITableView
, as others suggested, is that it only instantiate visible cells, so memory consumption is reduced.
In your case, since your content looks specific and non repetitive, I would suggest using a simple UIScrollView
which is easier to use. (UITableView
inherits from UIScrollView
btw)
If memory/performance is an issue, then prefer UITableView
or simply write your own logic to only instantiate views that are visible (by using scrollOffset for example)
EDIT:
On second thoughts, in your case, UICollectionView
is surely a better candidate than UITableView
.
Especially if you plan some day to do something like a 2 columns layout on iPad...
You should go with UITABLEVIEW
, easy to manage easy to understand, more reusability and good memory management
If you have lots of content to scroll through, a UITableView
might help you with keeping memory usage down.
When a cell scrolls out of sight, it gets removed from the view and kept around by the UITableView
for later use (via -dequeueReusableCellWithIdentifier:
). If you run low on memory then I believe that those invisible views (UITableViewCells) will get released. This basically means that your app will only keep views in memory that are actually visible. More will be cached, but can be purged any time if needed.
If you display a lot of data, and just add it all to a UIScrollView
it will potentially use much more memory than if you used a UITableView
. You might have to implement a similar mechanism to what UITableView
does to remove (and potentially release) invisible views.
So, you can basically achieve the same effect, but a UITableView
does a lot of that work for you already.
If you display lots of data (probably more than about two screens full) I'd lean towards using a UITableView
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With