//In App Delegate
UserProfileTableViewController *uptvc = [[UserProfileTableViewController alloc]init];
UITabBarItem *tempTabBarItem4 = [[UITabBarItem alloc]initWithTitle:#"Fans" image:nil tag:FANSTAB_INDEX];
//I am setting the user id information here directly in app delegate
uptvc.userId = [[UserStockInfo sharedUserStockInfo]getUserId];
UINavigationController *navconUptvc = [[UINavigationController alloc]initWithRootViewController:uptvc];
The problem arises when my UserProfileTableViewController gets unloaded due to low memory (might be due to using the camera feature in my app). The page will fail to load properly as it is missing the 'userId' information passed in from the app delegate (as seen above). I am unable to set this userId information directly in the UserProfileTableViewController (in view did load method) as other pages might pass a different userId when pushing the page onto their stack.
Any advise on how I can resolve this issue?
First off, you should keep your UserProfileTableViewController object into an ivar of the app delegate (since you allocate it there). Second, make the app delegate provide that userId to the controller. Third, if the navigation controller is removed from the interface/deallocated, then even with low memory your uptvc should not be deallocated either.
View controllers maintain the full hierarchy of controllers, even when running out of memory, what's deleted are views, and anything you tell them to remove.
You most certainly want to keep the UINavigationController in an ivar of the AppDelegate as well.
Related
I have pre allocated the mail and messaging controllers on startup in my app delegate to save the initialisation time (over 10 secs) when the user is using my application...
__mailController = [[MFMailComposeViewController alloc] init];
__messageController = [[MFMessageComposeViewController alloc] init];
It works fine the first time the controller is displayed then the next time the message is not changed and the old message is still displayed ?? ... Is it likely that the controller is being deallocated ??? Strange as the views work correctly just that the message is not correct ?
- (IBAction)actionSMS:(id)sender {
if([MFMessageComposeViewController canSendText])
{
self.messageController.body = self.MessageDetail.text;
// controller.recipients = [NSArray arrayWithObjects:#"+919999999999", nil];
[self presentModalViewController:self.messageController animated:YES];
}
}
Once MFMailComposeViewController and MFMessageComposeViewController are presented to the user you can't make changes to the content they display.
MFMailComposeViewController Class Reference:
Important The mail composition interface itself is not customizable
and must not be modified by your application. In addition, after
presenting the interface, your application is not allowed to make
further changes to the email content. The user may still edit the
content using the interface, but programmatic changes are ignored.
Thus, you must set the values of content fields before presenting the
interface.
That means those values are somehow locked in the implementation of the MFM*ViewController at the moment you present the controller. So you can't reuse these viewControllers. iOS doesn't care if the controller is, like in your case, invisible or not. If it is presented the content is locked.
I would figure out why it takes 10 seconds to allocate them. And then dump that whole pre-allocation thingie. 10 seconds are definitely to much.
I had the same problem. Not only are the MF controllers only good for one time use, as you discovered, they also cannot be init-ed in the background because their UI elements need to be init-ed in the main thread.
In the end, I just present a UIActivityIndicatorView over a HUD, so the users will know the app is responding.
I am working on an iPad (only) app and I stumbled across a weird problem. The app gets terminated after a memory warning on iPad 1 but works fine on iPad 2.
I am using ARC and targeting iOS 5. I use nibs and most of my assets are displayed using UIImageViews. I also have a few hundred buttons and plenty of gesture recognizers... I re-watched the WWDC11 videos (sessions 323 and 322) on ARC and I don't seem to be doing anything special.
The app is UIImage intensive, I am doing lots of animations using UIImage. I am however using the initWithContentsOfFile constructor rather than the imageNamed call. I'm trying to prevent the images from being cached by the system.
I'm also using GCD to schedule sound effects and to animate views. I'm always doing this on the main thread.
The app uses a UINavigationController that never has more than 1 UIViewController on it's stack. I can confirm that this is true because the didReceiveMemoryWarning only gets called on the current view controller (I'm logging the call).
The thing I don't understand is why Instruments is reporting high numbers (as if the view controllers don't get deallocated) in both the Allocations and VM Tracker instruments. The Allocations instrument shows a small drop when I navigate from one view controller to another (which is what I expect) but the VM Tracker Instrument shows that the Dirty Size is not dropping when I do the same thing. Eventually the app uses too much memory and gets terminated (on iPad 1). When I get memory warnings on the iPad 2 the app does NOT get terminated though...
It feels as if my images, sounds or views don't get destroyed and the memory does not get reclaimed... My object hierarchy is very basic and there should not be any retain cycles of any sort. I don't even have simple delegates...
Do you have any suggestions? I really don't want to release this app only for the iPad 2 or newer... It's an app for kids and it would be a pitty... I'd be so much happier to learn that I'm doing something wrong, as I really want to make sure this app is the best it can be...
Cheers,
Nick
There are ways to say, 'optimise' your objects by setting their properties to nil when certain things aren't needed -- so while you can't write a dealloc method anymore, you can do self.object = nil (when pertinent) which ends up doing something like this in a non-ARC world for an 'retain' (i.e., strong) property:
- (void)setObject:(id)newObject
{
[object release]; // send release message to current object
object = newObject; // set reference to newObject
[object retain]; // send retain message to newObject
}
Now while in ARC you don't/can't write retain/release yourself in your code, the compiler inserts these calls for you, meaning that in practise, setting a property to nil would do this in the above example:
[object release]; // send release message to current object
object = nil; // set reference to nil
[object retain]; // send retain message to nil (no effect)
Moreover, this is just the tip of the iceberg -- you should make sure that there are no retain cycles in your code, which could be resulting in objects leaking without recourse to their destruction. This means, that there may be places where you're using strong references to a property (i.e., an object), when you should be using a weak property. The difference being, that strong references are retained, and weak references are assigned, the former having its retainCount incremented and the latter resulting in a property assignment that looks like this if handwritten:
- (void)setObject:(id)newObject
{
object = newObject;
}
I don't like answering my own question but I figured it could be helpful to future googlers. I implemented my own UIImage based animation and I no longer use the animationImages property. Turns out my memory issues are now gone as I no longer need to store all the images in memory and I load them as they are required using a timer.
I actually think that rolling out a custom animation is beneficial since it allows for callbacks and more powerful customisation options.
Once I'm happy with it and I feel like it's ready to be shared I will post the class(es) on GitHub.
When I try to switch views from A to B, everything works. But when I want to go back from B to A the app crashes?
When I remove the autorelease the app works fine but then it leaks.
Here is the code for switching the views:
-(IBAction)switchToExplainView:(id)sender{
explainViewController = [[ExplainViewController alloc]
initWithNibName:#"ExplainViewController"
bundle:nil];
[self.view addSubview:explainViewController.view];
}
You have to consider both the controller and the view.
The controller will hold on to its view, but you need to hold on to that controller. If you (auto)release it, it may easily get deallocated, and if you try to access it, your app will crash.
The view itself will be released by it's superview, but not the controller.
One possible solution is to store that controller in an ivar of your class that manages (switches) the views. Only release them when you are done with them.
Are you using a navigation controller to switch back and forth between views? If yes, you may want to use the [myNavController pushViewController:... animated:...] message. After that, you can easily release your explainViewController.
I have a view that will be displaying downloaded images and text. I'd like to handle all the downloading asynchronously using ASIHTTPRequest, but I'm not sure how to go about notifying the view when downloads are finished...
If I pass my view controller as the delegate of the ASIHTTPRequest, and then my view is destroyed (user navigates away) will it fail gracefully when it tries to message my view controller because the delegate is now nil?
i.e. if i do this:
UIViewController *myvc = [[UIViewController alloc] init];
request.delegate = myvc;
[myvc release];
Do myvc, and request.delegate now == a pointer to nil?
This is the problem with being self-taught... I'm kinda fuzzy on some basic concepts.
Other ideas of how to handle this are welcome.
update: Looking at the source code for ASIHTTPRequest, it does not retain its delegate, so your code will either have to ensure that the delegate has not been released, or set the request's delegate property to nil before releasing your controller.
If you are going to have several asynchronous HTTP requests running, it may be a good idea to create an HTTPRequestManager class to act as delegate for all of your HTTP requests. This HTTPRequestManager class would remain in memory for the entire lifetime of your application, and it could take care of failing gracefully if/when your view controllers are released.
I would like to add a clarification about Cocoa's reference-counted memory management. It is important to remember that a released object is not automatically set to nil. Sending a message to nil is perfectly legal (and simply does nothing), but sending a message to a deleted object is undefined behaviour. Keeping a pointer to a deleted object is asking for trouble, and such living/dead pointers are referred to as zombies.
I have a very simple code to show a modal controller (nextController is a class member):
nextController = [[InstructionsScreen alloc] initWithNibName:#"InstructionsScreen" bundle:nil];
[self presentModalViewController:nextController animated:YES];
[nextController release];
And then when the controller should hide:
[self dismissModalViewControllerAnimated:YES];
nextController = nil;
All works good as expected, but when I run instrument Object Allocations it shows that after dismissing the modal controller the memory it allocated is not freed. This becomes a problem because when I show several controllers the memory is over ...
Can anybody give me some clues ? Clang doesn't see any problems, so I'm stuck hitting the memory limit, because the memory of the dismissed controllers won't get released.
EDIT: What I discovered up to now is that it seems to be a leak somewhere in Apple's stuff. Way to reproduce: XCode -> create new project with the template "Utility application". Don't write any code yourself. Just create a new utility application and run it with "Object allocations", choose to see "Created & Still living". Now flip the modal controller few times - you'll see the allocated memory only grows and grows every time the modal controller is appearing and when it's disappearing too ...
There is no leak in the code you show as far as I can see. There could be a leak in InstructionsScreen that would prevent it being deallocated.
I think it's worth running the Static Analyser to see if it finds a leak.
The leak in the Apple template code is interesting. It could be that there is a leak. It seems unlikely but obviously it's not impossible. I would say that it's more likely that it's a false-positive in Instruments, which is why I'd suggest using the Static Analyser.
(You might want to raise a bug report about the leak.)
Modal views are not subviews of the calling view but are instead subview of the apps window and are retained by the window itself. You generally you do not retain a reference to them in the controller that calls them. Instead, evoke the modal view and then have it communicate with the controller by defining the controller as the modal view's delegate.
I think that if you use synthesize to create the accessor for a nextController property defined with retain, then the accessor will retain any object assigned to the property. Simply setting the value to nil will not release the object unless the accessor is set up to do that and I don't think the autogenerated ones do.
You will expressly have to call release before setting to nil.
If this doesn't work, post the code for your definition of the nextController property.