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.
Related
I'm wondering what is the best approach/design when using custom UITableViewCells.
One way I'm doing it is having a init that takes all parameters necessary to setup the UITableViewCell. Like -initWithLabel:groups:error
Then I would init it like CustomUITableViewCell *cell = [CustomUITableViewCell alloc] initWithLabel:#"Hello" groups:#[#"1", #"2", #"3"] error:NO];
Then perhaps later if I would need to update the error of the CustomUITableViewCell to YES I would just reload the cell for CustomUITableViewCell and supply YES in the init.
Now I'm wondering if it would be "better" to have a setter for the cell, like - (void)setError:(BOOL)error that I can set whenever I need to update the error of the cell instead of reloading the whole cell.
What would be pros/cons comparing the two options?
Your first choice doesn't seems to be a good approach. If you are creating cell each time it just fine. But actually happening is table view will create only 10-15 cells(depends) and later they will be reused. So initialization is no going to perform unless you call it externally(that is not good).
So the good approach in custom cells are use the properties and expose all the things that is going to change in cellForRow of your datasource object. Make your labels, error... as properties if it is accessible to the outer class. So you can easily change any values.
When you have a member variable that can change, then for sure it should use a setter (and be a property), so you don't have to replace the class each time. The source-code will be clearer, and the program will be more efficient. You might also include it in your init, if you think it's a good idea to encourage clients to explicitly set that variable when they make a new object.
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.
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.