Oct 18, 2010 at 4:52 PM
Edited Oct 18, 2010 at 4:57 PM
Hmm. the documentation is very thin about UserIdleDetectionMode. 6.3 of the Application Submission Guidelines only talks about ApplicationIdleDetectionMode as requiring user opt-in, and thus be a cause of rejection if you did not implement that. I think
I might uncomment (or add back in) the UserIdleDetectionMode property and see what happens. As I understand it, UserIdleDetectionMode is merely intended to keep the phone from locking/screen blanking while your app is already running, ApplicationIdleDetectionMode
is meant to allow the app to keep running even when locked, which I don't need. If I do this local modification, I'll report back. Lots of games are using UserIdleDetectionMode.
See this forum thread:
Comments from Andreas Saudemont:
You also have a couple of options regarding the lock screen:
UserIdleDetectionMode property of PhoneApplicationService can be set to IdleDetectionMode.Disabled, in which case the screen won't automatically lock until either the application is deactivated/closed or until the property is set back to IdleDetectionMode.Enabled.
ApplicationUserIdleDetectionMode property of PhoneApplicationService can also be set to IdleDetectionMode.Disabled, in which case the application will keep running when the screen is locked. This has some caveats, though: 1) ApplicationUserIdleDetectionMode
cannot be enabled after it has been disabled; 2) according to the
application certification requirements (PDF) , you must ask the user for explicit permission plus the user must be able to switch this behavior off from the application settings; and 3) the application will still be tombstoned when the user presses the
Based on everything I've seen, I don't think using UserIdleDetectionMode is a cause for rejection, but I could be wrong. I believe that it is using (or referencing, in this case) ApplicationIdleDetectionMode, and not implementing user opt-in. I'm determined
to find out - the hard way if necessary It's not like I'm losing income from a $0.99 app if it is not accepted right away :). I DO think however that Tombstoning should make sure it is (re-)Enabled, in case the user presses the Back, Windows or Search
buttons, while your app has it set to Disabled, and I think I can find the place to do that in the Tombstone method. I don't care about it in Ressurect. We'll see.
Update: found another discussion thread:
Comments by Mick M:
This is true at least for ApplicationIdleDetectionMode. Refer App Cert Requirements 6.3.2 Launch Configuration of Running under a Locked Screen. I would agree though that user permission for this wouldn't be a bad idea.
Also some guidance on using UserIdleDetectionMode sensibly from the
doco : It is recommended that applications that disable user idle detection implement their own form of idle detection and enable UserIdleDetectionMode when appropriate.
For example, an accelerometer-based game could enable user idle detection if the accelerometer shows no activity for a period of time.
This seems fairly apt for Simon's application in question.