I have a UITableView where every cell either gets/loses a checkbox or goes to another table view when clicked. For every table, I want to add a check all button that checks off every cell in that table and all the ones inside it. How do I allow one UITableViewCell to toggle the checkbox of every one in it's TableView?
EDIT: Removing the last index in the index path, and replacing it by the new row number, I'm able to go through the entire table and check it off, like this:
for(int i = 0; i < [tableView numberOfRowsInSection:0]; i++){
UITableViewCell *newCell = [tableView cellForRowAtIndexPath:[[indexPath indexPathByRemovingLastIndex]
indexPathByAddingIndex: i]];
newCell.accessoryType = UITableViewCellAccessoryNone;
}
Oddly, it skips over every tenth cell or so - and it's not even consistent. For a list of years, sometimes it doesn't check off 2003 and 1993, sometimes 2003 and 1991, and and so on. It's always around every tenth cell or so, but I can't find a pattern.
When you click the cell didSelectRowAtIndexPath will be called, at that point all you gotta do is use tableView cellForRowAtIndexPath:indexPath method in order to get back all your cells one by one and set their accessory type to checkmark...hope this helps
EDIT: Another way to do it is, if you have maybe some sort of array (hard to tell you what to do exactly without looking at your code), but if you have some array that holds values as to which cells need have check marks on them, then you can use in cellForRowAtIndexPath to assign the checkmark accessory, so when your cell is selected, you can set all the values in the array to what you need them to be and just call UITableViews reloadData...hope that made sence :), heres a little snipet of code to try and make it more clear
lets assume you have 1 section and x amount of rows
NSMutableArray shouldHaveCheckmark; //this array will be of size x
//(one for each row) and hold NSNUmbers 0 means not checked 1 means checked you initialize
//this somewhere (viewDidLoad maybe) and should be declared in your .h file
//this is cellForRowAtIndex path
-(UITableViewCell)cellForRowAtIndexPath:(NSIndexPath*)path
{
UITableViewCell *cell=...
if([[shouldHaveCheckmark objectAtIndex:path.row] boolValue] )
//assign checkmark accesory
//other code
return cell;
}
So you can see in didSelectRowAtIndexPath you can just flip the numbers in the array and call reloadData on the tableView...that approach will work as well
Related
I am new to iphone.I have a small doubt that is,I have a table view with 66 rows initially i placed a progress view to all rows but in viewdidload i set it to hidden for all those like below in tableViewClass(ShowProgressViewCont)
cell.progressView.hidden = YES;
here (cell) is the the reference of the CustomCell class.In this class i declare a progress view and setter and getter properties also be set here in this class
here in tableview there is a download button in each cell.If we click on that download button(for example in 66th cell).we have to remove the hidden property to the progress view for that particular 66th cell only.The remaining 65 cells should have the progress view in hidden only like that for all cells.
If any body know this please help me....
Are you familiar with the concept of table cells being reused?
viewDidLoad is not an appropriate place to manipulate the content of a single cell. It may work fine if the table is so small that all of its cells fit on the screen (in both orientations).
When there are more cells in the table than beeing displayed on the screen, then those cell that became invisible recently is being reused and displayed again.
So if there are 6 cells on the screen at a time then table cell no. 7 (sometimes 8) will be identical with cell no. 1.
cellForRowAtIndexPath would be a better place to hide/unhide certain views of a cell.
If it is a custom cell already then the cell's layoutSubViews could be appropriate, too. However, only in the tableViewController's cellForRowAtIndexPath you will have easy access to both, the table's data and the associated cell.
cellForRowAtIndexPath is called every time when a cell is about to become visible. Use the default reusing-mechanism to ensure that a proper cell object will be reused. It is pretty much straight forward.
Get the cell at index 65 and then cast it to your custom cell
UITableViewCell *cell = [tableView cellForRowAtIndexPath:[NSIndexPath indexPathForRow:64 inSection:0]];
YourCustomCell *customCell = (YourCustomCell *)cell;
customCell.progressView.hidden = NO;
First set the row number in your download button in CellForRowAtInedexPath
downloadButton.tag = indexPath.row
[downloadButton addTarget:self action:#selector(actionDownload:) forControlEvents:UIControlEventTouchUpInside];
in actionDownload, make the IndexPath from button.tag and get the cell from "cellForRowAtIndexPath:",
finally update via reloadRowsAtIndexPaths: withRowAnimation:
Hide your progress view in your custom cell means make the default property of every progress view is hidden ,and then your button click method .
CutomeCell *cell = (CutomeCell *)[[button superview] superview];
[cell.progressView setHidden:NO];
NSIndexPath *rowToReload = [[self tableView] indexPathForCell:cell];
NSArray* rowsToReload = [NSArray arrayWithObjects:rowToReload, nil];
[UITableView reloadRowsAtIndexPaths:rowsToReload withRowAnimation:UITableViewRowAnimationNone];
may this help you ...
your model should be tracking the progress for every button clicked. for purposes of this answer, let's say the model is held in a property called modelInformationArray (which would contain an array of objects that relate to each cell in the table)
when the download button is clicked for a cell, modelInformationArray is modified in such a way that its object knows a download is being processed for it.
that object reports the downloading processing in a member called downloadingProcessingStarted. there are many other ways to do that part.
to get to the answer to your question … to then unhide the progress view, you would do something as follows in your UITableViewDataSource implementation of tableView:cellForRowAtIndexPath: .
- (UITableViewCell*)tableView:tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath {
YourCustomCell* cell = ...
if ([[self.modelInformationArray objectAtIndex:indexPath.row] downloadingProcessingStarted])
cell.progressView.hidden = NO;
}
So I've been trying to load cells from a UITableView and put those into an NSMutableArray to be iterated through later. I have a method called populateArrayWithCells which works fine until I put in more than 6 cells. For some reason the object returned is nil. My code is below, StocksAndAccounts is the UITableView and I have subclassed the UITableViewCells in section 1.
- (void) populateArrayWithCells
{
for (int i = 0; i < [StocksAndAccounts numberOfRowsInSection:1]; i++) {
if ([StocksAndAccounts cellForRowAtIndexPath:[NSIndexPath indexPathForRow:i inSection:1]] == nil) {
NSLog(#"object at index %i is nil", i);
}
[stocksCells addObject:[StocksAndAccounts cellForRowAtIndexPath:[NSIndexPath indexPathForRow:i inSection:1]]];
}
}
This function, when called through an IBAction, returns the cell successfuly until the index is 6, in which case it is nil and crashes because it's trying to add an object that is nil. Any help with this problem would be greatly appreciated.
I think you've misunderstood how UITableViews work. The cells in a tableview are only loaded when they need to be displayed, and they are recycled, so if you can only see six cells on screen at a time then the table will only ever contain six cells and it will just keep updating and reusing those same six as you scroll up and down.
Instead of storing data in your table cells, store it in an array of custom objects in your view controller and use those objects to populate the cells when the table requests them from your datasource methods.
That way if you ever need to use that data for something other than displaying in the table, you can re-create it from the original object instead of trying to copy it out of the table cell.
You are doing it backwards.
Your NSMutableArray (and preferably a sturdier model than that) should be holding what you want to display in your UITableView, not the other way around. Please review the Model-View-Controller design pattern.
I've discovered a strange behavior with setSelected:animated: in my custom UITableViewCell class. I discovered that this function gets called multiple times if I click on a cell in my table. I am wondering if this is normal behavior or a bug in my code.
To help with debugging, I've modified the setSelected:animated: function in my custom UITableViewCell class implementation as such:
- (void)setSelected:(BOOL)selected animated:(BOOL)animated {
[super setSelected:selected animated:animated];
// Configure the view for the selected state.
if (selected)
NSLog(#"Yes %X", &self);
else
NSLog(#"No %X", &self);
}
If I click on a cell in the simulator, here is what I get in the console:
2011-03-22 22:05:26.963 marketPulse[3294:207] Yes BFFFDDD0
2011-03-22 22:05:26.964 marketPulse[3294:207] Yes BFFFDE30
You would think that I would get only 1 entry, since I only clicked on 1 cell.
And if I click on a different cell after that:
2011-03-22 22:07:11.014 marketPulse[3294:207] No BFFFD890
2011-03-22 22:07:11.016 marketPulse[3294:207] No BFFFDD00
2011-03-22 22:07:11.017 marketPulse[3294:207] Yes BFFFDDD0
2011-03-22 22:07:11.017 marketPulse[3294:207] Yes BFFFDE30
If I click on the same cell 2 times in a row, I get more than 2 Yes:
2011-03-22 22:08:41.067 marketPulse[3294:207] Yes BFFFDDD0
2011-03-22 22:08:41.068 marketPulse[3294:207] Yes BFFFDE30
2011-03-22 22:08:41.069 marketPulse[3294:207] Yes BFFFDE30
The more times I click the same cell, the more Yes I will get, and if I click on a different cell after that, I'll get a lot of No
I put a breakpoint before the NSLog, and looking at the debugger, it seems that all the repeated calls are coming from the same object.
Here is a part of my tableView:cellForRowAtIndexPath: function so you can see how my cells are being treated:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
static NSString *ContentCellIdentifier = #"newsTableCellContent";
UITableViewCell *cell;
//index of cell data in tableData
NSUInteger index = indexPath.row / 2;
...
//content of story
else if( [indexPath row] % 2 == 1 ) {
cell = [tableView dequeueReusableCellWithIdentifier:ContentCellIdentifier];
if (cell == nil) {
NSArray *topLevelObjects = [[NSBundle mainBundle]
loadNibNamed:#"newsTableCells"
owner:nil options:nil];
for (id currentObject in topLevelObjects) {
if ( [currentObject isKindOfClass:[newsTableCellContent class]] ) {
cell = currentObject;
break;
}
}
}
((newsTableCellContent *)cell).content.text = [[tableData objectAtIndex:index] description];
}
return cell;
}
Everything works fine so its hard to tell if the repeat calls to setSelected:animated: are intentional or not. If this is normal operation, I can make do with another method, but I would just like to know if this is suppose to happen or not.
Thanks
What's going on is simply that the UITableView keeps track of which cells are selected in the table.
Since cells are reused when you scroll through a large table view, the table view has to keep the list of selected cells separate. Not only that, but whenever it reuses a cell it has to set its selected property, because it may be using an old, invalid selected state from a previous incarnation.
When you tap a cell, several things happen: the previously selected cell is deselected (using setSelected:). The new cell is highlighted. It's de-highlighted (at least if you tap, instead of holding your finger down), and the setSelected: method is called because the new cell was selected. That's one.
The second call is a delayed perform call, possibly from a point where the table view didn't yet know what the final state of the table would be. This call goes to _selectAllSelectedRows, which, as the name suggests, calls 'setSelected:animated:' on all selected rows. That's the second call. The reason for this is most likely to address potential issues due to the the table view being in a "transition", but who knows.
Whether it's a bug or not is up for interpretation. A fix for the duplicate calls is to simply do:
if (self.selected == selected) return;
right before the call to super (you do not have to call super if self.selected == selected).
This is a normal behavior if you're using iPad. (it is only called once on iPhone).
In order to stop getting multiple "setSelected:YES" or multiple "setSelected:NO", all you have to do is this:
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
[tableView deselectRowAtIndexPath:indexPath animated:YES];
}
Now, 1 click on any cell gives you:
1 entry of setSelected:YES animated:NO
1 entry of tableView: didSelectRowAtIndexPath:
1 entry of setSelected:NO animated:YES
So, calls are now stable regardless of what you do.
Ideally you should not be calling setSelected from anywhere in your code.
UIKit will take care of calling it.
If you want to show a cell/row as selected in cellForRowAtIndexPath method simply call
tableView.selectRowAtIndexPath(indexPath, animated: true, scrollPosition: .None)
for that specific indexPath.
Again never ever call setSelected explicitly unless you really mean to.
It should definitely be called when table is scrolled. Cells are reused, that means, if you scroll cells in invisible areas will be reused and reinitialized, including the call to setSelected, which is basically a lightweight property setter.
If you really want to see what's happening, add a NSLog to tableView:cellForRowAtIndexPath: which will log indexPath and the returned cell.
The entire log should give you a good understanding what happens inside and why.
I suppose it will be something like this (Clicked on IndexPath 1:1)
Give me cell on 1:0 (previously selected cell).
Deselect 1:0
Give me cell on 1:0 again (updated after deselection)
Deselect 1:0 (update selected flag on this cell and trigger animation)
Give me cell on 1:1
Select 1:1
Give me cell on 1:1 again (updated after selection)
Select 1:1 (update selected flag on this cell and trigger animation)
Clicking on a selected cell again is only slightly different - instead of triggering unselecting, it triggers another update.
I have a table view which I'm using for some settings in my app. The tables cells are all default (no customisation at all), and simply contain some text for their label and a UISwitch for the accessory view.
My problem is that I need a reference to the switch so that I know when it has been switched on and off.
Currently I am setting the 'tag' property of the switch to be that of the cell's index within the table (grabbed from [indexPath row] in tableView:cellForRowAtIndexpath:).
This is fine when you only have one Section in your table, but I am now adding a new section. The problem is that they are both 0 based indexed so the switches in each section will end up reusing the tags - which isn't good.
Any suggestions on a better way to achieve this?
Thanks.
If you know roughly how many sections and rows you will have, like oh, say, not more than 1 million rows per section, just hash the section and row like this:
const int oneMillion = 1000000;
int tag = (section * oneMillion) + row;
slider.tag = tag;
Then, to figure out the section and row, reverse the logic:
int tag = slider.tag;
int row = tag % oneMillion;
int section = tag / oneMillion;
NSIndexPath *indexPath = [NSIndexPath indexPathForRow: row inSection: section];
Now get the slider that is in the cell in that section,row of the table
UITableViewCell *sliderCell = [tableView cellForRowAtIndexPath: indexPath];
UISlider *slider = [[sliderCell.contentView subviews] objectAtIndex: 0];
This assumes the slider is always the only view in the contents of the cell.
This method is a bit longer than some of the other suggestions above, but it keeps you from having to cache references off to the side.
For each cell, set a delegate link back to the table view controller, and also some kind of row reference ID - then wire the switch to a cell IBAction method, that calls back to the delegate with the reference ID for that cell.
What you can do is either have an Array of arrays or a dictionary, key it by the section number (or in case of the array they will be in order of the section numbers), now to retreive a switch all you do assuming you know the section and the row number
UISwitch *switch=[[switchArray objectAtIndex:section] objectAtIndex:row];
or if you have a dictionary
UISwitch *switch=[[switchDictionary objectForKey:section] objectAtIndex:row];
The standard Grouped UITableView style allows UITableViewCells to be drawn with rounded corners at the top and bottom of each section. How is this accomplished? How does the cell know its own location within its section, and how does it know when to change its rounded edges?
I want to make my own rounded cells, and I have images to use, but don't know when to show which image
Note: I already know how the UITableView works, and I know how to use it. I just thought that since a UITableView is able to automatically draw rounded corners at the correct places, I should be able to as well, without needing to add anything to my data source or delegate.
NSIndexPath *indexPath = [(UITableView *)self.superview indexPathForCell: self];
int rows = [(UITableView *)self.superview numberOfRowsInSection:indexPath.section];
if (indexPath.row == 0 && rows == 1) {
// the one and only cell in the section
}
else if (indexPath.row == 0) {
//top
}
else if (indexPath.row != rows - 1) {
//middle
}
else {
//bottom
}
It's very simple. suppose cell is the object, whose position is to be found out.
UITableView* table = (UITableView *)[cell superview];
NSIndexPath* pathOfTheCell = [table indexPathForCell:cell];
NSInteger sectionOfTheCell = [pathOfTheCell section];
NSInteger rowOfTheCell = [pathOfTheCell row];
There is sectionLocation method of UITableViewCell that returns integer telling you what you need:
1 - middle cell
2 - top cell
3 - bottom cell
4 - single cell
I had no issues using this in several production apps since 2010.
UPDATE: one of our binaries was automatically rejected recently (end of 2018) because we were using 'sectionLocation' property, so it's not a good option anymore.
Add something like this into your header files and you can use it:
typedef NS_ENUM(NSInteger, MMMTableViewCellLocation) {
MMMTableViewCellLocationUndefined = 0,
MMMTableViewCellLocationMiddle = 1,
MMMTableViewCellLocationTop = 2,
MMMTableViewCellLocationBottom = 3,
MMMTableViewCellLocationSingle = 4
};
#interface UITableViewCell ()
/** Undocumented method of UITableViewCell which allows to know where within section the cell is located,
* so the cell can draw its borders properly. */
- (MMMTableViewCellLocation)sectionLocation;
/** Override this one to know when the value of sectionLocation changes. */
- (void)setSectionLocation:(MMMTableViewCellLocation)sectionLocation animated:(BOOL)animated;
#end
You can use
- (NSIndexPath *)indexPathForCell:(UITableViewCell *)cell
for this issue. In my example I am using this to scroll the cell (with custom content) to the top of the view.
If you need more robust and general stuff, take a look at http://cocoawithlove.com/2009/04/easy-custom-uitableview-drawing.html - Matt Gallagher shows what you need, pretty effectively. He basically recreates UITableViewController from UIViewController, while adding ability to use your own custom graphics. I'm just working on applying this to one my projects, so far it looks it would do the job.
Unfortunately, I have found no solution to this problem, and have resorted to subclassing UITableViewController and UITableViewCell into a generic solution that I can extend as necessary.
You don't do this in cell. Rounded corners are drawn in [tableView viewForHeaderInSection] and viewForFooterInSection.
The way I do it is to use Plain tableview style, then use these two views for roundness and cells are normal, no rounds.
Without getting into who draws what, you can know which cell is the last cell in its section inside of cellForRowAtIndexPath very easily.
You're passed in the indexPath of the cell you need to provide, right? You're also passed the tableView.
call [tableView numberofRowsInSection:indexPath.section] and if it's == ([indexPath.row]-1) you know you're being asked to supply the last cell in that section.
At the time that cellForRowAtIndexPath is being called, the cell is guaranteed to be at the indexPath passed in.
To expand upon Darren's answer (which I found most useful, thanks Darren!), what you can do is to iterate through all of the superviews' until you find the parent UITableView. This should be future proof since you do not rely on a fixed hierarchy of views.
I use a recursive method that will return the UITableView if it finds one or return nil if there is none.
- (UITableView *)parentTableViewOf:(UIView *)view {
Class class = [view.superview class];
NSLog(#"Class : %#", NSStringFromClass(class));
if([view.superview isKindOfClass:[UITableView class]]) {
return (UITableView *)view.superview;
} else {
return [self parentTableViewOf:view.superview];
}
return nil;
}
So far I've used this one and it seems to work without hiccups. Hope it helps! :)
The cells dont know where they go...The table view has cells, You are the one telling the table view WHAT goes in the cell. You do this in the DataSource where you implement cellForRowAtIndexPath...The way this works :
An index path has a row and a section
For a grouped table view
A section pertains to a group, and a row pertains to 1 entry in that section,
the way UITableView knows how many rows are in a section and how many sections there are is the DataSources methods numberOfSectionInTableView and the method numberOfRowsInSection, this will make the right calls to cellForRowAtIndexPath, it is up to you to recognize which section and row is being queried and you need to build your cell according to these specifications.
A good way to do this i s you can have a Dictionary with keys of section names and values of NSArray with the values that go in that section.
So you implementation for numberOfSectionsInRows would look like
return [[dictionary allKeys] count]
And the implmentation of numberOfRowsInSection would look like
NSString* key=[[dictionary allKeys] objectAtIndex:sectionNumber]
return [[dictionary objectForKey:key] count]
You can always refer to the UITableView programming guide at http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/Introduction/Introduction.html
Hope that helps
Simply add a property to your custom UITableViewCell (depending on implementation) class that contains an int, NSNumber, or an NSIndexPath specifying which one it is. In you're using a data structure instead, then put it in you element in that data structure. Then you simply set the property when you create the data structure, something like elt.id=i, and then you access it in the cellForRowAtIndexPath, something like if (elt.id == 0 || elt.id == n-1) where n is the number of rows in your section.
I might have totally missed your question, but if I did, just comment and I'll post again.