My app has a welcome screen that can only be shown in portrait mode. After the user has tapped through the welcome screen I'd like to show another screen that can be used in both portrait mode and landscape.
I have set up a view controller that implements shouldAutorotateToInterfaceOrientation: returning YES only for UIInterfaceOrientationPortrait, and I add the view to the window with [window addSubView:view]. I tag this view with the tag 1.
When the user taps through the welcome view and the app moves on to the new view I do:
[[window viewWithTag:1] removeFromSuperView];
[window addSubView:myViewController.view];
Where myViewController is an instance of the 2nd view's view controller (that handles the shouldAutorotateToInterfceOrientation method properly).
Now when I rotate, it still calls shouldAutorotateToInterfceOrientation on the original view's view controller, and does not call it on the new view's view controller.
This note from Apple says that only one view controller will get rotation notifications; however, I have removed the other view controller.
What am I doing wrong?
actually that note doesn't say that "only one view controller will get the notifications" but instead it says that "Only the first view controller added to UIWindow will rotate.".
So this might be the problem.
To resolve it, i would say to always have a view added to your window (call it permanent), and add your welcome screen and the next views to this permanent view.
Hope this helps.
as the note you link to state:
Only the first view controller added
to UIWindow will rotate.
So put a flag that makes sure that shouldAutorotateToInterfceOrientation returns NO until the user have dismissed the screen - and then returns YES afterwards. This is a simple and working solution - however, from a code readability point it might be confusing that a "dismissed" view actually controll the rotation.
Personally; my experience is that it's not really worthwhile having some views rotating and some don't - and users tend to don't like it.
happy coding
I wrote up a quick test that shows what you are trying to do should work. Here are the basics I did:
Create two view controllers. App starts with the first view controller being set in the AppDelegate into an instance variable viewController through NIB files. It is then added to the window as you have written.
I then setup an action that when called (could be a Timer, button on first view controller, etc.) that performed the following:
Remove view using [self.viewController removeFromSuperview]. This is different than the way you have done with the tag.
Created second view controller and assigned it to self.viewController.
Added to window like you have specified.
Not sure what is incorrect with your code. I would guess that perhaps the first view wasn't really being removed.
Related
I'm creating an app using the iPhone Utility App framework, and I'm trying to use a navigation controller on the flipside view, as there will be a lot of drilldown options on this view. When I'm done with this view, I call the following code:
- (IBAction)done:(id)sender
{
[self dismissModalViewControllerAnimated:YES];
}
When I dismiss this view, I want to be able to go back to the place in the navigation I was currently at when I reopen this view again. However, when I dismiss this view using this method, the vc gets deallocated, therefore the menu starts back at the beginning when I try to go back to the menu.
Thoughts?
You'll need to retain a reference to the object (I'm calling it the options controller). I would say the easiest way is to create an iVar in the presenting view controller that references the options controller. Then, when you go to present the options controller again, just present the referenced options controller rather than creating a new controller. If different view controller objects can present the options controller, you'll need to either pass that reference around, or store it in some object that all the other view controllers have access to.
Hmm not much code so maybe I'm misunderstanding your setup, but...
You could use the AppDelegate to store (as a property) your current position (index) in the views collection of the Navigation controller, and then write a method that pushes to that (stored) position when you re-visit it later.
Might be an easier way to do it though..
So what you want is to flip from a view to another view? If you want to keep the navigation bar status between flipping, I recommend you use only one view controller to control this 2 views. you can use + transitionFromView:toView:duration:options:completion: of UIView to flip views.
If I want to replace one screen of an app with another, but I don't use a navbar/tabbar controller, then I could just remove oldViewController.view from window and add newViewController.view to it. That's all, now newViewController will get rotation events, etc.
But UIView does not reference "its" controller, so how is this possible, how iOS know it should make newViewController an active one? Does iOS do some magic, it internally references controller from view or what?
UPDATE:
I think I was misunderstood: I don't ask how to make some view controller an active one - I know that. I'm just curious, how is it possible that I pass some view to UIWindow object ([window addSubview:view]) and it somehow finds view controller although view doesn't know its controller.
yeh I had the same question like you. and I figured it out.
UIView is derived from UIResponder. and UIView must subclass UIResponder::nextResponder.
Its default implementation is returning a view controller of the view (if it hadn't, it would be super view)
So, consequently view can see its controller. that means window know the topmost view and also
its controller.
good luck.
Unfortunately, iOS only send events to the first ViewController of the stack. You can try and present a new one on the top of others with video for example, it will never rotate.
If you don't use navbar/tabbar controller you will have to add and remove everytime from the Window to keep only one at the time if you wand to have events.
The main UIWindow class for your application will have a view controller set in its rootViewController property. That controller's view is the "main" view for the app. This is usually setup in the main .xib for the project. That view controller will receive the usual events like "viewDidAppear" or "willRotateToInterfaceOrientation". You can put up your own view over top of it if you want to, but you will need to manage those events yourself. Usually you don't do that though. You just use a UINavigationController or UITabBarController as your rootViewController and allow them to manage getting the events to new "pushed" view controllers, or you popup view controllers with "presentModalViewController".
I have an application with 8 UIViewControllers presented by navigating from left/right/up/down. They are created on start of the app and kept in an NSArray. Only 1 of them is added to the view tree (addSubview:) at any time - the rest just sit in the cache until they are needed.
Now the problem I am having is when rotating to Landscape. Only the currently visible view changes the bounds.size to Landscape. When navigating to the next view, that view still thinks it is in Portrait (but the containing views will all look in Landscape).
By the way, the view hierarchy of the app is the following: UIWindow -> Main UIViewController -> 1 of the 8 cached UIViewControllers.
For example:
* Change orientation:
- Main UIViewController.view.bounds.size = 480x300 (OK)
- One of the cached UIViewControllers view.bounds.size = 480x300 (OK)
* Go to next view:
- Main UIViewController.view.bounds.size = 480x300 (OK),
- Another of the cached UIViewControllers view.bounds.size = 320x460 (??)
Not sure whats going on. Do I have to tell the cached UIViewControllers somehow that the orientation/size changed or something else?
Thanks a lot
Yes you can. Optimally you should purge the view that each view controller manages when it goes off screen.
Simply assign nil to the view property of the view controller that is being replaced. This will free all resourced used by the view that is not visible anyway. As an added bonus the view is then recreated with proper frame whenever you decide to brin a particular viw controller in front again.
I am also assuming that what you are implementing is a subclass of UIViewController that acts as a container for other view controllers. Like a sibling to UITabController named CWGridController or similar. Noe that it is the responsibility of the the parent view controller (your subclass) to size the frame of it's child view controllers views as needed.
Creating a container view controller is not a small task, and the support for doing it is not complete from Apple. There are a few things you must do including but not limited to:
Forward all orientation change calls to all child view controllers.
Properly call all appear/disappear on child view controller as needed.
The last part to make it work is to break some rules. View controllers works very badly unless they know about their parent view controller, layout will be wrong and modal view controller behaves strange. Unfortunately the parentViewController is readonly, or so you would think. Setting it anyway using KVC will solve most problems, and Apple does not seem to object when you submit to App Store:
[childViewController setValue:self forKey:#"parentViewController"];
In viewWillAppear you will have to check the interface orientation and set the frames accordingly.
Using a UINavigationViewController, how do I find out how a view has appeared?
The view has either appeared in a straightforward manner, as the first view in the UINavigationController stack. Or it has appeared because a second view has been popped and the first view has revealed itself again. How do you find out which of these happened?
The only reliable way to do this, as far as I'm aware, is to subclass UINavigationController and override the UINavigationBarDelegate methods:
– navigationBar:shouldPushItem:
– navigationBar:didPushItem:
– navigationBar:shouldPopItem:
– navigationBar:didPopItem:
Don't forget to call super, of course.
Simple approach is to add a property to your RootViewController to track whether or not it has pushed another view onto the navigationController.
-(BOOL)hasPushedSecondView;
Initialize to NO in your init method.
Before pushing secondViewControllers view onto the stack, update the property to YES.
In viewWillAppear, check the value and update your view accordingly. Depending on how you want the application to behave you may need to reset the hasPushedsecondview property back to NO.
you could take a look at the leftBarButtonItem or backBarButtonItem, based on how your application is written and determine how the view appeared. If it is on top, unless you have a custom leftBarButtonItem, there would be no object there.
You can determine this directly via a couple of methods on your UIViewController subclass.
From Apple's documentation:
Occasionally, it can be useful to know why a view is appearing or
disappearing. For example, you might want to know whether a view
appeared because it was just added to a container or whether it
appeared because some other content that obscured it was removed. This
particular example often appears when using navigation controllers;
your content controller’s view may appear because the view controller
was just pushed onto the navigation stack or it might appear because
controllers previously above it were popped from the stack.
The UIViewController class provides methods your view controller can
call to determine why the appearance change occurred.
isMovingFromParentViewController: view was hidden because view controller was removed from container
isMovingToParentViewController: view is shown because it's being added to a container
isBeingPresented: view is being shown because it was presented by another view controller
isBeingDismissed: view is being hidden because it was just dimissed
So I'm trying to find out the best way to swap views for an iPhone game I'm making. I have a "root view controller" that has a reference to all the view controllers I want to swap between. So I add the main menu view to this root view controller - [self.view addSubview:mainMenuController.view]; - Then in the main menu view I have an instructions button. I define an IBAction in the mainMenuController to respond to the instructions button being clicked. From there, I call [self.view removeFromSuperview] which works great. It gets rid of the main menu. So next I want to add the instructions view. I figured that it would be as simple as [super.view addSubview:super.instructionsController.view], but no luck! I've thought of a few ways to get around this, but they all seem very inelegant, as I would like to keep all references to my view controllers in one place, the root view controller. Any thoughts?
Could you not have your main menu view controller tell the root view controller that it's closed, along with a reference to what view it should load next? I'm assuming you're not doing something akin to what UITableView does, in which case you'd likely want to use a stack.
Are you mixing super (an Objective-C keyword) with self.superview (an UIView property)?
At any rate it's indeed a better design to inform your main controller to switch to another view, rather than making that decision from the added subview.
I just got around it by setting a delegate property in each of my controllers to the root view controller.