1

I have a tabbar -> navigationcontroller structure. In one of these tabs, I want to switch between two UIViewControllers (a KalViewController and a UITableViewController to be be exact), using a UISegmentedControl located in the Navigation Bar.

Currently, I have a third UIViewController, that pops and pushes the appropriate ViewControllers on segment value change. I don't think thats the right way to do it and it also destroys the navigation stack (when I tap on the bar item, the navigation controller goes the root controller, which won't work). And there's even another bug, related to the Kal Component.

So, what's the right way to do it?

Felix Seele
  • 837
  • 9
  • 8

1 Answers1

3

The right way to do it is to have the controller handling the UISegmentedControl add the views of the controllers as subviews.

[self.view addSubview:controller.view];

It's your responsibility to send viewWillAppear: and so on.

EDIT: The offset you're talking about can be adjusted using:

controller.view.frame = CGRectMake(x, y, width, height);

EDIT 2: In response to tc.'s comment:

From the documentation of UISplitViewController:

Message Forwarding to Its Child View Controllers

A split view controller interposes itself between the application’s window and its child view controllers. As a result, all messages to the visible view controllers must flow through the split view controller. This works generally as you might expect and the flow of messages should be relatively intuitive. For example, view appearance and disappearance messages are sent only when the corresponding child view controller actually appears on screen. Thus, when a split view controller is first displayed in a portrait orientation, it calls the viewWillAppear: and viewDidAppear: methods of only the view controller that is shown initially. The view controller that is presented using a popover does not receive those messages until the popover is shown or until the split view controller rotates to a landscape orientation.

This is not magical and there is no reason why you wouldn't be able to write a similar controller yourself. In fact I've done it and it worked just fine.

Community
  • 1
  • 1
Erik B
  • 35,941
  • 21
  • 106
  • 122
  • Now it looks like [that](http://img696.imageshack.us/img696/4762/bildschirmfoto20110405ub.png). I have no idea where that offset comes from. The view is also scrollable now and my second view controller doesn't get displayed at all... – Felix Seele Apr 05 '11 at 19:29
  • @toffifee Look at the edit to learn how to handle the offset. – Erik B Apr 05 '11 at 19:43
  • Had to make a few adjustments, but now it's working. Thanks :) – Felix Seele Apr 06 '11 at 20:01
  • No. View controllers are not meant to be used like that - `controller` will miss out on a lot of the UIViewController magic that's taken for granted (namely -view{Will,Did}{Appear,Disappear}: and -shouldRotateToViewOritentation:). – tc. Apr 06 '11 at 22:19
  • @tc. I beg to differ. There is no magic. ***"It's your responsibility to send `viewWillAppear:` and so on."*** So I didn't list all of the methods, but so what? It's like writing your own custom tab bar controller. Obviously `UITabBarController` is sending `viewWillAppear:` to its controllers. Again, there is no magic. – Erik B Apr 07 '11 at 06:19
  • By "magic", I'm referring to everything UIKit does behind the scenes. You also forgot `-parentViewController` (which is important for things like modal view controllers). Additionally, somewhere in the depths of UIKit, it automatically calls `-viewSomethingSomething:` for you, so you might get `-viewDidDisappear:` twice! (I can't remember the exact details, but there's another user reporting that all you need to do is call `-viewWillAppear:` and the other three methods happen automatically.) The key issue is that Apple doesn't document the "magic" or how it changes between OS updates. – tc. Apr 12 '11 at 02:03
  • Not that I don't use custom UIViewController hackery when necessary, of course (damn customers and their UI designs...), but in this case switching view controllers entirely seems cleaner than embedding them into a root VC somehow. – tc. Apr 12 '11 at 02:09
  • Container view controllers are now supported, and automatically forward the events :) – Oscar Gomez Feb 08 '13 at 19:42