• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: KVO - receptionist design pattern
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KVO - receptionist design pattern


  • Subject: Re: KVO - receptionist design pattern
  • From: Kevin Meaney <email@hidden>
  • Date: Sun, 01 Dec 2013 23:22:28 +0000

On 1 Dec 2013, at 18:27, Quincey Morris <email@hidden> wrote:

> On Dec 1, 2013, at 07:26 , Kevin Meaney <email@hidden> wrote:
>
>> This property is mostly changed on a queue that is not the main queue (gcd queues, not NSOperation queues). Everything works as I would like but I'm concerned that it is only working out of luck rather than proper design.
>
> You didn’t actually state the nature of your concern. You’re worried specifically about the problem of triggering a UI update on a background thread? If so, then, yes, you’ve been lucky if it worked.

My concern was that would I be doing a pointless fix, because I missed the note that in some recent OS upgrade someone at Apple decided that when we bind properties in the interface editor that the UI observing of that property should only happen on the main thread. As you pointed out, that is not the case.

>> __weak AppDelegate *weakSelf = self;
>> dispatch_async(dispatch_get_main_queue(), ^
>> {
>>  AppDelegate *strongSelf = weakSelf;
>>  if (strongSelf)
>>    strongSelf.isAgentRunning = isRunning ? @"Yes" : @"No";
>> });
>>
>> But of course this is fine in my simple case, and since this is all I need I'll go with this.
>
> Yes, but why are you taking the trouble to “avoid” a reference cycle when none can be formed? What’s wrong with the simple version?

Your exactly right. Thanks

> It’s no robuster than the “simple” solution. It’s useful when the object modifying the property doesn’t or can’t know whether it’s a background thread — for example, when it’s in a 3rd party library you don’t control. But in your own code, you can always use [NSThread isMainThread] to decide whether to update the property synchronously or asynchronously.

I meant more robust in the sense that if you use the Receptionist design pattern, you don't in the future have to think about whether the assignment your making to that property is being done on the main thread or not. An approach I usually prefer and I think is more robust. Perhaps we have different definitions of robust in this case.

Kevin


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >KVO - receptionist design pattern (From: Kevin Meaney <email@hidden>)
 >Re: KVO - receptionist design pattern (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Fast hash of NSData?
  • Next by Date: Re: Fast hash of NSData?
  • Previous by thread: Re: KVO - receptionist design pattern
  • Next by thread: Re: Fast hash of NSData?
  • Index(es):
    • Date
    • Thread