In custom cell I have a UILabel and UISwitch. I want to fetch the text of label when the switch is on. I have kept a method on switch's value changed event but the application is getting crashed.
I'm assuming your mean a custom UITableViewCell. There are a number of ways of getting to the associated label when the switch changes:
If your table is not variable length (so that the cell with the label/switch is unique), when you create the cell cache the UILabel * object and the switch object in your UITableViewController subclass as ivars and associate them together.
If your table is variable length, you need to either maintain arrays of UILabel * and switch *, or you can also subclass UITableViewCell (note that you can provide a custom interface for a UITableViewCell via nib without having to necessarily subclass, you don't mention whether you've subclassed or not), hook up the switch event to go to your UITableViewCell subclass, then read the corresponding label, and/or forward the event to the UITableView subclass (this is a "push" model rather than the "pull" model), sometimes this organization is easier to manage than trying to maintain arrays of objects in your UITableViewCell that track objects in individual UITableViewCells.
Related
I am populating cells in a UITableView from CoreData and I have a question about how best to transfer the data I need to my DetailController (i.e. the viewController that shows when the cell is tapped).
Currently when populating the UITableViewCells I use the indexPath passed to the cell to retrieve the appropriate managedObject from Core Data. At this stage I only update the cell with a few bits of information from the managed object (i.e. name, age, sex).
After the UITableView has been fully populated I want to allow users to select a UITableViewCell and present a DetailController showing more in-depth information (i.e. name, age, sex, occupation, weight, height etc.) When the cell is tapped I am using -prepareForSegue to transition to the newly presented DetailController.
My question:
The "sender" for the segue is the UITableViewCell (subclass) but I have only populated this with the information I needed to originally display in the smaller cell. Should I
add more iVars to the UITableViewCell subclass and store all the data
I need,
keep a pointer iVar on the cell to the model managedObject
something else that I might have missed?
With the Model View Controller pattern we use in objective-c Your views should never know about your data model. This means that your UITableViewCells should not have any properties that store objects from your data model. Cells should only have labels and views as properties which your view controller fills in with data from the model in its -tableView:cellForRowAtIndexPath method or similar
You get the UITableViewCell object as the sender in prepare for segue. You can find out the index path for the cell with the following method:
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender{
NSIndexPath * selectedIndexPath = [self.tableView indexPathForCell:sender];
...
You can then use this index path to pull your model object out of core data again, and set it as a property on your next view controller, or whatever you need to do to pass the model object forward
What is the scope of the table view cell's reuse identifiers — are they shared within one table view instance or within all the table views that use the same reuse identifier?
Eg, I have a FooTableViewController and a BarTableViewController, both of them have a tableView and both of them use #"Cell" identifier in tableView:cellForRowAtIndexPath, but the cell properties/styling are different. The question is - will those cells be reused across table views or not?
They are never shared between instances.
A UITableView object maintains a queue (or list) of the currently reusable cells, each with its own reuse identifier, and makes them available to the delegate in the dequeueReusableCellWithIdentifier: method.
(from [UITableViewCell reuseIdentifier] docs)
Emphasis on "UITableView object".
However, you should make your cell identifiers more descriptive. A different identifier for every cell type you are using. Your code will be more readable.
They will only be used in a single UITableView, they will never be shared. Each UITableView has its own "pool" of reusable UITableViewCells
I have a custom UITableViewCell subclass, and a table view controller which I want to insert text boxes into.
What I have done is setup a three dimensional array to store the sections, rows and then in the third dimension I have put the placeholder text I would like to display -
In the custom UITableViewCell subclass I have defined the text box as a weak property (I think this is correct...?)
#property (weak) IBOutlet UITextField *plainTextField;
I then add this text field to my data model array in
cellForRowAtIndexPath:
however, when I try to access the textfield from my array (specifically plainTextField.text) I get
''
I get the feeling that something is being released somewhere and I can't figure out where (the actual textfield is not nil)
I guess, my question is really a design one -- how do you get UITextFields into a UITableViewController and then get the text out of them later....?
Thanks!
I've 'fixed' my problem -- it's really based on the fact that you can't have different content in UITableViewCells, as soon as anything is different you have to load it in cellForRowAtIndexPath. (A note in the UITableViewCell prepareForReuse method)
What I did was reserve a spot in my data model for a UITextField, and then when cellForRowAtIndex path got to the cell it would query the data model, then instantiate a UITextField and add it to the cell.contentView or (here's the tricky part) loop through [cell.contentview subviews] to find any UITextFields and call removeFromSuperview
Edit 2: What I previously planned was probably a bad idea and I now changed my design: My UITableViewController has an array with all the values of my UITextFields and I am using delegation to update the values in the array. (If a value in one UITableViewCell changes, I send a message with the new value and the index of the cell).
Original Question
I would like to create a UITableViewCell subclass. To access my cells, I would like to have an NSMutableArray in my UITableViewController with all the cells. Whenever I create a new cell in - tableView:cellForRowAtIndexPath: I would add it to the array. The cells should however know about this array. I would declare a property like this for the UITableViewCell:
#property (nonatomic, assign) NSMutableArray *cellsArray;
Whenever I create a new cell, I would set its cellsArray to my array.
My (probably simple) question is: Is it correct that cellsArray will hold a pointer to the array in the UITableViewController and when I add stuff to the array of the UITableViewController, the cells will know this too, i.e. can access it?
Edit: The UITableViewCells contain UITextFields. I used to rely on the -cellForRowAtIndexPath: method and the visibleCells array, however when the cells moved out of view, the content of their UITextFields would also be lost. I then decided to store the cells in an array. When the user taps save, I iterate through the array and store the values. Also, I would like to automatically update the enabled property of the save button, depending on whether all cells contain something - for this I need all cells, too.
The cells should know about the other cells so that they can select the next cell when the return/next key on the keyboard is pressed.
If there are better approaches to this, I am glad to hear about them!
Not a direct answer of your question, but this sounds like a very bad design. Why should one cell need to know about its siblings? Any event/change that occurs in one cell and has an effect on the other cells should be handled by the table view controller. The single cells should be separate entities that should have no need to know about the state of each other.
Secondly, there is no need to introduce another array to manage the table cells. The table view already has a property visibleCells that you can access from the table view controller. And should never have to interact with invisible cells anyway because those are managed by the table view and its reuse facility.
I believe the answer is Yes.
My understanding of assign is that you can assign a value to such a variable and the retain count for the original object is not incremented. Similarly you need not release the variable in the object's dealloc method. You may run the risk, however, that the original array goes away and then cellsArray is pointing at something that is no longer there.
I use assign when I want to pass a reference to an object to another object (e.g. a view controller that is going to display or otherwise manipulate the object). And in the latter object, I do not release it's pointer to the object.
You also see assign used with properties that are id's, like
#property (nonatomic, assign) id<SomeProtocol> _myDelegate;
All that being said, with the exception of the id case, often I feel "safer" using retain for the property and being sure to release in dealloc. :-)
Anyway, I think that's the crux of the difference.
Question - Is it necessary to have subview (e.g. UILabel) instance variables in a UITableViewCell subclass?
The alternative I am thinking of being to construct say the UILabels you want for your custom UITableViewCell subclass when you create it, assign them to the content view (e.g. [self.contentView addSubview:label_1]), and then release the UILabel (e.g. [label_1 release]).
So is it the case the only reason you need to keep the labels as instance variables (declared in the header) of the UITableViewCell subclass, so that you can grab them more easily to configure/make changes to them later. That is as opposed to having to find through by looking them up directly in the contentView via their tag values?
thanks
it is a convenience, but one worth sticking with. if you call viewWithTag everytime something needs to be changed/redrawn it can be less efficient than just using the pointer stored in the stack, as this would have to be recalculated each time.