I've been working pretty extensively the last couple months with UIImagePickerController, particularly with the new capabilities in OS3.1 and newer to overlay views on-top of the camera view. This has worked just fine.
However, I am currently working on a project where I'd like to be able to display the camera view of the UIImagePickerController within an existing view. Essentially, the exact opposite of what I've currently been doing.
An example would be a View Controller with navigation components (Think top and bottom horizontal bars with gradients), and upon tapping a button on one of these bars, then content area displays the camera view. The shutter animation would should up, and the top and bottom navigation bars would remain always on-top.
I've had success adding the UIImagePickerController to the window view, as well as presenting it modally, but haven't had any luck adding it as a subView.
ex:
[window addSubview:camera.view];
[self presentModalViewController:camera animated:YES];
All you need to do is call viewWillAppear and viewDidAppear.
Here is an example where _pickerController is an instance of UIImagePickerController:
[self.view addSubview:_pickerController.view];
[_pickerController viewWillAppear:YES];
[_pickerController viewDidAppear:YES];
Call viewWillAppear:YES on the image picker controller after adding its view to your view. Skip the modal view controller business.
I don't think the API provides direct access to the actual view of the UIImagePickerController. The class is actually a subclass of UINavigationController so I don't think it has an actual view itself but rather manages the calling of its subcontrollers and their views.
When you call the UIImagePickerController modally, its doesn't add the views it controls as subviews to the window (or any other view). That is what a modal view means. It presents the view off to the "side" of the view hierarchy.
Even if you could hack this together, I think Apple would reject it as not being part of the API and for violating the HIG.
Related
Given the below code
self.view.backgroundColor = [UIColor yellowColor];
MyViewController *myVC = [[MyViewController alloc] initWithNibName:#"MyView" bundle:nil]
myVC.view.backgroundColor = [UIColor clearColor];
myVC.modalPresentationStyle = UIModalPresentationFullScreen;
[self presentViewController:myVC animated:NO completion:nil];
What happens under the hood when we call presentViewController ? When myVC is visible I cannot see yellow color, then I checked myVC.view.superView in it's viewDidAppear method and it is UIWindow.
Q1. Is that mean until the modal window is up presentingViewController.view (self.view in above case) is removed from the View hierarchy and presentedViewController.view (myVC.view in above case) is added over UIWindow ?
Q2. What will be the case if myVC.modalPresentationStyle != UIModalPresentationFullScreen ?
Q3. Does iOS also remove all the views from UIWindow except presentedViewController.view until the full screen modal dialog is up for optimization ? If NO why not ?
First, let's discuss the case without animation.
Before calling present:
Your window has one view hierarchy, starting from its rootViewController view.
After calling present:
The view hierarchy still exists without change.
A special full-screen view called "dimming view" is added to the window (that is, not inside the rootViewController's view but inside the window (window is a UIView, too). This view is transparent, dims the presenting controler and blocks user interaction.
The presented (modal) controller's view is then added also to the window.
There are some other views added in between the window and the presented controller's window. If you log your view hierarchy, you'll see classes named _ControllerWrapperView or something similar. However, this has changed between iOS versions and you shouldn't rely on the view structure.
Note that that the modal controller can't ever be transparent because it is not direct subview of the window and the wrappers between the controller and the window are not transparent.
The animated case is almost the same. Only there are some fancy animations between the steps.
Edit 2:
The answer was really a bit incorrect. There is a big difference between iPhone and iPad presented controllers.
On iPhone, the presented controllers are always displayed full screen and the presenting controllers are actually removed from the window.
On iPad, if the presented controller is not fullscreen (see UIModalPresentationStyle), the presenting controller stays in the window.
Your questions:
Is that mean until the modal window is up presentingViewController.view (self.view in above case) is removed from the View hierarchy and presentedViewController.view (myVC.view in above case) is added over UIWindow ?
If the controller is full screen, then this claim is true. Otherwise, the presenting view controller stays there but the whole contents are overlapped by other views (even if they are semi-transparent). Also, there are always some views between the presented and the presenting controller views.
What will be the case if myVC.modalPresentationStyle != UIModalPresentationFullScreen ?
See the answer to the previous question - on iPhone, there would be no difference.
Does iOS also remove all the views from UIWindow except presentedViewController.view until the full screen modal dialog is up for optimization ? If NO why not ?
From my tests, only the presenting controller is removed from the window hierarchy. This is probably to optimize drawing performance. This is the only controller the system can safely remove. Removing any other view could cause problems (e.g. views that should be always visible).
Edit:
If you want to make a transparent controller, you can:
Add the view directly to your view hierarchy (either to the controller's view or to the window) with a transition animation (+[UIView transition...])
The same but also adding a child controller to your controller.
Is it possible to view the viewcontroller behind the displayed one? I have a viewcontroller with a scrollview, which has imageviews added as subviews and would like the view that presented this viewcontroller to be visible behind the presented view controller.
I have set all the views, the viewcontroller view too to have a clear color background, but still there is a black background. when I dismiss the viewcontroller, I see 2 layers being dismissed. one has alpha dropped, the other not.
Is there an easy way to make this effect possible?
Its not possible. When a new view controller is pushed or presented as modal view, the previous view controller will be removed from the display(may be UINavigationController/iOS hides it). The rule is only one view controller would be visible at a time. So you will see the color of your window(the black color you've mentioned) in the background.
What you could do is make a screenshot before displaying the other controller. and send this image to new controller to be displayed as background.
This will only work for static content, but you could do something like the curl display.
You can do this but the truth is what EmptyStack says.
You can use setFrame of the subView and add it on the viewController. Also use below method to set the index of the added View. By default currentView has Index 0.
[self.view insertSubview:myView atIndex:0];
or you can try below methods as per your logic
insertSubview:aboveSubview:
insertSubview:atIndex:
insertSubview:belowSubview:
addSubViews:
bringSubviewToFront:
removeFromSuperview:
How can I make a custom view in iOS which appears above the existing view,but smaller? It should be like UIAlertView, but taken from a .xib file. After user taps a certain button, the small view vanishes and the normal view appears.
If this is posiible, how can I do it? And.. if it's not hard for you, please, include code.
Thanks in advance!
I think what you're looking for is a modal view. Modal views make it easy to have a view take over the screen for a little while, then when they get dismissed have the background view resume where it left off without having to worry about who's on top or handling events in partially-obscured views.
Here is Apple's article describing it.
They key is to have the controller class for your view call [self presentModalViewController:popupController animated:YES]; where "popupController" is the view controller for the view you want to show up. When you're ready to make it go away, call [self dismissModalViewControllerAnimated: YES];
You can just use the addSubview: method on your UIWindow or your visible UIViewController's view to show the UIView, and you can hide/remove it later by calling removeFromSuperview on the presented UIView.
I have an app built from the UITabBarController starter project. The first tab is part of the main.xib that contains the tab bar. I would like to slide a view up from the bottom on top of that tab's view that only covers part of the screen. My understanding is that you can only cover part of the screen if you make the top view non-modal, but I don't see a way to do that without a NavigationController.
How can I do this?
you can add a UIView as a subview to the current view, and then animate its appearance into the screen using animation blocks, or Quartz or however you would like.
presentModalViewController: is actually a method that belongs to UIViewController, the superclass of UINavigationController, so you can use it from any view controller, not just a navigation controller.
Have you tried using a UIActionSheet? That's an easy way to get a view with a few buttons for user input to slide up and only cover the bottom portion of the current view.
There has been a lot of confusion and a set of corresponding set of questions here on SO how iPhone applications with proper handling for Landscape/Portrait mode autorotation can be implemented. It is especially difficult to implement such an application when starting in landscape mode is desired. The most common observed effect are scrambled layouts and areas of the screen where touches are no longer recognized.
A simple search for questions tagged iphone and landscape reveals these issues, which occur under certain scenarios:
Landscape only iPhone app with multiple nibs:
App started in Landscape mode, view from first nib is rendered fine, everything view loaded from a different nib is not displayed correctly.
Iphone Landscape mode switching to Portraite mode on loading new controller:
Self explanatory
iPhone: In landscape-only, after first addSubview, UITableViewController doesn’t rotate properly: Same issue as above.
iPhone Landscape-Only Utility-Template Application: Layout errors, controller does not seem to recognize the view should be rotated but displays a clipped portrait view in landscape mode, causing half of the screen to stay blank.
presentModalViewController in landscape after portrait viewController: Modal views are not correctly rendered either.
A set of different solutions have been presented, some of them including completely custom animation via CoreGraphics, while others build on the observation that the first view controller loaded from the main nib is always displayed correct.
I have spent a significant amount of time investigating this issue and finally found a solution that is not only a partial solution but should work under all these circumstances. It is my intend with this CW post to provide sort of a FAQ for others having issues with UIViewControllers in Landscape mode.
Please provide feedback and help improve the quality of this Post by incorporating any related observations. Feel free to edit and post other/better answers if you know of any.
What's in the documentation:
In your view controller, override shouldAutorotateToInterfaceOrientation: to declare your supported interface orientations. This property will/should be checked by the controller infrastructure everytime the device orientation changes.
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)orientation
{
return (orientation == UIInterfaceOrientationLandscapeRight);
}
This is the absolute minimum your view controller needs to do. If you want to launch your application in landscape mode, you need to add the following key to your .plist file:
<key>UIInterfaceOrientation</key>
<string>UIInterfaceOrientationLandscapeRight</string>
Apple recommends starting landscape only applications in Landscape Right mode (see the HIG under User Experience Guidelines > Start Instantly).
What's not in the documentation:
A little background:
Everytime you try to load a different view controller other than that loaded from the main nib, your view controller is neither interrogated about it's supported interface orientations nor is its frame set correctly. Only the first view controller bound to the window will be layed out correctly.
Other people have suggested using a "MasterViewController" hooked up to the main window to which other controllers add their views as subviews instead of hooking directly into the window. While I have found this solutions is a viable option, it does not work correctly in the case of modal view controllers added to those said subviews. There's also a problem if you have some subviews that should be able to autorotate (what the master controller will prevent).
The usage of undocumented API's to force a certain interface orientation is not an option either.
The solution:
The best solution I have found so far is a modification of the "MasterViewController" workaround. Instead of using a custom "MasterViewController", a UINavigationController with hidden Navigation Bar and hidden Tab Bar is used. If all other views are pushed/popped from the navigation stack of this controller, auto-rotations of controllers on that stack will be managed correctly.
Modal controllers presented via presentModalViewController:animated: from any of the view controllers on the UINavigationController's navigation stack will be rotated and rendered with correct layout. If you want your modal view controller to be rotatable to a different orientation than that of the parent view controller, you need to return the desired orientation from the shouldAutorotateToInterfaceOrientation method of the parent controller while the modal view is presented. In order to properly restore the interface orientation when the modal controller is dismissed, you need to make sure shouldAutorotateToInterfaceOrientation returns the desired orientation for the parent controller before you call dismissModalViewController:animated:. You can use a private BOOL on your view controller to manage that (e.g. BOOL isModalMailControllerActive_).
I'll add a piece of sample code soon, It's just to late now. Please let me know if any unresolved issues remain or anything is unclear about this post. Feel free to edit and improve.
I had an interesting requirement for ios application:
main viewController should be only landscape, but all others (which can be pushed from main) can be landscape and portrait.
Problem occours - when I push to a new viewController, which then is rotated to portraited - and the pop back - main view is no longer landscape. Also - opening application, it is not in landscape.
In order to keep main viewcontroller landscape, no matter from what orientation it was popped/pushed, I did the following thing: (in viewWillAppear:)
//set statusbar to the desired rotation position
[[UIApplication sharedApplication] setStatusBarOrientation:UIDeviceOrientationLandscapeLeft animated:NO];
//present/dismiss viewcontroller in order to activate rotating.
UIViewController *mVC = [[[UIViewController alloc] init] autorelease];
[self presentModalViewController:mVC animated:NO];
[self dismissModalViewControllerAnimated:NO];
Hopefully it will help someone!
P.S.Tested on sdk 3.2.5 ios 5.0.1.
P.S. Thanks for all the info in this FAQ!
For the second bullet point, if you want to use pushViewController to go from Portrait-only to Landscape-only view, one simple hack I found is to put the following code into your pushed controller's viewDidLoad:
UIViewController *viewController = [[UIViewController alloc] init];
[self presentModalViewController:viewController animated:NO];
[self dismissModalViewControllerAnimated:NO];
[viewController release];
I'd like to add to Johannes' answer (using the UINavigationController as MasterViewController).
The disadvantage I have found is that ViewControllers that are newly pushed onto the master VC's navigation stack do not adjust to any prior orientation changes. In short, VCs already on the stack are rotated, modal view controllers presented from them are also rotated, but newly added VCs are not rotated.
I have tried many tricks to fix this before finding one that works. Most only work for pushViewController: with animated set to YES.
To fix the issue entirely, I have subclassed UINagivationController and overriden pushViewController:animated: as follows:
- (void)pushViewController:(UIViewController *)viewController animated:(BOOL)animated
{
// Correctly autoOrient the given view controller
[self presentModalViewController:viewController animated:NO];
[self dismissModalViewControllerAnimated:NO];
// Push it as normal (now in its correct orientation)
[super pushViewController:viewController animated:animated];
}
Temporarily (and quite invisibly) presenting the view controller allows it to receive its orientation update. It can then be pushed onto the navigation stack in its correct orientation.
Please let me know if this works for you. All updates and improvements are very welcome!
Finally, I highly recommend Johannes' approach to rotation management.
EDIT: Update on popping view controllers from the stack
It seems that all the popViewController-related selectors go crazy when performed with animated:YES. Specifically, the view controller is animated out in the wrong direction. You can use animated:NO and restrict the use of such animations to other UINavigationControllers deeper down in your hierarchy (i.e. the ones that you push onto the root navigation controller's stack).
Any input is greatly appreciated.
I'm developing an iPad app that displays vertically scrolling gallery view of an array of items upon startup. In landscape mode there are 4 items across. In portrait there are three. When turning the iPad orientation it is supposed to refresh the gallery to have the items fit neatly across the screen. Then I double tap on an item to drill down to a modal view of that item. Then I do stuff with that item. Finally I dismiss the modal view.
During the refresh or orientation change the gallery view calculates the number of items to display based on the screen width (or height) and the current orientation from UIViewController.interfaceOrientation.
I was having a problem getting this to work correctly. Sometimes it would display only two items in landscape orientation after I dismissed the modal dialog.
At first I was using the UIViewController.view.frame.size values to calculate the number of gallery items. When the modal view was dismissed this frame size was incorrect e.g. the width and height had been reversed even though the orientation had not changed while the modal dialog was displayed.
I switched to using the application delegate ([[UIApplication sharedApplication] delegate]] and taking the window.frame.size to calculate the number of gallery items to display across. The window.frame.size stays correct under orientation changes and modal dialogs. The gallery items display correctly now.
This will work...
UIWindow *window = [[UIApplication sharedApplication] keyWindow];
UIView *view = [window.subviews objectAtIndex:0];
[view removeFromSuperview];
[window addSubview:view];