I've thought of a couple of approaches to use inside the - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath method:
Create outlets and link the cells to them, then check which one was selected by comparing the reference
Set and check a unique reuseIdentifier property on each cell
Use the indexPath, because you know which cell is at which index since they're defined statically anyway
What is the best approach? Or perhaps there's another, better approach?
Definitely indexpath is the best approach as many of the delegates of tableview works on indexpaths. You can easily get hold of the rows by keeping a track of indexpath. I guess you can also put to use the property of cell called 'selected' to check whether a cell state is selected or not. Hope this helps. Also make use of apple docs on tableviews.
Related
I have two custom models of TableViewCell, one for just basic informations and another for detailed informations.
How can I switch to the detailed one with the didSelectRowAtIndexPath method? (and afterwards if the detailed one is displayed, toggle to the basic one on select)
Thank you.
When the row is selected, toggle a flag indicating that the row needs to switch from one type of cell to another. Then reload the the cell at that index path.
Then your cellForRowAtIndexPath method looks at the flag for the given index path and returns one of the two types of cells.
In whatever kind of object you use to represent cell data, keep a flag for whether it's selected or not. Turn the flag on or off in didSelectRowAtIndexPath and then reload the table view data. When you return a cell for an index path, choose which kind of cell based on the flag value.
You can create an array or set consist of indexPaths of cells type 1. Add or remove from it cells if needed. Return the right cell in
- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
And if you want to reload specific cell, modify your array of cells and just call from tableView:
- (void)reloadRowsAtIndexPaths:(NSArray *)indexPaths
withRowAnimation:(UITableViewRowAnimation)animation
The design of the app I am working on, specifically the tableview part is quite complicated.
There are around 5-6 methods in which I need to get a reference to particular cell from the table view.
What I do not like is that I have to use the
-tableview:cellForRowAtIndexPath
This is a datasource method and does a lot of heavy lifting. Custom cell configuration, dequeueing, getting data for particular cell..etc.. The point is all this code is executed again,even if it does not make any sense at all. The cell object is completely loaded already.
Am I right in my observation and if yes, is there a working tested and lightweight solution?
Perhaps there could be an index of references to all cells. Asking it, I would immediately get the reference without the datasource code.
UITableView has cellForRowAtIndexPath: method.
From UITableView reference:
Returns the table cell at the specified index path.
- (UITableViewCell *)cellForRowAtIndexPath:(NSIndexPath *)indexPath
Parameters
indexPath The index path locating the row in the receiver.
Return Value An object representing a cell of the table or nil if the cell is not visible or indexPath is out of range.
As a user scrolls up and down in an uitableview cells get destroyed and created.
Is there a way to detect when a cell is going to be or has been destroyed?
Assuming that by "getting destroyed" you actually are referring to a cell getting reused, simply implement prepareForReuse within your UITableViewCell derived class.
prepareForReuse
Prepares a reusable cell for reuse by the table view's delegate.
- (void)prepareForReuse
Discussion
If a UITableViewCell object is reusable—that is, it has a reuse
identifier—this method is invoked just before the object is returned
from the UITableView method dequeueReusableCellWithIdentifier:. For
performance reasons, you should only reset attributes of the cell that
are not related to content, for example, alpha, editing, and selection
state. The table view's delegate in tableView:cellForRowAtIndexPath:
should always reset all content when reusing a cell. If the cell
object does not have an associated reuse identifier, this method is
not called. If you override this method, you must be sure to invoke
the superclass implementation.
Availability
Available in iOS 2.0 and later.
See Also
– initWithFrame:reuseIdentifier:
#property reuseIdentifier
Declared In
UITableViewCell.h
Without going into the implications of suitability or performance, another option might be to periodically check what cells remain visible, using the visibleCells method of the UITableView class:
- (NSArray *)visibleCells
As per the documentation:
Returns an array containing UITableViewCell objects, each representing a visible cell in the receiving table view.
You can subclass UITableViewCell and override it's dealloc method.
Any good reason to do it assuming you are reusing the cells to save the resources ?
What you're attempting to intercept is part of the internal implementation of UITableView and how it manages its cells. While there are ways in which you can attempt to intercept such behavior, I would suggest that you avoid using them, as there is no guarantee that future implementations of UITableView will maintain this behavior.
It would be better in cases such as this to consider a different approach: be it design and implement your own table class, or change your code logic.
As stated above, cells aren't destroyed when the leave the screen. However there are some things you can do, to track related actions, depending on what you are trying to do.
First there is a delegate message:
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath
This is called before a cell enters the screen. Another possibility is the already stated prepareForReuse method of a cell.
Another approach would be: Try and override willMoveToSuperview: or any other of the related methods. I am not sure if this is fired after the cell becomes invisible, but it might work.
Best regards,
Michael
I want to use the power of UITableViewCell like disclosure accessory, but I don't need the whole UITableView. Is this possible and appropriate to do so ? I don't see any delegate on UITableViewCell, so don't know where should I put code previously in - (void)tableView:(UITableView *)tableView accessoryButtonTappedForRowWithIndexPath:(NSIndexPath *)indexPath; any references or suggestions on this ?
Correct me if im wrong but .. Why would you use a cell like that ? If you dont want to use the power of the UITableView you can just add a view and do all the stuff you do in your cell. And that would keep the Apple Standard too.
You could just make a UITableView with one section and one row, and load that cell into it. This would be pretty easy to do and wouldn't run the risk of running afoul of the Apple review board.
Ok, I have a grouped TableView that has the following overridden method:
-(NSIndexPath*)tableView:(UITableView *)tableView willSelectRowAtIndexPath:(NSIndexPath *)indexPath{
return nil;
}
... Obvious enough, to disable selection.
BUT!
If the user presses and holds on a cell, it gets highlighted (selected)!! I need to disable this, too.
On a side note, I am using the tableView to display static Data, almost like the About tableView in Settings > General. It just loads the info from an array of strings that I created manually.
If there is a better way to represent the data, please do tell!
Thanks!
Set the selectionStyle property of the cell to UITableViewCellSelectionStyleNone.
See the documentation for tableView:willSelectRowAtIndexPath: to see why this is needed even though you're indicating that you don't want the cell selected.
[cell setSelectionStyle:UITableViewCellSelectionStyleNone];
...did the trick.