I have an iOS application which runs on the iPad. So the iPad has a larger screen than iPhones so that it can include many views within a single UIViewController which makes the UIViewController code very bulky and design is messed up.
I've been using ContainerView for now. I use 'protocol delegate' to pass data from child view's view controller to container view's view controller and NotificationCenter to pass data from container view's view controller to child view's view controller. I would like to know other approaches to this.
Related
I have an iOS project where I have my main view Controller, A, and another ViewController B. B is embedded in A as a child view controller. The whole thing is set up in Interface Builder using a Container View.
Now, B has some logic where it reacts to pan gestures to resize its view. This all works fine, the problem is that the Container View always stays the same size and does not resize with B's root view. I want the Container View's size to stay in sync with the root view of B.
What is the best approach for this? Is there any way to set this up in Interface Builder? The only feasible solution I found so far was to create a BDelegate, which A listens to and then resizes the Container View. Is there an easier way to achieve this?
thanks
Thanks to your answers, I got pointed in the right direction - specifically, that this is not possible the way I thought it was.
There is no way to have constraints between the views of a parent view controller and a child view controller - neither in IB, nor in code
As far as I can see, there are two ways to solve this:
Don't use a second UIViewController. Make the root view of your child view controller an actual subview of yourself, and just have a single UIViewController.
Do not use auto layout. Manage the frame of your child view controller's view manually, and have delegate callbacks back to your parent view controller where necessary. In those delegate callbacks, your parent view controller can react to size changes of the child view controller's view.
equalHeight and equalWidth constraints should solve your problem
I've been a Mac programmer since 1993 and find it somewhat hard to get into the iOS frame of mind from time to time.
I've got an iPhone app that was designed for the iPhone 5 screen size and shows 3 different views with different functionalities depending on the orientation of the device (portrait and 2xlandscape).
Now on the iPad I want to separate the landscape screen into a left part controlled by one (existing) view controller and the right part by another (existing) view controller.
As part of trying to support split screen multi-tasking I want to support size classes but my views are in xib files at the moment.. and as far as I know size classes are bound to using storyboards, so I'm migrating to storyboards which seem very ill-structured for my purposes.
I can see that the idea is
1 window = 1 root controller
and
1 screen full = 1 scene = 1 view controller.
But what I need is two (or 3) view controller in a single scene.
I've had a look at UISplitView, which seems perfect only that the left view controller has to be a navigation controller, so not what I need. Perhaps a custom collection view controller is the answer?
I'm sure I'm missing something as I'm very much stuck in a Mac mindset and haven't used storyboards before.. what's the best way of re-using my existing view controllers in this scenario?
Any advice would be very much appreciated.
Take a look at this image:
There is a component in the object library called a container view. You can connect a new view controller via a segue to that container view. Basically, you can create a parent view controller whose sole purpose is to manage/move the views of other view controllers.
The parent view controller can have outlets to container views (which are simple UIView objects) and each container view can be its own view controller.
Hope this make sense, and sends you in the right direction.
I know there is the common practice in iOS development of having one UIViewController presented on the screen whose view is loaded from a XIB which will contain all the UIView subclasses in it.
While I was working on a pretty complex widget for an app, I decided to make the widget subclass a UIViewController instead of a UIView. This was because I thought a UIViewController was essentially a UIView with some helper methods around it. Then I could create a XIB for it (I know UIViews can have their own XIBs too), load the views it contains, place ITS view in the presented parent VC's view, and lay it out.
This works fine so far, but I'm wondering if this is bad practice and if I should just subclass a UIView instead and give it a normal NSObject controller. I am seeing some problems with this and I was wondering if anybody could address concerns I have with this approach?
EDIT NOTE: The widget VC does NOT relate to the VC view it is in and is reusable on ANY screen. So the answer is not subclassing the widget VC with the parent VC. The widget is INSIDE the parent VC, but it is NOT a parent VC.
EDIT NOTE 2: I am NOT using Storyboard. Only Autolayout, XIBs, and ARC.
Why can't we have VC's in VC's?
1) Can VC's be simply dropped into ANOTHER VC's XIB and be loaded easily as a subview?
2) I read here: When to use a UIView vs. a UIViewController on the iPhone?
The top answer explains how the VC controls rotation of the screen and laying out the subviews again, so if you add another VC, then the system will automatically think that THAT is the main VC and will attempt to rotate it instead, causing problems. Is this true? Or is he just talking about if you somehow got into a state where 2 VC's were "presented"? I wasn't sure if his answer applied to VC views that were SUBVIEWS of other VC views.
3) In general is this good practice? It certainly seemed more reasonable as it made loading the subview VC's view much easier.
Thanks!
It's absolutely fine. The answer to your problem is ContainerView.
Container View defines a region within a view controller's view subgraph that can include a child view controller. Create an embed segue from the container view to the child view controller in the storyboard.
You almost got it right. Yes, it's good to make a view controller for what you needed. But you shouldn't just add it's view to the parent view, you should also add the view controller as a child view controller of the first view.
You can add many views controllers as child view controllers of a view controller.
You can learn more about this here.
On iPad, I've got a main UIViewController that's supposed to embed side by side two childViewControllers. How can I instantiate them both, and put them on screen?
You can use container views in IB. Drag out 2 container views into the controllers view, and size them how you want. You will automatically get two connected view controllers, sized appropriately. The main view controller, and its two children will all be instantiated at the same time. If you need to get access to the children from the parent, you use self.childViewControllers.
Sounds like you should use a UISplitViewController as a container for two view controllers:
The UISplitViewController class is a container view controller that
manages the presentation of two side-by-side view controllers.
When using custom container view controller, I don't quite understand why the presenting view controller needs to specify the from, because being the container class, it should already know what's in the view hierarchy, no?
transitionFromViewController:toViewController:duration:options:animations:completion:
Container view controllers sometimes need to put the views of the contained controllers into specific subviews of their own view. (For example, a SplitViewController reimplementation might have left and right positioning views holding the master and detail controller views respectively.) Providing the fromViewController tells UIViewController where in the view hierarchy the new controller's view should be inserted, and also which specific view should be removed after the animation.
(contrary to another answer, the frames of the views aren't set for you at all. You do that, before the call, and in the animation block. The "Creating Custom Container View Controllers" system guide in the docs has a pretty good example.)
As it happens, actually using transitionFromViewController:... appears to be optional. You can manage your view hierarchy manually, with or without animations, and it works fine. I'm still forming my opinions, but I think I prefer to do it manually, to more easily handle cases where one of the VCs is nil.
This is done this way to allow you to have a view controller that has views with viewControllers in it. The from defines the originating view controller and gives the system the ability to position the animations appropriately.
Imaging you had a view with 4 views in it like tiles. the main view controller can consecutively call this on its "child" view controllers and with the from -> to specification, it won't make the assumption that the caller is the from viewController.