3

OK - newbie Objective-C question:

When declaring properties there are attributes such as below:

@property (weak, nonatomic)

I realize I need read up on this to fully understand it but most of what I found was reference material, so a link to a good article that could explain best practices / usage scenarios (when to use which attribute for primitives, reference types, outlets, etc) or a couple of examples would be appreciated.

Thanks!

AlexVPerl
  • 6,653
  • 5
  • 36
  • 74
  • 3
    atomic vs nonatomic: http://stackoverflow.com/questions/588866/atomic-vs-nonatomic-properties – justin Aug 22 '12 at 19:29

3 Answers3

3

Even though it is waaaay to late for an answer i've found this question while googleing the same issue and also found this article by apple which explains the whole thing perfectly.

Hope it helps to anyone who are researching the same thing,

http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html

Berker Soyluoglu
  • 198
  • 1
  • 14
2

From a recent class I gave on this (inspired by Paul Hegarty)

nonatomic - NOT thread safe see link Justin pointed out in the comments above.

strong (or retain) - keep this object allocated until I don’t point to it anymore (set it to nil). Compiler will also throw this out of the heap (deallocate it) if I am not pointed to strongly anymore (I get dealloc’d)

weak - keep this object allocated as long as something still points to it strongly. IBOutlets are usually declared as weak since they will be retained automatically by the view controller.

Primitive types are not allocated on the heap and don't use strong or weak

Community
  • 1
  • 1
LJ Wilson
  • 14,327
  • 5
  • 34
  • 57
  • This is great, quick question on the 'weak' explanation: I didn't quite get the part where you mention "..keep this object allocated as long as something still points to it strongly", if there's a reference to an instance shouldn't ARC detect that keep that in memory anyways? – AlexVPerl Aug 23 '12 at 14:44
  • For example, an IBOutlet (say a UILabel) is declared weak because it will be retained ONLY as long as some other object has a strong reference to it. In the UILabel case - the parent UIView keeps a strong reference to it and so the compiler will keep it retained only as long as the parent UIView is retained. Once the view unloads or gets deallocated some other way - the UILabel is dealloc'd too. – LJ Wilson Aug 23 '12 at 15:40
1

Atomicity has to do with threading, and is a pretty advanced topic for a newbie. The short answer, however, is that iOS properties are always declared as nonatomic. Here's some more detailed information about it.

The weak/strong keyword has to do with memory management with ARC and preventing what's called a retain cycle. This can also be a bit of a tough concept for a newbie, but the high-level overview is that a retain cycle happens when two objects have strong references to each other and thus neither object will be destroyed by ARC. This is a form of a memory leak, as you may have an object that's no longer in use but is still taking up memory. By declaring a property as weak, it will ensure that it's not automatically destroyed so long as something still has a strong reference to it. For instance, let's say you have an array with a couple of objects in it. Two of the objects have strong references to each other. Then, the array loses its owner and is destroyed. BUT, the two objects in that array that point to each other are NOT destroyed since they have strong references. Thus, you have two objects which you cannot access since the owning array is destroyed, but they're still taking up memory.

Community
  • 1
  • 1
  • I said I was a newbie to Objective-C not a newbie to programming :) – AlexVPerl Aug 23 '12 at 14:30
  • Thank you for your answer, this explains the weak/strong part very well! I'm quite familiar with concepts of threading, atomic vars and reference/value types, just trying to make sense of language semantics. – AlexVPerl Aug 23 '12 at 14:37