Re: Protecting against "app nap"
Re: Protecting against "app nap"
- Subject: Re: Protecting against "app nap"
- From: Jonathan Taylor <email@hidden>
- Date: Wed, 11 May 2016 10:31:22 +0100
Thankyou both for your replies - a couple of replies below:
On 10 May 2016, at 23:33, Jens Alfke <email@hidden> wrote:
>> However, I was a bit surprised to find that I seem to need to explicitly retain the object I get back [this is non-ARC code…] if I want my request to remain in effect or even for the object to remain allocated to allow me to call endActivity at a later point.
>
> It’s standard Cocoa memory management: when an object is returned to you from a method, you don’t own a reference to it, so it’s not guaranteed to remain valid. Since you’re holding onto the object, in order to call -endActivity later, you must be storing it in a non-local variable, so you need to retain it.
Fair enough. I agree that according to standard memory and naming conventions I should be expecting to have to retain the object. I guess I just found method naming a bit odd (not really referring to an object at all), and might have expected it to have an ‘alloc/new’ naming since I’d have thought the API would be almost exclusively used for activities that continue beyond the calling scope. Oh well.
>> My question here is what is the most appropriate way of identifying in code whether this feature is available, to ensure I only set it when it will be accepted.
>
> Hm, it’s hard to say, because the declaration of DISPATCH_TIMER_STRICT doesn’t specify what OS versions it’s usable with (via __OSX_AVAILABLE_STARTING or something similar.) You may have to do some research to narrow down when it was added.
OK, will do. Just wasn’t sure if there was a better way to nail it down.
On 10 May 2016, at 18:40, Paul Scott <email@hidden> wrote:
> Did you try clicking “Prevent app nap” in the “Info” inspector for the app?
I’ll be honest, I hadn’t spotted that. Useful to know about (and it looks like setting NSAppSleepDisabled in Info.plist should achieve the same thing without manual user intervention). However, it looks like beginActivityWithOptions has a broader remit than just app nap, so I’ll go with the belt and braces approach and do both…
Cheers
Jonny
_______________________________________________
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