I'm developing an iPad application and I need to create an UIView that is always on top in respect to other views.
A is the area (consider it as a sort of sidebar) where I need to create a UIViewController which view remains always on top. B, instead, is the content area where a UIViewController (with its view) can change: depending on several button actions (inside A's view), it's possible to remove the current visible content (in this case controller B and its view) and display other controllers (C, D, E, etc.) with theirs views.
I created all the elements for my application but I have problems to maintain A's view on top and, at the same time, implement the logic used to dinamcally change the content area. As requirements I need that A always overlaps B. In other words, a portion of B (the left part) is always under the area of A. B always extends the entire device screen.
Could you give me some advice?
I made two configurations but I have problem with them.
First Configuration
In the first one, I created an UIViewController for A (called SideBarController). I added SideBarController view to UIWindow (within the application delegate). Then I created an UIViewController for B (called HomeViewController) and I added it as a rootViewController for my application.
This solution could be a valid one because I can change the content area dinamically (setting a new rootViewController) through my application delegate but the SideBarController remains always under the current visble view.
Second Configuration
In the second one, I created an UIViewController (called MainViewController) and I added it as a rootViewController for my application. Then within MainViewController I created an UIViewController for A (called SideBarController) and I added SideBarController view to MainViewController. Then the content area has been filled creating an UIViewController for B (called HomeViewController) and adding it to MainViewController.
The sidebar remains always on top but I have difficulties to change dynamically the content area within MainViewController. How is it possible to access the content area and change it?
Note I'm aware about standard components on UIKit but I need to implements such a solution because of user specifications.
I would begin by trying to implement your sidebar in a UIPopoverController. It's designed pretty well for this kind of problem, and you can customize it extensively to meet your UI needs. If UIPopoverController causes you some kind of problem, I'd put the sidebar in its own UIWindow and float that over the main window.
EDIT
Personally I'd go for the popover myself since it's more built for this kind of issue. Another thought that comes to mind and I've used in the past is a UIView that you add to directly to the UIWindow ([view window] from any view will get you the main one). Remember, UIWindow is just a special kind of UIView. The problem with this and the UIWindow solution is that you will have to do your own rotation logic which can be trickier than it sounds if you have autorotations. UIPopoverController handles all this very cleanly and automatically if you can use it.
If you pursue UIWindow see the Windows section of the View Programming Guide: http://developer.apple.com/library/ios/#documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/CreatingWindows/CreatingWindows.html
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.
There's a particular control which I'm trying to build properly. I refer to it as an ImageTile. It's basically a little square box, which, when the user taps it, will present the user (via an action sheet in a popover) the option of selecting an image from the library, or taking a photo. Depending on the response, I then either present the UIImagePickerController inside a popover (for selecting an image) or modally (for taking a new picture). Once they take/select the image, I have a modal view which appears and allows them to edit the picture in a few simple ways. When they finish editing, the modal dismisses, and the original ImageTile, rather than being a blank square box, gets filled up with the user's edited image.
The issue is that this ImageTile control is going to be used profusely throughout several different parts of the application, across numerous View Controller hierarchies, and so on... and I really want it to be a basically totally self-contained unit, such that whenever I stick an ImageTile inside a UIView onscreen, all the above functionality is handled by the ImageTile itself.
Initially, I made it a UIViewController subclass (so it could present modals etc), and just added its view as a subview of a "holder" view onscreen. I know this isn't recommended, as the controller isn't part of the VC hierarchy then... and also, I wound up with some really weird behavior regarding things like autorotation, especially when the camera was involved.
What's the "right" way to implement something like this?
I think what you've done by making it a UIViewController subclass is correct. You should just use the methods that UIViewController exposes for adding child view controllers, such as - addChildViewController:.
You will also note that Interface Builder has a Container View object designed specifically for holding a place in the hierarchy for a child View Controller:
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
Our app has some upper view, that is visible all the time.
This bar has a UITextField, UIButtons, side scroller, and segment control, and they are dynamic.
When you hit them, the view behind them(full screen) is changing.
I was thinking about navigation control, or tab bar, but seems that they can't have a text field and a scroller on them.
So my main thought was to create some COSTUM view of my own.
Question is , how can I create a view in storyboard, and add it as a constant view, than create some other views(+viewcontrollers) that will be changed according to that upper bar?
I want to create 5 views in storyboard, and switch between them according to the bar.
Sounds like a job for a containment view controller to me. I've used technique many times to both create a set of static controls on the screen which you describe and inject reusable content into an app in several locations.
The basic concept is:
Setup you Heads Up Display(HUD) with all the UI you want (this will be your base UIViewController).
Create a UIView in it and call it your contentView or something of the like. This is where all your dynamic content will appear.
Then your backing view controller adds another UIViewController as a child and tell it to show it's view in the contentView you specified.
Your view controller continues to remove and add children putting their content into the contentView as needed.
If you are unfamiliar with the technique there are many tutorials(by NSCookbook) of do a web search for "view controller containment tutorial". There is also a good WWDC (2011) video introducing the concept Session 102 - Implementing UIViewController Containment.
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