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

icecavern

macrumors regular
Original poster
Apr 30, 2005
132
0
Reading, UK
OK so I'm taking my first steps into iOS development ( iOS 9 and swift2 ) and I've been using tables to create the look of the first page on my app. This is working great and looks clean etc which works for me.

The issue is I have 4 rows in my table, and I want to open a different view controller depending on which of the 4 rows are selected. Similar to the way OneNote works in that you have a list of things, notes, todo's etc and when you click on one of the items in the list it takes you to the correct view for that item in the list. Does anyone know how I might go about doing this?

At the moment I've only managed to create a single view controller that's launched on any of the row selections, but I want different view controllers for each.

The only way I can see to do it right now is to hard code everything with 4 different table Views on one page, but that seems like a big cludge.

Thanks

Pete
 
Last edited:
You get an index path from - tableView:didSelectRowAtIndexPath: use the row to decide which ViewController to load.

You can do a simple check like 'if row is equal to 0, load this view controller', 'if row is equal to 1 load this view controller'.

If you want to get smarter, then you can keep an array of the View Controller class names, and load them from using NSStringFromClass(). That doesn't work if you need to know specifics about the view controller class so that you can pass in information, but works well if you don't.

There's nothing wrong with using a table to create your menu. It's the best way to go if you need repeating elements, you can just design the cell once and use it several times. Better than trying to set up several identical stacked views in IB!
 
  • Like
Reactions: dejo
Thanks that worked great, just had to figure out how to do multiple manual segues for the storyboard but it all works fine now :)

One other question. In my tableView I have 4 items, but when rendering the view there are extra 'empty' rows created. Is there an easy way to stop these extra rows being drawn?
 
The usual way to do this is with a static table view. You create your four table view cells in the storyboard, connect the appropriate segues to those cells and then things will just work. No need to implement didSelectRowAtIndexPath.

If you turn off the separators you won't see those extra phantom rows.
 
  • Like
Reactions: dejo
Is there a way to remove the phantom rows without just turning off the separators? I like the look of the separators between the items that are there. One of the reasons for using a dynamic table is that I want the ability to add and remove items from this main list depending on config.
 
I like to create UITableViewCell subclasses (using a xib for design of the cell).

If you do it this way you can add a small 1px (or whatever) line to the top of the cell and it basically becomes your new separator. This gives you much more precise control of what the separator looks like, I've never liked Apple's default separator. The phantom cells aren't going to show up using this method since the line/separator is a part of the cells themselves.

If the table view is going to be dynamic you will really want to do it this way.
 
I like to create UITableViewCell subclasses (using a xib for design of the cell).

If you do it this way you can add a small 1px (or whatever) line to the top of the cell and it basically becomes your new separator. This gives you much more precise control of what the separator looks like, I've never liked Apple's default separator. The phantom cells aren't going to show up using this method since the line/separator is a part of the cells themselves.

If the table view is going to be dynamic you will really want to do it this way.

You should really create prototype cells on a storyboard and then make a subclass for UITableViewCell. Making .xib cells is old style
 
You could also use a grouped tableview with one section. You can choose the grouped tableview from interface builder
 
@AxoNeuron, I also create subclasses for most custom rows but they live in the storyboard, not a nib. You can easily copy and paste your cell from one tableview to another in the storyboard. This is not completely DRY but I prefer it to wrangling nibs these days. I agree that this is a fly in Apple's storyboard ointment. There should be a better way to have a single custom cell that can be shared by multiple table views using a storyboard.
 
Just copy the cell from tableview to any other table views where needed, don't have to redo the class, if the cell is generic just give it a generic name i.e. myProjectCellTypeCell

Always worked fine for me!
 
What I mean is, it's hard to give it to other people. In a commercial project I try and make it so that any and all resources such as a tableview cell can be given to other people as needed, because that happens quite often. Usually easiest if you started working using a nib.
 
What I mean is, it's hard to give it to other people. In a commercial project I try and make it so that any and all resources such as a tableview cell can be given to other people as needed, because that happens quite often. Usually easiest if you started working using a nib.

I agree. I use storyboards and separate my code into as many classes as possible, not just because I like to, but it makes it more modular for future development and segmentation.
 
There should be a better way to have a single custom cell that can be shared by multiple table views using a storyboard.

Contrary to what was said earlier, you really should not copy and paste the same prototype into separate table views in your storyboard. You should only draft prototypes in your storyboard if they're isolated to that specific view. Isolating them creates duplication that prevents you from applying changes without addressing each copy which leaves too much room for error and takes too much time. You (PD) seem to be hinting at those issues...

Instead, you can create a nib (and controller) for a table cell, then register it in your storyboard'ed tableviews using
registerNib(_:forCellReuseIdentifier: ). This solves all of the above plus separates universal views from the "story" of your app.

Also, just for kicks:
It's also wise to pull your data source out of the view controller so you can use it to register cells and retrieve data in the same way across many table views with less markup.
 
Last edited:
@Mascots. Different strokes I guess. The cells in the storyboard tend to be simple, so there aren't that many updates to them. If I do update a cell that's used in more than one table I just copy and paste the updated cell replacing the old version.

I've given up on nibs so all my cells will be in storyboards. Using a nib for the cell as you suggest isn't a bad idea but I prefer to not have nibs anymore.

As I said I think there should be a way to share cells inside storyboards but that doesn't exist yet. Probably I'll file an enhancement request on this.
 
Hmm, just seems silly to not use a resource that is available to you. Nibs are certainly not old or dated as they share the same templating as Storyboards. They're merely separation of embeddable reusable components, while Storyboard's represent the logical flow.

Maybe one day we'll get the ability to store views in stories, but until then, it's about making two files and a single line of code. Different strokes, I suppose. ;)
 
OK so one issue down, and I've found another.

I have another viewcontroller, for a separate screen, on that controller I have some labels, and also another table view, with a cell set up as a prototype. The viewcontroller has been made the delegate, and datasource for the table view, and the table is being dynamically set up with the correct items and updated correctly. However I cannot get the didSelectRowAtIndexPath function to be called when an entry in the table is selected. I've scoured the net and as yet haven't found anything not set correctly. Anybody had this before?
 
Wasn't sure there was much point starting a new thread since it's pretty much the same problem, just a different use case.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.