Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 8:41 PM, Alex Zavatone wrote: > > Yet we are seeing log output indicating the init method getting executed > twice. Set a breakpoint on it? Or add a counter to the init method so it crashes on the second call, so you get a crash log with a backtrace?

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

On Oct 19, 2016, at 3:03 PM, Jens Alfke wrote: > >> On Oct 19, 2016, at 12:54 PM, Alex Zavatone wrote: >> >> Is there anything wrong with what I'm doing? > > Looks fine to me. Is any of this code using manual ref-counting? If so, I’d > suspect an over-release. Thank god,

Re: inconsistencies in view renderings

On Oct 19, 2016, at 17:34 , Alan Snyder wrote: > > Do you have a test of a textured button in a textured window that does not > gray out when inactive? (I’m ignoring the fact that textured buttons are not > supposed to be used in the content area.) > > I have

Re: inconsistencies in view renderings

My goal is understanding, and I'm not quite there yet. I tried changing my program to use a textured window, and the textured buttons now gray out when the window is inactive. However, the buttons are not in the toolbar or a bottom margin. At least I don’t think they are in a bottom margin,

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 2:29 PM, Steve Christensen wrote: > > The only difference between your code and mine is that you haven't > initialized onceToken = 0 so it has a random value. > > I looked around to see if that makes a difference and didn't get much > confirmation one

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

The only difference between your code and mine is that you haven't initialized onceToken = 0 so it has a random value. I looked around to see if that makes a difference and didn't get much confirmation one way or another. One by Mike Ash

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On 19 Oct 2016, at 22:14, Jens Alfke wrote: > So that’s not what the problem is. > It may be that the a separate instance of the singleton is getting created via the normal alloc - init sequence outside of the normal singleton accessor. That should be trivial to check

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 2:14 PM, Jens Alfke wrote: > > No, nothing would be dealloced. The whole process would just be killed Sorry, I misspoke — I got it mixed up with termination for using too much memory. If the app gets quit in the background it does get notified that

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 2:14 PM, Jens Alfke wrote: > > >> On Oct 19, 2016, at 2:04 PM, Doug Hill > > wrote: >> >> Presumably if the app is terminated due to inactivity everything would be >> dealloc'd including singletons.

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 2:04 PM, Doug Hill wrote: > > Presumably if the app is terminated due to inactivity everything would be > dealloc'd including singletons. No idea if that is happening or not in this > case though. No, nothing would be dealloced. The whole process

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 2:00 PM, Jens Alfke wrote: > > >> On Oct 19, 2016, at 1:23 PM, Steve Mills wrote: >> >> Pardon my obvious question, but this isn't a matter of your app napping >> while in the background, is it? Or something like that? > > Why

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 1:23 PM, Steve Mills wrote: > > Pardon my obvious question, but this isn't a matter of your app napping while > in the background, is it? Or something like that? Why would that cause a singleton to be dealloced? The app just stops getting CPU time for a

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

Pardon my obvious question, but this isn't a matter of your app napping while in the background, is it? Or something like that? Steve via iPhone ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 12:54 PM, Alex Zavatone wrote: > > Is there anything wrong with what I'm doing? Looks fine to me. Is any of this code using manual ref-counting? If so, I’d suspect an over-release. > should I be using [GeofenceControllerSingleton alloc] init] instead of

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

On Oct 19, 2016, at 2:08 PM, Steve Christensen wrote: > This is the model I use for singletons and I've never had the singleton > instance deallocated out from under me. > > + (MyClass*) sharedThing > { > static dispatch_once_t sOnceToken = 0; > static MyClass* sSharedThing = nil;

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

> On Oct 19, 2016, at 11:41 AM, Alex Zavatone wrote: > > I have seen on discussion where people suggest keeping a private strong > property in the singleton with a reference to self to prevent this from > happening. Bad idea: it relies on the implementation detail that the

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

This is the model I use for singletons and I've never had the singleton instance deallocated out from under me. + (MyClass*) sharedThing { static dispatch_once_t sOnceToken = 0; static MyClass* sSharedThing = nil; dispatch_once(, ^{ sSharedThing =

iOS: Preventing a singleton from being deallocated when the app is in the background.

We are running into what appears to be a case where a singleton that has been created through GCD dispatch_once may be getting deallocated by the OS. To check and see if this is the case, I have put logging code in the dealloc method, but our logs do show the init method being called twice even

Re: observeValueForKeyPath:... called too often in macOS 12

> On 19 Oct 2016, at 15:08, Quincey Morris > wrote: > > On Oct 19, 2016, at 00:49 , Gerriet M. Denkmann wrote: >> >> Before: >> >> TextField1 bound Value to: >> Shared User Defaults Controller >> Controller Key = values >>

Re: observeValueForKeyPath:... called too often in macOS 12

On Oct 19, 2016, at 00:49 , Gerriet M. Denkmann wrote: > > Before: > > TextField1 bound Value to: > Shared User Defaults Controller > Controller Key = values > Model Key Path = TextField1 > > This worked fine. Yeah, I didn’t realize you were binding to a

Re: observeValueForKeyPath:... called too often in macOS 12

Oo! I see! Here’s the main problem: > On Oct 14, 2016, at 23:08 , Gerriet M. Denkmann wrote: > > My app (macOS 12) observes a value in NSUserDefaults. Well, no, it doesn’t. It observes a value in a NSUserDefaultsController.values. That’s a different kettle of wax.

Re: observeValueForKeyPath:... called too often in macOS 12

> On 19 Oct 2016, at 13:01, Quincey Morris > wrote: > > > One way around this is to use a NSObjectController bound between the text > field and the data model (user defaults in this case). NSObjectController > implements the editor protocols, so this

[NSEditorRegistration sidetrack] observeValueForKeyPath:... called too often in macOS 12

> On 19 Oct 2016, at 08:01, Quincey Morris > wrote: > > On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann wrote: >> >> I have just done this (can send it to you if you are interested). > > I’d be interested at looking at it, if you can

Re: observeValueForKeyPath:... called too often in macOS 12

> On 19 Oct 2016, at 13:01, Quincey Morris > wrote: > > On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann wrote: >> >> I have just done this (can send it to you if you are interested). > > I’d be interested at looking at it, if you can

Re: observeValueForKeyPath:... called too often in macOS 12

On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann wrote: > > I have just done this (can send it to you if you are interested). I’d be interested at looking at it, if you can email it to me. > Bug4: changes not keep on quit > Check:change a TextField; do not use