I've created a simple navigation application, which alternates between two views through the use of push/popViewController. I've decided to add a background image, rather than a pattern or single colour, to both view controllers.
Is there a way to have the same backgrounds for both views, without them scrolling when the view changes? This way, it will look like the background stays still, while everything else slides over the top.
I haven't found any help on this issue, and the only idea I've come up with up to now is to attempt to use the app delegate (or, tenuously, the navigation controller) to draw the background, but my attempts to do such have all failed terribly.
Maybe try to add image to application window and set background color for both viewcontrollers to clearColor.
You could use a "root" view controller that manages all other view controllers in your app.
Create a view controller (with the background image as its view) and add it to the window.
Instantiate your navigation controller and then [rootVC.view addSubview:navController.view].
Caveat: This should work, but "nesting" view controllers like this isn't really good practice. Read the discussion Abusing UIViewControllers, and search for "UIViewController Containment" for how to do it properly in iOS 5.
Related
(I have read other questions and answers on this topic, but most are very old and do not relate to iOS 9 or 10.)
The app design calls for the top half of the display to always contain the same content. (An image being edited by the user.)
The bottom half of the display needs a UITableView. When a UITableViewCell is tapped, the bottom section needs to transition to a new UIViewController with slide-on animation, similar to how UINavigationController push segues work.
Problem: only the bottom view needs to transition to the new view controller(s), and back again. The upper half of the view hierarchy needs to remain unaffected. For this reason, I can't place everything inside a UINavigationController, and I can't have a UINavigationBar at the top of the screen.
Question: what approach should I take in such a situation, where I need only one UIView hierarchy to transition in push-segue fashion, but not anything else? Thanks.
Edited with Solution
Solution follows, for those following along at home.
Yes, you can actually use a UINavigationController for the bottom half.
If you are using Storyboards, the easiest way to do this is to use a container view for each part of the screen which you then can embed a UIViewController in for the top part and a UINavigationController in for the bottom part. If you are doing this programmatically, just add the view controllers as child view controllers to your app's initial view controller (see this answer for more info) which is essentially what the Storyboard will do for you automatically when using a container view.
As a child view controller, the UINavigationController will act independently from the top UIViewController and should behave as expected.
I recommend the programatic approach for the following reasons:
It helps you understand the inner workings of child/parent view controllers much better which will likely save you a significant amount of debugging time down the line.
It makes adding/removing/swapping child view controllers as simple as a few lines of code. Trying to do this with Storyboards is notoriously hacky and cumbersome.
It's much easier to keep track of changes using GIT (most mid-size/larger companies actually prohibit Storyboards for this very reason)
If you want change in part of the screen you can use container view. For details refer Swift - How to link two view controllers into one container view and switch between them using segmented control?
You can use multiple view in one view controller and can give animation like push or pop to show or hide it.
Second approach is you can use Container View which will give exact effect like navigation stack.
I am subclassing UIApplication to intercept and display touches in my TouchDisplay view. I would like to extend the Application, Window, Delegate or Main ViewController in order to keep my TouchDisplay view on top of all other views. As my and most other applications work, views and controllers are added and removed all the time. I figure the correct answer will be able to deal with these additions and removals and stil keep the TouchDisplay view on top.
Thanks for your help,
Joe
Here are a few approaches you could take for this:
If you're targeting iOS 5+ and iPad only, you can make a top-level view controller which has two contained view controllers. The first would be a view controller for your "TouchDisplay" view. The second would be the application's normal root view controller. (i.e. your existing main view controller; you'll need to set definesPresentationContext to YES on this view controller) Since you're writing the container view controller, you can order those two subviews however you like. There is a WWDC 2011 Talk on view controller containment that goes into great detail about this. This is the most "correct" approach IMHO, because it gives you a view controller for your TouchDisplay view, handles rotation and generally plays nice with others. (This only works on iPad, because on iPhone a new modal view always covers the full screen.)
A more straight-forward approach is to simply add your TouchView to your existing top-level UIWindow as a subview with addSubview:. Most applications don't actually remove the top-level view controller or add new top-level ones; they just present other view controllers from it. A view you add in the top-level window will stay above those. Of course, your app may not follow this rule, in which case you might try option #3 instead. This has rotation gotchas (your view will not auto-rotate when the device rotates, so you need to do this yourself.) You could also force your view back to top, say, on a 1-second timer, if you are having issues with other things covering it. This is also not as nice as option #1 because you don't get a UIViewController, just a UIView.
The most extreme approach is that you can create another UIWindow and give it a higher window level, such as UIWindowLevelAlert and put your TouchDisplay view in that. You can then make the window background transparent, and it will stay above your normal app content. There are lots of gotchas here, especially about auto-rotation and which window is the keyWindow (which is why you should use #1 or #2 instead if you can).
After some time I was able to get my app working. I have made an easy to use overlay that shows touch feedback over your existing application.
You can download the project here:
https://github.com/megaplow/FingerTracks/tree/master/FingerTracks
Happy coding,
Joe
I'm keeping on developing an iPhone app (rigth now native one) and I would need to use a common "header" for all views but I don't want/need a UINavigationBar and prefer much more have a common "partial view". It will have some actions to perform but always the same ones (showing notifications panel, basically). It should be something like you can see in the screenshots.
I don't need (I feel) delegation because the controller's view can handle notifications and show them when user clicked the customize button.
I don't mind to use a Nib o make the view hardcoded but I'm not sure how I must make an instance of the view or the controller that handles it within each app tab (I'm using UITabBar as navigation control).
From my point of view it doesn't exist a way to get a common controller to call wherever needed; you just can use some method to present new controller as modal o push it out and I think that is not what I'm looking for.
Any idea is welcome. Thanks
Create a custom view controller with 2 subviews. Subview 1 is the header. Subview 2 is the container view where child view controllers are displayed (your tab bar controller in this case).
Your custom view controller could be the delegate of the tab bar controller if you want, so it can be notified when the tabs change and update anything on the header view.
Well, finally is have used the solution I found on the link http://patientprogrammer.wordpress.com/2012/03/12/re-usable-subviews-in-ios/
I have created a Nib with a view controller and then, in the main window I have added two view, the top one subclasses the view controller for the Nib view and it is rendered automatically when app is launched without a single line of code within "main" controller. See the screenshots for more detail:
Thank you very much for your help
I am subclassing UIApplication to intercept and display touches in my TouchDisplay view. I would like to extend the Application, Window, Delegate or Main ViewController in order to keep my TouchDisplay view on top of all other views. As my and most other applications work, views and controllers are added and removed all the time. I figure the correct answer will be able to deal with these additions and removals and stil keep the TouchDisplay view on top.
Thanks for your help,
Joe
Here are a few approaches you could take for this:
If you're targeting iOS 5+ and iPad only, you can make a top-level view controller which has two contained view controllers. The first would be a view controller for your "TouchDisplay" view. The second would be the application's normal root view controller. (i.e. your existing main view controller; you'll need to set definesPresentationContext to YES on this view controller) Since you're writing the container view controller, you can order those two subviews however you like. There is a WWDC 2011 Talk on view controller containment that goes into great detail about this. This is the most "correct" approach IMHO, because it gives you a view controller for your TouchDisplay view, handles rotation and generally plays nice with others. (This only works on iPad, because on iPhone a new modal view always covers the full screen.)
A more straight-forward approach is to simply add your TouchView to your existing top-level UIWindow as a subview with addSubview:. Most applications don't actually remove the top-level view controller or add new top-level ones; they just present other view controllers from it. A view you add in the top-level window will stay above those. Of course, your app may not follow this rule, in which case you might try option #3 instead. This has rotation gotchas (your view will not auto-rotate when the device rotates, so you need to do this yourself.) You could also force your view back to top, say, on a 1-second timer, if you are having issues with other things covering it. This is also not as nice as option #1 because you don't get a UIViewController, just a UIView.
The most extreme approach is that you can create another UIWindow and give it a higher window level, such as UIWindowLevelAlert and put your TouchDisplay view in that. You can then make the window background transparent, and it will stay above your normal app content. There are lots of gotchas here, especially about auto-rotation and which window is the keyWindow (which is why you should use #1 or #2 instead if you can).
After some time I was able to get my app working. I have made an easy to use overlay that shows touch feedback over your existing application.
You can download the project here:
https://github.com/megaplow/FingerTracks/tree/master/FingerTracks
Happy coding,
Joe
I have a set of table views which the user can switch between using a tab bar controller, each table view has the same background.
Rather than have each table display the same background image I instead can do either of these:
[myDelegate.window addSubview: theUIImageView];
or
[myDelegate.window.rootViewController addSubview:theUIImageView];
Both work, should one be used rather than the other and why?
I have a similar question for displaying an activity indicator.
Thanks
I think the principle is that the window should have one root view controller at the top of the tree, so I would maintain that. Other rulesets are available!