mentby.com
Blog | Jobs | Help | Signup | Login

loading

Notification Block Retain Cycle

Mon, 17 Dec 2012 09:06:36 -0800 Post Comments

The ARC migration docs ( http://developer.apple.com/library/mac/#releasenotes/Objecti[..] ) recommend the following pattern (which I've extended to your situation):

@implementation MYObject
{
    id observerReference;
}

- (id)init
{
    if ((self = [super init]))
    {
    __weak MYObject *weak_self = self;

        observerReference = [[NSNotificationCenter defaultCenter] addObserverForName:MYCoolNotification object:nil queue:[NSOperationQueue mainQueue] usingBlock:^ (NSNotification *note) {
            MYObject *strong_self = weak_self;
            if (strong_self) {
                [strong_self someMethod];
                strong_self->someIvar = someValue;
            }
        }];
    }
    return self;
}

- (void)dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:observerReference];
}

@end

This prevents the block from taking a retain on "self" by having it capture a weak reference instead, which breaks the retain cycle. The subsequent assign to and use of "strong_self" prevents the weak reference from being deallocated out from under you during the block's execution. As a consequence, you must not refer to "self" within the block, even implicitly by ivar access. Methods called by the block can continue to refer to self normally. This code is thread-safe for the effects observable here (though obviously I can't say anything about what your notification handler is actually doing).

-- Gwynne Raskind

Making _objc_rootAutorelease public

Tue, 07 Aug 2012 15:53:58 -0700 Post Comments

Because it's all tied up in the runtime now, isn't it? Especially with
ARC doing its own autoreleases, if there's a runtime function for
doing something, you want to use it.

-- Gwynne

Object Literals

Fri, 23 Mar 2012 15:58:18 -0700 Post Comments

I believe that Objective-C shouldn't be afraid to tie itself to a
framework, but that 1) that framework should be as tiny as possible,
the absolute minimum to support the language structure, and 2) that
framework should be distributed with and considered part of the
language itself, as happened with the C++ STL (<further thoughts on
C++ redacted>). Implementations that can do something "better" on a
given platform (such as Foundation) can override, replace, or
supplement that core, but the basic interface should always be there
(so for example, in Foundation's case the NSString object would be a
thin wrapper over, subclass of, or even an alias for OCString).

It's fine for simple things like numeric literals, string literals,
ordered collection literals, and keyed collection literals to be
considered fundamental to a language, and therefore defined by it, as
long as it doesn't get out of hand. No high-level, object-based (or
object-capable) language doesn't have a basic library that's just
assumed to be there no matter the platform - C# has the System
namespace, Java has java.*, C++ has STL (for better or for worse), Lua
has its semi-builtin functions for introspection, PHP has a "stdClass"
object and the array functions, etc. etc. ad infinitum.

-- Gwynne

Read more »

Profile Widget
Copy and paste this HTML code to your blog or website: