UIViewController has to be presented modally in iPad while the same should be pushed in iPhone. Is there any support for the same by apple by default ?
You have to detect the device and perform tasks accordingly.
if UIDevice.current.userInterfaceIdiom == .pad {
//present modally
} else if UIDevice.current.userInterfaceIdiom == . phone {
//push
}
As already mentioned you will need to do this manually. You can check what device you are having and decide how to present your view controller.
But this usually produces a huge issue and can greatly increase complexity of your application. Since you are in one case presenting and in other case pushing a view controller you will also need to pop or dismiss it. This can easily be solved by adding some extra properties but then later on it might interfere again when you want to dismiss a whole navigation stack or similar. Not to mention problems with deep linking.
So if possible I would try to avoid having different view controller hierarchy depending on device. If possible I would try to simply change the animations (I assume that is all that you need). Maybe this will help.
Related
In my iPhone app I have a view that I want to show only in portrait mode. When navigating to that view it should be automatically displayed in portrait view. When navigating away, the orientation should change back to what it was, or, if the device orientation has changed, adapt to that. I could find information on forcing an orientation and preventing auto-rotate. I could not find anything on how to change back to the correct orientation after navigating away from that view.
So my idea was to
save the initial orientation (store in currentOrientation)
subscribe to orientation change event to keep track of orientation changes while the content is locked to portrait (update currentOrientation)
when leaving the view, restore the correct orientation using the currentOrientation value.
Edit (code now removed): Apart from it not working it was a dangerous way to go as it made extensive use of unsupported APIs.
Edit:
I believe this question can now be boiled down to the following:
Is there a documented, supported way to force the interface orientation independent of the device orientation? setValue(UIInterfaceOrientation.Portrait.rawValue, forKey: "orientation") has been recommended many times on SO and elsewhere but it does indeed seem to be an unsupported hack.
Is there a documented, supported way to update the interface orientation to the device orientation? That would be needed to "recover" from the forced interface orientation in another view without having to trigger auto rotation by turning the device back and forth.
Supported are supportedInterfaceOrientations() and shouldAutorotate(). But these will only lock the interfaceOrientation after the device has been turned to that position. They do not prevent wrong initial orientation.
There are many questions similar to this one, showing that this problem setting is not uncommon, but so far no satisfactory and complete solution using supported methods.
I had a similar problem except I needed one view controller to only work in Landscape mode and another when it was in portrait. The way I achieved this was making a custom 'root' view controller. Then on the viewWillTransitionToSize method for that controller checking for orientation and non animatedly pushing the correct view controller (so it looks like a rotation to the user). And then in Interface Builder I set the view controller's orientation property explicitly instead of being inferred. You could apply this solution by having only the landscape orientation set on the restricted view controller and then on the portrait rotation doing nothing and disabling auto rotation on the restricted view controller.
Update
I haven't had the time to test any of these but these are just the ideas I used when implementing my solution for a different VC for a different orientation, some combination of the following should hopefully work I can't be a 100% certain about it cause I did this some months ago and don't exactly remember what did and didn't work.
First of all make sure that you have setup the constraints as shown in the screenshot. Mine has iPad full screen and landscape because that's what I was doing change yours to whatever you need (portrait and the size can be inferred).
Now before doing anything else I would first check to see if this solved the problem. I needed the root view controller cause I needed a different VC for portrait and and a different one for landscape. You only need to restrict it so if this works than that's perfect otherwise there are a few other things you can try as mentioned below.
Once that's setup I would first go to the view controller who you want to restrict's class and prevent autorotation using:
override func shouldAutorotate() -> Bool {
return false
}
Now if you do that since you are restricting to portrait I'm guessing you don't really care about upside down so you don't need to do anything additional. If you do want to use the viewWillTransitionToSize method and rotate manually.
If things still don't work you can finally try the root controller way (but I would use this in the last case). Heres a sketch of it:
class VC : UIViewController {
override func viewDidLoad () {
UIDevice.currentDevice().beginGeneratingDeviceOrientationNotifications()
NSNotificationCenter.defaultCenter().addObserver(self, selector: "orientationChanged:", name: "UIDeviceOrientationDidChangeNotification", object: nil)
// this gives you access to notifications about rotations
}
func orientationChanged(sender: NSNotification)
{
// Here check the orientation using this:
if UIInterfaceOrientationIsLandscape(UIApplication.sharedApplication().statusBarOrientation) { // Landscape }
if UIInterfaceOrientationIsPortrait(UIApplication.sharedApplication().statusBarOrientation) { // Portrait }
// Now once only allow the portrait one to go in that conditional part of the view. If you're using a navigation controller push the vc otherwise just use presentViewController:animated:
}
}
I used the different paths for the if statements to push the one I wanted accordingly but you can do just push the portrait one manually for both and hopefully one of the ways above will help you.
I have a UIViewController. A button on the UIView should bring the user to a UISplitViewController. I'm using a segue for that, setup using the storyboard UI.
While some answers here seem to suggest this might not work (UISplitViewController has to be the root - or does this mean something different?), this does indeed work. Except - The SplitViewController on iPhone always starts with its DetailView, not with the MasterView.
What can be done about that?
As far as I know you cannot use splitViewControllers with iPhones, so you will have to use separate code to handle the iPhone version of your app(unless they have released something recently enabling this).
You could say
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone) {
// Show your master view
} else {
// Present normally
}
So I've got a screen that does a check for certain attributes and under defined circumstances will instantly load another view modally in viewDidLoad, without animation, over the currently-loading view (so as not to show the view below). Prior to iOS 8 when this was done, the original view would pause its loading (would not proceed with viewWillAppear, viewDidLayoutSubviews etc.) until the overlaying controller was dismissed. This behaviour I found was appropriate for my needs, as any animation on elements in the original view, could then be done. However, in iOS 8 I'm getting a completely different chain of events. First off, for some reason viewDidLayoutSubviews is being called twice (what's up with that?) but more importantly the view is not liking another controller being popped up at all anytime before viewDidAppear, complaining about unbalanced calls to begin/end appearance transitions. Not only that, but the underlying viewController continues with it's loading (viewWillAppear,viewDidLayoutSubviews etc.) even though it's not being shown which causes all the methods in those events to fire. I appreciate if Apple have updated the way something like this is meant to be achieved, so if the new meta is a completely different process I'm willing to adopt, however, as it is I can't get this to work appropriately.
I'd appreciate any help on how to get this modal view to interject without causing the underlying view to continue it's loading.
Thanks,
Mike
UPDATE: Going to bring some code in. Below is the viewDidLoad of the main viewController that presents the modal VC if need.
-(void) viewDidLoad{
if(hasNotSeenTutorial){
TutVC* vc = [[TutVC alloc] initWithNibName:#"tutNib" bundle:nil]
vc.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;
[self.navigationController presentViewController:vc animated:NO completion:^{
NSLog(#"Has Completed Presentation");
}];
}
}
This is where the issues are. Calling the presentation here in viewDidLoad, causes the presentation of the presenting VC to continue. Prior to iOS 8 the presenting VC if not yet presented, would pause, until the modal VC had been dismissed, it would then complete as usual. This is not the case in iOS 8, as per my original post.
Apple has made its rules stricter with ios 8. To give you an example and I ll drive my point through this:- In my app i used to pop some view controllers off the navigation stack and just after that, push the a new one, but that pop was never seen in ios7, only a push transition appeared to happen (when logically, pop should have been seen and then the push). And in ios 8 this thing changed. Now a push is seen only after the pop is seen and noticed. which breaks the UX rather badly.
I have noticed this strictness in other areas as well but those are not UI/UX related so i wont go into its detail right now.
As far as your situation go, With my experience I can tell you that you ve been doing stuff in a wrong manner. As apple has gone strict your implementation seems to break.
The only solution in my opinion is to shift every check in viewdidAppear.
If you wish to continue the way you were doing for ios7 earlier you might use this check:
if([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0)
{
// Code for ios 8 implementation
}
else
{
// Code for ios 7 implementation
}
Though i would reccomend you to avoid because wat u are aiming is perfectly achievable.
Also what you are doing can easily cause inconsistency in the navigation stack which can crash the application.
I have been trying to get multiple orientations to work with a single view controller. Currently it checks for the device orientation and view controller. Then switches based on whether it's landscape or portrait. The problem is that it works fine in portrait, but since it pushes another view on the stack whenever it's in landscape the back button links to the portrait view instead of the actual screen we want to get back to (which is one further step away).
if (UIDeviceOrientationIsLandscape(deviceOrientation) &&
self.navigationController.visibleViewController == self)
{
self.landscapeViewController =
[self.storyboard instantiateViewControllerWithIdentifier:#"view_landscape"];
[self.navigationController pushViewController:self.landscapeViewController
animated:NO];
}
else if (UIDeviceOrientationIsPortrait(deviceOrientation) &&
self.navigationController.visibleViewController == self.landscapeViewController)
{
[self.navigationController popViewControllerAnimated:NO];
}
I cant present the landscape view controller in modal fashion, since there is a navigation controller involved.
Another thing is that I'm instantiating the same view controller for each orientation (using the same class but linking to different identifiers in the storyboard).
The thing you're trying to do is REALLY bad and goes against Apples way of doing things.
There's something called Autolayout, with which you can design a single view to work both in landscape and portrait mode.
It is possible you can handle programatically or simply use auto-layout depends on your requirement .just prefer this LINK
I am just looking for a sanity check here.
I have a screen that the user passes through on the way into the main application. That screen can be navigated back to from almost anywhere in the system.
As it stands I am just presenting ViewControllers without using a NavController to manage them (it does not seem applicable for most of my app, since screens are not necessarily sequential or related to one another).
My question is, if I have presented VC1, then navigate to other screens, and finally want to present VC1 again, I am doing something like:
[self presentViewController:[self.storyboard instantiateViewControllerWithIdentifier:#"VC1"] animated:YES completion:nil];
Is this bad form? Am I leaking memory by creating a bunch of VC1 instances or is there some magic that uses the previously created one?
If it is bad form, how do I get back to the original VC1 to reuse it?
Thanks for any input.
I think you pegged it: It's not a great idea to have multiple instances of the same view controller in memory at the same time. Every time you instantiate a new view controller and present it modally, you'll consume more memory.
The most elegant solution is the iOS 6 unwind segue. But most of us would be unwilling to give up on iOS 5 support quite yet.
If you need to support iOS 5, you could contemplate using navigation controller, but hide the navigation bar if you don't like it in your user interface. Then replace modal segues with push segues and now you can do popToRootViewController whenever you want to return to the main view controller.