I was wondering something about the app delegate of my app.
Why can't I release like this :
-(BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
RootViewController *controller = [[RootViewController alloc]
initWithNibName:#"RootViewController"
bundle:[NSBundle mainBundle]];
[self.window addSubview:controller.view];
[controller release]; // Here's my question
[self.window makeKeyAndVisible];
return YES;
}
I was almost sure that -addSubview method increase by 1 my retain count. So why do I have crash when I release my controller ? Why is it working in another class but the delegate ?
Thanks !
The other answers are correct, the UIVIewController is not being retained, what I recommend is setting the UIWindows rootViewController (only available iOS 4.0 and later) property which does retain the controller. If your app supports pre iOS 4.0 then you will need to store controller in an instance variable.
-(BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
RootViewController *controller = [[RootViewController alloc]
initWithNibName:#"RootViewController"
bundle:[NSBundle mainBundle]];
//controller will be retained and view will set for you
window.rootViewController = controller;
[controller release];
[self.window makeKeyAndVisible];
return YES;
}
This line
[self.window addSubview:controller.view];
increases the retain count of controller.view not controller. That's why
[controller release];
creates a problem.
If this is the main window, then you don't need to worry about the memory leak, because the window is active for the entire life of the program, and all memory is purged when it terminates.
addSubView increases the retain count of the view inside of the view controller, that is why the app crashes if you release the controller.
in any case, if you don't release it, you will have a leak. the solution is creating an ivar in your class and assigning to it the view controller (instead of a local variable), then release it in dealloc.
When you add view as subview then view gets retained, not its controller. So when you release controller it gets deallocated and its view - not. As result later view try to send messages to its already deallocated controller and app crashes.
This because you are the unique owner of that controller. You just add its view as a subview of the window. Although the view gets retained by the window's view, the controller not.
So, it will get deallocated and any further use of it will make your app crash.
Related
ViewWillAppear is never called automatically I have to call them manually. ViewWillDisappear is often called though.
I do not know where to debug this.
I suppose the problem is because I created the application on 4.1 where people have to call viewWillAppear explicitly.
I suppose, because viewWillAppear will be called depending on its relation with window I can check if my viewController has an outlet to window.
How do I do so?
I suspected the problem is somewhere in my delegate:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
[Crashlytics startWithAPIKey:#"a08863b514ef09558ba82fec070cc7468fdbeeae"];
if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
{
NSLog(#"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");
}
[self.window addSubview:self.navController.view]; //This seem to be the problem. I should have specified the viewController and not the view
[self.navController pushViewController:self.MainBadgerApplication animated:YES];
//[cachedProperties singleton].lastAnchor =[cachedProperties currentLocation];
[cachedProperties singleton].currentAnchor=[cachedProperties currentLocation];
self.MainBadgerApplication.selectedIndex=0;
[BNUtilitiesQuick tabBarController:self.MainBadgerApplication didSelectViewController:self.MainBadgerApplication.selectedViewController];
[self.window makeKeyAndVisible];
return YES;
}
I suspected that
[self.window addSubview:self.navController.view]; is the issue.
Also I've heard before ios5 you do have to call viewController explicitly. So should I create a different program for ios5 and ios4 (not like there is any danger in calling viewController twice for my program)
I suspected that [self.window addSubview:self.navController.view]; is the issue.
Probably. You should be doing this instead:
self.window.rootViewController = self.navController;
Just adding the view doesn't put your view controller into the hierarchy properly. See the WWDC 2011 view controller containment video for more information.
I've searched for this on Apple's site and can only seem to find documentation using Storyboards or Navigation Controllers, neither of which I'm using. It's an incredibly straightforward question about memory management.
I created a completely blank application. In my AppDelegate's didFinishLaunchingWithOptions function I'm creating an instance of a View Controller which I've built. My design (which itself could be a problem) is to have a 1:1 relationship between View Controllers and Views.
So the main menu of my application, which is a launching pad for everything is in MenuViewController.h/m.
In .h:
MenuViewController *m;
In .m:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
self.window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
// Override point for customization after application launch.
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
m = (MenuViewController *)[[MenuViewController alloc] init];
m.window = self.window;
[m doStuff]; // handful of functions, not actually called this
//[m release]; // doesn't make sense to me
return YES;
}
This is where I'm confused. I want this to exist for basically the entirety of the application life cycle. But I'm also under the impression that you should (in the scope of the current function) release anything you allocate. If you need it beyond that, you should retain it elsewhere first. Is this not true?
My fundamental question is...where should I be releasing this View Controller? Is there anything else I've said that seems out of whack?
The initialization is wrong. You don't assign a window to controller, you assign a controller to window:
// window creation code here
...
m = [[MenuViewController alloc] init];
[window setRootViewController:m]; // window does retain for m
[m release]; // so we release it here
[self.window makeKeyAndVisible];
return YES
}
You're right. Generally you should release anything you create in a scope. But in this case you want ownership of the view controller. In this case you need to release the object in the dealloc method of your app delegate:
- (void)dealloc {
[m release];
[super dealloc];
}
Alternatively you could define a #property for your view controller with retain flag and then do this:
MenuViewController *viewController = [[MenuViewController alloc] init];
self.m = viewController;
[viewController release];
Btw, you don't need to cast to MenuViewController in either case.
EDIT: I completely missed that you don't add your view controller to your window. Good point #Eimantas.
I apologize in advance for the n00b question. I am just getting started w/ iOS!
I am trying to push a webViewController onto a navigation controller.
mudWebViewController *webViewController = [[mudWebViewController alloc] initWithNibName:nil bundle:nil];
[[webViewController webView] setDelegate:webViewController];
[[self navigationController] pushViewController:webViewController animated:YES];
But this doesn't seem to work, as I don't see any of the logs in the delegate messages.
If I set the delegate in the viewDidLoad: method, it works fine.
I guess the webView doesn't actually exist at that point, but why? If I initialize the controller, shouldn't the webView be initialized too?
Is viewDidLoad: the right place to be setting up this stuff?
initWithNibName should be not nil, since you obviously are using a nib file to build the view, else you have to create the view in code, which you don't
mudWebViewController *webViewController = [[mudWebViewController alloc] initWithNibName:#"webViewController" bundle:nil];
[[self navigationController] pushViewController:webViewController animated:YES];
Also any delegates should be set either from the Interface builder or from the view itself in the viewDidLoad delegate and not from the previous class, as the object might not been yet initialized in the code so it can fail to set the delegate properly.
In my app I have a UIViewController subclass (VC for short) that I only use in one place in the entire app. In that place, I have been creating and pushing it like this:
MyViewController* VC = [MyViewController new];
[self.navigationController pushViewController:VC animated:YES];
[VC release];
but I was thinking that since this is the only place I am using a view controller of this type, I could do something like this so the settings used won't be reset each time the view controller is pushed onto the stack:
static MapsToSendPicker* VC = nil;
if(!VC) {
VC = [MapsToSendPicker new];
}
[self.navigationController pushViewController:VC animated:YES];
[VC release];
The problem with that code is that in VC's dealloc method, I release all of my instance variables and set them to nil, and finally I call [super dealloc]. This deallocates the static view controller, but the test if(!VC) isn't evaluated to true after (this would defeat the purpose of the whole idea if it were; then I'd have to recreate the view controller each time anyway).
My solution is overriding the dealloc method in MyViewController and not calling [super dealloc] at the end. This works, but the compiler raises a warning. How can I get rid of that warning while maintaining the functionality I gain with this design? Thanks!
Edit:
After a quick Google search, I have found this solution:
- (void)dealloc {
if(NO) {
[super dealloc];
}
}
but I would like something a little bit... cleaner. Any thoughts?
Remove the [VC release]; line and add [super dealloc] back. Everything will work properly and dealloc will never get called. Generally you should consider using NSUserDefaults in order to restore the VC properties instead of keeping the controller in memory all the time.
I used the instruments tool and it tells me I have no memory leaks. But I am struggling with the logic behind it. Why wouldn't this be leaky? It appears that some magic is happening behind the scenes and my AppDelegate is using my allocated navController to set the property of the self.navigationController. Without my initialization here, my property is nil.
Shouldn't I be forced to make these instance variables of the delegate and then release them in the dealloc? Why isn't this a leak? Or am I using the instruments tool wrong?
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// two alloc calls which would imply I need a release
UINavigationController *navController = [[UINavigationController alloc] init];
UIViewController *calcController = [[CalculatorViewController alloc] init];
[navController pushViewController:calcController animated:YES];
[window addSubview:navController.view];
[window makeKeyAndVisible];
// can not release here, if i do, no views show up
// [navController release];
// [calcController release];
return YES;
}
...
// NOTE: No dealloc for navController or calcController
- (void)dealloc {
[window release];
[super dealloc];
}
Both navController and calcController exist for the life of the program. When the program terminates, everything is purged, so it doesn't matter. You do have a leak, but an irrelevant one.
Since your app delegate exists for the duration of the application run, you would only see a memory leak right before the application quits. So while there is technically a "leak" it only occurs right before the application is purged from memory.