Well, my code doesn't show things being allocated and assigned to the
IBOutlets, but it shows a bunch of releases of the associated members. As
far as I can gather, the code is now correct. It is this asymmetry that
strikes me as messy and error-prone.
On Mar 20, 2012, at 5:59 PM, G S wrote:
> I'm doing an iPhone app. I'm not doing any Mac app.
>
> I should simply have said "the nib-loading behavior".
Except the nib loading behavior is vastly different on the two operating
systems. This is why the documentation goes into detail about both.
I'm doing an iPhone app. I'm not doing any Mac app.
I should simply have said "the nib-loading behavior".
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderator
On Mar 20, 2012, at 5:33 PM, G S wrote:
> Needless to say, it seems like ARC was a desperately needed step forward.
> I don't mind doing things "the right way" and I have a high tolerance for
> syntactic tedium, but the invisibility of NSNib's usage of properties and
> the resulting asymmetry of
I went through and removed all the IBOutlet notation from the members and
reconnected everything to the properties in IB. Also added release calls
for all the controls in dealloc. The app appears to be quite solid, with
no leaks or analyzer issues detected. I'm calling it done!
Needless to say,
Set breakpoints on them and right after them and when you hit them see:
1) what their values are
2) if they ever get hit at all.
That should help you get to the bottom of what's being used when.
On Mar 20, 2012, at 5:50 PM, G S wrote:
> OK, I think I know why there weren't any leaks.
>
> Per
OK, I think I know why there weren't any leaks.
Per (possibly old) examples, I have "IBOutlet" in both the member-variable
declarations and the property declarations.
Now I'm realizing that IB will show two outlets: one for the member
variable itself, and one for the property when you have this:
Thanks. I didn't know whether they meant weak as a keyword necessarily, or
simply the concept of a weak reference.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the m
The material quoted is post-ARC usage (not the use of "weak" and not "assign").
In the legacy paradigm material, you will see that pre-ARC. You can choose
"retain" or "assign" (or "copy", but I'll leave that out here). iOS outlets
should be held as "retain", and therefore need to be nil-ed in vi
On Mar 20, 2012, at 1:49 PM, G S wrote:
> This just adds more confusion. If the properties for the majority of
> IBOutlets are weak (since they're usually all going to be owned by the
> UIViewController's view), why would we release them in dealloc?
If you aren't using ARC, then you couldn't hav
The Apple doc for iOS says:
"From a practical perspective, in iOS and OS X outlets should be
defined as declared
properties. Outlets should generally be weak, except for those from File’s
Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)
which should be strong. Outlets that
11 matches
Mail list logo
