I am converting an iPhone application to work on the iPad. In this case, the user interface was created with interface builder. The interface of the root controller (at index 0), consists of a Tab Controller & Navigation Controllers in this layout:
Tab Controller
Navigation Controller 1
Navigation Controller 2
Navigation Controller 3
I have been implementing this in pieces. When I setup the Tab Controller & Navigation Controller 1 as a first step, everything works correctly. willHideViewController & willShowViewController work correctly. My interface switches from SplitView to Popover correctly. When I add Navigation Controller 2, willHideViewController & willShowViewController never fire & I always see the Popover controller no matter what orientation the iPad is within the simulator.
When I add a second navigation controller, is there something else I need to tie off within the interface builder to get the interface to work correctly?
I'm guessing that you've set a delegate for the first navigation controller but not one for the second. The delegate object would receive methods like willHideViewController.
I'm also not sure that having multiple navigation controllers is good style. A view controller knows that it has been placed in a navigation controller, and you can access this with self.navigationController. You should keep pushing view controllers on the same navigation controller. Or I may have misunderstood what you're trying to do with your tab controller.
The answer to this is pretty simple: When you implement the split view controller & you want everything to switch correctly from portrait to landscape, you need to make sure that all the interface elements implement shouldAutorotateToInterfaceOrientation for portrait & landscape layouts.
Related
So far, I have two distinct uses of a navigation bar in my app: one produced by a Navigation Controller with a View Controller embedded in it and one added manually from the Object Library into a different View Controller presented modally (since a modally presented view apparently doesn't inherit the navigation controller of the view under it).
My question: do either of these navigation bars require constraints?
Yes, the one added by you, as it is managed by you. The other one is managed by UINavigationController. Also it wouldn't make sense for a modal controller to have the navigation bar of its presenter - you are showing an "extra" screen, not navigating the hierarchy. It is also worth mentioning that nothing stops you from presenting another UINavigationController modally with a separate navigation flow.
I have a storyboard with this situation;
The root view controller is a UISplitViewController with:
MASTER: a UITabBarController
0 ->UINavigationController -> ...other ViewControllers
1 ->UINavigationController -> ...other ViewControllers
DETAIL: a UINavigationController -> a DetailViewControler
With this hierarchy the segue showDetail from last viewcontroller in master to the Navigation Controller in Detail doesn't work because the Detail is presented Modally in a Collapsed environment instead of presenting it with a push.
I think this behavior comes from the Tab Bar Controller because it isn't a Container like a UINavigationController. In fact if i remove the tab bar and set a navigation as Master of Split View Controller it works like usual.
What can i do for using a tab bar like Master of Split View Controller and get the right behavior of showDetail segue in a collapsed environment?
P.S.: for right behavior i mean pushing the Detail in the Master Navigation Controller in a horizontal compact environment (iPhone 6 plus Portrait).
I solved this issue overriding these methods of the UISplitViewControllerDelegate and implementing inside them all the behavior i want from the SplitViewController:
primaryViewControllerForCollapsingSplitViewController
splitViewController:collapseSecondaryViewController:ontoPrimaryViewController
primaryViewControllerForExpandingSplitViewController
splitViewController:separateSecondaryViewControllerFromPrimaryViewController:
I suggest you to take a look at UISplitViewController Documentation because it explains very well the behavior of the Split Controller:
UISplitViewController Documentation
You can find what you need here:
The split view controller performs collapse and expand transitions when its size class toggles between horizontally regular and horizontally compact. During these transitions, the split view controller changes how it displays its child view controllers. When changing from horizontally regular to horizontally compact, the split view controller collapses one view controller onto the other. When changing from horizontally compact back to horizontally regular, it expands the interface again and displays one or both of its child view controllers depending on the display mode.
When transitioning to a collapsed interface, the split view controller works with its delegate to manage the transition. At the end of a collapse transition, the split view controller normally shows only the content from its primary view controller. You can change this behavior by implementing the primaryViewControllerForCollapsingSplitViewController: method in your split view controller delegate. You might use that method to specify the secondary view controller or an entirely different view controller—perhaps one better suited for display in a horizontally compact environment. If you want to perform any additional adjustments of the view controllers and view hierarchy, you can also implement the splitViewController:collapseSecondaryViewController:ontoPrimaryViewController: method in your delegate.
The expansion process reverses the collapsing process by asking the delegate to designate which view controller becomes the primary view controller and to give the delegate a chance to perform the transition itself. If you implement the delegate methods for collapsing your split view interface, you should also implement the primaryViewControllerForExpandingSplitViewController: and splitViewController:separateSecondaryViewControllerFromPrimaryViewController: methods for expanding that interface. If you do not implement any of the methods, the split view controller provides default behavior to handle the collapsing and expanding transitions.
For more information about the methods you use to manage the collapse and expand transitions, see UISplitViewControllerDelegate Protocol Reference.
Hope this can help you.
PS: sorry for bad english.
During a showDetail segue the Split View Controller checks if collapsed and calls showViewController on the primary, which in this case is the tab controller which doesn't implement this method so relies on the default view controller method which is to search up the hierachy to find on that does; in this case showViewController called on the Split View Controller which implements it by firs checking if collapsed then it calls presentViewController which is why you see it as presented modally.
To solve this you could subclass the Tab Controller, implement showViewController and call it on the selected view controller, which would be the current navigation controller.
You also need to handle the collapse and separate, one way would be to implement separateSecondaryViewControllerForSplitViewController in your tab subclass and forward that on to the nav controller child that contains the detail nav controller because that is what un-hides its nav bar and pops it off the stack. You wouldn't get that behaviour if you implemented the split controllers' separateSecondary delegate method
Difference between navigation controller and viewcontroller?
I mean how can we decide when to use navigation controller or a normal view controller?
Just my two cents:
A UIViewController represents a single view and you can put buttons in this view controller to segue to another UIViewController. If you want to segue back to the first UIViewController, you will have to worry about putting a button in the second view controller that leads back to the first. If you are drilling down into view controllers, this can be tedious having to remember to give the user a way back to a previous view controller.
A UINavigationController does a lot of this tedious work for you. As mentioned, it contains a stack of UIViewControllers. It will create a navigation bar at the top that will allow you to easily go back up the hierarchy of view controllers.
In short, if you have a hierarchy of view controllers that you want the user to easily navigate around, inbed your UIViewControllers into a UINavigation controller.
UINavigation Controller is a combination of 2 or more view controllers,those are connected through "segue" feature of "Ios". Benefit of using Navigation Controller is that we can navigate between different screens easily with default "Back" button on each screen . We don't need to give any individual button to move back onto previous screen.
Whereas a ViewController provides a single screen & we can connect more screen using "segue" but we also have to design a "Back" button to navigate onto previous screen.
We should use Navigation Controller , in case where one option resides into another one.Like in an iPhone settings ->Mobile Data Options->Voice->4G or 3G or 2G. It's a hierarchy of menus so here navigation Controller is better option than using UIController.
We should use UiController with "segue " , in case where
we have to choose one option among multiple.Like -
Photos ->There are many folders in which , any one is selected, that are Favourites or People or Places .
Here's a very brief, high-level overview.
Whereas a UIViewController can be thought of as representing a single 'screen', UINavigationController, as the name implies, is used as a means of being able to navigate multiple 'screens'.
From the documentation:
The UINavigationController class implements a specialized view controller that manages the navigation of hierarchical content. This navigation interface makes it possible to present your data efficiently and makes it easier for the user to navigate that content. You generally use this class as-is but in iOS 6 and later you may subclass to customize the class behavior.
Please see the rest of the UINavigationController documentation here: https://developer.apple.com/library/ios/documentation/UIKit/Reference/UINavigationController_Class/index.html
Okay, Thank you everyone for helping me to find out a clear answer on this.
Navigation Controller consists of navigation bar and tool bar to move in and out from view controllers present in navigation stack.Therefore there can be many view controllers in Navigation Controller.
In view controller we don't have this facility and it represents a single screen view.
Please correct me If I am wrong.
See the Navigation Controller discussion in the View Controller Catalog.
Bottom line, a navigation controller actually is a view controller, but it just happens to be one that presents and navigates between other view controllers.
I have an iOS app which is structured in this way:
One tab bar controller with 4 navigation controllers. Each navigation controller has its own view controller with a xib file.
The issue, is that ONLY THE FIRST TIME, when I push a new view into one of the navigation controllers, the new view doesn't appear at all. When I switch to another nav controller (touching one of tab bar's options) and then switch back to the first one, it works all the time.
The error I'm getting is when I come back is:
[35731:70b] Unbalanced calls to begin/end appearance transitions for
.
Thanks for helping out.
Make sure you are presenting all your view controllers from the parent / top level view controller (the tab bar controller). I've had this a few times when presenting a view controller from one of the view controllers in the tab bar.
In viewdidload assign your first view controller to load when xib loads. Its the correct way to load first view controller to appear when nib loads.
I have an application in Xcode 4.6 that uses storyboards. The root view controller is embedded in a navigation controller, and all view controllers in the application are accessed via push segues via the navigation controller.
I ran into a complication when I wanted to have one particular view controller (called photos) accessed via a push segue by two different view controllers. I ended up with what appeared to be a navigation controller inside a navigation controller in the photos controller after I added the second segue. The goal is to just have (in photos) one navigation bar with a dismiss button that (when pressed) pops back to whichever of the two view controllers presented the photos view controller. I am somewhat new to iOS and I am not sure of the best way to accomplish this or how to generally handle this situation.
Here is a picture of my storyboard for reference:
You should really do it programmatically using SotyboardID. It's only a few lines of code in each ViewControler.