I am confronted with the same issue as this post Iphone - cellForRowAtIndexPath behaving weirdly when scrolling down and up. I am confused how I should be using different cell IDs for different cells. I have a variety of cells:
cells with switches
cells with checkmarks
groups of cells such that only one is checkmarked
cells that change text after tapping them
cells with indicators
cells with no accessory type
Should I be using a different cell ID for each of these different types of cells?
I would use different reuse identifiers for each different type of cell. That would make it so you won't have to do things like take a checkmark cell and change it to a switch cell. You'll dequeue each type of cell and get back what you expect. Does that make sense?
Related
I am updating my iOS app from table views to collection views to support a "gridded" option.
I have two cell types. One that is more suitable to a "tableView" type look, and takes up the full width of the screen. The other is a cell that is more suitable for grids.
I can't use the same cell type for both because the tableView type cell has a lot more horizontal information than the grid cell.
I have a button press event that will cycle between my cell types, updating the layout and changing the cell reuse identifier appropriately. The problem is, any cells that were already in view do not change to the new cell type. If I scroll for a bit, the new cell types start coming in.
I imagine that this has something to do with the dequeue function for collectionView taking an indexPath. I can explicitly reload those cells to get them to use the new type, but this causes an unwanted animation, not to mention feels like a hack.
How can I switch cell types dynamically?
Linked is a video demonstrating the issue.
https://imgur.com/1Q0Xu9S
As you can see, after I change the cells they remain using the old NIB (with all the extra information). But if I scroll down the new NIB will be used.
There are two solution for this: -
Use two collection view for each type of cell, hide and show respective collection view on click of button.
Remove the collection view from super view on click of button, add again and reload
Recently I have been trying to create a table view with different table view cells. What I want to do is that when users click on each table view cell, it shows an extra cell underneath the selected cell to handle user inputs and the extra section disappears when the cell is unselected.
I am fairly new to iOS development and I am wondering what would be the best way to achieve this. At the moment I am thinking of hiding the extra cells initially and displaying each of them when the cell above is selected.
Any help would be appreciated.
Apple has a great set of sample code that demonstrates the behavior you're looking for — displaying a cell beneath another cell when selected. This behavior is used in Calendar when displaying a date picker, and it's pretty much what you've described.
Question: Will each cell have an identical set of options?
If so, I'd consider including the user inputs as part of the source cell and adjusting the height of the source on selection. You can animate the cell's height changing using tableView's beginUpdates and endUpdates. This way, you avoid messing around with cell indices.
If I have a UITableView with each cell having a different layout. For example, cell 1 has one text field, cell two has two text fields and so on, in this case height of tableview cell varies based on how many text fields it has one below the other. For this specific scenario, will I be able to make use of reuseIndetifier and reuse the cell.
Is tableView reuseIdentifier useful only when layout of each cell is same? Or can I still reuse cells by making use of single identifier but adding textfields in cellForRowAtIndexPath dynamically?
I experimented a bit. I can do some basic reuse of cells by having a cell with empty template/blank cell. But in the cellForRowAtIndexPath I can dynamically create text fields and add. This works perfectly fine, allowing me to add as many number of views required to be added to TableView cell. I am using blank cell, which will be reused on scroll. However I am not sure that will be the impact on performance when I create and add UI elements dynamically to the cell in cellForRowAtIndexPath. Any ideas there?
I have few types of cell in table view and sometimes, for some field, these types are merged in one cell. For instance, I have cells for date and for simple text input, but sometimes those cells can be merged in one like here :
If any chance I can use UITableView standard pool for reusing this cells (inside one that include them).
My concern is when I get 3 cell inside tableView:cellAtIndexPath: (compound cell, date and text cell). When compound cell will be released table view will reuse date and text cell too? How tableView knows if it's use cell or not?
I know it can be done with custom layout for UICollectionView, but I want to know is that feasible for UITableView
I have a UITableView into which I populate a small number of static UITableViewCells (about 6 cells). I am not using storyboards. Each of these cells is a custom UITableViewCell, has a different layout, so I my thought is that cell reuse is never going to happen in this case.
So I am creating these cells beforehand and storing them into an NSArray. In cellForRowIndexAtPath I just return the corresponding cell that is already stored in my array.
Everything works fine with this approach on iOS6. However on iOS7, the visible area of the table view goes completely blank. When I scroll up, the part of the table view that was underneath the main view previously shows the cells (partial cell if the cell was partially underneath before). But the initial visible area of the table view still remains blank.
Two questions here - Is it fine to store the cells in an NSArray and return them in cellForRowAtIndexPath? As I mentioned earlier, the number of cells is small and each cell is unique, no reuse is going to happen while scrolling.
And what is going wrong in IOS7?