Search code examples
iosuitableviewautolayoutuitableviewautomaticdimension

How to structure complicated table elements


Normally tables are easy to manage , especially since autolayout can do most of the heavy lifting to determine cell sizes and so on. However, there are cases where things become a little bit more tricky like having a table of polls.

A poll in this case consists of labels with variable description lengths, images with varying sizes and a set of options for the user to choose from ( a nested table essentially ).

----Approach 1------

Break each poll into a number of cells

enter image description here

Pros: Its easy to add more fields to a poll in the future, layout is easier to handle for a single cell for each element especially in the case of the nested table. If you need to fall back to manually calculating the size of a specific cell you can do it while keeping everything else on automatic.

Cons: If you have multiple polls you need to keep track which cell corresponds to which poll, and you generally need to do some arithmetic to keep track of whats what.

----Approach 2-----

Have the poll that contains all these elements be one big cell and set the constraints between them appropriately.

enter image description here

Pros: Its easy to implement, maps your model to your cell in a one to one fashion without having to multi-demultiplex your data.

Cons: Autolayout can get hairy with nested tables. For example, for the height of the cell in this case, i used to return UITableViewAutomaticDimension until i realised this wont cut it as a nested table exists that could be any kind of size. Its quite straightforward to calculate the contentsize of the nested table, however, this would mean you would have to calculate ALL of the other elements as well as now you're returning a specific height and not automatic. Your job has become that much harder.

----Outro----

How do you approach issues like that? Approach 1, 2 or something entirely different? I've simplified the structure of the elements here to make things a bit more readable, there's more arcane stuff involved like shadowed views containing the elements you see to create the illusion of a floating card etc.

Thanks everyone.

P.S : If there's already an answer about this somewhere please point me towards that, i just haven't found much on this yet. Hopefully this post can spark some discussion on the matter and help other people in my shoes.


Solution

  • A straightforward alternative suggested by Paulw11 is to use sections and Approach 1. Even though this may not cover cases that have tables within tables within tables, it will suffice for what I imagine is mostly every conceivable case that has a respectable UI.