Re-use tableview from different controller: how to split didSelectRowAtIndexPath behaviour?

I'm currently working on my Favorites implementation. In the end, it should work the same as the favorites features in the Phone book on the iPhone.

I've the following set-up (besides other controllers and classes):

• TabBarController (named mainTabBarController)
• NavigationController with a Tableview (let's call it listNavController)
• ViewController with some components for displaying row details (named detailViewController)
• NavigationController with a TableView for favorite records (named favoritesNavController)

From the favoritesNavController, I want to select a row (from listNavController) so I can add a new entry to my Favorites tableview.

So, I decided to re-use my listNavController because it has all the functionality I need. Like searching, index, etc.

I've managed to show the listNavController from the mainTabBarController. So no problem here. When I select a row from the listNavController, it displays my detailViewController for that row. Of course, this was expected because that's in didSelectRowAtIndexPath in listNavController.

But, when I launch a listNavController from my favoritesNavController with the help of presentModelViewController, it still shows the detailViewController when selecting a row.

In this case, I want to return the selected row to my favoritesNavController. Then I can add it to my Favorite's list.

So, how do I differentiate this behaviour in code ? Should I use pr开发者_运维技巧otocols, delegation, etc. ?

Any tips ?

With regards,

Rutger

It turned out that I was looking in the wrong direction.

The solution to the posted question is as follows:

I created a subclass of my listNavController and overrided the didSelectRowAtIndexPath method. Next I presented this new view controller with a navigation controller as a modal view (presentModalViewController).

Finally I set the delegate and a protocol for the subclassed view controller to the initiating class. This way I can present and dismiss the subclassed view controller from the same controller. A much more clean and MVC way to go!