My problem is as follows: At the first startup of my app the cellforRowAtIndex method doesn't load all items of an array, although the numberOfRowsInSection method gives right number of items, exp: numberOfRowsInSection method give 4 items but cellforRowAtIndex method loads only 2 items of these.
But at the second startup loads all items correctly, I hadn't found the reason of this problem, its just so annoying.
I have loaded all objects from an SSL Encrypted HTTPConnection to an array. I have debugged a few times with breakpoints already, but nothing found. The array is loaded with all objects already but cannot be loaded by cellforRowAtIndex method somehow.
Try to make sure that the table is updated after the array ends loading.
or just call [UITableView ReloadData]; after your array is fully loaded.
Related
I have multiple data in my UITableView and when I delete one record.
Don't use didEndDisplayingCell to manipulate the cell or the data source array by the passed index path.
It's just a notification that the specified cell was removed from the table
The documentation also states:
Use this method to detect when a cell is removed from a table view, as opposed to monitoring the view itself to see when it appears or disappears.
The solution is to move the entire code in this method to the location where the cell / data source item is removed and use it before removing anything
The app is crashing because even though you have deleted the object( so now array will have one less element) but you have not told the table view to reset itself according to new datasource. Even cellforRowAt will crash if you delete the last element. One solution is to reload the tableview by calling:
<tableViewName>.reloadData()
but it will produce unnecessary flicker if tableViews are quite large and complex. And the Second thing, You should'nt be using didEndDisplayingCell
numberOfSectionsInTableView and numberOfRowsInSection are both called on my table. The array I'm using has 3 items in it.
cellForRowAtIndexPath is never called. What would cause this behavior?
Might be something to do with the dimensions of your tableView. See this other answer for details. Basically, what is says is that if your tableView is too small, then the cellForRowAtIndexPath method is never called. Try making your tableView smaller, or decreasing the size of your header or footer of the tableView. If this doesn't work, try reloading the table using tableView.reloadData() on the main thread.
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.
Let's assume there exists a UITableView called myTable. Let's say the following sequence of events occur --
Table is fully populated.
The data source is updated (in this case an sqlite3 db, but doesn't really matter), an NSNotifcation happens to indicate that there is new data, the main thread receives the notification and then calls [myTable reloadData].
myTable's UITableViewDataSource's numberOfSectionsInTableView gets called. Assume only 1 section.
myTable's UITableViewDataSource's tableView:numberOfRowsInSection: gets called.
Several tableView:cellForRowAtIndexPath:'s get called depending on the number of rows in the data source.
My question has to do with the interruptability of cellForRowAtIndexPath.
The question --
If a "reloadData" is called and cellForRowAtIndexPath's are getting called AND another reloadData comes in, will the cellForRowAtIndexPath's stop midstream and restart after the calls to numberOfSectionsInTableView and numberofRowsInSection?
Or will the new reloadData be queued, such that all of the cellForRowAtIndexPaths will finish BEFORE the numberOfSectionsInTableView and numberOfRowsInSection get called?
I've looked and have been unsuccessful in finding an answer to this question in docs or the net. I'm concerned that if the data store is updated while the cellForRowAtIndexPaths are "running", the numberOfSectionsInTableView can change which can result in the cellForRowAtIndexPath requesting data for a cell that's now out of range.
Any help would be greatly appreciated.
Since you should only call reloadData on the main thread and since by the time a call to reloadData is done, all of the visible cells have already been loaded, there is no problem to worry about. The second call to reloadData will be made after the 1st one is done.
I don't think it is possible to be in the middle of cellForRowAtIndexPath when reloadData is called assuming they are both called on the same (main) thread (having an async processing on background thread at cellForRowAtIndexPath seems meaningless).
I've been stuck on this for all day.
I have a Nib file with a custom table cell wich I use to load into a
tableView instance variable of a view controller.
In the view controller I have a Search Bar and a Table View IBOutlets and a NSMutableArray to store my data as instance variables, among other stuff.
I have an object wich does asynchronous calls to an external API using Restkit so I define my view controller as it's delegate to receive the data when the request is finishe, save it on the NSMutableArray and then trigger a reloadData.
Because I'm making asynchronous calls the method shouldReloadTableForSearchString is in charge of sending the request and then return NO.
If I return YES instead of NO, making a call to reloadData after, my cells get loaded into the tableView one step back of my calls, that means that if I type the first letter nothing happens but on the second letter I get the results from the first letter. That behavior it's ok because the instance variable are setted after shouldReloadTableForSearchString returning YES. That is expected, Ok.
The problem that I'm facing is that if I use only reloadData, with shouldReloadTableForSearchString returning NO, the cells are not being assigned to the tableView. I checkhed and cellForRowAtIndexPath is being called and every cell is created with the data but it does not show.
Maybe I have problems with the datasource property, but I'm not sure.
I don't get the difference. Any Ideas?