I have a quick question:
View Controller X has added a sub-view: View Controller Y.
Y has a "quit" button. When the button is tapped, it removes its view from X's view hierarchy.
But I found Y's 'viewDidUnload' method is not called and its memory can't be released. How could Y release itself properly, or how could X know that Y is gone?
I believe I can make a protocol and let Y call a method from X, but I hope there is a easier way.
So you want the Y view controller to get cleaned when its view is closed?
Prior to iOS5 there's nothing fancy to support more than one UIViewController on screen at once, so you basically how to make the calls yourself.
You could notify X when Y is closed (you could use NSNotificationCenter, or a delegate), and X would set Y's view to nil which would cause the viewDidUnload method to be called in it.
Additionally you could even release the Y view controller, which would dealloc every instance it has (along with the view itself) if you're not going to show it again.
As you have added View Controller Y in View Controller X by coding...
[viewX.view addSubView:viewY.view];
So, the viewDidLoad method wont going to execute. And, as far as memory management is concerns, you can code for that in viewX.m, i.e. as the "quit" has been tapped...
[viewY removeFromSuperView];
[viewY released];
If you only need to know when a subview has been removed from its parent view, implement didAddSubview: and/or willRemoveSubview:. (See here in the documentation)
If you want to release the viewController when removing the view, you need to... release the viewController when you remove the view: [viewController.view removeFromSuperview]; [viewController release]; viewController = nil;
The viewDidUnload method is only called when there is a memoryWarning being issued by iOS, and that the ViewController then automatically unload its view (if it is not onscreen, e.g. the ViewController is not the topmost of a NavCtrl's stack so its view is not visible) to release some memory (and will then re-load the view from your XIB and recall viewDidLoad when it needs to reload the view to display it again).
You should not have 2 UIViewControllers on screen at the same time. There is a whole range of problems associated with that and it is not how they are intended to be used.
A single UIViewController should manage all subviews associated with a single screen. If you want a "child" view subclass UIView and add it as a subview.
To allow to switch between view controllers easily, add a UINavigationController as the root view controller, and push/pop view controllers via that. You can then change screens very easily. Remember - you can turn of the navbar and/or animation you get no visual indication that your app is using a navigation controller, but full benefit of it's ability to manage a stack of views and ensure all the correct notifications are sent to each view controller as it loads/appears/disappears/unloads.
If you get in the habit of building every app with a UINavigationController as the root view controller things become very simple.
Related
I've been working for a while now on switching UIViews, and am trying a basic UIView switch, without using UINavigationController. I've looked into UINavigationControllers, but I have been wrestling with the below for so long that I want to explore it fully.
My project organisation is:
MainViewController.h/.m -> viewDidLoad: This method runs a NSTimer to update self.view with a few bits and bobs.
ConfigView.h/.m: -> viewDidLoad: nothing - just an idle view.
MainViewController.xib -> Main window NIB
ConfigView.xib -> ConfigView NIB
I have the following method in MainViewController.m execute on a UIButton press event:
- (IBAction)switchToConfigView:(id)sender {
if(self.configViewController == nil) {
ConfigView *cv = [[ConfigView alloc] initWithNibName:#"ConfigView" bundle:nil];
self.configViewController = cv;
[cv release];
}
[self.view addSubview:configViewController.view];
}
Now, when I switch to the ConfigView, the view is indeed displayed, but it appears that viewDidLoad: from MainViewController still executes, causing both views to effectively be merged. From the code, I can see that this is obviously the case, as the actual view switch itself is performed within the MainViewController context, and as you can see, simply a subview.
My question is, how do I neatly tuck away/pause all goings-on within MainViewController when switching the view by just adding another subview to it? My guess is that it's not possible, or rather it's a lot of leg work where some other methodology would be better applied. I suspect I need to implement the actual switch from the ConfigView.h/.m but I could be wrong.
Any light you can shed on the above would be grand.
thanks
swisscheese.
My suggestion is:
1) have a base, empty view;
2) add a subview to it; this would be your actual first view;
3) when you want to switch, remove the first subview from the base view and add the second one as a subview;
4) when you want to switch back, remove the second one and add the first one as a subview to the base view;
you can easily handle as many view as you like. it works.
alternatively, you can hide the view instead of removing it.
Believe me adding a whole new sub-view on another view is really a massive task and later on when the project becomes big it becomes a painful task to switch views.
This is my own personal experience as I did this big mistake in one of my previous project.
In all cases navigation control is the best choice for switching views rather than adding sub-views.
Please tell me that what difficulties are you facing in Navigation control and I can help about this.
Thanks,
If the NSTimer you've set up in MainViewController's viewDidLoad method is adding subview's to mainViewController's view with the addSubview method, those views will be placed on top of all other subviews, i.e. on top of the config view. So, you might try either invalidating the timer when presenting the config view.
You should really just use a UINavigationController, or present the config view controller with presentModalViewControllerAnimated. Why don't you want to?
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.
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.
I'm trying to figure out from Apple's sketchy documentation which method is the best place to be initializing and adding my Views controls to the controller's view.
With winforms it's fairly straightforward, as they're always initialized inside InitializeDesigner, called in the constructor. I'm trying to match the reliability of this pattern if possible.
I'm working with UIViewControllers and UITableViewControllers inside a UINavigationController most of the time - if this effects it all.
Here's an example:
public MyController()
{
// Here?
AddViews();
}
public override ViewDidLoad()
{
base.ViewDidLoad();
// Or is should it be here?
AddViews();
}
public override ViewWillAppear(bool )
{
base.ViewWillAppear(animated);
// Here?
AddViews();
}
public override ViewDidAppear(bool animated)
{
base.ViewDidLoad(animated);
// Or maybe here?
AddViews();
}
void AddViews()
{
UILabel label = new UILabel();
label.Text = "Test";
label.Frame = new RectangleF(100,100,100,26);
View.AddSubView(label);
UIWebView webview = new UIWebView();
webview .Frame = new RectangleF(100,100,100,26);
View.AddSubView(webview);
}
I get mixed results with some UIControls when I add them to the view in different places. Visual lag sometimes, othertimes the webview is hidden somewhere.
Is there a general rule to keep to for adding them?
In general, this is what I do:
ViewDidLoad - Whenever I'm adding controls to a view that should appear together with the view, right away, I put it in the ViewDidLoad method. Basically this method is called whenever the view was loaded into memory. So for example, if my view is a form with 3 labels, I would add the labels here; the view will never exist without those forms.
ViewWillAppear: I use ViewWillAppear usually just to update the data on the form. So, for the example above, I would use this to actually load the data from my domain into the form. Creation of UIViews is fairly expensive, and you should avoid as much as possible doing that on the ViewWillAppear method, becuase when this gets called, it means that the iPhone is already ready to show the UIView to the user, and anything heavy you do here will impact performance in a very visible manner (like animations being delayed, etc).
ViewDidAppear: Finally, I use the ViewDidAppear to start off new threads to things that would take a long time to execute, like for example doing a webservice call to get extra data for the form above.The good thing is that because the view already exists and is being displayed to the user, you can show a nice "Waiting" message to the user while you get the data.
There are other tricks you can use, though. Lets say you want a UILabel to "fly" into the form after the form is loaded. In that case, I would add the label to the form in the ViewDidLoad but with a Frame outside of the view area, and then in the ViewDidAppear I would do the animation to fly it back into view.
Hope it helps.
Hmm, Apple's docs seem to be pretty clear, IMHO.
If you create your own root view (the root view of this particular controller's view hierarchy) programmatically, you should create it in -loadView without calling super and set the view property when done. If your view is loaded from a nib, you should not touch -loadView.
You add custom subviews to the view controller's view or otherwise modify it in -viewDidLoad. The recommended practice is to create your UILabel and UIWebView in -viewDidLoad and release them in -viewDidUnload, setting their references to nil if you need to keep them in ivars.
Note: -viewDidUnload is deprecated in iOS 6 and is just not called any more, because UIViewController no longer purges its view under memory pressure.
viewDidLoad relates to 'MEMORY', and viewWillAppear/viewDidAppear relates to 'APPEARANCE'. A view controller's view (which is a root-view of your view controller's views) can appear/disappear numerous times, even if the controller's view is already in memory.
(When referring to root-view, I also means its subviews, because the root-view has reference to its children (subviews), but from a view controller's perspective, it usually knows just the root-view. Reference to subviews can happens normally through view controller's outlets.)
The root-view itself MAY be removed from memory when there's a memory warning. The view controller will determine when is the best time to removed them from memory.
So, you would normally add subviews in viewDidLoad, because adding subviews means adding them to memory. BUT not if you create all of your views programmatically (not from a nib files). If that's the case then you should override loadView method, and create a root-view and add subviews there, so in this case you can omit viewDidLoad to add subviews.