On Jan 25, 2011, at 6:41 PM, Matt Neuburg wrote: > You should not be using view controllers merely as dumpster divers to load > nib files and extract their contents in a semi-automatic way. As I said in my > previous note, if you want to store those views in nibs, fine, but then the > way to extract those views is with a normal class whose job is to function as > the File Owner for the nib and pick up the desired view through an outlet. > Using a view controller is wrong because it does all kinds of other stuff not > appropriate to this situation.
I fear you didn't completely understand why I'm doing things this way (probably my fault since I didn't give a reason for the non-standard design - see the end of this message for the reason). I am *not* using view controllers "merely as dumpster divers to load nib files." I am using the view controllers to load their views and do what those views require their view controllers to do. The fact that I am replicating some of the functionality of a tab bar controller indicates that I need the view controller to do more than just load a view from a nib file. I know very well that view controllers aren't supposed to be used just to load stuff from nib files. Please don't make it sound as if that's all that I'm doing because it is not. > You asked for further support from the documentation for my statement that > you're using view controllers for views that are going into the wrong sort of > place in your view hierarchy. The devil can quote scripture for his own > purposes, but since one of the view controllers you're misusing is a > UINavigationController, I'll just paste in, directly from the docs, this > convenient list of the places where such a controller is permitted: > > • Install it directly in your application’s main window. > • Install it as the root view controller of a tab in a tab bar > interface. > • Install it as one of the two root view controllers in a split view > interface. (iPad only) > • Present it modally or otherwise use it as a standalone view > controller that you can display and dismiss as needed. > • Display it from a popover. (iPad only) > > The place you're putting it is none of those. On the contrary. The navigation controller *is* installed as the root view controller of a tab in a tab bar interface. It's installed as the root view controller of tab 0 of the window's root view controller (which implements a tab bar interface). Regardless, that has never been the cause of my problems nor has it been the root of your criticism. Your criticism was towards my having a UIViewController load a nib that contains other view controllers. That has little or nothing to do with (a) faking a tab bar controller (something I'm doing) or with (b) having a navigation controller placed where it's not supposed to go (something I am not doing). So much so that I could completely take away the tab bar and the navigation controller and, instead, simply have only the "some view controller" of my original post (which is just a UIViewController). I would still be having a view controller (the window's root view controller) load a nib containing another view controller (this time nothing fancier than a vanilla UIViewController) and you'd still be making your original criticism. Please don't make this problem about something that it is not about. > Recall that your original note said explicitly that you did *not* want a > "just do this" answer; you wanted a more general explanation of what was > causing this issue. I provided one, and you immediately rejected it, and > abandoned your stated principles and contented yourself with your own "just > do this" answer, ending up no wiser than before about how view controllers > work and how they are intended to be used. m. First, your explanation was incorrect, because view controllers need not and do not always manage the window root view. Secondly, it was misguided, because you thought I was doing something that I am not, namely, use view controllers for the sole purpose of loading objects from nib files. Third, I already said in another message that I understand the solution. In fact, I already understood it even before I posted my original message. What confused me was that I thought I had already tried that solution and, so, I was puzzled that it had not worked. The truth, of course, was that I had never tried it in the first place. Now, here's why I'm trying this design. Imagine that you have a collection of lab experiments for which you want to see some results and some statistics. On the app's "front" screen you have a table of those experiments with a *minimal* amount of results for each. This is the (global) "results" tab. Now, if you switch to the (global) "statistics" tab, you see some statistical information about ALL experiments taken as a whole. A third tab might, for example, show some app info. Then you tap on one particular row/experiment of the Results tab and a view is pushed in to show *detailed* results and statistics, and possibly other things, about that particular experiment. However, here too you might want to have a tabbed interface. Yes, I know the standard way here is to use a toolbar but the first two buttons on that toolbar would have the exact same name, icon, and functionality of the first two tabs of the front screen tab interface, only now applying to a particular experiment rather than to a whole set of them. So, it makes some sense not to use a toolbar but to reuse the tab bar, changing its items list and its delegate so that when you're on the front screen you see Results | Statistics | App Info but when you're in a particular experiment, you see Results | Statistics | Analysis ... (other relevant tabs for this particular experiment) When you're on the screen for a particular experiment, the tabs apply only to that particular experiment. When you're back to the front screen, the tabs apply to all experiment at once. In order to accomplish that, I need to be able to change the tab bar's delegate and list of items and restore them when the navigation controller returns to its root view. A tab bar managed by a UITabBarController cannot have its delegate changed, so I'm faking a UITabBarController. I believe this is much less confusing to a user than having an interface with a toolbar on top of a tab bar where the first two buttons on the toolbar are identical in name, icon, and functionality to the first two tab bar items. The only difference is one of scope not of functionality. Now, if someone can suggest a similarly intuitive interface that does not need to be coded around the guidelines, I'm all ears (well, ok, eyes). WT_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
