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.
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
I understand the concepts of cell re-usability for Xcode 5.0 table views. However, I have one very weird observation which I don't understand and wish anyone of you could enlighten me here. Thanks.
I have implemented a table view with a search bar utility (just on top of the table view). Under each custom cell (prototype cell), whenever a user clicks on it, it will be marked with a checkmark (UITableViewCellAccessoryCheckmark). The number of cells are more than 10.
Observation:
- Without using any search, marking and unmarking a cell is working as intended. Cells are updated instantly along with their checkmarks.
- When doing a search, from the results given, marking and unmarking a cell is also working as intended.
[Problem] Here comes the weird issue: when cancelling a search, an already marked cell (marked during search) does not refresh itself in the tableview unless scrolling up or down is performed!
And hence, I wrote [tableview reload] at the end of tableview:didSelectRowAtIndexPath: method. Obviously, it doesn't refresh the tableview for me. Without further changing any other code, merely modifying [tableview reload] to [self.tableview reload] under the same method works!
Why is the only addition of "self." able to make the table cells refreshed instantly? I have always thought the first argument, tableView, from the method (void) tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath is as equal to self.tableview. Obviously, my interpretation in this case is wrong.
Thank you. I'm sorry for my lengthy post.
My guess is that this UISearchBar comes from a UISearchDisplayController. Is that correct?
If true, that is a common misconception, but an easy one to understand.
When filtering your UITableView entries and showing results, UISearchDisplayController actually overlays the view with its own tableView, UISearchResultsTableView.
Thus, this overlaid tableView also gets to call data source and delegate methods on your implementation, and this is when the tableView argument from tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath stops being equivalent to self.tableView.
This means that calling [tableView reloadData] during filtering actually asks UISearchResultsTableView to reload its contents, not self.tableView, a property of your viewController.
I was following this tutorial: https://developer.apple.com/library/ios/referencelibrary/GettingStarted/RoadMapiOS/ThirdTutorial.html#//apple_ref/doc/uid/TP40011343-CH10-SW1,
where you have a table view.
The table view has Dynamic prototype cells.
During the tutorial, I selected a cell on storyboard, and set the 'Selection' type to: none.
But in the final part of the tutorial, still we were told to add
[tableView deselectRowAtIndexPath:indexPath animated:NO];
line inside the
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
method.
For me this seemed redundant, due to the 'Selection´ is none which I did as above.
Or I am wrong? Since I selected none as Selection in storyboard(for a cell), why do we need that deselect method? The cell won't be higlighted anyway, isn't it?
The row is still selected. The style of 'none' only relates to how it looks when selected.
So yes, you need to deselect the row when you are done with it.
Changing the "Selection" setting in storyboard changes the way that the cell looks when selected. (Thank you rmaddy, that was my mistake)
The line in didSelectRowAtIndexPath will perform some operation when a specific row is tapped, and then removes the selected graphic from the cell that was just tapped.
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.
I'm trying to figure out the best way to do this - I have a UITableView of items which the user has previously selected and which is stored. When you click an item it takes you to a detail page. What I need is to be able to click a button below the table view which reloads the table and changes the accessory so its a tick instead of a disclosure, then the user can un-tick the items and remove them from the list, before clicking another button which reloads the updated table and restores the disclosure accessory.
Question is, what is the best way to "remember" which way to handle the table reload after the click so it knows which way to display it? Would you use the NSUserDefaults to store a flag on the button click or is there a more elegant way to do it? I guess I could use the status of the button, whether it's in one state or another, but I'm guessing there is something in-built I'm missing.
Hope that makes sense - thanks.
Usually I have some 'model object' and depending on array of those objects I construct table. My cellForRowAtIndexPath looks like this:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
InterestsCell *cell = (InterestsCell*)[tableView dequeueReusableCellWithIdentifier:kInterestsCellID];
if (cell == nil) {
...
}
Interest *i = (Interest*)[self.interestsArray objectAtIndex:indexPath.row];
cell.myTfSubview.enabled = i.isChecked;
return cell;
}
If you don't have your model then you can create array of BOOL values and store flags there.