I'm looking to implement a custom segue that pushes to a UIViewController, but completes before the new UIViewController fully fills the screen, leaving some of the source view controller still in view and functional. (For example; new view controller covers half of the user interface).
I'm keen to use a segue rather than a view that is moved using CGRect, Quartz framework method, or similar, as constraints get messy really easily, unless a custom segue could utilise such methods(?)
Any pointers greatly welcomed! :)
For this task you would use a container view controller, which manages and displays the content of multiple other view controllers at a time while letting them interact with their views like normal. An example of this would be the UISplitViewController, which displays two view controllers' views at a time, one on each side of the screen. You can design segues that swap out one view controller of the multiple on display in a container view controller, similarly to the Replace Segue implemented by Apple to swap out a UISplitViewController's detail view controller (the one on the right hand side).
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 don't like the UINavigationController because the tree/drill-down navigation style does not work in all situations. What I'm looking for is a sort of UISwitchController where a view controller can tell the UISwitchController what the next view is and the data to pass to it. Then the current view closes itself and the UISwitchController would handle opening the next view and passing in the data from the previous view. The UISwitchController could remember the name/type of the last view opened so the current view could tell who opened it (also allows the UISwitchController to handle a Back request by the current view without the current view specifying the name of the view that opened it). A view could also flag the UISwitchController to keep it in memory and not to release it after it closes so the view controller is essential reused for each call to that view. Is there such an framework?
So basically you are talking of a UIViewController that holds several UIView(Controller)s and handles the presentation.
In iOS < 5 I would just use a UIViewController, that adds views to another view, that is displayed.
in iOS 5+ you should familiarize yourself with UIViewController Containment, that is actually a pattern of how to use UIViewControllers with other child view controllers.
form the UIViewController doc
Implementing a Container View Controller
In iOS 5.0 and later, custom UIViewController subclasses can also act
as container view controllers. A container view controller manages the
presentation of content of other view controllers it owns, also known
as its child view controllers. A child’s view can be presented as-is
or in conjunction with views owned by the container view controller.
Your container view controller subclass should declare a public
interface to associate its children. The nature of these methods is up
to you and depends on the semantics of the container you are creating.
You need to decide how many children can be displayed by your view
controller at once, when those children are displayed, and where they
appear in your view controller’s view hierarchy. Your view controller
class defines what relationships, if any, are shared by the children.
By establishing a clean public interface for your container, you
ensure that children use its capabilities logically, without accessing
too many private details about how your container implements the
behavior.
Session 102 - Implementing UIViewController Containment — WWDC 2011
I haven't used it much so I don't know if it's exactly what you're looking for, but you can use TTNavigator from the three20 framework to do URL based navigation which sounds like it could be what you want.
https://github.com/facebook/three20
I'm having trouble to achieve the following using a storyboard:
When setup is not done:
run app -> show settings view controller -> show main navigation controller
When setup is done:
run app -> show main navigation controller
So basically, I want the app to programmatically start with the settings view in certain cases, and otherwise skip right ahead to the main navigation controller.
I did manage to show the settings view with a modal style segue from the main navigation controller, but I don't know how to display it before the main navigation controller is displayed. Any ideas?
By default, the initial view controller from your main storyboard is instantiated and displayed automatically when your app starts up. To prevent this happening you need to remove the UIMainStoryboardFile setting from your info.plist file.
With no default view controller, you are now free to create one programmatically at app startup. See the UIStoryboard documentation. Use +storyboardWithName:bundle: to load the storyboard and then use –instantiateViewControllerWithIdentifier: to create the correct view controller. You will also need to create a main UIWindow and add the view controller's view to it just like you used to do with .nib based UI. Note that without the UIMainStoryboardFile setting a main window is not created for you - read the explanation.
I managed to do it a bit different:
Use a UINavigationController as the initial view controller.
Create a root view controller that will manage the decision of what to load.
Create a Storyboard Segues from the root view controller to the main view and to settings view, and give the segues proper identifiers.
Call the performSegueWithIdentifier with the proper identifier from your root view controller.
Just another solution, hope this helps.
I did something similar to amoshaviv, his advice is sound. I did it slightly different though, and I'll give some more info.
I created a custom MyInitialViewController class, derived from UIViewController, and made this the initial view controller.
In the storyboard file, I created modal segues with appropriate names to all (in my case three) possible 'real' first view controllers.
In the MyInitialViewController class, I implemented the
- (void)viewDidAppear:(BOOL)animated;
method, to first perform the check which view to switch to, and then do the correct
[self performSegueWithIdentifier:#"NameOfSegue" sender:self];
Effectively, this makes the MyInitialViewController nothing more than a switch performed when it's brought into view. I first tried doing this when loaded because I don't care for actually seeing this view, but that did not work, while viewDidAppear does.
To make this visually smooth, I tried the following. In the properties of the segues, I disabled animation. The view I left empty, and I gave it a background color matching to that of the startup image.
I'm trying to put an iAd banner in an app that is based on a UINavigationController (it's not the standard nav-base app proposed by xcode, cause I don't need the table view).
I'd like to place an ADBanner on its bottom, to be always visible, no matter how the user pops and pushes views.
I studied the iAdSuite example in the apple sample code, but, though it's reported among the "best practices", I don't think it's the best practice for what I need. It basically declares an ADBannerView in the app delegate class and then implements the ADBannerViewDelegate methods for every single view the app needs. That means implementing the ADBannerViewDelegate methods over and over again on every view controller class you need! It doesn't seem too smart... :(
I'd rather prefer to have an approach more similar to what Apple itself does in the tab bar based app, where you have a part of the window always occupied by the tab controller and all the views switching above without affecting the tab bar view below.
You can't directly put an ADBannerView along with the nav controller in the app delegate, because ADBanner needs to be placed in a view controller (you get a runtime error otherwise).
I tried to subclass from UIViewController, implementing the ADBannerViewDelegate in this class, and place it in the rootViewController along with a UINavigationController but I'm not having good luck with this approach...
Has anybody found a good, simple way to to this? Any hint?
Thank you for any help...
You can have just one class for ADBannerViewDelegate, and just one instance of ADBanner itself. When the currently active view changes, remove ADBanner from the old view, add it as a subview to the new view.
EDIT:
to clarify, you don't need each view implement the ADBannerViewDelegate. You only should have one class implement it (that class doesn't have to be a view controller for that matter).
You would also need to maintain a somewhere a property that would point to the currently active view (e.g. you can update that property in your Navigation Controller's navigationController:didShowViewController:animated:, or come up with your own protocol for that if your views appear in a more complex way).
Then in your ADBannerViewDelegate you'd just resize the view currently pointed to by that current view property. The actual view doesn't even have to know it has an ad in it ;)
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.