IOS5 arc,iboutlets should be defined strong or weak

Original posts: http://blog.csdn.net/yiyaaixuexi/article/details/7864974

The reason for writing this article is because I stackoverflow on the post, see a named should iboutlets be strong or weak under ARC? The post is very hot, and I have been adopted as the answer to the standard answers have some words to add, I think for each of the first to know the arc model of the people, will have this question, so may I also come to discuss with you.

Someone asked, under the arc, Iboutlets should be defined as strong or weak? The answer is supported by the largest number of people, with only one excerpt from an official document:

From a practical perspective, in IOS and OS X outlets should is defined as declared properties. Outlets should generally is weak, except for those from File's Owner to top-level objects in a nib File (or, in IOS, a sto Ryboard scene) which should be strong. Outlets that you create would therefore typically be weak by default, because:

• Outlets that you create to, for example, subviews of a view controller ' s view or a window controller ' s window, is Arbitra Ry references between objects that does not imply ownership.

• The strong outlets is frequently specified by framework classes (for example, Uiviewcontroller ' s view outlet, or Nswindow Controller ' s window outlet).

  @property (weak) IBOutlet MyView *viewContainerSubview;@property (strong) IBOutlet MyOtherClass *topLevelObject;

The main idea is that in ARC, the general outlet property is recommended to use weak, and the outlet that should use strong is the top-level object that the File's owner connects to the nib.

What is the File ' s owner attached to the top-level object of the nib? White, the custom view is not directly displayed as a sub view in main view, but is created by instantiation. You instantiate yourself, of course, you need to strong, otherwise who will retain the ownership of the object for you?

The above analysis is not wrong, but always feel that something is missing. For the end is weak or strong, in the final analysis, or to the object of the ownership of the problem, but it is not easy to summarize the simple and understandable rules of use. So, there will be one exception to break the document summary of the general, do not understand the root of the rule is what, or will encounter trouble.

Let me give you a simple example of creating a program entry that points to the navigation controller's project, and the navigation bar with 2 buttons:

The right button controls whether the camera button is displayed or not, and according to the documentation, we define the two buttons as weak properties in the program.

[CPP]View Plaincopyprint?

1. #import
3. @interface Testviewcontroller:uiviewcontroller
4. {
5. BOOL isshowing;
6. }
8. @property (nonatomic,weak) iboutlet Uibarbuttonitem *controlbtn;
9. @property (nonatomic,weak) iboutlet Uibarbuttonitem *camerabtn;
11. -(Ibaction) Controlaction: (ID) sender;
12. @end

Use the right button to control the hiding and display of the camera buttons:

[CPP]View Plaincopyprint?

2. #import "TestViewController.h"
6. @interface Testviewcontroller ()
10. @end
14. @implementation Testviewcontroller
16. @synthesize camerabtn,controlbtn;
20. -(void) viewdidload
22. {
24. [Super Viewdidload];
26. Additional setup after loading the view, typically from a nib.
28. isshowing = YES;
30. }
34. -(void) viewdidunload
36. {
38. [Super Viewdidunload];
40. Release any retained subviews of the main view.
42. }
46. -(BOOL) Shouldautorotatetointerfaceorientation: (uiinterfaceorientation) interfaceorientation
48. {
50. Return (interfaceorientation! = Uiinterfaceorientationportraitupsidedown);
52. }
56. -(Ibaction) Controlaction: (ID) sender
58. {
60. if (isshowing) {
62. Self.controlBtn.title = @ "Show camera";
64. Self.navigationItem.leftBarButtonItem = nil;
66. isshowing = NO;
68. }else {
70. Self.controlBtn.title = @ "Hide Camera";
72. Self.navigationItem.leftBarButtonItem = camerabtn;
74. isshowing = YES;
76. }
78. }
80. @end

The experimental result is that the first time the camera button is hidden, it is no longer visible. The reason is simple, camerabtn point to empty, we lost camerabtn object ownership.

There are two ways to solve a problem:

1. Do not drag the camera button on the Xib or storyboard, but instead use the code to create and control the ownership of the object

2. Define CAMERABTN as Strong

I want to emphasize of course is the second method, of course, after changing to strong, corresponding also need to cooperate with ARC to do the next work:

[CPP]View Plaincopyprint?

1. -(void) viewdidunload
2. {
3. [Super Viewdidunload];
4. Release any retained subviews of the main view.
5. SELF.CAMERABTN = nil;
6. }

By the way, the rules for other ARC properties:

• Strong: Equivalent to "retain", property becomes owner of object

• Weak: property is weak pointer and automatically set to nil when object is disposed

• Unsafe_unretained: Equivalent to the previous "assign", only IOS 4 should be used

• Copy: Copy an object and create a strong association as in the previous copy

• Assign: The object cannot use assign, but the original type (BOOL, int, float) can still be used

The last sentence, memory rules, understand the rules, make good use of the rules.