Views & view controllers - what is the correct way to structure?

Hello

Following my last post, I have been trying to learn how to transition between views without using storyboard. I have been successful with the following two practice projects - this a breakdown of the structure:

1. Multiple views without a navigation controller

- CustomViewController1 created in AppDelegate

- CustomViewController1's view contains a toolbar with 2 buttons on it

- CustomViewControllers 2 and 3 created as IBOutlets in .xib file of CustomerViewController1

- insertSubView and removeFromSuperView methods used in ViewController1's .m file to load and unload CustomerViewControllers 2 and 3's views (by linking the toolbar buttons to actions)

This works fine.

2. NavigationController app

- NavigationController created in AppDelegate

- CustomTableViewController created in AppDelegate, passed to NavigationController using initWithRootViewController method, and then displayed using addSubView method.

- CustomTableViewController .xib contains a tableview and a CustomViewController as the detail view, which is linked to the CustomTableViewController via IBOutlet

Everything loads fine, and when didSelectRowAtIndexPath method is activated, I use pushViewController method with the CustomViewController property to load the detail view and it works fine.



So, my problem arose when I tried to mix the two together. I wanted to have a main menu screen with a button that, when pressed, would launch a navigation controller. Essentially, example 1 above for the menu and example 2 thereafter.

I have done the following:

- CustomViewController1 is loaded in AppDelegate and has just a completely empty view

- CustomViewController1's .xib file contains a MenuViewController linked via IBOutlet. MenuViewController is loaded by [self. view addSubView] method

- MenuViewController's view has a button on it. A navigation controller is declared within MenuViewController and, when the button is pressed, a CustomTableViewController as in example 2 is created, given to the navigation controller via initWithRootViewController, and then the rest is as example 2.

At this point, MenuViewController's view is a sub view of CustomViewController's view, the navigation controller's view is a sub view of MenuViewController's view and CustomTableViewController's view is the root view of the navigation controller.




I get "unrecognized selector sent to instance" errors on the pressing of the button.

When I moved the navigation controller stuff into CustomViewController1 instead, I got the same error for the cellForRowAtIndexPath method on scrolling the table view.

The cellForRowAtIndexPath method seems to get called when the CustomTableViewController is first created, but then it crashes when it is called again when I scroll some of the cells off the top of the screen.

Lastly, when clicking on a table view cell, the detail view doesn't load - the cell just highlights and nothing happens.

From trawling the internet most of this afternoon, I think it is maybe a problem with things getting released when they shouldn't be and so are not there to deal with some of the method calls.

If anyone can explain what is happening or, if what I am doing is totally wrong, explain simply the correct way for transitioning between different views that have their own view controllers then I'd be grateful.

Thank you and sorry for writing so much but I don't know which part is the problem.

 

I didn't realise you could do that, and that would certainly solve the issue.

However, I decided to try this to see if what I thought I understood about views and view controllers was the case. The first two examples are from a book and from an internet site. From these I thought I had worked out how transitioning from one view to the other worked, which is:

a) A view must be paired with a view controller

b) A view is loaded into a window in the AppDelegate, and control passes to that view's view controller via the viewDidLoad method (call it VC1)

c) If VC1 has the responsibility of loading another view, a second view and view controller (VC2) are created, and an instance of VC2 is created in VC1's .xib file so that you can refer to it via an IBOutlet declaration (by creating a parent controller and selecting the custom class from the drop down list). The following would load the view of VC2:

Code:

[VC1.view insertSubView:VC2.view atIndex;0];

(That's from memory as I'm at work, so sorry if the syntax is not quite right)

d) As the view is loaded at index 0, it is the view that is foremost and therefore appears on the screen

e) If VC2 wants to load a sub view, it does so as in c) but with, say, VC3.

f) If VC3's view needs to close, I could call:

Code:

[self.view removeFromSuperView];

and VC3's view would be removed and it would effectively "kill" itself (as I have ARC enabled) and hand back control to VC2's view controller just after the point where VC3 was originally created.

So, at this point I have a hierarchy of sub views where VC1 has loaded a sub view of a VC2 view, which in turn has loaded a sub view of a VC3 view. On loading a view, that view's view controller has control until I discard the view, at which point I thought control would pass back to the method in the next view controller up where the view was loaded.

Am I completely wrong on this? I just thought that it can't be the case that every app in the world that has multiple views uses a navigation controller and so I wanted to understand how to shuffle things around manually first before using the free functionality a navigation controller offers.

I did leave ARC ticked, but I will read the guide - thank you.

I will do so when I get in from work - sorry.

What does that mean - I have been loading views using code from the examples in the book I have (Sams Teach Yourself iPhone Applications) so I don't think I've come across modal?

Thank you all for responding.

 

Thank you! After reading the article my app now works.

I think I also spotted a mistake in my AppDelegate too - I wasn't assigning a root view controller to self.window at any point. I think this was probably what was causing my "unrecognised selector sent to instance" errors because I don't get any at all now after changing that.

Just one last quick question:

When you create views and view controllers in this way, is it absolutely best practice to create a delegate and have the presenting view controller dispose of the presented one? Could the presented view controller remove itself instead, which would mean not having to bother with delegates and protocols?

For example, in the presented view controller, could I put the following instead of calling the protocol method to get the presenting view controller to dismiss it's presented view:

Code:

[self.presentingViewController dismissViewControllerAnimated:YES completion:nil];

Seems to work, but just want to be doing and learning what is deemed to be best practice as it does say in the Apple guide that presenting controllers should take care of their presented ones. Just seems like the protocol stuff is a bit of extra trickiness just to get a view to disappear.

Thank you again for that link, and I'm going to buy the Big Nerd Ranch guide and see how I go with that.

 

I did read that part, and amended my app to work with a delegate initially and everything worked fine.

However, I was looking at it and thinking that if there was just a way of talking to the presenting view controller I would be able to call the dismiss method that way, and realised I did have access via the presentingViewController property.

Interesting that it can be called on itself as well.

So just to absolutely clarify (sorry) - does that mean that for all custom view controller classes that I ever create I should implement at least one protocol method (i.e. the method to dismiss it) so that it can be dismissed properly?

And absolutely last last last question - is this approach and the stack-based approach of the navigation controller pretty much the only two ways views are loaded and unloaded (segues aside - I'll worry about pre-storyboard stuff for the moment) - there aren't any more completely distinct ways that I should look at?

Thank you very much for your help - thoughts of giving up did momentarily flash through my head at one point over the weekend but you've really helped.