I have this problem and I can't seem to find the answer so I asked here. I need to overlap 2 UIViewControllers. It is in a navigation controller. Each Controllers is using xib files as view since I am not using storyboard. It needs to be overlapped since the first controller is on live feed and I cannot afford to use a screenshot for background to make the live feed stay on while the user is navigating on the second controller. Any Ideas?
try content views doc tutorial
and the VC which you want to overlap, you will not keep it in you navigation stack, you will have to make overlapping VC, child of the VC on which you want to present it, after making child you will add child VC's view as a subview to parent's view. in that way both view controllers will appear to be overlapping
Related
I would like to have custom view set in one screen and have it across all view controllers in my application.
I find solution with using Container view. So I create RootViewController and I give it Container view and set my original MainViewController as embed in container. I added view to RootViewController and in first view controller (MainViewController) it looks good.
The problem is when I go to another view controller by Push segue. New view controllers covers whole screen (which is okay) and covers custom view too. I was thinking that it could help if I add Navigation Controller with root MainViewController and this navigation controller would be embed in RootViewController but the result is same. I set Navigation bar as hidden (same for status bar) because I want to be hidden.
So where could be problem? Or how would you add custom view to all screens? This custom view should work as global (I am using NSTimer and counting time) so I solution with inheritance isn't for me.
You can use application window and add this custom view as subview whenever required. I have used it in one of my app to show notifications (if there area any) and it works great.
Get handle to Application Window and add subview to it. Custom view can be created from a singleton class or App delegate.
You could try it the other way round. Make a view which will never change inside your root view controller and a container view and just change the content of the container view depending what u want to display next to your unchanging view.
I have the task to design a application that has a main view which is always visible (it has a button on it's bottom side, and when pressed a image displays on top of all views), and a set of TableControllerView's that should appear under it, and the user needs to be able to navigate through them.
I know that you can embed a view inside another, but you cannot refer more than one view to it. The current way I'm trying to do now load one TableViewController inside the embed view, and when the user clicks the cell I manually load the other controller and add it as a child of the main view, which is the RootViewController. The problem with this approach is that the navigation bar gets stuck using the root view controller, so I have to manipulate the main navigation items on each subview transition, and second is that the frame for the second view I load is coming as it had full size, making some cells be under the main view button. This way doesn't uses segues for transition, so it makes the storyboard kinda useless.
I was thinking into using a TabViewController with it's tab hidden, but wanted to ask here for a better solution.
As you discovered, a TableViewController likes to fill up the whole screen (except navigation bars, tab bars, status bar, etc. which are official Cocoa Touch GUIs). When you want a table view to fill only part of the screen, you are supposed to use a UITableView but not a UITableViewController. You set your custom view controller object (subclass of UIViewController, not UITableViewController) as the table view delegate and data source. You will need to duplicate part of the functionality of UITableViewController in your custom view controller, but it's not a lot more than you have to do already to supply the data.
You should probably follow the standard design pattern and have separate view controller objects for each of the "pages" the user can navigate to. You just have a main button and image on each of them. But I could imagine why that might not give you exactly the effect you want.
I am attempting to connect two UINavigationControllers, representing different tabs in a tab bar application, towards a single UICollectionViewController. The collection view controller will be populated by different data based on which navigation controller is the parent. When both navigation controllers are connected, navigating to the second tab displays a black screen and the viewWillAppear() code in the controller for the collection view does not fire. When navigating to the first tab, everything fires and is displayed correctly with data populated.
The storyboard setup looks like this:
The navigation controllers are connected to the collection view controller as seen here:
If I disconnect either one of the two navigation controller connections, the remaining connection to the collection view works and collection items are displayed as expected.
Is this the correct way to reuse the collection view? Is there something missing from how I am connecting the two navigation controllers with segues to the single UICollectionView?
I see this is almost a year old, so I'm not sure if you found an answer or not, but I thought I'd help answer if needed. Without knowing too much of your project, can I ask why you want a tabBarController to point both of its view controllers to the same one? Makes me wonder why tabBarController is necessary.
Setting up a test project, I witnessed the same you did. The only thing I can think of is that when a view controller is instantiated via the Storyboard, it creates an instance of it and is stored in the tabBarController's viewControllers[i] property, which the other tab may not have access to in the hierarchy. It would be best to just copy the view controller object from the Storyboard and paste it onto another area of the storyboard, and have the tabBarController instantiate a new instance of the same view controller object. That way, in your viewDidLoad method, you can tell what the selectedIndex is, and know how to load data, alter interface, etc. Copying/pasting the Storyboard view controller should keep intact any outlets/actions you've set up.
Hope that helps...
I'm a little bit confused about view-hierarchies when they meet ADBannerViews.
I want to insert iAd-Banners programmatically into an existing app, but I don't know where to start. I did read apples documentation and watched a really good WWDC-video, but I still have difficulties to understand how I can use this informations to bring ads in a propper way into my app.
Here is the architecture of my app:
At the bottom there is the window.
The rootViewController of that window is a UINavigationController.
The first viewController in the navigationControllers stack is a UITabBarController.
This tabBarController holds five simmilar UITableViews.
Tabbing on one of the tableCells of one of this tableViews pushes a new viewcontroller onto the navigationControllers stack.
This new viewController is again a UITabBarController, but this one has just four tabs, and the four Viewcontrollers in this tabBarControllers array are:
two different UITableViewControllers
two different simple UIViewControllers, one with just a single picture, the other with many nested views.
I want to insert an ADBannerView at the bottom of each of this four children of the second tabBarController in the navigationControllers stack. And I am not shure how to to this.
My problem is: I do not understand what will happen when the user tabs onto the ad. I know, that the ad's code will push a new view over my app, but I do not understand how. Will the new view be part of the stack of my navigationController (I don't think so)? Or will the new view be a new subview of one of the tabBarControllers views?
I don't have any proof, but my guess is that when the user taps on the banner, the ADBannerView code will push a new subview onto the view of the root view controller, because it needs to display full screen, on top of everything in your application. The root view controller is typically set in your applicationDidFinishLaunchingWithOptions method.
p.s. off topic a bit but are you sure you want to change the number of tabs? The more conventional UI paradigm is the tabs stay constant at the bottom of the screen. In that case, you have a UITabBarController with several UINavigationControllers under it.
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.