0

Let's say that on the tap of a UIButton in ViewControllerA the following happens before transitioning to ViewControllerB:

- (IBAction)levelSelectButton:(id)sender {
    ViewControllerB* obj = [[ViewControllerB alloc] init];
    [self addChildViewController:obj];
    CGSize screenSize = [MainScreen screen];
    CGFloat screenWidth = screenSize.width;
    CGFloat screenHeight = screenSize.height;
    obj.view.frame = CGRectMake(0,0,screenWidth,screenHeight);
    [obj.view addSubview:_banner];

    //[obj didMoveToParentViewController:self];
    [self runPushAnimationWithController:obj];
}

When ViewControllerB shows up, I can see my _banner (a GADBannerView object) view in place, but when I return to ViewControllerA it is no longer there.

I have never used addChildViewController:/didMoveToParentViewController: methods before so I don't know if this is expected, but I want to be able to return to ViewControllerA with _banner still visible.

Do I need to retain it?

  • What exactly do you want to do on button click event? Like opening another view controller inside your own view controller? or you simply want to push the view controller with some custom transitioning animation? – Syed Qamar Abbas Nov 29 '16 at 18:35

1 Answers1

0

A view can only belong to a single superview. To quote Apple's docs:

Views can have only one superview. If view already has a superview and that view is not the receiver, this method removes the previous superview before making the receiver its new superview.

So when you add your view to a newly created parent view controller, it gets removed from the current view controller's view hierarchy.

I would advise against doing this sort of thing. Just create a copy of the view in both places. If it uses large amounts of data, share the data (model) between view controllers, but not the view objects.

If you are completely set on moving your view around between view controllers, I would add a property to the new view controller and set that property rather than manipulating the other view controller's view hierarchy. You'll also have to pass the view BACK when you return to your current view controller.

You should treat a view controller's view hierarchy as private. Not doing that violates the principle of encapsulation.

Duncan C
  • 128,072
  • 22
  • 173
  • 272
  • Thanks Duncan, that helps a lot, and you've convinced me to scrap the whole parent-child relationship between the two controllers (and, in turn, all the other controllers I have as well). – Anthony Shintoluggenprog Nov 29 '16 at 23:41
  • The parent-child relationship can be very useful, but I don't think you're using it correctly. Take a look at container views and embed segues. – Duncan C Nov 29 '16 at 23:48
  • That's what I thought I was doing, or at least applying correctly. I'm not dealing with Storyboards or Xib files, so I'm doing everything programmatically. Overall what I wanted was to have an embed segue between the two controllers where the `_banner` was the container view (the article [link]https://spin.atomicobject.com/2015/07/21/ios-container-views/ sums it up) – Anthony Shintoluggenprog Nov 30 '16 at 02:11
  • Trying to do everything in code is a mistake. Storyboards are your friend. – Duncan C Nov 30 '16 at 03:55
  • I will only agree with that if Storyboards allow for things that can't be done in code...which would be a forceful initiative on Apple's part. It might be prudent to use them for visual purposes and drag-and-drop simplicity but I don't want to cheat around the hard coding, especially since I'm new to iOS development. – Anthony Shintoluggenprog Nov 30 '16 at 12:51
  • Storyboards are no more cheating than higher level languages like C, Objective-C and Swift are cheating vs. programming in assembler. You can do everything in assembler, it just takes 10x as long, and is much harder to maintain. Building your UI in code makes it much harder to change later. – Duncan C Nov 30 '16 at 13:42
  • Bear in mind I say this as somebody who developed a commercial word processor in assembler back in the day. Storyboards both greatly increase your productivity AND make it easier to change and maintain your UI/UX. – Duncan C Nov 30 '16 at 13:43
  • Oh very nice, well put, never thought of it like that before. When I get more experienced then I'm sure I'll opt for Storyboarding (or anything similar to that type of graphical coding) in the future. For now, hard coding let's me go through the works of high-maintenance techniques that really show how unnecessary it is to do everything by hand (in Objective-C, that is). Right now I just wrapped up creating my own hard-coded version of Autolayout specific to my app's graphical features. It's going to be awful to maintain it but at least I get to find out why in the future. – Anthony Shintoluggenprog Nov 30 '16 at 16:22
  • Is Assembly something cool to learn on the side? I've thought about getting involved with it but if a good amount of experienced people tell me 10 other things I could've been doing with my time then I'll scrap it. – Anthony Shintoluggenprog Nov 30 '16 at 16:24
  • Knowing assembly helps you understand what's going on at the lowest levels of your computer. However, the learning curve is HUGE, and writing an app of any complexity at all in assembler is like trying to build a bridge out of toothpicks. – Duncan C Nov 30 '16 at 16:44