My app in iPad mode and landscape calls for a single navigation bar its proving troublesome.
The idea is that in landscape there wouldnt be 2 separate nav bars for Master and Detail : see below (Images taken from Google Images and modified, not my project)
but instead there would be a single nav bar, like so:
I'm trying to avoid very hackish methods because my navs use a lot of custom stylings but the only way I can think at the moment is to resize the view in the SplitView superclass and override the nav bar, but wanted to see if anyone else had any success before
Any ideas?
The way that the split view controller works, it displays two separate view controllers. If you want to have the unified navigation bar, don't use a split view controller, just use a regular view controller, and embed the table view in your normal view, and implement the appropriate protocols to control the table
Related
I have a simple Navigation View Hierarchy that has 2 views it goes between. I wanted a customized navigation bar, so I have the default one hidden, and I've implemented a Container View which is shared between the 2 views in the nav hierarchy.
Everything works as I want it to, except when I segue to the lower or higher view the top bar appears slides away and reappears on the new view. I would like it to appear stationary when I push or pop to other views in the hierarchy.
Is there an easy way to do this? Or should I delete my custom shared Container View and try to make this work with the Navigation Bar (which I have currently "hidden")?
I had to do this for a client once. The way we did it was, like you said, make an encompassing view controller that housed a container view. Within this container view, we embedded a UINavigationController and would manually pop and push UIViewControllers to its navigation stack. Of course you want to hide the UINavigationController's nav bar.
It sounds like you sort of implemented this, but instead you just embedded a plain old view controller inside your custom navigation controller, and then segue to another view controller that is also embedded in the custom view controller? Ideally you want one instance of this custom nav controller with an embedded UINavigationController. I believe you will have to do all the view controller transitions programmatically.
Opinion: Personally, I would recommend against doing this. I believe that an app should feel like an extension of the OS it's on. A user should feel it's a part of their phone. Using the native navigation bar also decreases the level of effort a user is required to put forth to understand your app.
I know you're thinking "but it's just a nav bar" but we're talking about the same people that will potentially uninstall an app if it takes longer than 2.5s to load.
I wanted a customized navigation bar, so I have the default one hidden
That's your mistake. The way to get a customized navigation bar in a UINavigationController interface is to initialize it with init(navigationBarClass:toolbarClass:). Now the built-in navigation controller is using your navigation bar! And from there on, all will be well.
https://developer.apple.com/reference/uikit/uinavigationcontroller/1621866-init
I've done a lot of research and read a lot about the use of Tab Bar Controllers with Split View Controllers but cannot seem to find any hint of how to solve my problem...
The following post in the Apple Developer Forum for Cocoa Touch under the heading "Place SplitViewController inside TabBarController" has so far given me the greatest lead.
As of iOS 8, embedding a Split View Controller in a tab bar controller
(or your own container view controller) is supported and expected to
'just work'. Pushing a split view controller onto a navigation stack
remains unsupported.
This appears to go against Apple Documentation including this article titled "Combined View Controller Interfaces" dated November 2014.
You can use the view controllers that the UIKit framework provides by
themselves or in conjunction with other view controllers to create
even more sophisticated interfaces. When combining view controllers,
however, the order of containment is important; only certain
arrangements are valid. The order of containment, from child to
parent, is as follows:
Content view controllers, and container view controllers that have
flexible bounds (such as the page view controller)
Navigation view controller
Tab bar controller
Split view controller
I have a UITabBarController with seven tabs. Of these, five tabs lead to UISplitViewControllers and two tabs lead to UINavigationControllers.
Here is a screenshot of some of the storyboard the shows the tab bar controller leading to three of the five split view controllers...
No problem when I run for target with self.traitCollection.horizontalSizeClass = UIUserInterfaceSizeClassRegular - where the horizontal (width) dimension of the device screen is Regular (not Compact) -> running on an iPad. All seven tabs appear across the bottom tab bar and all view controllers, including split view controllers, work perfectly.
My problem?
Xcode spits an error and freezes app operation when I run for target with self.traitCollection.horizontalSizeClass = UIUserInterfaceSizeClassCompact - where the horizontal (width) dimension of the device screen is Compact -> running on iPhone or iPhone Plus. Same outcome, as expected, for both IB and on iOS device.
Error Message: Split View Controllers cannot be pushed to a Navigation Controller <UIMoreNavigationController: 0x7ffda38b0200>
I know why I've received the error. Where the horizontal size class is "Compact", the seven tabs drops to five on screen, including one (specially prepared by iOS) "More" tab. The remaining three tabs are relegated to the "More" tab that is its own navigation controller and table view controller. My storyboard is attempting to push the split view controller onto this navigation stack.
Any thoughts on a legitimate solution?
I would recommend using a custom tab bar controller with a "More" section that does not push view controllers into a navigation controller. Preferably, one that is a subclass of UITabBarController, so you can use it with Interface Builder.
My approach would be to replace the current "More" table view controller with a view controller of your own that shows a list of overflowing tabs, but does not push their corresponding view controllers into the navigation bar when displayed.
One possible strategy is to become the delegate of the UITabBarController's more navigation controller (found in the tab bar controller's moreNavigationController property). Then use a delegate method, such as navigationController:willShowViewController:animated:, to replace the content of the navigation controller's viewControllers array if the view controller to be displayed is anything but your custom "More" view controller.
I haven't tried this, but it seems like a good place to start and does not require too much knowledge of the tabview controller's internals.
In my app, i have a main view controller which sometimes brings a modal view on top of it. This modal view is a UINavigationController with a navigation bar. I want to display an image above the navigation bar, and have the navigation bar appear below the image.
I do not want to subclass anything and the app uses autolayout, i do not want a bunch of delegate callbacks and frame calculations. The view inside the navigation controller (the actual modal content) must still respond to different screen sizes correctly, such as rotation, call status bar etc. Also, no IB solutions please, these views are all managed in code.
How do i accomplish this?
I would turn off AutoLayout and place the image at the top
I don't think you can do it with your modal view being a navigation controller. I would do it by making that modal controller a UIViewController that you set up as a custom container controller. You can add an image view to the top of this controller's view and add the view of a child view controller (which would be a navigation controller) to the bottom. This would be a lot easier to do in a storyboard using container views, but it certainly can be done in code.
I am creating a iPad App and it has several views to load data,but for one view i need to add split view. I dont need split views in other views. They are just detail pages. I search Through the net and found lots of tutorials based on iPad split view. But the problem is they all are creating a project as Split view project or they create a window base app and add slipt view to the delegate. I dont need to do that, I need to implement this split view only for one view. Is There any way to overcome this problem?
You can add the split view inside a Navigation Controller.
Even if the Split View is a container view controller and Apple recommends in the documentation that all containers should not be embedded in other containers, adding a split view inside a navigation controller works correctly and I never noticed any side effect in doing it.
Basically what you should do is:
- in the app delegate create a UINavigationController and use it as root view of your application window
- hide the navigation controller navigation bar if you don't want to see it (showing a split view with a main navbar on top is not nice looking...)
- then add your view controllers inside the navigation bar.
Example: imagine you have this application views sequence:
FIRST VIEW (full view = detail page)
SECOND VIEW (split view)
THIRD VIEW (full = detail page)
So you can represent FIRST and THIRD as standard view controllers (full screen), while SECOND will be a split view. Your app will be initialized by creating the main navigation controller, adding FIRST on it as top controller and using the main navigation controller as window's root view.
Than use the navigation controller push, pop methods to switch between these views or change the navigation controller "viewControllers" array directly if you don't want the recommended push/pop methods.
If you need to add special behavior to the navigation controller based on the type of view on top, just register your app delegate as navigation controller delegate (or a "main controller" object dedicated to this if you don't want to complicate your app delegate).
I am not 100% sure, but it seems to me that you can't use a SplitView just somewhere in your view hierarchy.
The Apple intended way is to use the SplitViewController as the top level controller. The left side of it can include a drill down mechanism with a navigation controller so you are ably to drill down hierarchies and the right side will present details for the item you select on the left side.
If you need a view with some kind of split mechanism in it, you probably have to code it yourself. Or even better: find some other mechanism you can use in your UI.
How are you switching your view hierarchies now? Maybe you could integrate your existing UI into a SplitViewController?
I understand that view controllers help control multiple views in an application, but I have trouble understanding when to use them.
If I have an application with a main page, several views with a "hierarchy" structure, and an about page not connected with the hierarchy, what files should my application have? An appdelegate, navigation controller and view controller? More than one view controller? Just a navigation controller?
Also, should they all be contained in one .xib file, or multiple .xib files?
Any help would be greatly appreciated.
Thanks.
A good habit is to have a UIViewController for each page you want to show. If I get the structure of your app you should have a main page (with many other UIViews inside it) and another page (about page). If that's true I suggest two UIViewControllers.
The UINavigationController is a subclass of UIViewController that lets you "navigate" among the pages. It's not strictly necessary but suggested (you can also implement your self a custom navigation system, but it's easier to exploit the one Apple offers you). Another navigation system is the one based on UITabBarController, if you want to take a look.
Assuming I get the structure of your app you should need two .xib file, one for each page you have.
The app delegate is conceptually different from a view controller, you'll have just a single app delegate, automatically created by Xcode (you can, of course, modify it to fit your needs).
Each "screenful of content" (Apple uses this term) should be handled by it's UIViewController or more likely a subclass of it. The point of view controller is to handle view appearing or disappearing (going on/offscreen), device rotation, memory management, navigating to other view controllers and so on. If you are creating your UI with IB, then each of those view controllers would most likely have it's own .xib file.
Each view controller has one view (it's view property) that acts as main view for each "screenful of content" to which you then add your subviews.
UINavigationController and UITabBarcontroller are there to help you control the hierarchy of your app. They only act as containers for other view controllers and don't contain any UI except navigation bar or tab bar. Using tab bar controller you can have multiple view controllers which act exactly like browser tabs. Using navigation controller you can have a stack-like navigation where new view controllers are pushed from right to left and are popped from left to right when user goes back to previous view controller. You can even have a view controller inside navigation controller inside a tab bar controller.
If you don't want to use tab bar or navigation controller, you can navigate through your view controllers by presenting them modally using presentModalViewController:animated: and dismissing by dismissModalViewControllerAnimated:. If you send YES for animated parameter of these methods, you will get an animation specified by the modalTransitionStyle property of view controller being presented or dismissed. Possible animations are slide in from bottom (default), horizontal flip of entire screen, fade in/out and half-page curl.
There are also some Apple-provided subclasses of UIViewController that help you setup your UI quicker like UITableViewController which is basically a view controller that contains a table as it's main view and conforms to 'UITableViewdataSourceanddelegate` protocols which are required to define how each cell looks and what it contains.
On iPad there is one additional container controller UISplitViewController and one additional way to present new view controllers using UIPopover.