On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
> Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil in
> horror.
>
> First, NSNotificationCenter is a singleton. If you subclass it, you now must
> have two notification centers.
It has the facility to have different Cent
On 12 Sep 2013, at 09:54, Graham Cox wrote:
>
> On 11/09/2013, at 5:33 PM, Etienne Samson wrote:
>
>> I think the best way for what you're trying to do is to subclass
>> NSNotificationCenter (or at least provide your own framework-wide singleton
>> that quacks like it), wrap -postNotificati
On 12 Sep 2013, at 18:45, Kyle Sluder wrote:
> On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
>>
>> On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
>>
>>> Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil
>>> in horror.
>>>
>>> First, NSNotificationCenter is a singleto
Hi Dave,
With all the top coders getting fired-up/tangled up over this thread,
I'm thinking we should get a better idea of the original situation
you are dealing with.
You talked in terms of when the object comes back 'alive'
obviously the same programmatic object doesn't come back ali
Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil in
horror.
First, NSNotificationCenter is a singleton. If you subclass it, you now must
have two notification centers. Which one is the right one to subscribe to? Do
you only move notifications over to it that need to be
On 11 Sep 2013, at 16:33, Etienne Samson wrote:
> Hi !
>
> I think the best way for what you're trying to do is to subclass
> NSNotificationCenter (or at least provide your own framework-wide singleton
> that quacks like it), wrap -postNotification: with some dictionary-munging
> code that k
Hi,
Something that may be confusing people is that although
LTWCachedNotificationCenter is defined as Sublass of NSNotificationCenter, it
does NOT allocate itself as an object and it does not call Super, instead it
calls [NSNotificationCenter defaultCenter] as in:
- (void)postNotificationName:
On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
>
> On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
>
> > Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil
> > in horror.
> >
> > First, NSNotificationCenter is a singleton. If you subclass it, you now
> > must have two not
Le 12 sept. 2013 à 20:11, Dave a écrit :
> On 12 Sep 2013, at 18:45, Kyle Sluder wrote:
>
>> On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
>>>
>>> On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
>>>
Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil
in horror
On 12 Sep 2013, at 20:24, Etienne Samson wrote:
>
> That's not true : you won't get notifications sent by the Cocoa framework,
> because it will use `[NSNotificationCenter defaultCenter]` and you have
> (obviously) no way to change the sender.
>
> I feel like I'm playing the devil's advocate
On 12 Sep 2013, at 18:45, Kyle Sluder wrote:
>>
>> No, just at the receiver, the sender need do nothing, in fact its
>> unchanged.
>
> How? You need to update the sender to send to the correct notification
> center.
Sorry, I mis-read this, I see what you mean now, I might have had to change
On 11 Sep 2013, at 15:11, dangerwillrobinsondan...@gmail.com wrote:
>
> On Sep 11, 2013, at 10:52 PM, Dave wrote:
>
>>
>> On 11 Sep 2013, at 14:22, Graham Cox wrote:
>>
>>>
>>> On 11/09/2013, at 3:13 PM, Dave wrote:
>>>
Yes, but it doesn't remember the last value of a notification,
On 12/09/2013, at 11:17 AM, Etienne Samson wrote:
> If there's 26 different objects that need that "cache" capacity, that's 26
> class methods
So just make a tiny class for the sole purpose of storing the latest data
state. All 26 different sender classes can then use it - since it only stor
Le 12 sept. 2013 à 10:54, Graham Cox a écrit :
> On 11/09/2013, at 5:33 PM, Etienne Samson wrote:
>
>> I think the best way for what you're trying to do is to subclass
>> NSNotificationCenter (or at least provide your own framework-wide singleton
>> that quacks like it), wrap -postNotificatio
On 11/09/2013, at 5:33 PM, Etienne Samson wrote:
> I think the best way for what you're trying to do is to subclass
> NSNotificationCenter (or at least provide your own framework-wide singleton
> that quacks like it), wrap -postNotification: with some dictionary-munging
> code that keeps trac
Hi !
I think the best way for what you're trying to do is to subclass
NSNotificationCenter (or at least provide your own framework-wide singleton
that quacks like it), wrap -postNotification: with some dictionary-munging code
that keeps tracks of the last notification send by notification name,
On Sep 11, 2013, at 10:52 PM, Dave wrote:
>
> On 11 Sep 2013, at 14:22, Graham Cox wrote:
>
>>
>> On 11/09/2013, at 3:13 PM, Dave wrote:
>>
>>> Yes, but it doesn't remember the last value of a notification, which is
>>> what I would like.
>> []
>>
>>> Yes, I am removing myself as a recei
On Sep 11, 2013, at 6:52 AM, Dave wrote:
> I mean when the object is created - at this point I want the latest version
> of the Notification, not the Notification when the Object Died.
NSNotification and the various Center classes are meant to be used for loosely
coupling between classes. If
On 11 Sep 2013, at 14:22, Graham Cox wrote:
>
> On 11/09/2013, at 3:13 PM, Dave wrote:
>
>> Yes, but it doesn't remember the last value of a notification, which is what
>> I would like.
> []
>
>> Yes, I am removing myself as a receiver, but ideally I want to receive these
>> notification e
On 11/09/2013, at 3:13 PM, Dave wrote:
> Yes, but it doesn't remember the last value of a notification, which is what
> I would like.
[]
> Yes, I am removing myself as a receiver, but ideally I want to receive these
> notification even if the object is dead. By this I mean, I want the last
>
On 11 Sep 2013, at 13:55, Graham Cox wrote:
>
> On 11/09/2013, at 1:35 PM, Dave wrote:
>
>> Is there any problem with having all notifications handled by one object
>> that doesn't go away,
>
> Well, [NSNotificationCenter defaultCenter] is that object…
Yes, but it doesn't remember the last
On 11/09/2013, at 1:35 PM, Dave wrote:
> Is there any problem with having all notifications handled by one object that
> doesn't go away,
Well, [NSNotificationCenter defaultCenter] is that object...
> and have this ship the notificationa off to the correct object as long as it
> is still al
On 2013 Sep 11, at 04:35, Dave wrote:
> the problem it was a Notification being sent to a dead object
Yup.
> Is there any problem with having all notifications handled by one object that
> doesn't go away, and have this ship the notificationa off to the correct
> object as long as it is stil
Hi,
Sorry for the lack of data in my original post! I Found the problem it was a
Notification being sent to a dead object, it didn't happen very often, one
crash after over an hour running continuously. I was more worried about the
data I was passing not belonging to same thread (I recently add
On Sep 10, 2013, at 4:08 AM, Dave wrote:
> I have a crashing problem when calling postNotificationName
Most of the time this happens because an object registered as an observer of
that notification has been dealloced.
Try running with NSZombieEnabled and, if this is the case, you should get an
On 2013 Sep 10, at 04:52, Pax <45rpmli...@googlemail.com> wrote:
> What do the debug logs for the crash say? At what point does the crash
> occur? Is your program getting into parseOperationComplete?
Yes, like Pax said, and also, assuming that Xcode stops and shows you a call
stack, make sur
What do the debug logs for the crash say? At what point does the crash occur?
Is your program getting into parseOperationComplete? When you step through,
which line fails?
On 10 Sep 2013, at 12:08, Dave wrote:
> Hi,
>
> I have a crashing problem when calling postNotificationName, the follo
Hi,
I have a crashing problem when calling postNotificationName, the following
method is called from an Operation Queue method/thread. It is called on the
Main Thread (the operation queue method, uses performSelectorOnMainThread which
calls "parseOperationCompleted" below. I've tried copying th
28 matches
Mail list logo
