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

2016-10-19 Thread Jens Alfke 

> 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?

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Alex Zavatone 

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, no.  

> 
>> should I be using [GeofenceControllerSingleton alloc] init] instead of 
>> [[self alloc] init]?
> 
> It would be slightly safer since it guarantees the base class will be 
> instantiated (which is what you probably expect) instead of any subclass that 
> this factory method is called on.
> 

In that case we would find out really quickly, because this is one of the 
classes that starts up as soon as the app makes several server calls.  When our 
error happens that appears like a dealloc, the app has been running and using 
this class for a while and is sitting around on iOS while it is in the 
background.

Yet we are seeing log output indicating the init method getting executed twice. 
 

Thanks much guys.

> —Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: inconsistencies in view renderings

2016-10-19 Thread Quincey Morris 
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 also noticed that if I add a template icon to the textured button, 
> then the text and the icon both gray out, even in a non-textured window.
> 
> However, if I use a textured segmented control with a label and a template 
> icon, the label grays out but the icon does not.
> 
> Perhaps the intent is to gray out all textured buttons in inactive windows 
> but the support is buggy?

I think the behavior is tailored (for each macOS version, so it’s not set in 
stone) to meet the human interface guidelines, not so much for absolute 
consistency in all possible scenarios. I don’t believe that textured windows 
are recommended any more (they’re not even mentioned in the current HIG 
document, that i can see), the question of what the buttons do is moot — or 
perhaps retains a behavior defined in earlier versions. Ditto for different 
button configurations, such as the ones with images. Segmented controls have 
always been weirdly different in appearance from buttons, for much the same 
reasons.

If I’m starting a new UI design from scratch, I generally go through the HIG 
and choose my layout, styles and behaviors from amongst those explicitly 
discussed, and avoid those on which nothing is said. That way, at least, if 
there’s some behavior that doesn’t follow the HIG rules, I can submit a bug 
report.

So, clearly, there is an intention to gray out toolbars and status bars in 
inactive window, and an intention not to gray out controls in the body of a 
window. At a high level, doesn’t that describe the things that you’ve been 
seeing?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: inconsistencies in view renderings

2016-10-19 Thread Alan Snyder 
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, unless the entire window excluding the 
toolbar is a bottom margin. The buttons are within a box with a fill color.

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 also noticed that if I add a template icon to the textured button, then 
the text and the icon both gray out, even in a non-textured window.

However, if I use a textured segmented control with a label and a template 
icon, the label grays out but the icon does not.

Perhaps the intent is to gray out all textured buttons in inactive windows but 
the support is buggy?

  Alan





> On Oct 18, 2016, at 8:53 PM, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 19:43 , Alan Snyder  > wrote:
>> 
>> Well, try this on Sierra:
>> 
>> Use the Open File… menu item of Safari to open a dialog. Then activate a 
>> different application. On my system, the Cancel button in the dialog grays 
>> out (although it still looks different than the disabled Open button). Now 
>> click the Cancel button. Even though the button is grayed out, on my system 
>> the dialog is dismissed.
> 
> Yup, that works as you say. Guess why? (You won’t like the answer.)
> 
> The buttons change appearance when they’re in a window margin at the bottom 
> of an inactive window (and, I would expect, when they’re in a toolbar at the 
> top). If they’re in the body of the window, they don’t change.
> 
> I’ve lost track of what the point is here. Apparently there is no 
> programmatic way to control to inactive appearance, and 
> “acceptsFirstResponder” only affects the inactive behavior. Is there 
> something you were trying to do that you couldn’t, or was it only about 
> explaining the apparent inconsistency?
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Greg Parker 

> 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 way or another. One by Mike Ash 
> (https://www.mikeash.com/pyblog/friday-qa-2014-06-06-secrets-of-dispatch_once.html)
>  mentions, "Note that dispatch_once_t is just a typedef for long, initialized 
> to zero, and with the meaning of other values left up to the implementation."

No difference. C static storage with no initializer is always initialized to 
zero.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Steve Christensen 
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 
(https://www.mikeash.com/pyblog/friday-qa-2014-06-06-secrets-of-dispatch_once.html)
 mentions, "Note that dispatch_once_t is just a typedef for long, initialized 
to zero, and with the meaning of other values left up to the implementation."

It's a simple thing to change to see what happens.


> On Oct 19, 2016, at 12:54 PM, Alex Zavatone  wrote:
> 
> 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;
>> 
>>  dispatch_once(,
>>  ^{
>>  sSharedThing = [[MyClass alloc] init];
>>  });
>> 
>>  return sSharedThing;
>> }
>> 
> 
> It appears that this is what I am doing.  Though the details are not the 
> same, should this matter?
> 
> We have already had to patch one instance where the ref to this was getting 
> lost 
> 
> + (instancetype)referenceGeofenceController {
>   static GeofenceControllerSingleton *geofenceController;
>   static dispatch_once_t onceToken;
> 
>   dispatch_once(, ^{
>   geofenceController = [[self alloc] init];
>   });
>   return geofenceController;
> }
> 
> 
> Is there anything wrong with what I'm doing?  should I be using 
> [GeofenceControllerSingleton alloc] init] instead of [[self alloc] init]?
> 
> Thanks a million.  
> Alex Zavatone
> 
>>> On Oct 19, 2016, at 11:41 AM, Alex Zavatone  wrote:
>>> 
>>> 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 though the method is past the dispatch_once.
>>> 
>>> I'm interested in seeing if I can prevent the singleton from being 
>>> deallocated.
>>> 
>>> 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.
>>> 
>>> Something like 
>>>  self.selfReference = self;
>>> 
>>> within an interface extension.
>>> 
>>> Naturally, this is raising some eyebrows with other members of the team, 
>>> but currently, no one has a solution to make sure that this core singleton 
>>> doesn't get deallocated when the app is in the background and has been 
>>> running for a while.
>>> 
>>> Does this sound sane or a horrible idea?
>>> 
>>> If it does sound like a horrible idea, how would you suggest preventing an 
>>> important singleton from being deallocated?
>>> 
>>> Thanks in advance,
>>> Alex Zavatone


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Jonathan Mitchell 

> 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 for.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Jens Alfke 

> 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 it’s quitting 
and can clean up. But the singleton isn’t going to be dealloced. Not unless the 
Obj-C runtime has an on-termination task that nils out static strong object 
references, which seems like a silly thing to do because all it does is delay 
the process’s exit.

(C++ static destructors _do_ run on termination, but generally one tries to 
avoid having those, because they’re usually useless. There’s even a compiler 
warning for them.)

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Doug Hill 

> 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. No idea if that is happening or not in this 
>> case though.
> 
> No, nothing would be dealloced. The whole process would just be killed, and 
> _nothing_ would happen in it after that point, including seeing a null 
> singleton pointer. So that’s not what the problem is.
> 
> —Jens



FWIW, in the past I saw my iOS shut down gracefully when being terminated due 
to inactivity or low-memory, rather than just a kill -9. I haven't checked this 
lately though.

Doug Hill
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Jens Alfke 

> 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 would just be killed, and 
_nothing_ would happen in it after that point, including seeing a null 
singleton pointer. So that’s not what the problem is.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Doug Hill 

> 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 would that cause a singleton to be dealloced? The app just stops getting 
> CPU time for a while.
> 
> —Jens

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.

Doug Hill


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Jens Alfke 

> 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 while.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Steve Mills 
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 comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Jens Alfke 

> 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 [[self 
> alloc] init]?

It would be slightly safer since it guarantees the base class will be 
instantiated (which is what you probably expect) instead of any subclass that 
this factory method is called on.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Alex Zavatone 

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;
> 
>   dispatch_once(,
>   ^{
>   sSharedThing = [[MyClass alloc] init];
>   });
> 
>   return sSharedThing;
> }
> 

It appears that this is what I am doing.  Though the details are not the same, 
should this matter?

We have already had to patch one instance where the ref to this was getting 
lost 

+ (instancetype)referenceGeofenceController {
   static GeofenceControllerSingleton *geofenceController;
   static dispatch_once_t onceToken;

   dispatch_once(, ^{
   geofenceController = [[self alloc] init];
   });
   return geofenceController;
}


Is there anything wrong with what I'm doing?  should I be using 
[GeofenceControllerSingleton alloc] init] instead of [[self alloc] init]?

Thanks a million.  
Alex Zavatone

> 
> 
>> On Oct 19, 2016, at 11:41 AM, Alex Zavatone  wrote:
>> 
>> 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 though 
>> the method is past the dispatch_once.
>> 
>> I'm interested in seeing if I can prevent the singleton from being 
>> deallocated.
>> 
>> 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.
>> 
>> Something like 
>>   self.selfReference = self;
>> 
>> within an interface extension.
>> 
>> Naturally, this is raising some eyebrows with other members of the team, but 
>> currently, no one has a solution to make sure that this core singleton 
>> doesn't get deallocated when the app is in the background and has been 
>> running for a while.
>> 
>> Does this sound sane or a horrible idea?
>> 
>> If it does sound like a horrible idea, how would you suggest preventing an 
>> important singleton from being deallocated?
>> 
>> Thanks in advance,
>> Alex Zavatone
> 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Jens Alfke 

> 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 runtime can’t detect 
reference cycles. It would fail in the (obsolete) garbage collected 
environment, and it could fail in the future if Apple extends the Obj-C runtime 
to be able to detect unreachable reference cycles and collect them.

(Also, even in the present day it will trigger the leak detectors in 
Instruments and in Xcode 8’s new memory visualizer.)

If you want something to stick around forever, make a static variable that 
points to it (as in Steve’s example.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Steve Christensen 
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 = [[MyClass alloc] init];
});

return sSharedThing;
}



> On Oct 19, 2016, at 11:41 AM, Alex Zavatone  wrote:
> 
> 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 though 
> the method is past the dispatch_once.
> 
> I'm interested in seeing if I can prevent the singleton from being 
> deallocated.
> 
> 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.
> 
> Something like 
>self.selfReference = self;
> 
> within an interface extension.
> 
> Naturally, this is raising some eyebrows with other members of the team, but 
> currently, no one has a solution to make sure that this core singleton 
> doesn't get deallocated when the app is in the background and has been 
> running for a while.
> 
> Does this sound sane or a horrible idea?
> 
> If it does sound like a horrible idea, how would you suggest preventing an 
> important singleton from being deallocated?
> 
> Thanks in advance,
> Alex Zavatone


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Alex Zavatone 
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 though the 
method is past the dispatch_once.

I'm interested in seeing if I can prevent the singleton from being deallocated.

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.

Something like 
self.selfReference = self;

within an interface extension.

Naturally, this is raising some eyebrows with other members of the team, but 
currently, no one has a solution to make sure that this core singleton doesn't 
get deallocated when the app is in the background and has been running for a 
while.

Does this sound sane or a horrible idea?

If it does sound like a horrible idea, how would you suggest preventing an 
important singleton from being deallocated?

Thanks in advance,
Alex Zavatone
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Gerriet M. Denkmann 

> 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
>>  Model Key Path = TextField1
>> 
>> This worked fine.
> 
> Yeah, I didn’t realize you were binding to a NSUserDefaultsController. Since 
> that implements NSEditorRegistration and NSEditor, switching to 
> NSObjectController doesn’t improve anything.
> 
> The real problem is that it just doesn’t know when you app is about to quit. 
> If you want to save text fields that are still being edited, make sure you 
> invoke one of the NSEditor methods on the NSUserDefaultsController before you 
> quit, e.g. “commitEditing”. That will force it to end editing.

I added:
applicationWillTerminate:
[ NSUserDefaultsController.sharedUserDefaultsController 
commitEditing ] 
which seems to fix this issue (which was clearly a bug in my own code).

Thanks for your help!


Kind regards,

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Quincey Morris 
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 NSUserDefaultsController. Since 
that implements NSEditorRegistration and NSEditor, switching to 
NSObjectController doesn’t improve anything.

The real problem is that it just doesn’t know when you app is about to quit. If 
you want to save text fields that are still being edited, make sure you invoke 
one of the NSEditor methods on the NSUserDefaultsController before you quit, 
e.g. “commitEditing”. That will force it to end editing.

However, you will have to consider related issues such as Sudden App 
Termination and Automatic App Termination. There are mechanism to suppress 
these, if your app is using them, while there are “unsaved changes”, but since 
your AppDelegate doesn’t implement the NSEditor protocols, there may be 
something you need to do manually, if the NSUserDefaultsController doesn’t do 
the right thing automatically.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Quincey Morris 
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.

First of all, any NSController subclass defines a mediating controller, aka a 
glue object, aka a piece of junk black box. NSUserDefaultsController exists in 
particular to provide a way of binding UI elements directly to NSUserDefaults 
*without programmatic involvement*. As far as I’m concerned, any programmatic 
use of a NSController class is a code smell (although there are certainly a few 
things where the programmatic need is greater than the smell).

However, NSController subclasses do what they do, however they want to do it. 
The “new” 10.12 behavior you’re seeing may be a bug, or it may be a change to 
the implementation that doesn’t care about poorer performance, or … . See above 
under “piece of junk” and “black box”.

NSUserDefaultsController.values *is* documented to be KVO compliant, and you 
*can* observe its values, but there’s no API contract that says you’re going to 
be happy about what exactly happens.

Some comments about particular issues:

> Bug1: no NSKeyValueObservingOptionOld. Should have old value, but just has 
> NSNull

I think all NSController subclasses have this flaw.

> Bug2: called at start (after applicationDidFinishLaunching) - although 
> nothing has changed yet

The user defaults haven’t changed, but the internal binding[-equivalent] 
between NSUserDefaultsController and NSUserDefaults has to be set up, and that 
*is* a change to the values as held by the NSUserDefaultsController. If this is 
different from 10.11, it may actually be a bug fix.

> Bug3: any change is observed twice

Looking at the stack trace, the first notification occurs when the text field 
reports its new value across its binding to the NSUserDefaultsController. The 
second occurs sometime later. I suspect that’s because the change to the 
NSUserDefaults value flows back across the NSUserDefaultsController binding. 
This may be a bug, or it may be a result of some part of the NSUserDefaults 
happening asynchronous now. AFAIK, there’s no clear contract about values going 
around in circles across bindings. See above under “piece of junk” and “black 
box”.

> Bug4: changes not keep on quit
> Check:change a TextField; do not use CR or leave the TextField; quit 
> the app. Start it again.
>   Maybe this is the way it should be. But in the age of autoSave 
> it feels a bit strange though.

We’re treating this as not a bug in observations.

> Bug5: changing a TextField to empty string reverts to registrationDefaults 
> for this TextField.
> Check:start app; set both TextFields to other than 
> registrationDefaults; quit.
>   start app again; select any TextField; hit "delete", then CR or 
> tab to other TextField →
>   empty string will be replaced by the registrationDefault.
>   
>   This happens only once per TextField. Replacing the 
> registrationDefault again with an empty
>   string just keeps this empty string.
>   At the next start of the app, the empty string will again be 
> replaced by the registrationDefault.
>   
>   Maybe this is the way it should be: empty string → nil and nil 
> → registrationDefault.
>   Feels a bit strange though.

I think this is a consequence of using a binding or of using a NSController 
subclass. One of those mechanisms, I guess, changes the empty string to nil, 
being unaware that that’s going to trigger the reversion to registration 
defaults. It’s probably doing the right thing according to some set of rules, 
just not the rules you want.

> Bug6: sometimes the first change in any TextField reverts to 
> registrationDefaults for both TextFields
> Check:not reproducible. Just happens when it feels like it: sometimes 
> bug a few times in a row,
>   sometimes no bug half a dozen times.

I dunno, I didn’t get as far as looking into this.

My advice is: don’t use NSUserDefaultsController for this. (Don’t use 
NSUserDefaultsController except for binding UI elements directly without the 
involvement of code.) Unfortunately NSUserDefaults isn’t documented as KVO 
compliant for user-defined keys, although it may actually be.

The way I handle this is that I create a custom class for preferences, which is 
fully KVO compliant for its custom properties, and I bind to or observe this 
object. Internally, the preferences object updates and/or reads the 
NSUserDefaults values. This is actually a useful level of abstraction, because 
often what you would like to store is not quite in the same form as what you 
would like to display. At the same time, it tends to be a lot of glue code.

There’s probably more to discuss, but

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

2016-10-19 Thread Gerriet M. Denkmann 

> 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 covers the case where the window 
> closes while an edit is in progress. However, IIRC it doesn’t help when a 
> document “save” occurs or when the app quits, for separate reasons.

I am struggling to do so (and failing miserably):

Before:

TextField1 bound Value to:
Shared User Defaults Controller
Controller Key = values
Model Key Path = TextField1

This worked fine.

Now added NSObjectController
Mode = Class
Class Name = NSMutableDictionary ??
not prepares Content
editable

Bind Controller Content to:
Shared User Defaults Controller
Controller Key = values
Model Key Path = standardUserDefaults ??

TextField1 bound Value to:
Object Controller
Controller Key = selection
Model Key Path = TextField1 ??

This crashes with -[_NSControllerObjectProxy copyWithZone:]: unrecognized 
selector sent to instance 0x10….

Obviously I am not knowing what to do and am just groping blindly.

How does one put an NSObjectController between an NSTextField and the Shared 
User Defaults Controller ?

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Michael Starke 

> 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 email it to me.
> 
>> Bug4:changes not keep on quit
>> Check:   change a TextField; do not use CR or leave the TextField; quit 
>> the app. Start it again.
>>  Maybe this is the way it should be. But in the age of autoSave 
>> it feels a bit strange though.
> 
> I’m pretty sure this is nothing to do with KVO or user defaults.
> 
> An edited text field won’t get “committed” back to the data model until you 
> end editing (Tab or Return) unless you arrange for it to happen. There’s are 
> two *informal* protocols (NSEditor and NSEditorRegistration) that bridge 
> between editors and controllers. Both NSDocument and NSViewController 
> implement both of these, but that would only work if the view controller 
> registered itself with the document, but it doesn’t. In effect the 
> NSWindowController intervenes between the document and view controller, but 
> it *doesn’t* implement those protocols, so it breaks the chain.
> 
> 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 covers the case where the window 
> closes while an edit is in progress. However, IIRC it doesn’t help when a 
> document “save” occurs or when the app quits, for separate reasons.

I've had to deal with the issue of lost data on save/autosave recently and came 
up with the following solutions:

Solution A: bind the text field's value directly to a property of the 
NSDocument so it is the model controller, the text editor get's registered and 
NSDocument commits changes on active editors before saving as documented in 
NSDocument.h

Solution B: bind the text field's value to a custom NSController and vent the 
NSEditorRegistration calls up to NSDocument.

Both of these work, but you have to keep track of other instances where you 
bind to objects, that do not implement NSEditorRegistration, e.g. I used 
objectValue for NSViews in a NSTableViews to bind values. This required a 
custom NSViews to get editors registered in NSDocument.

> Anyway, my point is that I think this is an unrelated problem.


___m i c h a e l   s t a r k e 
   geschäftsführer
   HicknHack Software GmbH
   www.hicknhack-software.com
   
___k o n t a k t
   +49 (170) 3686136
   cont...@hicknhack.com
   
___H i c k n H a c k   S o f t w a r e   G m b H
   geschäftsführer - maik lathan | andreas reischuck | michael starke
   bayreuther straße 32
   01187 dresden
   amtsgericht dresden HRB 30351
   sitz - dresden


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Gerriet M. Denkmann 

> 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 email it to me.
Already sent by separate mail.

> 
>> Bug4:changes not keep on quit
>> Check:   change a TextField; do not use CR or leave the TextField; quit 
>> the app. Start it again.
>>  Maybe this is the way it should be. But in the age of autoSave 
>> it feels a bit strange though.
> 
> I’m pretty sure this is nothing to do with KVO or user defaults.
> 
> An edited text field won’t get “committed” back to the data model until you 
> end editing (Tab or Return) unless you arrange for it to happen. There’s are 
> two *informal* protocols (NSEditor and NSEditorRegistration) that bridge 
> between editors and controllers. Both NSDocument and NSViewController 
> implement both of these, but that would only work if the view controller 
> registered itself with the document, but it doesn’t. In effect the 
> NSWindowController intervenes between the document and view controller, but 
> it *doesn’t* implement those protocols, so it breaks the chain.
> 
> 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 covers the case where the window 
> closes while an edit is in progress. However, IIRC it doesn’t help when a 
> document “save” occurs or when the app quits, for separate reasons.
> 
> Anyway, my point is that I think this is an unrelated problem.

I am quite sure you are right. I will try to use an NSObjectController. 
Probably should have done so in the first place.


Kind regards,

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

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

2016-10-19 Thread Quincey Morris 
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 CR or leave the TextField; quit 
> the app. Start it again.
>   Maybe this is the way it should be. But in the age of autoSave 
> it feels a bit strange though.

I’m pretty sure this is nothing to do with KVO or user defaults.

An edited text field won’t get “committed” back to the data model until you end 
editing (Tab or Return) unless you arrange for it to happen. There’s are two 
*informal* protocols (NSEditor and NSEditorRegistration) that bridge between 
editors and controllers. Both NSDocument and NSViewController implement both of 
these, but that would only work if the view controller registered itself with 
the document, but it doesn’t. In effect the NSWindowController intervenes 
between the document and view controller, but it *doesn’t* implement those 
protocols, so it breaks the chain.

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 covers the case where the window closes while an 
edit is in progress. However, IIRC it doesn’t help when a document “save” 
occurs or when the app quits, for separate reasons.

Anyway, my point is that I think this is an unrelated problem.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com