Mavericks is putting my app to sleep

@Sam: thanks for the information, but this is worse than laywerese. Can you translate this to english?

I must admit, that I got a little confused too…

I’ll be honest and say that I don’t have enough time to sit through the video at the moment, so far everything I’ve read doesn’t seem to help… The plist key is in reference to background helper application.

The api might be able to help, but it does depend on Tom’s implementation.
The new API has two forms. The first form is a begin/end pairing. Call -[NSProcessInfo beginActivityWithOptions:reason:] when your application begins a user initiated activity. The returned object should then passed into -[NSProcessInfo endActivity:] when the activity is finished.

If Tom is using a timer to initiate a network connection and then do the processing, the above should work. However if Tom’s waiting for a network connection… Then this won’t work.

:slight_smile:
I’ll watch the video later. I’ve got a background app myself. So I think the NSSupportsAppNap should work, but as the others have also noticed it doesn’t do anything.

This is how it worked for me:

a) Install MacOSLib and read the doc on TT’s smart preferences.
b) in the open event or init method of your app, include

AppPref = new TTsSmartPreferences("CallCentral") AppPref.Value ("NSAppSleepDisabled") = true AppPref.Sync

Err, yes – replace the app name by your app name of course or get it from system.

(And AppPref is an app property in my case, with a type of TTsSmartPreferences)

Has anyone else had a chance to check to see if the plist setting requires developer mode? My thoughts were that since Apple put it in the developer docs, and mentioned it as a temporary last resort, that it may be a developer only tool.
Considering Apple really doesn’t want you to use the plist method: [quote]Immediately file a bug describing the app and explaining how to reproduce the problem.[/quote]
https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html

[quote=78640:@Tim Parnell]Has anyone else had a chance to check to see if the plist setting requires developer mode? My thoughts were that since Apple put it in the developer docs, and mentioned it as a temporary last resort, that it may be a developer only tool.
Considering Apple really doesn’t want you to use the plist method:
https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html[/quote]

Apparently, Apple provides a way to disable App Nap from the command line, that you can use from a shell command :

Note: If you experience problems with App Nap, you can temporarily disable it for a particular process by typing: defaults write <app domain name> NSAppSleepDisabled -bool YES

I checked several sites for usage of that and it seems like a common way of proceeding.

I tried entering that for one of my apps and replacing by the bundle. No error.

Michel,

Read earlier in this thread for info about that not working.

Okay, so I took a look at the app I’m developing right now and found I’m quite mistaken. As it’s a background app, it does not go into App Nap (thankfully it uses 0.0 CPU while doing nothing).

So I added the plist key to allow it to go into App Nap (as I determined from Apple’s docs). Fired it up, waiting for a little while and sure enough asleep it fell… Then when it was supposed to do it’s business it performs exactly as expected (i.e. working perfectly).

However, when the app needs to do something, it’s either because the user has selected an option from the status item menu or because it’s time to process, either way a GUI is shown and the application is bought forwards which wakes it from it’s nap.

@Tom Iwaniec Does your app display any GUI elements while it’s processing and how do you initiate it’s business? i.e. Timer?

Yes it displays a GUI almost always. The problem is that if your window is in the background or hidden behind another app, it can still nap even if the window is open.

The network connection with the server is usually kept active and connected. When the client side app receives a message from the server, it needs perform tasks, display notifications, save files, etc. The problem is that if it naps, none of this happens and the connection breaks.

The plist key hasn’t worked to prevent app nap consistently when the app is open and behind other applications. Because of this the only solution for me so far has been the ungraceful “please check prevent app nap in the Finder’s get info box.”

hmmm…

So the network socket basically times out while the app is in napping mode. Could you configure a timer to check to see if it’s broken and attempt to reconnect the socket. If you can initiate the process, then we can inject code to wake the process from it’s nap and then everything should function as normal.

Exactly, thats one issue (among a few other smaller ones). The problem is that any notifications or commands sent from the server are completely lost (not even queued in the socket’s buffer) when an app is napping. I could have the sockets automatically reconnect and re-authenticate when the app wakes up from napping, but that defeats the point of having the live syncing /notifications/commands.

If a large file needs to be sent from the server to client, the user would much rather have it download in the background without having to wake the app up, wait for it to reconnect & authenticate, check for any pending server commands, and then wait for it to download.

The main problem is that many of these actions are sent from the server, so there’s no way for the client app to know it will receive a notification, and thus the APIs won’t really work to keep the client awake. I could possibly try to ALWAYS have an [NSProcessInfo beginActivityWithOptions:reason:] running, but that would obviously be a terrible solution.

While it may be a terrible solution in the long run, it’s worth a shot now?

@Tom:

I believe you can set up a timer to give your app a kick every now and then. Timers will still fire when your app is in the background and napping, but they will no longer fire at the frequency you requested; they will typically fire much slower. You could use a timer to reconnect to the server, check for files, and if they are found start the downloading process after calling [NSProcessInfo beginActivityWithOptions:reason:]. When you’re done, end the activity and wait again.

The key question is this: how important to your user is it that they get the files RIGHT NOW as opposed to, say, 10 seconds from now? If they can wait 10 seconds (i.e., napping), your app can consume significantly fewer resources and still deliver a great experience.

So this morning I decided that as my little app will eventually need to perform tasks in the background, that I’d take a look into this all. After watching the WWDC video, App Nap is awesome! Sorry Tom, I know it’s causing you grief.

Anyhoe, I created and tested the following code below. Compile the application and then hide the window, give it up to half a minute and then Activity Monitor finally shows it napping.

Go back into the application and click on “Disable App Nap” and then obscure the window again, I went away and made coffee and it was still active.

http://www.ohanaware.com/xojo/NSProcessInfo.zip

I’ve also added in some other functions which I thought on the off chance might be worth noting.

Oops… In my demo app, I should have specified NSProcessInfo.NSActivityUserInitiatedAllowingIdleSystemSleep, so then the computer can still go to sleep, but App Nap is disabled. Sorry.

The last thing, is to separate your application into two parts. Have one part that sits in the background (we know that by default App Nap doesn’t affect a faceless app) and then to have the interface as a separate application. There’s a lot of work involved, but it might be a better solution in the long run? Just a suggestion.

[quote=78698:@Sam Rowlands]
Anyhoe, I created and tested the following code below. Compile the application and then hide the window, give it up to half a minute and then Activity Monitor finally shows it napping.

Go back into the application and click on “Disable App Nap” and then obscure the window again, I went away and made coffee and it was still active.

http://www.ohanaware.com/xojo/NSProcessInfo.zip
I’ve also added in some other functions which I thought on the off chance might be worth noting.[/quote]

I realise this is an old thread awaken from the the other side…but, Sam, this seems to work!
My app, that is a timer, was put to sleep if another app was run in Full Screen Mode…I’ll try to implement your solution and see what happens :slight_smile:

I’m on 10.10.1 btw.