Freigeben über

[Windows Phone 7] Faire persister son application sous l’écran de verrouillage

  • Artikel

Malgré le fait qu’une application ne peut exécuter du code quand elle est en background, Windows Phone 7 autorise une application à tourner sous le lock screen (ou écran de verrouillage). On peut aussi empêcher que le téléphone se verrouille, ce qui peut être utile pour certaines applications (navigation turn by turn, détection de mouvement, ce genre de choses). En fait, avec la logique Windows Phone 7, il s’agit de dire à l’application de ne pas détecter que l’utilisateur est inactif (ou l’application elle même…) d’ou la présence de 2 APIs

  • Microsoft.Windows.Phone.Shell.PhoneApplicationService.ApplicationIdleDetectionMode, qui permet de détecter ou pas l’inactivité du téléphone, et qui quand elle est activée, tombstone l’application quand le lock screen démarre.
  • Microsoft.Windows.Phone.Shell.PhoneApplicationService.UserIdleDetectionMode, qui permet de détecter ou pas l’inactivité de l’utilisateur et donc déclencher le lock screen.

Du coup on peut avoir 3 comportements:

  • Les deux modes sont “enabled” : l’écran se verrouille au bout d’un certain temps comme prévu dans les paramètres du terminal et l’application est tombstonée
  • ApplicationIdleDetectionMode est “disabled”: l’écran se verrouille quand l’utilisateur est inactif mais l’application continue à tourner (et donc à consommer de la batterie!!!
  • ApplicationIdleDetectionMode et UserIdleDetectionMode  sont “disabled” et dans ce cas l’écran ne se verrouille pas et l’application continue à tourner (et donc à consommer de la batterie!!)

Plusieurs warnings sont à prendre en compte quand on utilise ces APIs, particulièrement en regard des critères de certification (critère 6.3)

  • Il faut que cette fonctionnalité soit une option configurable dans un écran de l’application
  • Lors du premier appel à cette API, il faut avertir l’utilisateur (explicitement) et lui demander son consentement!

Par ailleurs le modèle de multithreading et de tombstoning étant susceptible d’évoluer, il faudra vérifier au fur et à mesure des versions du SDK le comportement de son application!!

Dernier point, une fois que la détection d’inactivité, de l’application ou de l’utilisateur, a été “disabled” il n’est pas possible de la réactiver de façon programmatique: une InvalidOperationException sera levée (à traiter, donc!!).

La page MSDN qui traite du sujet

Comments

  • Anonymous
    October 10, 2010
    Tiens donc... j'ai lu ça quelque part récemment.