We got UI specs for a change in a page with a table view. The last cell of this table view should be at the bottom of the page. However, if the table view content is longer then the page, then the cell should scroll.
Here are two approaches that I have tried, with success:
Have a UIView of the cell content with a constraint to the bottom of the page, as well as the cell in the table view. If the table view content height < the view height, hide the cell from the table view and use the UIView instead.
Have a buffer cell between the rest of the table view and the final cell. In the viewDidAppear, since it seems to be the place where the table view elements have their height, get the sum of the height of the other cells of the table view. If this sum is smaller then the screen size, set screen size - cellsHeight to a View controller variable, and trigger a table view reload. In the heightForCellAtIndexPath function, when rendering the buffer cell, use the variable's height to define the buffer height. In the first calculation it will be 0. in the second table view calculations , it will be 0 if the cell need to scroll, or whatever the calculation returned if it needs a buffer.
I feel like both of these solutions are dirty. Are there any better way to approach this problem? If not, is there a way to run the second solution without two data reloading?
Related
I am using an UICollectionView to display a list of items in a 2 column layout with equal size of columns. This is obtained by a flow-layout.
Simple.
However, the first row is different from the rest, as it can vary from being full "screen" width or two column width. In continuation hereof, the collection view displays two types of cells (A and B). A is always displayed with full "screen" width in first row and B cells always in columns of two.
An option button can switch displaying type A cell or not.
All this can be brought to work with a flow-layout and proper width sizing of the items through delegates.
Unfortunately, when switching between not displaying type A cell with full width and displaying type A cell, an visual disturbance occur, because the collection view calls first delegate with "sizeForItem" and then collection view calls delegate "cellForItem":
collectionView(_:layout:sizeForItemAt:)
collectionView(_:cellForItemAt:)
This means that the "old" B cell in first row is being displayed with full width for about 1 second or less. Which does not look good.
Difficult to see any solution to this.
Hope someone can.
Below, three images shows how cell B is temporarily being shown with full width before cell A is being shown.
I have a UITableView which have some cells that will be always be there, one cell with a UICollectionView in it that will act like tabs, and finally one cell with a UITableView in it, whose data will change.
Then when the user selects one of this "tabs", I want to reload the nested table to show the correct data rows (the height of this rows will be dynamic).
I have already achieved that the nested table changes on the collection item selection, but the problem I am facing is that the UITableView inside the cell is not sizing properly.
I have build a sample app just to simplify the views. As you can see in the screenshot, the cell that contains the table is not filling the rest of the screen, so the 10 rows are not visible unless you scroll this table.
What I want is this table to fill the rest of the screen. The user must be able to scroll the main tableview, not the nested one, and still see all of the nested table cells.
I can't do this with multiple sections because I will have a header section that will be always fixed on top, if I had another section, it's header will replace the sticky one on scroll.
I have set the rowHeight of the main UITableView to UITableViewAutomaticDimension and an estimatedRowHeight too. I have pinned it to top, left, right and bottom of the cell's ContentView.
Can you help me with this, please? If it helps, I could upload the sample project and link it here.
Thank you very much!
If you are using autolayout then,
Give height constant to nested table view, create outlet for that height constraint.
When you reload that nested table, you will get that table's content size.
Fetch height from that content size and modify height constraint.
I'm struggling with wired kind of problem. I have UITableView with one cell. This cell is only holding containerView with childViewController (second tableView). My problem is that, first tableView(parent) must have UITableViewAutomaticDimension row height but it doesn't work (It dosen't know correct size of that cell with second tableView).
How to get correct size of second tableView) ?
Second tableView (inside Cell) have scrollingEnabled turned off (tableView.scrollEnabled = false), first tableView must have correct size of second tableView in order to provide correct scrolling experience.
Since a UITableView inherits from UIScrollView you can use the contentSize property to get this information. This is how the scrollbar works on the side.
I have done a similar thing before (long ago), so the following is somewhat hazy/ irrelevant/ unessecary. There might be some gotchas with unknown/unrendered cell heights in the embedded tableview. I rememeber having to set the tableview height to a large number (forcing all cells to render) fetching the contentSize then resetting the tableview height to the contentSize.height.
Are you shure you really need second table view? If you have just one cell probably you don't need it. I recommend you to calculate table view height as the summ of it's cells heights. If cells of embedded table view have constant height it could be simple. In other case you also could calculate cells height.
I would like to make my UITableView load covering half of the window with a background view that starts visible, and as the window scrolls, is gradually covered by the table's cells.
Initially, I want to style is like so:
As the user scrolls, the cells will cover the background element.
The only way I could think to accomplish this would be to put the background element behind (and outside) a ScrollView (which is sized to fit over the background element and has a transparent background), put the TableView inside the ScrollView, and set the load coordinates to start the table far enough down. Is there a better way to accomplish my desired design?
I would prefer to avoid this layout because I would like to be able to easily add more cells dynamically as the user scrolls, ideally without having to deal with resizing the ScrollView.
You can take a view inside table view just above the table view cell and make its height whatever you want space in table view and make a outlet of that view. Then in view did load assign the view as table header view like this.
self.tableView.tableHeaderView = self.headerView;
This will be displayed exactly like you given and when user scrolls it will show the below cells and when you want you can change the frame of the header view and your header become invisible. You can do it whenever you want i mean if you want to change height on scrolling or if you want to change on adding more cells.
I have tried looking for an answer to this question but so far I haven't got any luck.
Context
I have a UITableView inside a standard UIViewController (NOT a UITableViewController..). I have subclassed UITableViewCell and all the cells in the tableview are from the same class.
Requirement
I would like to find an efficient way to resize the cells based on the scrolling of the tableview. For example, when the cell is at the bottom of the visible list, the height is X. When the cell moves up on the screen, its height should proportionally increase to 2X.
Additional Info
I am close to just ditch the UITableView way and start making my own control that would implement such a feat by subclassing a UIScrollView. However, I would like to see if it is possible before going this path. I did see some very interesting SO posts but nothing that would put me on the right path.
Any hint or help would be highly appreciated.
You would need to respond to the scroll view delegate method scrollViewDidScroll: and implement it to record the cell at the top of the table view and reload the table view. Then your table view delegate method tableView:heightForRowAtIndexPath: sets the cell height by the relationship between the index path and the top cell index path.
Your main issue is performance while reloading the table view all the time.
If you wanted to roll your own solution it would be along the lines of the above description anyway, but you would be able to be more efficient than the table view as the table view will call the tableView:heightForRowAtIndexPath: method once for every row for every reload in order to calculate the total height of the table content.