I ask this because I find it's strange that heightForRowAtIndexPath firstly work with the last cell in my tableView.
Here's what I got, I've 13 sections, each section has only one cell. So when I called reloadData and log the indexPath.section in heightForRowAtIndexPath, the last section's indexPath got printed. Then it started from section 0, then 1, 2, 3, till 11 in order.
This is tested on both device & simulator and both iOS 7 & iOS 8.
Is this the fixed order or only for the case that I test?
Apple doesn't specify the order in which -tableView:heightForRowAtIndexPath: is called.
This means you cannot rely on any particular order. When you call -endUpdates, or any of the reload/insert/delete/move methods, the row heights will be recalculated. UITableView may take advantage of special knowledge (like the currently visible cells) and recalculated row heights in a different order.
Worse, even if you test every version of iOS on every Apple device and get the exact same order every time, the next point release could change it.
If you are using AutoLayout . Fix Constrains Properly . They might make the difference. In iOS * you don't even have to use -tableView:heightForRowAtIndexPath:.
Related
I have a logic regarding the content in the cells of a UITableView where at some point I call tableView.endUpdates(). The behavior of my scenario was the expected in iOS 10, but now in iOS 11 I am seeing that is behaving in a different way.
In iOS 10, user taps a cell, then I perform some logic and when tableView.endUpdates() is called, then tableView(_cellForRowAt:) is called once (at this point, 3 cells are shown in the screen and only one is being reused).
In iOS 11, user taps the cell (at this point, same 3 cells are shown in the screen), and after tableView.endUpdates() is called, tableView(_cellForRowAt:) is called 3 times. This is causing a behavior that it is not suitable for me.
Has somebody experienced an issue like this? How could I do in iOS 11 if I want to "refresh" the content only of the cell the user has tapped?
Can you make an assumption as to when collectionView:cellForItemAtIndexPath: will get called? I have a UICollectionView where each cell is the same size as the collection view. Most cells get dequeued just as they become visible. Sometimes, however, collectionView:cellForItemAtIndexPath: gets called not only for the next index path but also for the one after that (at the same time). For example, if I'm currently seeing index 5, and start scrolling, but 6 and 7 will get dequeued.
Is the way collectionView:cellForItemAtIndexPath: gets called documented somewhere, or are we not supposed to assume any recurrent functionality?
or are we not supposed to assume any recurrent functionality
That is correct. I can name some calls you can make that will cause it to be called, but that's not the point. The point is that your job is to be ready to answer this question correctly and quickly at any moment. The runtime calls you as often as it thinks might be necessary in order to display the current set of cells and in order to make future scrolling as smooth as possible. As some poet says: "That's all you know and you need to know."
I have create custom cell in table view. Each cell is different in terms of UI. I have craetd three cell and identifier for each cell is different. The custom table view cell are not released when I called the method "reloadRowsAtIndexPaths". Here is the link of my project source code
http://www.megafileupload.com/en/file/486016/TableVIewTestSample-zip.html
or
http://www.2shared.com/file/PgExc8W_/TableVIewTestSample.html
When run the code click on "Push" button on the screen and then wait 4 second at the 2nd screen and click back button. The cell are not released.
Can anybody run the code and suggest any fix for this.
I haven't looked at your code but cells aren't necessarily released when you reload. Cells are built to be re-used, so just reloading the data doesn't necessarily free the old cells. (There's no reason to free and re-create a cell if you've already created enough cells.)
In general if you create a tableView and scroll around you shouldn't see any cells released. You should see them released only when you nuke the tableView (that's when it's sure it won't need them again) and a few other situations.
(On the other hand, you might just be leaking the cells.)
This issue exist in iOS 7.0.0 to iOS 7.0.2. The cells do not release when we perform the "reloadRowsAtIndexPaths" method. This issue is solved in iOS 7.0.3.
I have a simple tableView where the value in numberOfRowsInSection depends on the type of data I am displaying, ie, names or details, etc..
The table is first loaded with certain details where the row count is 6. I added an NSLog statement and indeed I am returning 6 rows.
I also have to set the row height and again, my log statements says it is being called 6 times. great. My problem is cellForRowAtIndexPath is only called 5 times. it's missing the last call.
Note: I have a toolBar that reloads the table with different options. When I select a new option then go back, the table populates properly. It has 6 rows as it should have.
Everything is connected properly: delegate, datasource and outlet as proven by the fact that the table is being partially loaded. Does anyone have any idea why this is happening or how to fix it?
If your last cell is not visible on the screen the method cellForRowAtIndexPath won't be called if you don't scroll and make the cell visible.
I'm new to iOS and MonoTouch, and I have a pretty basic need - I have two vastly different views to display in the same table cell depending on whether it is selected or not. When you load the app I'll present a list of products in a custom UITableView, with all the rows deselected and each row basically just showing the product names in a label. As soon as a user taps one of the rows and selects it, I show a very different view with more of a shopping cart layout. Since the two views are so different they have vastly different sizes. What i need is for the cell itself (or row?) to grow and shrink according to the natural height of whichever view is currently being displayed.
I'm using descendants of UITableViewController, UITableViewSource, and UITableViewCell for the solution. What I do is add both versions to the cell's ContentView, then set the Hidden property as needed when the cell/row is selected/deselected to show the right layout. That works well. I'm in demo mode right now, so I'm not overly worried about efficiency or responsiveness, that will have to come later.
I know that GetHeightForRow is responsible for sizing the rows but it only gets called once, when the cell is first shown. It seems to me that I need to alert the TableView to re-poll the source for a new size as the views are changing, but I can't figure out how to do it.
I tried (rather hopefully) to cause GetHeightForRow to be invoked again manually using Cell.SetNeedsLayout and Cell.SetNeedsDisplay, hoping that would cause the table to re-query the source for new dimensions, but no joy.
I tinkered with the direct approach, trying to size the contentview itself but it didn't seem as if it was leading anywhere. I feel as if the table needs to be told to query for a new row size, but I'm open to any suggestions.
Surely I'm not the first to attempt this? What am I missing?
Try forcing GetHeightForRow to be called again by calling ReloadRows instead.
You may or may not have to specify begin/end updates (this might just be for animation, though?)
tableView.BeginUpdates();
tableView.EndUpdates();