Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

erdinc27

macrumors regular
Original poster
Jul 20, 2011
168
1
I have 15 or 16 UIViewControllers in the storyboard and most of them have UITableview. I dont want to put an UITableView in each view controllers. So what can be alternative way of doing this ?
 
What do you mean that you don't want to put a tableView in each view controller? I usually use UITableViewControllers these days if I want a tableView. When I add that to the storyboard the tableView is already there. I'm not sure what you're asking.
 
That sounds like a lot of duplicated effort. Good programmers absolutely despise duplication. Are the table views displaying very similar things? Perhaps you could consolidate your efforts and build a single table view for each 'type' of thing you want to display.

It's really difficult to answer a question like yours with absolutely no knowledge of what you are actually trying to accomplish.
 
@PhoneyDeveloper : I want to create an UIViewController which contains an UITableView. Then i want to send the custom tableviewcell class and data source(e.g nsarray) as a parameter to that UIViewController. Then display the data inside there. I hope now it is more clear what i intend to do.

@AxoNeuron : That is all i want to do to avoid from dublicate. The point i should consider some UITableViewCell is almost same with other but some are not. That is why i created that thread. What is the alternative way to create UIViewControllers without duplicating so much code
 
OK, so you want some tips on how to implement multiple table views in different view controllers where the tableviews are very similar. And you want a minimum of duplication of code or of effort.

First off I recommend you use UITableViewController if at all possible. You might also make your own view controller that is a base class that has common behavior that your other view controllers need.

A common design that has been discussed a lot lately is to use a separate class for the tableview datasource and tableview delegate. If the code for cellForRowAtIndexPath and related methods is the same for many of your view controllers then using a single class that is separate from your view controller that implements these methods will reduce duplication. In viewDidLoad you build one of these objects and set the tableview's delegate and datasource properties.

Regarding the cells there is a little more debate on the right way to do things. The storyboard allows you to add cells to each tableView complete with their layout. These cells are automatically registered with the tableView and can be dequeued without any further source code. I find this very convenient. However, in the case where you have the same cells in multiple tableViews you find yourself copy/pasting the cells from one tableView in the storyboard to another. If you later update the cell's layout you need to copy/paste again to keep things in sync. Another option is to build your tableViewCells in their own xib files. Then register the cells with the tableView in code. I find this messier but it is a viable option.
 
I personally use xib files in situations like this. It depends on how different the different types of cells you want to show are. You might consider making them all the SAME basic design, and then using clever auto layout constraints and changing them in code to get the different looks you are after.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.