I have view control with five button i am setting there properties also is it necessary to release them in dealloc thanks
#interface MainViewController : UIViewController{
IBOutlet UIButton*homeButton;
IBOutlet UIButton*economicDataButton;
IBOutlet UIButton*riskButton;
IBOutlet UIButton*financialImpactButton;
IBOutlet UIButton*probabilitiesButton;
IBOutlet UIButton*enterButton;
}
in ARC you don't have to. the system does it for you. but if you are not using arc then you may do it. even when i use arc or partial arc just for a few classes i still do it. i guess i'm a paranoid coder.:)
EDIT:
well if it is your project and you started it then you must check the box at the beginning for using automatic reference counting or not checking it. if you are using a sample project from someone else then go the target level of your project. then you go to built phases and expand that and see if this phrase is in front of anyone of them. -fobjc-arc. that is for the projects that started without arc and then arc was added to some classes. on the hand if the entire project is arc enabled just declare a iboutlet and try to synthesis it and project will give you an error asking for storng or weak reference. that's how you know that entire project is arc enabled.
happy coding my friend
Related
I have dilemma about Memory releasing IBOutlet object.Do anyone please suggest what to do when we create IBOutlet object without property, need to release it?? if need to release... why we are releasing it
The answer is YES.
The runtime connects the objects to IBOutlet using [setValue:ForKey:]. This function will find the private instance variables, retain the target and set it to the instance variable. Please visit here iOS Developer Library to know more.
I highly recommend you to read the article because many iOS framework accesses properties by Key-Value compliance ([setValue:ForKey:] or [valueForKey:]), instead of directly calling getters/setters/instance variables.
IBOutlet does not change the ownership semantics of properties. If you do not use ARC you have to release retained objects as with any other property.
Just Set it to default, which is "Weak". Then you are fine with ARC.
Why not just have a private IBOutlet property, to make things clearer and more explicit. I always do this personally:
MyClassName.m
#interface MyClassName ()
#property (nonatomic, weak) IBOutlet NSObject *myPropertyNameForAnOutlet;
#end
#implementation MyClassName
...
#end
You are not the owner of that object. so no need to release IBOutlet object.If you are using #property (nonatomic, retain) on IBoutlet object then you must release that object in dealloc.
Take a look at Advanced Memory Management Programming Guide
You must not relinquish ownership of an object you do not own
Answer is YES...
i was confused about that too, but try this:
open a xib file
onen assistant editor window and get the .h file code near your XIB IB file
chose an object in IB file (an object with no reference to any var)
ctrl click on it and chose: "new reference outlet" button
drag the line to your .h code file in the #interface{ } section
give a name to your new var ("aaa")
(note that no property "aaa" is created)
now Xcode has done all the magic for you, and...
in .m file you can find, in dealloc method:
- (void) dealloc {
[aaa release];
[super dealloc];
}
so... if apple release it, it seems that the default IBOutlet vars loaded via XIB file are retained...
EDIT:
here's the point in apple doc:
You are not the owner of the object, therefore you do not release it.
You become the owner by retaining, copying or creating (init/alloc) an object. Only then you are you (one of the) owner(s) of the object, and need to release it when you are done with the object. Fore more info check
Cocoa core competencies - Memory Management
I hope this explains why you do not have to release the object.
Even though you didn't set it as property, the property is refer to setter and getter methods. When you use an object you should always remember to release it. The property is unrelated with memory issue.
I have been developing for iPhone from last 1-2 months and all the time for taking IBOutlet I use the following method to declare any property:
In .h files:
#interface ....
{
controlType varName;
}
#property() IBOutlet controlType varName;
In .m files:
at top -#synthesize varName;
in delloc method - [varName release];
Although the method is good but it isn't very good when its taking a couple of minutes just for declaring property.
Is there any automatic process for declaring properties, IBOutlets, IBActions or basic data variables.
I hope there should be some automatic methods for this scenario as this is a very basic process.
Thanks all.
Another one that not many people are aware of is that you can drag from Interface Builder to your header file to create IBActions or IBOutlets.
NOTE: Open the Assistant Editor with focus on the XIB inside IB.
If you create your IBOutlets this way Xcode automatically adds the property, synthesizes it, sets it to nil in viewDidUnload and releases it in dealloc.
You simply drag from the IB object to your header file the same way you would when creating connections between the view objects and their file owners (screenshot below).
In fact, yes!
You no longer need to declare the actual iVar.
In short, simply leave out this part: controlType varName;
For now, you do still need to explicitly "synthesize".
(As far as I can see, they could possibly automate that in the future. But for now you have to "synthesize" to create the setter and getter.)
You do still have to release the memory - there's really no way that could be automated, as memory handling is "real he-man programming."
For any new chums reading, don't forget the "self." part when using the property.
Plus note that XCode4 even has a new automatic thingy. Simply drag from the interface builder, to your .h file, and it will do everything for you -- try it!
In answer to your suplementary question: An IBOutlet DOES NOT PARTICULARLY NEED TO BE a property - you can just use a normal cheap iVar. On the other hand, if you wish, to you can use a property. Furthermore: you can even use the new trick (2011) of not bothering to declare the ivar, just use the property declaration, and shove an IBOutlet in there!
There is an awesome tool that speeds the whole process up: accessorizer.
You write controlType varName; select it and press some buttons and accessorizer will create the property, init, dealloc, viewDidUnload and much more for you. You just have to paste the code into your project.
Try it, a demo is available.
You can save yourself having to release the object by changing the property declaration. If you use:
#property (assign) IBOutlet controlType varName;
retain wont be called on your view so you wont have to release it later. This is generally safe as views are retained when they are added to a parent. If you are removing the views from their parent for some reason then you will have to retain them.
Here's an xcode script to automate the tedium of declaring properties.
I'm trying to build a simple TableView program struture.
It seems to work fine, but if I scroll the list to high or to low, the app crashes without any console error and the trace into the debugger does not help.
You can see it by yourself looking at the project I put at : http://shine.free.fr/tmp/myTestApp.zip
Can you help me :
to know what goes wrong
to know how I may find what goes wrong without having to ask each time. Usually I check my connection, lokk for compile errors, look into the console and try to debug, but there, nothing helps me.
Thank you for your help
The problem is that your ListController object is not retained when it is loaded from nib file, so it is not guaranteed that it will be valid after nib is loaded (and in fact it is not). To solve your problem add an outlet for ListController property and define retaining property for it. Here's FenetreListeController.h that fixes your problem:
#import <UIKit/UIKit.h>
#class ListeController;
#interface FenetreListeController : UIViewController {
IBOutlet ListeController* listController;
}
#property (nonatomic, retain) ListeController* listController;
#end
You will also need to set outlet connection in IB and synthesize property in .m file
For more information about how objects are loaded from xib files check "The Nib Object Life Cycle" section from "Resource Programming Guide"
While coding always the same questions concerning retain counts of IBOutlets came along: Retain count after unarchiving an object from NIB? When to use #property's for an IBOutlet? Retain or assign while setting? Differences between Mac and iPhone?
So I read The Nib Object Life Cycle from Apple's documentation. Some test apps on Mac and iPhone gave me some strange results. Nevertheless I wrote down a few rules how to handle this issue to stay happy while coding but now wanted to verify with the community and listen to your opinions and experiences:
Always create an IBOutlet for top-level objects. For non-top-level objects if necessary (access needed).
Always provide a property as follows for IBOutlets (and release them where necessary!):
Top-level objects on Mac:
#property (nonatomic, assign) IBOutlet SomeObject *someObject;
#synthesize someObject;
[self.someObject release];
Non-top-level objects on Mac (no release):
#property (nonatomic, assign) IBOutlet NSWindow *window;
#synthesize someObject;
Top-level objects on iPhone (must retain):
#property (nonatomic, retain) IBOutlet SomeObject *someObject;
#synthesize someObject;
[self.someObject release];
Non-top-level objects on iPhone (should retain):
#property (nonatomic, retain) IBOutlet UIWindow *window;
#synthesize window;
[self.window release];
Side notes:
On Mac and iPhone outlet connections are made with a setter if available.
Top-level objects: "have [...] no owning object"
Non-top-level objects: "any objects that have a parent or owning object, such as views nested inside view hierarchies."
So the question would be: is this correct and good practice?
I hope you can approve or correct it.
Always have your nibs' File's Owner be a subclass of NSWindowController or NSViewController (on Mac OS X) or UIViewController (on iPhone), and use #property (retain) IBOutlet for all of its outlets, doing appropriate releases in your controller subclass -dealloc method.
This pattern will work fine on both Mac OS X and iPhone OS, because NSWindowController and NSViewController on Mac OS X take implicit ownership of top-level objects for you (and relinquish that in their own -dealloc methods), and iPhone OS doesn't take any implicit ownership of top-level objects for you during nib loading.
Top-level objects: "have [...] no owning object"
Nix. Top-level objects are owned by the File's Owner, which is the File's Owner because it owns all the top-level objects in the file.
Windows have that option to release themselves as a convenience, but I find my design cleaner (even if it's a little more work) when I either turn it off and manage its lifetime myself, just like any other object I own, or use a window controller.
If you think this conflicts with the documentation you were quoting, let's go through the entire paragraph:
Objects in the nib file are initially created with a retain count of 1. As it rebuilds the object hierarchy, however, AppKit autoreleases any objects that have a parent or owning object, such as views nested inside view hierarchies.
Thus killing off its own ownerships. The nib loader doesn't want to own your objects.
By the time the nib-loading code is done, only the top-level objects in the nib file have a positive retain count and no owning object. Your code is responsible for releasing these top-level objects.
In other words, it's handing the ownership over to you.
The curious artifact of that is that you'll actually leak the object if your property to it has retain semantics. The documentation says you should retain it:
For both Mac OS X and UIKit, the recommended way to manage the top-level objects in a nib file is to create outlets for them in the File’s Owner object and then define setter methods to retain and release those objects as needed.
But if you do this, the object will remain alive even after you release your ownership of it.
I think I'll go file a bug about this. (Edit: Done. x-radar://problem/7559755) At the very least, the nib loader shouldn't be handing off two retentions, which it does in my test app (on 10.5.8 and 10.6.1).
From apple's doc mentioned above:
For both Mac OS X and UIKit, the recommended way to manage the top-level objects in a nib file is to create outlets for them in the File’s Owner object and then define setter methods to retain and release those objects as needed. Setter methods give you an appropriate place to include your memory-management code, even in situations where your application uses garbage collection. One easy way to implement your setter methods is to create a declared property (using the #property syntax) and let the compiler create them for you. For more information on how to define properties, see The Objective-C Programming Language.
Otherwise use #property(nonatomic, retain) IBOutlet * outletName;
I can write my opinion about iPhone NIB development:
If you use IB then use as many IBOutlets as possible (sometimes you don't know the views hierarchy when you build a NIB - it may be dynamic) or don't use them at all - otherwise there will be a mess
Use properties only if you want to access the views from outside the View Controller (if they should be public)
AFAIK there's no need to manage memory for IBOutlets
Hope it helps...
You should follow standard memory management guidelines. If your outlet is connected to a retained property, then you must release it in the -dealloc message.
And yes, you any top level objects not retained by any other objects usually need to be retained by yourself.
1) In general, why would you have a top-level object with no IBOutlet to point to it anyway? That requirement has never seemed very restrictive.
2) I think you got the settings about right for the iPhone. You can also use an assign property on the iPhone as well, which does what you would expect... but in general after a lot of use I prefer to use retain properties so I am 100% clear on when I consider the object released (especially with the viewDidUnload method to implement).
Also, just as a side note it's not good form to call [self.property release]. That leaves the reference intact but potentially invalid, if something else ever also releases the object... either say self.property = nil, or (better) set the underlying class variable to nil directly without using properties in dealloc statements (to avoid any possible side effects in dealloc).
As I mentioned in response to another poster, you can keep things clean by using IBOutlet properties declared in private class-local category extensions so they are not public properties. That looks like:
// in .m file
#interface MyClass ()
#property (nonatomic, retain) IBOutlet UIView *myPrivateView;
#end
#implementation MyClass
#synthesize myPrivateView;
.....
I am pretty new to iphone programming therefore I apologize if my question could result trivial or obscure.
In many examples and tutorials I have seen that in the declaration of the outlets within Xcode (interface section of the view controller) the keyword "IBOutlet" is used or it is not, in conjunction with the class the outlet belongs to, apparently without a relevant difference.
e.g.
IBOutlet UIButton * myButton;
or
UIButton *myButton;
I have seen by myself in my experiments that both ways seem to work the same (provided that in both cases I set the proper connections in IB, and declare the property and synthesize it)
Anyone could tell me if there is a relevant difference and different behavior between the two statements?
Thank you
IBOutlet is defined the following way:
#define IBOutlet
So it has no impact on the running code, and its only purpose is to allow Interface Builder automatically determine it while parsing class header. Without IBOutlet keyword in header you will need to declare it in IB Inspector's Identity tab to make it avaliable to be connected to interface elements.