I have a TableView in which a most cells are pretty standard. I make them buy using static cells in Storyboard. However, one cell I would like to customize probably using an XIB file so I would need to load it programmatically.
In the TableView's data source, is it possible to handle loading XIB view for this particular cell only, while leaving other cells to what's delineated in the static cells in the Storyboard? Or is it an all or nothing thing where I need to just give up using static cells altogether?
The rationality for doing this is that I would like to make Storyboard to look as close to the real thing as possible. Right now if I provide a data source, the static cells in the storyboard would have no effect on the actual output and is not in any sense linked to the actual output.
Yes, it is possible. Set the custom class for the custom cell. If you wish to customise it from code, just connect it as an IBOutlet to the UITableViewController.
Related
I have very complex cell in UITableView within UIViewControllerA. Now I need to use the same cell within UITableView of UIViewControllerB.
How to do this without copy and paste views from one scene to another?
Do not wanna use xib approach.
Is it related to registerNib:forCellReuseIdentifier?
You mentioned you don't want to use xib. Storyboards don't support this and therefore the last option you have is to construct your UITableViewCell in code. With the new Auto Layout anchors, it's not that bad.
I need to display a table with in my iPhone app:
neither the number of cells nor the contents are known at compile time, but only at run time.
Views for each cell may differ, one cell has textField and another may have some other view control.
Should I consider Static or prototype cells?
Should I consider tableViewController or viewController with tableview in it?
Any thing I need to consider before I start coding? Thanks in advance
For The issue of dynamic Number of cell at Run time, you can call reload data for table view at any time you have the data source ready.
Prototype Cells should be used with no problem.
Simple Table View will be sufficient for the task.
You have to make cell, either in code or in storyboard, for each type of cell you want, 1 table View can have multiple types of prototype cells, Just name them differently and then make the objects of only the specific cell of which the data is best suited.
It is not that difficult but do handle the data source with extreme care.
Should I consider Static or prototype cells?
If you know all possible subview combinations that your cells might need to display the data appropriately, and they are relatively few, make one prototype for each. for example:
One text field,
Two labels,
One image view and a label,
...etc.
Otherwise, just use the plain-vanilla UITableViewCell (no subclassing) and remove/add subviews at runtime when reusing them (that is, inside the method -tableView:cellForRowAtIndexPath:).
Should I consider tableViewController or viewController with tableview
in it?
The only reason I would choose UIViewController + UITableView over UITableViewController is if -for example- I needed the table view to only take up part of the main view's bounds/screen, and display some other subview in the remainder. Otherwise, you get so much "for free" with UITableViewController that there's just no point in implementing all of that from scratch.
You have to choose prototype cell, u can create different types of cell depending upon your requirement.Any think ok for u, u can create tableview controller or view controller.
I decided today that using static tableViews would suit my app better than dynamic ones.
Each cell has a label, and a UITextField
I subclassed one of the static cells and then tried to create IBOutlets for the label and textField... only it wouldn't work. Zero IBOutlet functionality when it comes static cells apparently and their subclass
I can however drag in IBOutlets to the UITableViewController these cells are apart of
So, essentially I would have a UITableViewController with outlets for each cell, each cells textField, each cells label, and potentially any other properties I want to add to the cell
I didn't want that much annoying code so I tried using dynamics
I was able to create IBOutlets for each object the way you can normally expect
I again decided against dynamics UITableViewCells, and switched back to static...
ONLY the static cells now have IBOutlets connected to them (they didn't disappear or throw errors when i returned to static UITableView)
I can access the cells properties by using cell.textField which is a lot better than a billion IBOutlets for each object on the cell
My question is... Why can't I create IBOutlets on the subclass of Static TableViewCells
Is the way I did it the only way, or is there a better way? I would hate to keep switching back and forth, but it allows me to get rid of dozens of lines of code I'll do it
When you create IBOulet for a UITableViewCell and you try to connect them on your StoryBoard, go to the left bar (where the objects of your view controller are) and press Ctrl + Click over your custom cell. Then the IBOutlet object will appear in a popup and you will be able to link them.
I have a UITableViewCell set up in a Storyboard UITableView that I want to also use in a different UITableView.
My current solution is to have a separate nib for the cell and load the bundle in cellForRowAtIndexPath: for both view controllers. However, this is messy and I lose a benefit of Storyboards: being able to view the whole layout on the screen at the same time.
The other solution is to copy and paste the cell. But now I have two copies of the same cell I'd need to manage.
Long shot, is there a way to dequeue a cell from a different UITableView?
I don't think you should do that. I tried once to share a cell between my main table view and a search results table view, and it caused crashes. I don't think having to copy and paste the cell a few times if you end up changing it is too much work if you really want to see everything in your storyboard. If seeing the cell isn't that important (as opposed to seeing the controller hierarchy and flow), then I would go with the xib option.
I'm trying to figure out how to have a few static cells in addition to dynamic cells (I think) but when I start a new Master-Detail app and switch the default Dynamic Prototypes to Static Cells, it crashes.
I think, since I'm still new at this, that I don't understand how all of the components (table views, cells, delegates) are wired. After I switched to Static Cells I made three cells but they don't show up. The app just crashes.
I can include code but basically, I create a new Master-Detail, switch to Static Cells, change the name of three cells and it crashes (in the main loop).
Thanks ahead for everything.
If I understand your question, this is the explanation you are looking for:
Prototype (reusability):
When you use Dynamic cells, you use Prototype cells. That means either in IB or in your code, you create an instance of UITableViewCell, and give it an identifier (reuseIdentifier). The UITableView uses this prototype to generate as many cells (rows) as you need. UITableView create (and use memory) for as many cells as it needs to fill the screen. Once some of these cells go off the screen, UITableView reuses them -- recycles them.
You can define more than one prototype cell in a UITableView. The idea is that each prototype serves a different purpose. For example, you define a prototype cell that has only one big UILabel and its purpose is to use static text. You define another prototype that has only one UIImageView. It depends on your design and how you want to display your data.
To use prototype cells, in IB, you use Dynamic Prototypes cells, and set an identifier. Then you have to implement UITableViewDataSource methods, such as:
– tableView:numberOfRowsInSection:
– tableView:cellForRowAtIndexPath:
These methods are delegate methods of UITableView.
If not using IB, you would create cells in – tableView:cellForRowAtIndexPath: method:
UITableViewCell *cell = [[UITableViewCell alloc]
initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString
*)reuseIdentifier];
Static:
The idea of static cells is just simplicity. You can use the prototype cells (e.g. only one prototype) and feed in a static NSArray, for example, as data source. To take the task of implementing UITableViewDataSource methods, Apple introduced static cells, where you would only use the storyboard and IB. In IB, you select the table view, and choose Static Cells instead, and type in your text, or set the image.
You don't want to make any dynamic changes to static cells later when the app is running because it is not meant to, and you would have to implement many more methods that it is not worth it. Although it not much of a work to get the indexPath of the selected row, but the idea is if you need to push a new view from selection of a static cell, you would use segues, instead of implementing any code.
When using static cells, you should not implement UITableViewDataSource method, otherwise your app crashes, and vice versa, if you do not implement UITableViewDataSource methods (required ones) when using prototype cells, your app crashes.