I need to load a UITableViewCell xib into the root controller of a split view. The UITableViewCell contains a UITableView as a subview (designed in Interface Builder). This UITableView will be used to load other cells. Is the loading of the UITableView within the UITableViewCell possible to achieve??
In short - a cell with a tableview as a subview that loads data from DB.
I have tried this but with little success. The problem is that the delegate method...
- (UITableViewCell *) tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
..placed within the UITableViewCell implementation file, never gets triggered.
Please help.
Your design may be ill advised, however...
If you have code for your UITableViewCell class, then that object needs to be the data source and delegate for your embedded UITableView. Something, certainly, has to be the tableView's data source and delegate, of course.
Another best practice, in this case, would certainly to be to make sure that the tableView argument in the various data source and delegate methods is the tableView object you think it is before you do anything.
How many custom table cells with embedded table views are you planning? Why not use a single table view with Grouped style? Eacn section of the table can then contain the content that you are now putting into your UITableViewCell/UITableView element. Would certainly be simpler, and might achieve the same result.
Related
I have a UICollectionViewCell containing some buttons, label and a UITableView. This table view varies in number of rows and content. The UICollectionViewCell is the table views data source and delegate.
UICollectionViewController forces me to use [collectionView dequeueReusableCellWithReuseIdentifier:#"CellID" forIndexPath:indexPath].
When scrolling through the UICollectionView the UITableView within the UICollectionViewCell doesn't update its content.
Calling [tableview reloadData] doesn't affect the number of rows.
Calling UICollectionViews reloadItemsAtIndexPaths:(NSArray *)indexPaths seems to be no good choice for performance.
Does anybody know a more clever way to update the table view inside the collection view cell instead of reusing previous cells' table views?
Have you set the delegate properly? If reloaddata is not updating the number of rows, there might be a problem with the delegate settings.
Is it safe to deque UITableViewCell prototype from one table and use them in another?
When I want to display the UITableViewCell in the other UITableView I am simply dequeueReusableCellWithIdentifier a reusable cell from the table where the prototype type cells are specified. That is, not the UITableView they will be displayed in.
It seems to work fine and I haven't noticed any errors in the logs but I am concerned it might cause weird issues as I have not seen it done before.
Should I simply implement this using a separate nib for each cell? Or is this approach fine, bad practice or dangerous?
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
if (self.prototypesTableView == tableView) {
cell = [self.prototypesTableView dequeueReusableCellWithIdentifier:cellType];
}
else if (self.otherTableView == tableView) {
cell = [self.otherTableView dequeueReusableCellWithIdentifier:cellType] ?: [self.prototypesTableView dequeueReusableCellWithIdentifier:cellType];
}
}
I'm pretty certain that each table view in memory has it's own queue of table view cells.
And when the table view (and view that hosts it) disappears, all the objects associated with it are released (assuming ARC here). Having one view with two tables shouldn't matter: each table has their own collection of cells to dequeue.
And in my own code, I frequently reuse the same custom "UITableViewCell" from one table to the next. To register a custom UITableView cell (which would be the only object in a XIB file), I do:
UINib * nib = [UINib nibWithNibName: #"SomeVeryCustomCell" bundle: nil];
if(nib)
{
[myTableView registerNib: nib forCellReuseIdentifier:#"SomeVeryCustomCell"];
}
This code is now running in production and I have seen no ill affects caused by dequeueing reusable cells from one table and using them in another. To ensure correct reuse I always dequeue from the "otherTableView" and if no UITableCell is available dequeue from the "prototypesTableView".
Although I implemented it like this for the sake expediency I would suggest it is better practice to implement it in the manner suggested by Michael, as it provides greater ability to share cells between view controllers.
I'm trying to do something very simple: set up a segue so that when you click on a cell in a table it will take you to another View Controller. The problem, I believe, originates from the fact that the TableView these cells are in is embedded in a regular ViewController (as opposed to a TableViewController), and is one of two subviews in this ViewController.
As far as I can tell, I've set everything up correctly: I embedded the ViewController with the two subviews in a Navigation Contoller, set it to be the dataSource and delegate for the TableView, and created a push segue from a TableViewCell to my second View Controller in the storyboard. However, when the app is run and a user clicks a row in the table, it merely selects the row and the segue doesn't fire at all (I've debugged it and the prepareForSegue function isn't even being called).
Is there something I'm missing here? Or is this for some reason not possible if the TableView is not the only view in its view controller?
I find that if I had recently wired the segue from the cell's accessory view, and later delete the segue and try to wire a new segue to the cell directly it does not work (using Xcode 4.6.2) -- Xcode keeps connecting the segue to the accessory view (even if there isn't one)! The way I fixed it is by selecting the cell in IB and using the connection inspector to (1) delete the original "accessory action" segue and (2) directly wire the "selection" segue by dragging from the filled circle in the image below to the appropriate destination view controller.
This may or may not help you, but I ran into this issue because I had defined two different cell types, and had provided didSelectRowAtIndexPath implementation. I had to add [self performSegueWithIdentifier:#"Whatever" sender:self] as part of didSelectRowAtIndexPath and the issue got resolved.
If you are able to at least detect row selections, you may be able to take advantage of this method.
If you have customized the cell rendering, e.g.:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = #"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
then ensure you are using the same cell identifier as specified for the prototype cell in ste story.
So in this case the 'Identifier' of the cell which hooked up the segue should be set to 'Cell'.
If you are creating the StoryBoard in Xcode then do the following:
Create a UITableViewController
Add a prototype UITableViewCell
Create the UIViewController that will be your segue target.
Control-Click on the prototype UITableViewCell and drag to the segue target.
That's it. You'll probably want to edit the characteristics of the UITableViewCell to be, for example, your subclass of UITableViewCell.
I had the similar issue.
Fix is
1. Write SegueIdentifier for the segue in Storyboard
2. Add the following line [self performSegueWithIdentifier:#"SegueIdentifier" sender:nil]; in didSelectRowAtIndexPath.
I hope this would help.
Had the same problem. Segue from a prototype table view cell inside a regular View Controller would make the app crash. In case someone have the same problem.
My solution:
If you are using a push segue make sure your first View Controller with the table view is embedded in a Navigation Controller otherwise "push segues" wont work. Also point the segue at the destination View Controller, not its Navigation Controller!
And as mentioned earlier, make sure your "segue identifiers" are correct.
at "didSelectRowAtIndexPath" I call "[self performSegueWithIdentifier:#"Your_destination_View_Controller" sender:self];
What is the difference between dragging a Table View Controller into the storyboard vs dragging a UI View Controller and dragging a Table View inside that in xCode?
I know how to populate a table view controller in code.
- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath;
How do I populate a table view within a UI View Controller? What custom class do I delegate to the UI View? I cannot seem to put a tableViewController on it as it is only a ViewController with a table view...
I'd like to know this because I'd like to have objects other than the table in that view (i.e. a section of the view is for the table and the other section contains a label, an image, and a button.)
Populating a UITableView inside of a UIViewController is no different than populating a UITableView inside of a UITableViewController. You just have to make sure you implement the required datasource and delegate methods. You also need to be sure to assign the UIViewController as the delegate and the datasource for that UITableView.
If you want objects other than the table, then you should us a UIViewController. In fact, I rarely use the UITableViewController any more just in case I need to add other objects.
I found another difference too .
While using a UITableViewController , which has UIScrollView in it , the view scrolls up when keyboard moves up .
This doesn't happen with UIViewController as you need separate methods for View scrolling up and down .
You can also take a look at this
https://stackoverflow.com/a/14465669/5553647
Only UITableViewController can have static content. https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/TableView_iPhone/TableViewCells/TableViewCells.html#//apple_ref/doc/uid/TP40007451-CH7-SW20
I Have one tableview(First) in that i want another tableview(Second) in the cell of first tableView.
In short i want each cell contains one more tableview.
So help me out with this problem.
Thanks in advance.
Although I think the below method is better this tutorial shows you how to create a tableView inside of another tableView http://iosstuff.wordpress.com/2011/06/29/adding-a-uitableview-inside-a-uitableviewcell/
My Solution:
That approach is bound to run into serious problems, so I suggest scrapping it. If you have nested table views (or scroll views, more generally) then the scrolling behavior of the views will be erratic. A better solution is to use variable height table view cells: you just create the cell view to hold all the multiple choice options you need, and implement
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
in your table view delegate to supply the heights of the cells.