I have a storyboard setup with the main view having a bunch of buttons and a container view and I would like for a different view to be loaded into that container view each time I press one of those buttons, kind of like a tab view controller works but without using one of those.
Also, later on I plan to have buttons inside those views that load other views replacing the views themselves.
Anyone can give me some hints?
Thanks
"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 mentioned NSContainerView, so I assume you're trying to do this on macOS, not iOS. Here's a useful article and code project (for iOS 6, but I was able to set up switchable subviews in iOS 9 using this as a guide):
http://sandmoose.com/post/35714028270/storyboards-with-custom-container-view-controllers
The important bits are using the embed segue, then wiring the view controllers together through a combination of viewDidLoad and prepareForSegue, and then finally loading one of the switchable view controllers (say one for each of your buttons) from the storyboard, where they are not connected to anything else.
Related
I am writing an application for mac OSX in swift and I would like to separate the code clearly so I am looking for a way to have a view controller for each NSTabViewItem in a NSTabView without use the Tab View Controller. Is it possible ?
Finally, I found a solution.
It’s possible to do that with a “Container view”. I put a Container View in a view. I created a new view controller. Finally, I linked both with Ctrl-Drag from container view to the new view controller and selected "embed".
More information in this tutorial
Currently have I implemented iAd and AdMob to each and every view controller in my Xcode project. I have about 6 view controllers and every time I switch back and forth between them one adbanner disappear and another appears. I want to make only one single adbanner for all view controllers. So even though its a transition between two view controllers, only one adbanner will be visible and it will not disappear and appear again.
But I also need to reach it from each class. So I can show it and hide it when I want to.
I would appreciate a ditailed step-by-step instruction.
INFO:
I am using storyboard. I am developing for iOS 6.0 and higher. I am using navigation controller.
So pass the banner view from one view controller to the next just as you'd pass any data. Install the view in the view hierarchy in each controller's -viewWillAppear method. You can pass the view between controllers in your -prepareForSegue method. If you're not sure how to pass objects between view controllers, search here -- here are many questions covering exactly that topic.
In iOS5 using storyboard feature I want to create a custom container which will have 2 ViewControllers embedded in it. For Example, embed Table view controller as well as a view controller both in one ViewController.
That is, one view controller will have 2 relationship:
to table view controller
to view controller which in turn will have 4 UIImage view Or UIButton in it
Is creating this type of relationship possible using storyboard's drag drop feature only & not programmatically?
,You should only have one view controller to control the scene. However, this viewController might have two other view controllers that control particular subviews on your scene. To do this you create properties in your scene viewController, in your case one for your tableViewController and one for your view. I like to keep things together so I make both these viewControllers outlets and create them in interface builder. To create them in interface builder pull in an Object from the Object library and set its type to the relevant viewController. Hook it up to the appropriate outlet you just created in your scene's viewController - Note: this is important otherwise the viewController will be released if you are using ARC and crash your app. Then hook these viewControllers up to the view you want them to control and you are done.
Alternatively you can instantiate and hop up your viewControllers in your scenes viewController should you prefer to do this.
Hope this helps.
Edit: On reflection this is not a good idea and actually goes against the HIG you should maintain only one ViewController for each screen of content and instead try to create a suitable view class and have the single view controller deal with the interactions between the various views.
There is a way to do it that isn't too hacky. It is described at the following URL for UITabBarControllers, which you could use the first view controller in the list control the first subview, and the second one control the other. Or, you can probably adapt the code to work with UISplitViewController.
http://bartlettpublishing.com/site/bartpub/blog/3/entry/351
Basically, it works by replacing the tabbarcontroller at runtime after iOS has finished configuring it.
I'm newbie in iOS dev. I need windows with tree views on it. I created view-base application, and added UIView controls in master view. Also i added 3 View controllers for that views with view definition in separated xib files. How to link views from separated xib files with view areas on master view? Should i manually create controller instances and load controller's view into view areas? Or maybe is possible to create them in IB? Thank you.
You should be able to just drag the instances of the three controllers into the nib file of the master view, and resize them in order to create the desired layout. However, make sure that the properties on the subviews are correct or they could overlap. In the library window of IB, go to the classes tab, and drag the classes you want (View Controllers) to the nib.
I prefer that method over manually adding them through code, as it allows much better functionality with resizing such as from rotation.
I'm tinkering with an iPad app that (like many iPad apps) doesn't use the UINavigation root view control system, so I don't have natural ownership for each app "view". I essentially have two basic views: a document list view, and a document edit view.
I'm playing with UIView animation for getting from a selected document to the edit view.
I also have a toolbar on top that exists (with different buttons) in both "views".
Because I don't have UINavigation running the show for me, I have a tendency to just throw more and more stuff into one NIB and one view controller that owns the whole container. But now I'm trying to figure out how to segue from the document list view to the edit view if the edit view lives inside a different NIB, preserving the toolbar too.
Anyone have thoughts or experience on app structures like this? I find the docs lacking on best practices around code/UI structure for anything except trivial one-screen apps or full-on navigation apps.
You're not "supposed" to have parent/child view controllers owning subcomponents of the same "screen" according to the docs, but this implies one massive honking view controller that basically contains the whole app, and that can't be right.
Not sure if there's a "right answer" to this; I'm looking for some intelligent examples or suggestions. Nobody's touched this question in months, so I'm adding a bounty to generate good chatter. :)
Thanks!
UPDATE: I'm not talking about a split view, which is clearly well handled by a split view controller. Instead, take a look at Apple's iWork apps (e.g. Pages) which have a document list view and an independent edit view, but these are related by animation.
Maybe the real question here is: how would you (or could you even?) build a "container" view controller like the split view or navigation controller, yourself? Are you required to build the whole damn thing from scratch? I sense that you are, because seems to be hidden wiring in the interaction between view controllers. If so, thoughts on this?
I think the only hidden wiring in view controllers is setting parentViewController, which is required to support the categories declared for split and navigation.
View controllers are designed to be nested, with each controller owning a part of the view hierarchy. The only design goal is that no view controller reach into the view hierarchy of another controller. A parent view controller will usually have some call for adding child controllers so that it can set the frame of the view within the view hierarchy it owns. A child view controller should not do anything to the superview of the view it controls, as that is owned by another controller. Not should it set the center or frame of the view it controls.
For example, a navigation controller has a push method, in which it removes the previous controller view, adds the new controller view, and sets the frame of the newly added view. In general, a parent view controller is free to set the frame of the view of a child controller, but not the bounds.
If you want to change the animation of a navigation controller, I think you would start by implementing every method with an animated: argument. Set up your animation then call super with the animated flag off before committing the animation.
I haven't tried the multiple-view-controllers thing outside of the UIKit-provided ones (navigation/tab-bar/modal/etc) but I don't see why it shouldn't work. Under the hood, everything is a view, though I'll note that UIKit has special views for view controllers which no doubt have some kind of special handling by the system (UIViewController has a wrapper view, UINavigationController has a UINavigationTransitionView or something, ...).
I'd advise not worrying too much about "best practice" — just code something which does what you want. A couple of options:
Stick logic into view classes (ewwww!). One of our apps does this so it can handle rotation in a custom way (views slide in/out instead of rotating). We should've probably implemented our own view controller logic instead.
Break the model into components which correspond to views. Make each view know how to load its component and recursively load subcomponents. Then the view controller only needs to worry about "big picture" stuff.
Also note that you can load multiple nibs into the same view controller by e.g. connecting it to an outlet called editView.The big difference is that it's not done automatically by -[UIViewController loadView] so you need to do something like
-(EditView*)editView {
if (!editView) {
// Loads EditView into the outlet editView
[NSBundle loadNibNamed:#"EditView" owner:self];
}
return editView;
}
You'll also need to worry about adding it to your view hierarchy, unloading it on -(void)viewDidUnload (iPhone OS 3.0+), setting it up in -(void)viewDidLoad in case there was a memory warning during editing mode, etc...
It's not easy, but UI never is.
You need a master-detail view implemented with a split-view/popover-view and controlled with a UISplitViewController.
The master view is the document list and the detail view is the edit view. Each has its own controller. The two controllers themselves are managed by the UISplitViewController.
If you don't use the splitview controller you will just end up hand coding something that works very much like it. This is really the only way to do what you want easily in the API and it is the layout that iPad users will expect.
See Creating a Split View Interface in the iPad programming guide for details.