Should IBOutlet be weak?

Question

Possible duplicate:
Should IBOutlets be strong or weak in ARC?

I read briefly about ARC and thought, everything is strong, and the delegate is weak.

Now I create a view in the interface builder and do IBOutlets, and the default value for Xcode is set to "weak".

There seems to be a reason for this proposal, is there a reason most IBOutlets would like weak property?

Is it because these views (IBOutlets) are already saved, because they are tied to its superwin? and we rarely replace IBOutlet views?

But I see no harm in establishing it as strong, is there a problem with it?

Answer 1

For a discussion of why IBOutlet links should be weak, see Resource Programming Guide: Nib Files . I quote the manual:

Sockets should usually be weak, except for those that belong to the file owner, for the top-level objects in the nib file (or in iOS, storyboard scene), which should be strong. Therefore, the videos you create should be weak, because:

• The outputs that are created for viewing in the view of the view manager or window windows, for example, are arbitrary links between objects that do not imply ownership.
• Strong sockets are often defined by wireframe classes (for example, UIViewController s view outlet or NSWindowController s).

For my two cents, I do things strong if I own it, or I need a strong link if the owner leaves, and I need it to be saved, none of which apply here. Therefore, instead of asking, “Why can't I make it strong ?”, I would ask, “Why do I want to make it strong ?”? If there is no good reason for this, I would let Interface Builder do this and make it weak .

Answer 2

This is just a preference. The rationale for weak or assignment is that supervisors, controllers, etc. Will contain strong references during the life of the object in this column.

Personally, I am an old school and prefer strong links - even in this scenario. Sometimes using strong links means that you may need to explicitly destroy the subgraph components of your objects (for example, you must “break” all circular dependencies when breaking). I take advantage of the weak in exceptional circumstances because I prefer consistency; There are fewer variables when playing, when / if when something goes wrong and when reading programs.