Is it possible to use one storyboard setup of a view controller with two view controllers?
Situation: I created one view controller's view in my storyboard. This one lets the user add a new data entry. Lets call it MyNewEntryViewController. This works fine. Now I need a way to edit my data entries. For that I'd just like to subclass my first view controller and adapt it where it needs to be. Lets call this one MyEditEntryViewController.
I would load MyNewEntryViewController using instantiateViewController… on my storyboard:
MyNewEntryViewController *newEntryViewController = [storyboard instantiateViewControllerWithIdentifier:#"NewEntryViewController"];
That works great.
What if I want to instantiate my new view controller now? Trying the obvious
MyEditEntryViewController *editEntryViewController = [storyboard instantiateViewControllerWithIdentifier:#"NewEntryViewController"];
results in an MyNewEntryViewController stored in my variable because that's what I had defined in that storyboard.
So, whats the best way to work with my storyboard definition and be able to use two different view controllers? How do you guys do this?
Thanks!
–f
No this is not possible. It is possible to do this with plain old xibs. You can then specify the name of the nib when you initWithNibNamed:bundle: the view controller.
However, I think it's worth taking a step back. Is it really a good idea to do this? Subclassing view controllers can get messy. View controllers are intended to be self contained units of functionality, which is at odds with subclassing. Unless a view controller is specifically designed to be subclassed then I would avoid doing so. I would suggest that you merge the two view controllers and override setEditing:animated:.
Related
I'm trying to do a project for the iPad in which I'd like to utilized the split view controller. I'll be having different detail view controllers for each of the cells in the master view controller.
I saw one solution how to do this via storyboard segues in this site.
He basically linked each of his UITableViewCell to different detail view controllers. But I'd like to know if this is a "stable" or a "good" way of doing this. I mean, is it any better or as stable as doing it programmatically? What would be the consequences of doing his method, if there are any?
Here is the link to the solution I found
This is kind of a tricky one, even though it's an incredibly common use case.
1) One idea is to have an empty root view controller as your detail and it handles managing segues under the hood to quickly segue to the detail view you actually care about, utilizing the "replace" segue. This should "technically" fix having the "back" button at the top left and still allow you to pop to root and not have it show the empty controller. Haven't tested these though, so I'm not sure.
Edit: In Xcode 6, the "replace" segue is conveniently handled by a "show detail" segue which is used specifically for this type of view handling on Split View Controllers. I recommend using this method exclusively in new projects. See sample code.
2) The other idea is to have separate navigation controllers in your storyboard (one connected, the rest all stranded). One for each detail view type and tapping on the master menu will simply swap the navigation controller for the detail view to the one you care about.
Code similar to this in AppDelegate:
self.detailNavigationController = [self.masterNavigationController.storyboard instantiateViewControllerWithIdentifier:#"MyChosenNavigationControllerStoryboardId"];
self.splitViewController.viewControllers = #[self.splitViewController.viewControllers[0], self.detailNavigationController];
self.splitViewController.delegate = (id)self.detailNavigationController.topViewController;
The downside to this second way is that in memory tests, it doesn't appear that swapping a new nav controllers in frees up all of the memory that the old nav controller was using. So it's good to use for simple apps but not for anything crazy complex.
I need to know how to add one view contoller as a child of another view controller in objective-c.
As of now I am presenting a view controller as a modal of the rootview controller. But I want to change it now. I have 2 view controllers which I am presenting as modals of root view controller. But how can I present them in a different way? How does this parent-children concept work? Please give me some references.
To start with you should read the following:
View Controller Programming Guide
Abusing UIViewControllers
I believe that between the two of them you should be able to learn most, if not all, of what you need to learn about UIViewControllers and view hierarchys.
I am trying to develop an application that has screen flow similar to oracle app. I have attached the images here. Can anyone please tell how this can be achieved ?
Thanks in advance.
What you are looking for is a custom Split View Controller. The screenshots you provided are of custom split view controllers. The UIKit has UISplitViewController but this must be a fullscreen view controller.
To make a custom split view controller there's the old way, by having a main view controller and making your two master and detail controllers, adding their view to the main view controllers view.
You need to forward on calls from viewWillAppear:, viewWillDisappear: etc from the main view controller to the two controllers that you manage.
As of iOS 5, you can do something similar with view controller containment, this has a few more bells and whistles, more interesting it handles rotation animations better and all the call forwarding to the children controllers that you had to do manually in the first solution.
Check out this link for more details on custom split view controllers:
http://www.mindtreatstudios.com/how-its-made/custom-uisplitviewcontroller-ios/
To answer your question directly: if you make a custom split view controller - yes you can add this as a detail view controller. But watch out, this isn't a UISplitViewController, so just be careful not to use that term so much.
Haven't really tested this, but doesn't this solve your problem?
Create a storyboard file
Drop in a SplitViewController
Delete the DetailViewController
Drop in another SplitViewController
Link the two together using CTRL-drag and select Detail
Set the size of the detail-splitviewcontroller to Detail
????
Profit!
Anyways, not sure if it really works, but give it a try. This is IOS5 though (I think, might try it out with IB).
It'll look something like this:
If you're going to have to write your own class, you might want to first look at https://github.com/mattgemmell/MGSplitViewController for inspiration.
Quite possibly I'm missing something obvious, but I have a very simple requirement and neither of these two seems to meet it.
I have an application with 3 distinct views, however for reasons I won't go into here (essentially views may or may not be valid depending in what is done in other views), using persistant tabs as navigation will not work. I also want each view to be created as needed and UITabBarController creates all its views upfront. However I still want some of the functionality of UITabBarController - being able to pass it in an Array of UIViewControllers.
UINavigationController offers the chance to have it create its views as needed, but there is no way for me to pass a list of views to it up front, so I end up with ViewControllers creating and pushing other (sibling) ViewControllers which is nasty.
So here are my requirements:
I want to be able to add ViewControllers upfront
I want to be able to navigate between the view controllers
I want each ViewController to be created as needed and destroyed when navigated away from
Is there anything that fits the bill?
I would use the AppDelegate to create a hash of viewcontrollers upfront and create a navigation controller.
Once you click the button to navigate to a new viewcontroller you can go to the hash and look for that specific view controller. If it is not created you can create it there. If you want to destroy that view controller just release it and remove from the hash.
I've got a fairly complex view, for me anyway, that has a few "trays" with custom interface items on them. They slide in and out of my root view. I'd like to nest (addSubview) the items inside the view. Each needs some setup before being displayed...and none can be configured in IB (they're subclasses of UIView).
I'm wondering if it makes sense to subclass UIViewController for each "tray" and then have the VC's view property point to the "tray" view which I can populate with my custom UIView objects. This way I can leverage the viewDidLoad, etc... methods in UIViewController.
I'm not aware of others doing this - at least in the few samples I've looked at. It would create a situation where there would be multiple view controllers being displayed on the screen at once. from the Navigation controller itself on down to the rootViewController and its view and then any number (well, screen size permitting) of these small trayViewControllers. If so, how's the responder chain work? i assume it'd go from lowest UIView to its enclosing VC, then to that VC's parent view, then that view's VC, etc. etc. repeat, repeat.. up to UIApplication... am I asking for trouble?
OR, do I just stick with UIViews and adding subviews into subviews, etc. etc..
Prior to iOS 5.0 this will specifically not recommended because the nested view controllers' lifecycle events – viewWillAppear, etc. – won't be called. See Abusing UIViewControllers.
With multiple UIViewController’s views visible at once some of those controllers may not receive important messages like -viewWillAppear: or -didReceiveMemoryWarning. Additionally some of their properties like parentViewController and interfaceOrientation may not be set or updated as expected.
iOS 5.0 added containment UIViewControllers that correctly handles those lifecycle events by adding child view controllers.
- (void)addChildViewController:(UIViewController *)childController
I spent countless hours trying to get nested view controllers to work in iOS 4. I eventually did, but it required a lot of glue code that was easy to get wrong. Then I saw the warning in the docs.
I'm trying to do the same thing, but was dissuaded from your approach by Apple's documentation, which states that "You should not use view controllers to manage views that fill only a part of their window—that is, only part of the area defined by the application content rectangle. If you want to have an interface composed of several smaller views, embed them all in a single root view and manage that view with your view controller."
My experience on what you are trying to do has been a good one. I try to keep nib files as simple as possible, so I take any posible "subview" and encapsulate it in its own nib file with it's own view controller, therefore I end up having nested view controllers.
In one of my apps I have a very complex table view cell, that has a subview. So I ended up having a hierarchy that goes like this: the tableview controller on the top level, the tableviewcell's controllers for each row and inside each of these a subviewcontroller for the subview inside each cell.
And everything works fine.
Pardon my english.