This is driving me nuts. I am using three20's TTTableViewController and when I get a memory warning, the screen goes white. Now, after reading on the three20 google group is seems that the tableView got released. But, I cannot for the life of me figure out a check to see if that is the case, then create it again.
I was using the following because I thought it would fix the issue, but it seems that it doesn't satisfy the if statement:
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
// If we don't have a datasource we need to reset it
if (!self.dataSource) {
// Create datasource again
}
}//end
Does anyone know what to do when this happens? The google group has been no help.
Are you subclassing TTTableViewController? I haven't used it before, but assuming it's just like UITableViewController...
How does your "viewDidUnload" look like? Are you releasing the tableview here? If so, you need to create tableview in viewDidLoad to match it.
No need to check if dataSource is available in viewDidAppear, because if you read View programming guide, it explains that memory warning will call "viewDidUnload" to give you a chance to clean up data that are created in "viewDidLoad".
i had the same issue and it drove me crazy as well.
Nobody mentions it in the three20 docs, but you shouldn't use UIViewController's initWithNibName function to add subviews. If you do, a memory warning will release these subviews.
Try to move your code from initWithNibName function to viewDidLoad function. I have noticed that some code need to be kept in the initWithNibName, such as navigation styles. However, any subviews added to the controller's view should be in the viewDidLoad function.
In general you should be careful to set up views in viewDidLoad rather than the class constructor. For instance, you should set up your launcher view in viewDidLoad rather than the constructor of your launcher view controller, otherwise your launcher will become empty after a memory warning.
In the case of TTTableViewController however this does not (usually) apply because you don't set up the table view manually. I had the same problem you had, and eventually tracked it down: I had redefined viewWillDisappear: and forgot to call [super viewWillDisappear:animated]. This meant that some of the flags that the Three20 controller maintains about the state of the view were not updated correctly.
I also found that it was beneficial to redefine didReceiveMemoryWarning to call [self setEditing:NO] before calling super; I found that the state of the table view got confused otherwise (this is not relevant if you don't use edit mode for your table).
Finally, there is a bug in Three20 which means that tables in loading/empty/error mode will not be restored properly; see a discussion in the blog post by TwoCentStudios and a proposed fix on github.
Related
Is there a BOOL or some other way of knowing if viewDidLoad: has been called?
I need to change a view property every time my view has entered active, but if the view hasn't ever been loaded, I don't want to prematurely trigger viewDidLoad:. If there isn't way of easily telling if viewDidLoad: has been called, I'll simply add a BOOL called loaded set to NO in the view controller init, then change the view properties after entered active if loaded is YES or in viewWillAppear: if loaded is NO then set loaded to YES.
Use isViewLoaded. Other than that it does exactly what you want, there's not that much to say about it. The documentation is as simple as:
Calling this method reports whether the view is loaded. Unlike the
view property, it does not attempt to load the view if it is not
already in memory.
Perhaps you should init your UIView in viewDidLoad, and then change it in whichever way you need to inside viewWillLayoutSubviews.
Here's the pedantic answer to this question. If you want to know when viewDidLoad has been triggered, you have to implement viewDidLoad in your view controller
- (void)viewDidLoad
{
[super viewDidLoad];
viewDidLoadCalled = YES; // Not actually the best way to do this...
// Set up more view properties
}
But as Tommy says, you actually need to use isViewLoaded. This gets around the problem of doing a check like
if (!self.view) {
// do something
}
which inadvertently loads the view by virtue of asking about it.
Be aware that by the time viewWillAppear: is called, the view will always have loaded. Also, on older (pre-iOS 6 I think) releases, the view can unload and be reloaded many times over a view controller's lifetime. Refer to the very nice Big Nerd Ranch view lifecycle diagram for the old behavior. It's almost the same in iOS 6+, except that the view doesn't unload under low memory conditions and viewDidUnload doesn't get called:
I'm fairly new to Cocoa Touch. Right now I'm trying to subclass UIViewController to provide my custom view. Since I intend to save the content of a UITextField (passcodeField) using NSUserDefaults, I want to be notified whenever the UITextField changes its value.
I've read somewhere that in order to do that I should add the view controller to be an observer of the UITextFieldTextDidChangeNotification notification. However I'm just not sure when to do that. I've considered several options.
In the -loadView method. However, since I'm loading my view using a XIB, I think i shouldn't mess with this method and should instead leave it as-is. (Am I correct on this point, BTW? )
In the -viewWillAppear method. But this method may be called multiple times because the view may be moved out and into the screen without being destroyed and recreated. (Am I correct? ) This will not do any harm to the program but sure doesn't seem like the correct way.
In the initializer of the UIViewController. If I want to add the notification there I must reference the UITextField. By doing this I essentially cause the view to created before it is really needed. Also I think I read somewhere that if the system runs low on memory the offscreen views may be destroyed. Thus I may lose the notification observing if such thing happens, right?
So I'm totally confused right now. Could you guys give me some advice of where to put it? Thanks so much!
Put it in the - (void)viewDidLoad method of your ViewController remember to call [super viewDidLoad]; at the start of your implementation.
I have a view with many retained IBOutlets, loaded from a XIB.
I have read that they have to be released when the controller's dealloc method is called.
May I use a cycle to do this(also to avoid releasing each outlet separately)?
something like
for(UIView *v in self.view.subviews){
[v release];
v=nil;
}
?
also, after that, should I release the view as well?
That would only make sense if you've actually retained every single subview, and even then it seems like asking for trouble -- if you ever wanted to change your .xib, you'd have to remember to update you code as well. And there may also be non-view objects in a nib that can be connected to outlets, like view controllers.
There are only so many views you can fit on an iPhone- or iPad-sized screen, so it's hard to imagine that you have more than a few dozen outlets. I think the prudent thing to do here is to simply release each one separately. This is what and iOS developer would expect to see, and it won't be any slower than using a loop. It'll be more code, yes, but the code will be easy to understand.
self.view is automatically released on UIViewController deallocation, and subviews also, if not retained by your code.
You should re-read the chapter on memory management in Apple Documentation... ;)
I wrote like a releaseVars function, which takes address of variables, release them and set to nil. This save some lines of code, but still you have to manually take care of them.
I'm developing an app to browse online photos, and sometimes received memory warning(level 1), after that, if I go back to last UIViewController(in a NavigationControll), I found that some custom UIView lost, I cannot get them back, but I can create new such UIView
does anyone know the problem?
The memory warning prompts the os to dump any unneeded views. If you create them in IB, or in the viewDidLoad or loadView method in your view controller they'll be re-created when your view re-loads. You could also have your view controller retain them specifically, but that'll have a larger memory footprint than just re-creating them whenever they're needed.
I should say, loadView is only called if you don't use a nib for creating your view, so viewDidLoad is probably where you want to put them.
It's expected behavior. You can override didReceiveMemoryWarning (i.e. do nothing and don't call on super); but what you really want is to handle those situations correctly, i.e. set the views up again if necessary.
I've implemented a View Controller, and I'm trying to do some very basic initialization in initWithNibFile...which I understand to be the designated initializer for View Controller objects.
I've tried to put breakpoints on the code, and have put very simple NSLog statements into it as well. Regardless...I'm not seeing it be executed (and the object i'm attempting to alloc/init inside the function is also not being allocated - so I'm about 99% sure I'm not hitting the code.
Is there something I need to do elsewhere to cause this method to be invoked?
I'm getting a clean build, no warnings or errors. And the app successfully loads up the View, and I can invoke a ButtonClick method I've coded and connected to this same View Controller.
Any suggestions would be appreciated.
TC
I ended up moving my allocation logic to viewDidLoad, and that works fine.
Not sure why the initWithNibFile was not working...but I'll take the small victory !!!
Thanks for offering to look at the code bpapa.
You probably need initWithCoder: It's what the SDK uses to read from nib files during startup.
initWithNibFile: is almost never called by the system. Usually you call this manually. The documentation is quite misleading on this point.
In any case, be careful doing too much initialization in the initWithXXXX methods. The view's targets and actions aren't likely to be set up and connected yet. viewDidLoad is almost always the right place to do viewController setup anyways.