On Nov 17, 2008, at 9:33 PM, Jeff Laing wrote:
How about:
http://developer.apple.com/samplecode/CacheInfo-MacOSX/listing1.html
(for example) which has the IBOutlet tag on the instance variables
rather than the properties; I'll bet its different because properties
and instance vars have the
On Nov 19, 2008, at 3:59 AM, mmalcolm crawford wrote:
On Nov 18, 2008, at 10:01 AM, Brian Stern wrote:
OK Erik, I'll bite. What you describe above is correct as far as
it goes. However, when you say all the memory management is
handled in one place, of course it's two. The object has
On Nov 19, 2008, at 7:00 AM, Brian Stern wrote:
This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is in
many respects academically unsatisfying.
(b) For non-top-level-object, specify an assign attribute for the
property -- and risk
On Nov 19, 2008, at 10:29 AM, Greg Titus wrote:
On Nov 19, 2008, at 7:00 AM, Brian Stern wrote:
This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is
in many respects academically unsatisfying.
(b) For non-top-level-object, specify an
On Nov 19, 2008, at 10:13 AM, Brian Stern wrote:
I think that you're probably right and that it's redundant.
Needless to say, mmalc's best practice has the outlets being
released in dealloc. That's why I had that code there in the first
place.
FWIW, I don't think that UIViewController
But if your dealloc is like this...
- (void)dealloc
{
self.thisProp = nil;
self.thatProp = nil;
...
}
then you'll be calling the accessors and the right thing will happen
(i.e. release if necessary). This is what I currently do for all dev
work (iPhone or Mac OS X).
On Nov 19, 2008, at 4:41 PM, Ricky Sharp wrote:
From Apple's template code, didReceiveMemoryWarning does have these
code comments generated:
[super didReceiveMemoryWarning]; // Releases the view if it doesn't
have a superview
// Release anything that's not essential, such as cached
On Nov 19, 2008, at 7:00 AM, Brian Stern wrote:
There are competing issues. Following this best practice forces me
to add public properties for all my outlets that my code never
uses. This violates encapsulation and seems wasteful and error-prone.
No, it's not. The nib-loading
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that best practices
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
That is indeed correct. The official guideline is, AFAIK, to not call
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that best practices
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
Correct.
(This is the one thing I hate the *most* about properties - they
On Nov 19, 2008, at 5:11 PM, j o a r wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that best practices
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
That is indeed correct. The
On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford [EMAIL PROTECTED] wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
(This is the one thing I hate the *most* about properties - they really
feel glued on, at this point, rather than being a language feature that
the whole compiler knows
On Nov 19, 2008, at 2:22 PM, Brian Stern wrote:
That is indeed correct. The official guideline is, AFAIK, to not
call through your properties in init / dealloc.
For whatever reason UIViewController sets its view property to nil
from its dealloc method. Greg's override of setView is based
On Nov 19, 2008, at 2:29 PM, Michael Ash wrote:
On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford [EMAIL PROTECTED]
wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
(This is the one thing I hate the *most* about properties - they
really
feel glued on, at this point, rather than
On Nov 19, 2008, at 1:57 PM, Brian Stern wrote:
I'm starting to think that maybe using the assign properties is the
better way to handle this.
That's certainly one approach, and one that was considered.
The problem is that you then have to think through every outlet
declaration to make
On Nov 19, 2008, at 4:11 PM, j o a r wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that best practices
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
That is indeed correct. The
On Nov 19, 2008, at 3:05 PM, Ricky Sharp wrote:
Now, when you say call through your properties in init/dealloc, is
that explicitly for things set up with @property? Or, has what I've
been doing all these years with calls to accessors in init/dealloc
really bad?
There's no difference
On Nov 19, 2008, at 2:29 PM, mmalcolm crawford wrote:
You send a release message to instance variables for which there is a
corresponding retain or copy property.
which is why I originally said:
(This is the one thing I hate the *most* about properties - they
really feel glued on, at this
On Wed, Nov 19, 2008 at 5:41 PM, mmalcolm crawford [EMAIL PROTECTED] wrote:
On Nov 19, 2008, at 2:29 PM, Michael Ash wrote:
On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford [EMAIL PROTECTED]
wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
(This is the one thing I hate the *most*
On Nov 18, 2008, at 2:12 AM, Jonathan Hess wrote:
Which parts do you feel are contrary? I'm guessing it's that outlets
with no setters are retained.
Yes, that's the root of the whole issue. The fact is that outlets
without setters that are retained aren't released by the code that
If you write correct accessors for all outlets, then the retain/release memory
management is entirely handled in one method. the -set retains the new value
and releases the old value.
Any confusion regarding memory management for IB outlets seems to stem from
failure to write the accessors
On Nov 18, 2008, at 9:15 AM, Erik Buck wrote:
If you write correct accessors for all outlets, then the retain/
release memory management is entirely handled in one method. the -
set retains the new value and releases the old value.
Any confusion regarding memory management for IB outlets
Brian,
The way to handle this is to _not_ respond to memory warnings in
subclasses (at least not for the purposes of view outlet handling -
there may be other non-view memory you want to free up in response to
a memory warning). Instead, implement -setView: in your
UIViewController
Thanks Greg,
That does work and has no bad side effects. I can leave in the retain
properties and release the outlets in the view controller's dealloc
method.
Thanks,
Brian
On Nov 18, 2008, at 1:19 PM, Greg Titus wrote:
Brian,
The way to handle this is to _not_ respond to memory
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a UIViewController whose view
is released in
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
OK, this issue has come up for me very recently. It appears that on
iPhoneOS IBOutlets are retained, regardless of the presence of
properties. Even worse, in the presence of an assign property the
outlet is still retained. Whatever code
On Nov 17, 2008, at 10:17 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
OK, this issue has come up for me very recently. It appears that
on iPhoneOS IBOutlets are retained, regardless of the presence of
properties. Even worse, in the presence of an
On Nov 17, 2008, at 10:53 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 7:46 PM, Brian Stern wrote:
On Nov 17, 2008, at 10:17 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
OK, this issue has come up for me very recently. It appears that
on
OK, this issue has come up for me very recently. It appears that
on iPhoneOS IBOutlets are retained, regardless of the presence of
properties. Even worse, in the presence of an assign property the
outlet is still retained. Whatever code is retaining the outlets
never releases them.
On Nov 17, 2008, at 11:05 PM, Roland King wrote:
OK, this issue has come up for me very recently. It appears
that on iPhoneOS IBOutlets are retained, regardless of the
presence of properties. Even worse, in the presence of an
assign property the outlet is still retained. Whatever
On Nov 17, 2008, at 8:15 PM, Brian Stern wrote:
When you say I can manage the outlets any way I like this is wrong.
They are managed for me. I want them to not be retained. I don't
have that option.
I never said this. I compared having objects unarchived from a nib to
being alloc'd,
On Nov 17, 2008, at 8:17 PM, Brian Stern wrote:
I think it makes more sense to release the Outlets in viewDidLoad.
Why would you be releasing outlets when the view just loaded?
Generally releasing happens when you're ready for something to go
away
On Nov 17, 2008, at 11:20 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 8:17 PM, Brian Stern wrote:
I think it makes more sense to release the Outlets in viewDidLoad.
Why would you be releasing outlets when the view just loaded?
Generally releasing happens when you're ready for
Yes, but this is exactly the point. If I have no property for an
Outlet it's still retained. If I have a property for an outlet that
is assign, and not retain the outlet is still retained, and I still
must release it, even though I never retained it.
When you say I can manage the
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a
On Nov 17, 2008, at 11:35 PM, Roland King wrote:
Yes, but this is exactly the point. If I have no property for an
Outlet it's still retained. If I have a property for an outlet
that is assign, and not retain the outlet is still retained, and I
still must release it, even though I
On Nov 17, 2008, at 8:05 PM, Roland King wrote:
The iPhone version of nib unarchiving and hookup seemed very
consistent to me, it makes use of properties or setFoo: if you have
them, allowing you to manage objects any way you like.
This applies to both iPhone and Mac OS X/desktop.
This
On Nov 17, 2008, at 8:17 PM, Brian Stern wrote:
I think it makes more sense to release the Outlets in viewDidLoad.
This way I only have to release them in one spot, not two.
No, it doesn't.
There is no sense at all in releasing outlets in viewDidLoad.
Follow the pattern I described and
On Nov 17, 2008, at 8:34 PM, Brian Stern wrote:
Don't you find it odd that you need to release outlets in
didReceiveMemoryWarning?
Not at all -- assuming that you have a reference -- strong or weak --
to an item in the user interface, you want to make sure you break it
if the view is
On Nov 17, 2008, at 11:51 PM, mmalcolm crawford wrote:
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
Brian Stern wrote:
On Nov 17, 2008, at 11:35 PM, Roland King wrote:
Yes, but this is exactly the point. If I have no property for an
Outlet it's still retained. If I have a property for an outlet
that is assign, and not retain the outlet is still retained, and I
still must
On Nov 17, 2008, at 9:10 PM, Brian Stern wrote:
I simply don't need properties for all my Outlets, except for this
issue. I also don't really like making all my outlets implicitly
public. But I'm forced to do that.
You can use the readonly option for your properties. Alternatively,
On Nov 17, 2008, at 9:11 PM, Roland King wrote:
I'm a bit limited at work, no Mac here, so I took a look with
wordpad .. how nice.
You've defined the actual label pointers as IBOutlet, like this
IBOutlet MyLabel* mLabel1;
and then called the properties label1 etc.
in your .h file. When
On Nov 17, 2008, at 8:53 PM, Brian Stern wrote:
Here's my test project:
http://bellsouthpwp2.net/b/r/brians99/projects/TestPropertiesAndOutlets.zip
There are three labels that are outlets. One has a retain property,
one an assign property, and the third no property. Unless they are
On Nov 18, 2008, at 12:11 AM, Roland King wrote:
Brian Stern wrote:
On Nov 17, 2008, at 11:35 PM, Roland King wrote:
Yes, but this is exactly the point. If I have no property for
an Outlet it's still retained. If I have a property for an
outlet that is assign, and not retain
If you declare a property:
@property (nonatomic, assign) MyLabel *label1;
but make the connection in IB to mLabel1, then the property accessor
isn't used. So the outlet is set using setValue:forKey:. Which
results in the value being retained, precisely as described in the
On Nov 17, 2008, at 10:12 PM, Brian Stern wrote:
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a
On Nov 18, 2008, at 12:13 AM, mmalcolm crawford wrote:
On Nov 17, 2008, at 8:53 PM, Brian Stern wrote:
Here's my test project:
http://bellsouthpwp2.net/b/r/brians99/projects/TestPropertiesAndOutlets.zip
There are three labels that are outlets. One has a retain
property, one an assign
Perhaps the new @property() syntax makes it easy to forget about
object lifetimes because it does the set/get/change automagically.
These days when I add any property I go right to the dealloc method
(and init if I have one) and ensure I've managed that property
before I forget.
Yes, but
On Nov 18, 2008, at 1:11 PM, Roland King wrote:
Brian Stern wrote:
On Nov 17, 2008, at 11:35 PM, Roland King wrote:
Yes, but this is exactly the point. If I have no property for
an Outlet it's still retained. If I have a property for an
outlet that is assign, and not retain
On Nov 18, 2008, at 12:34 AM, Jonathan Hess wrote:
The solution to a memory leak should never be an unbalanced release.
What I did to fix this was to add all of the properties to all of the
outlets so they'd all be retained through those properties. Then I
added all the releases to all
On Nov 18, 2008, at 12:49 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:35 AM, Jonathan Hess wrote:
Normally instance variables and properties share the same name,
Normally in your code maybe, not mine.
so it doesn't matter to Interface Builder where the 'IBOutlet' text
appears. If
On Nov 18, 2008, at 12:49 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:35 AM, Jonathan Hess wrote:
Perhaps the new @property() syntax makes it easy to forget about
object lifetimes because it does the set/get/change
automagically. These days when I add any property I go right to
the
On Nov 18, 2008, at 12:59 AM, Roland King wrote:
Hey Brian -
Outlets for iPhone OS are established by calling
setValue:forKeyPath:. The behavior of setValue:forKeyPath: is
that if a setter exists, it is called. If a setter does not
exist, the instance variable is looked up and set
On Nov 18, 2008, at 1:14 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:59 AM, Roland King wrote:
Hey Brian -
Outlets for iPhone OS are established by calling
setValue:forKeyPath:. The behavior of setValue:forKeyPath: is
that if a setter exists, it is called. If a setter does not
55 matches
Mail list logo
