I am working on an iPad application which is converted to ARC. Application is for os >= ios 5.0. So my doubt is that, how do I manage viewOutlets? I use -(void)didReceivememoryWarning to set ViewOutlets to nil. But in ios 5.0 and 5.1 application shows lots of memory leaks. As -(void)viewDidUnload is deprecated in ios 6.0 , I am not using the same in the application. Is the correct way to manage outlets? Please give me a quick reply.
ARC (automatic reference counting) features is available in iOS 5 and ahead (iOS 6 and so on..) version.
When you are using ARC unable in your project, you dont need to `manually release any object` that you have allocated for your stuff.
ARC will automatic handle this one.so it will beneficial for `Memory Management`.
Hope ,You understand what i m trying to say.
for more clarification , please refer below link:
To ARC or not to ARC? What are the pros and cons?
ARC, worth it or not?
Good Luck !!!
There is NO DIFFERENCE in how you code for iOS 5 vs. iOS 6.
If you are having problems, it's because you don't understand what viewDidUnload does and when it's called.
viewDidUnload is called when the view of the controller is unloaded. In iOS 6, views are never unloaded. In iOS 5 and before, views were almost never unloaded either. So in both cases, pretty much viewDidUnload is never called.
If your program is leaking stuff, it's because you are not releasing things. You always need to release instance variables in dealloc. I suspect that this is your problem.
When the controller's view is unloaded (which only happens in iOS 5 and before, but this is irrelevant), viewDidUnload allows you to optionally discard some resources to save memory, as long as they are resources that will be re-created when the view is loaded again. This usually includes properties and instance variables that are outlets (since when the view is loaded, it will load the Xib again and re-connect the outlets to new objects), as well as any variables that are set in viewDidLoad.
If you coded your program correctly, I can go in there and remove viewDidUnload, and it would not have any effect on the correctness of the program. (Since viewDidUnload is almost never called anyway.)
You should almost never have to use didReceiveMemoryWarning either.
Related
I am starting a new project (without ARC) targeting iOS 6. From Apple doc:
Use this method to deallocate all noncritical objects associated with
your view controller. On iOS 6, you can also use this method to
release references to view objects.
My question is after we deallocate "noncritical objects" within didReceiveMemoryWarning, when can we reinstate the "noncritical objects" again ?
I am asking this because since viewDidUnload will never be called in iOS6, I reckon that viewDidLoad will not be called the second time before program termination. Am I right on this?
Use lazy loading for your non-critical data. Clear up this data in didReceiveMemoryWarning. Then the data will be lazy loaded again the next time you try to access it.
I recently migrated an existing Cocos2D project from version 0.8 to 2.0 & enabled ARC.
The way I did it is by Apple's empty application template & then adding the code from the Cocos2d 2.x template since it has major changes. After that I added code from the game & made the necessary changes for the deprecated code & for the ARC issues.
Since that the game is working but not as expected, I had no animations & the game was taking the whole CPU power. From the console I saw that everything gets dealloc-ed right after it's creation. My old code is not the reason for that because it even happens before any of my scenes gets pushed.
EDIT
I also repeated again the whole process & made an ARC-enabled version from the Cocos2D template project, but the same there too.. Is that a normal thing maybe?
That's not normal, although common problem when converting to ARC. ARC will release objects out of scope, whereas under MRC an alloc/init object would stay in memory (and leak). Check where you may need to keep a strong reference.
Here's an example that worked before converting to ARC:
-(void) someMethod
{
id object = [[MyObject alloc] init];
}
Under MRC, object stays in memory (leaks) after someMethod returns. Under ARC, ARC cleans up the object when the method returns. The simplest fix is to turn object into an ivar (aka instance variable, member of class).
Also check singletons. Depending on how its implemented, the Singleton class might dealloc right away. For example if the static instance is declared __weak or __unsafe_unretained.
You should also run the Xcode Analyzer (Build -> Analyze) to get pointers for potential issues.
I'm fairly new to ARC for iOS (and pretty new to iOS in general) and I have a few quick questions about ARC.
~ In a View Controller, if I do not have statements in my viewDidUnload() method setting my properties to nil, will the properties' memory still be freed when my view controller is released? If so, why do I need to explicitly have this viewDidUnload method?
~ In objects that are not View Controllers, where should I set the properties to nil at? In dealloc? What about primitive properties such as #property BOOL isActive;...do I need to set them equal to nil/zero?
Thanks.
You don't need to set your properties to nil as long as they're weak references. IBOutlets should generally be weak references, since they the view controller contains a strong reference to the view, which in turn contains strong references to all of its subviews. (If you have IBOutlets that aren't part of that view hierarchy, they should be strong.)
You shouldn't need nil or zero anything, objects or scalars. Xcode will insert nilling statements when working with Interface Builder, but this is it still generating code for pre-ARC Objective-C.
You probably don't even need a viewDidUnload; it's only called in special circumstances, when there's low memory stress. Thus, you can't depend on it for cleaning up. Your IBOutlets should be weak, so they'll be cleaned automatically when the view is purged from the viewcontroller (and they'll be restored if the view is reloaded).
I'm assuming here that you're writing a new product, which means you're targeting iOS 5 or later only. If you're targeting iOS 4 in a new product, you really shouldn't be. The world has moved on, with 80% of the market on iOS 5 or later. And that's today. Going forward, it's going to be even harder to avoid iOS 5 features for an even smaller percentage of people.
Memory management for #properties is handled automatically under ARC. For times when you have set yourself as delegate, it is common to set the delegate to nil before going away (in viewWillDisapear for instance) so that future calls to delegate don't reference garbage. Stay tuned for the soon-to-be-posted WWDC videos for the latest guidance.
In viewDidUnload you need to set outlet references to nil, because ARC will release them and you do not want to accidentally use them after that happens.
You don't have to do anything with properties, they will be handled automatically. In fact you really do not normally even have a dealloc method any more with ARC.
Using xcode 4.2 for iPhone app, without ARC ---
When I create an outlet using the interface builder xcode adds two lines of code to my viewController. One in viewDidUnload: -- [self setMyOutlet:nil] and second in dealloc -- [myOutlet release].
I understand the latter (the release). But why set the outlet to nil in viewDidUnload. Doesn't viewDidUnload get called before dealloc and won't setting the outlet to nil negate the release operation in dealloc? Setting to nil makes sense I would think for building a Mac application which is using garbage collection -- but it doesn't make sense for an iPhone app.
Why does the interface builder do this? Should I delete the lines which set the outlets to nil?
viewDidUnload may be called and may be not called. It depends on the current memory usage. dealloc is a place where you should clean all your properties (like arrays, custom objects). In viewDidUnload you clean views and perhaps objects created to support the view. viewDidUnload mean that your view is unloaded (but not whole view controller) and it may be created and loaded again (in viewDidLoad, of course) in the future.
Why to nil - Objective-C Difference between setting nil and
releasing
Understanding How Views Are Loaded and
Unloaded
viewDidUnload is not called everytime before a dealloc, see what the apple docs say..
When a low-memory condition occurs and the current view controller’s
views are not needed, the system may opt to remove those views from
memory. This method is called after the view controller’s view has
been released and is your chance to perform any final cleanup. If your
view controller stores separate references to the view or its
subviews, you should use this method to release those references. You
can also use this method to remove references to any objects that you
created to support the view but that are no longer needed now that the
view is gone. You should not use this method to release user data or
any other information that cannot be easily recreated.
so the idea behind it is too release any unwanted objects which can be created easily.
Now coming to the part where it sets the properties to nil.. it does so because this way you release all the memory and set the objects to nil (thus bringing your down your memory usage) and after this if a dealloc is called your app will not crash as in objective-c you can send release messages to nil objects..
I would advise you to read the apple ViewController Programming Guide , it will clear a lot of your questions.... hoping this clears some of the air.. :D
Not sure why, but making a simple [[NSOpenPanel openPanel] runModal]; creates a memory leak - seen in Leaks Instrument.
Seems off.
It's an auto-released object, shouldn't it be automatically released after ARpool is drained?
Is there a way to fix this?
NSOpenPanel is a singleton, which means you always get the same instance of the object every time you use it. This means that the first time you call [NSOpenPanel openPanel], an instance of NSOpenPanel is created and not released.
This is not a leak, it's an optimisation. However, sometimes the Leaks instrument picks up such once-only instantiations as leaks because the instances are (by design) never released.
NSOpenPanel is such a widely-used and tested class that any leaks in its standard implementation are unlikely to exist.
NSOpenPanel is not a singleton. It may have been at one time but looking at the latest NSOpenPanel.h file makes it explicitly clear it is not a singleton or at the very least Apple doesn't want you taking advantage of this implementation detail.
As for the leak, I was confused on when I should release my open panel and was retaining it. From the Using the Open and Save Panels section of the File System Programming Guide your life is a lot easier in 10.7 and above:
Important: In OS X 10.6 and earlier, you must retain an open panel prior to displaying it and release it when you are done with it. Because the openPanel method returns an autoreleased object, the panel is normally released shortly after it appears on screen. Retaining the panel prevents it from being deallocated and dismissed prematurely. You do not need to retain the panel if it is attached to a window and you do not need to retain the panel in OS X 10.7 and when using ARC.
Once I stopped retaining it things got easier and became a lot easier :)
Instruments is not perfect at detecting leaks - particularly for autoreleased objects, and has a tendency to have false positives. You might try creating a new NSAutoreleasePool, then draining it when you are finished with the NSOpenPanel to force release early - but I suspect you don't actually have a leak. If you are confident that the code looks good and it is autoreleased, then its probably fine.
I was seeing "leaks" reported in Xcode's memory graph tool when using NSOpenPanel in an unsandboxed app built on OS X 10.11.6 using the 10.12 SDK and Swift 3.0.1. The "leaks" were reported in PlugInKit classes (PKHostPlugin, PKDiscoveryDriver, etc.) and would show up even if the only line of code was let openPanel = NSOpenPanel().
NSOpenPanel's documentation states
In a sandboxed environment, Open panels are drawn in a separate
process by the powerbox, not by AppKit itself. When the user chooses a
file to open, macOS adds that file to the app’s sandbox.
After I sandboxed the application, the "leaks" did not show up in Xcode's memory graph as the NSOpenPanel implementation code was no longer in the application's address space, so I no longer had to worry about it.