C2DM des conseils sur la mise en œuvre

Question

Fellow en difficulté, les programmeurs

J'ai consulté tous les documents concernant C2DM mais je suis toujours à la recherche pour quelques conseils. Dois-je implémenter un service au sein de mon application pour écouter les intentions créées lorsque le serveur google les envoie à l'appareil?

http://android-developers.blogspot.com/2010/05/android-cloud-to-device-messaging.html

https://developers.google.com/android/c2dm/

La documentation indique qu'il se réveillera l'application lorsque l'intention est reçue en ayant les bons filtres d'intention et les autorisations dans le manifeste d'application. Mais comment cela est-il possible lorsque l'application n'est même pas chargée en mémoire? Comment l'OS sait-il où aller?

Il me semble que j'ai besoin d'un service en arrière-plan avec ces autorisations qui vont ensuite démarrer mon application quand une notification est reçue.

Quelqu'un a-t-il un aperçu de cette idée?

peut-être quelqu'un qui a mis en place un service de fond en utilisant C2DM

ou trouvé pour être inutile.

Answer 1

Les filtres d'intention ne nécessitent pas le démarrage d'une application ou d'un service. Lorsque le système d'exploitation voit qu'un événement s'est produit pour lequel vous avez enregistré un filtre d'intention, il lancera l'intention à laquelle le filtre d'intention est attaché, comme indiqué dans votre manifeste.

Answer 2

En général, vous n'avez pas besoin de service. Cela dépend du type de réaction dont vous avez besoin pour un message. Si vous voulez démarrer une activité, n'hésitez pas à le faire directement depuis le récepteur de messages C2DM. Par ailleurs, les intentions de C2DM ne sont pas des intentions de service. Ils sont des intentions de récepteur. Un service ne peut pas les attraper même s'il le veut. Au niveau de l'API, vous ne pouvez pas déclencher une intention en soi - vous avez appelé startActivity() ou start/bindService() ou sendBroadcast(). En fonction de l'API appelée, le système correspondra à l'intention par rapport aux activités, aux services ou aux destinataires.

J'ai implémenté C2DM. Dans mon cas, j'ai un service - mais c'est seulement parce que la réaction à un message C2DM dans mon application est une requête HTTP sans interface utilisateur qui peut prendre un certain temps. Cela semble un modèle assez commun dans le grand schéma des choses - un C2DM est seulement un déclencheur, il indique seulement une application que de nouvelles données attendent à l'arrière-plan. Dans ce scénario, un service interroge discrètement le back-end pour lesdites nouvelles données et les traite. C'est mon cas. Mais ça ne doit pas être comme ça. Un récepteur seul n'est pas un bon véhicule pour HTTP parce que les objets récepteurs sont transitoires - une fois qu'une intention est livrée, Android suppose que le récepteur est terminé et le rejette. Après cela, le processus de l'application n'a aucun objet en cours d'exécution et peut être arrêté à tout moment. Un service, d'autre part, une fois démarré, s'exécute jusqu'à ce qu'il soit explicitement fait (stopService() est appelé). Cela dit Android que l'application est en train de faire quelque chose, s'il vous plaît ne pas terminer. Un service en cours d'exécution n'est pas une garantie solide que l'application ne sera pas fermée en cas de mémoire insuffisante, mais c'est mieux que rien. Techniquement parlant, votre application est en cours d'exécution même si la seule chose qui fonctionne est un récepteur de diffusion. Android démarre l'application (le processus, pas l'activité principale) lorsqu'un message C2DM arrive. L'utilisateur ne le saura pas à moins que vous ne flashez une interface utilisateur. C'est à vous de décider quels autres composants de l'application invoquer du récepteur.