Créer un service ou utiliser l'AlarmManager ?

Bonjour à tous,

J'ai un projet qui me trotte dans la tête depuis un petit moment, mais je bloque sur un point :(

Mon application devrait périodiquement, par exemple toutes les 10 minutes, communiquer avec un serveur. Il pourrait très bien y avoir plusieurs "sessions" avec des délais différents (une toutes les 5 minutes, une autre toutes les heures, etc.).

Là où j'hésite, c'est sur la technique à employer : soit je crée un service qui tourne en permanence et qui effectue les opérations au bon moment (je ne sais pas trop comment), soit je programme des alarmes répétitives avec l'AlarmManager.

Le problème du service, c'est que c'est moins "facile" à écrire et ça consomme des ressources CPU et mémoire en permanence.

Le problème des alarmes, c'est qu'elles disparaissent à l'extinction (c'est contournable si besoin) et je ne sais pas si c'est très "efficient". Pour une tâche qui a lieu une fois par jour, c'est parfait, mais pour des tâches aussi répétitives, ce n'est sûrement pas l'idéal en terme de batterie et d'efficacité !

D'après vous, dans quelle direction devrais-je partir ? Peut-être avez-vous une troisième alternative. Merci d'avance :)

Précision importante : je cherche à respecter le plus possible les guidelines de Google et les bonnes pratiques, merci d'en tenir compte dans vos réponses. Le cas contraire, j'aurais pris la solution de la simplicité avec les alarmes...

Citation:

---

Envoyé par Volgaan

Là où j'hésite, c'est sur la technique à employer : soit je crée un service qui tourne en permanence et qui effectue les opérations au bon moment (je ne sais pas trop comment), soit je programme des alarmes répétitives avec l'AlarmManager.

En fait, je ne vois pas le rapport entre les deux....

Le problème du service, c'est que c'est moins "facile" à écrire et ça consomme des ressources CPU et mémoire en permanence.
Non, pas plus qu'une activité qui serait en avant plan.

---

Je pense que tu confonds "Service" Android, avec thread... un Service n'est *pas* un thread qui tourne, ni en tâche de fond et encore moins en permanence.
Il n'y a aucune différence entre un "Service" et une activité qui serait visible.
Le service représente une "fonction" de l'application qui peut être réalisée *sans interface visible* c'est tout.

Un service, tout comme une activité, ou même n'importe quel thread sera *interrompu* (pas au sens java "InteruptedException", juste que l’exécution sera mise en pause). dès le passage en veille du terminal. Ils ne consommeront donc plus aucun CPU (heureusement d'ailleurs).

Les seuls moyens pour une application d'être "appelée" téléphone en veille est par:
* L'utilisation de messaging exterieur (GCM par exemple).
* L'utilisation de AlarmManager (dont c'est d'ailleurs l'unique rôle).

Citation:

---

Le problème des alarmes, c'est qu'elles disparaissent à l'extinction (c'est contournable si besoin) et je ne sais pas si c'est très "efficient". Pour une tâche qui a lieu une fois par jour, c'est parfait, mais pour des tâches aussi répétitives, ce n'est sûrement pas l'idéal en terme de batterie et d'efficacité !

---

Au contraire, c'est le plus efficace. D'autant plus si l'alarme n'a pas besoin d'être exactement à heure précise. Dans ce cas le système va "empiler" toutes les alarmes en même temps, ne faisant un "réveil" du téléphone que toutes les 15 voir 20 minutes selon les alarmes bien sur.
Si par exemple le gestionnaire de mail a besoin de partir à 19h40 et que ton alarme est prévue à 19h43 mais pas précisément, elle sera "lancée" à 19h40 en même temps que la gestion du mail: un seul réveil du téléphone, une seule reconnexion au réseau (c'est ce qui coute le plus cher en energie), batterie sauvegardée.

Citation:

---

D'après vous, dans quelle direction devrais-je partir ? Peut-être avez-vous une troisième alternative. Merci d'avance :)

---

AlarmManager pour la récurrence, et un Service pour executer le code sans interface. Il n'y pas vraiment d'autre alternative que cette unique option.

Citation:

---

Envoyé par nicroman

Je pense que tu confonds "Service" Android, avec thread... un Service n'est *pas* un thread qui tourne, ni en tâche de fond et encore moins en permanence.
Il n'y a aucune différence entre un "Service" et une activité qui serait visible.
Le service représente une "fonction" de l'application qui peut être réalisée *sans interface visible* c'est tout.

---

Merci pour ta réponse ! Oui, en effet, par service, j'entendais un service tournant dans son propre processus qui tournerait en permanence, comme certaines applications le font.

Je pense que je vais rester sur la solution des alarmes, comme tu le proposes. Par contre, une petite question à ce propos : est-il nécessaire d'annuler une alarme avant de la redéfinir ?

Non aucune application ne fait cela....

Les "service" qu'on voit dans Android sont des "parties" d'une application (au même titre que les activités visible), mais sont absoluement inactives quand le téléphone est en veille et leur "processus" est le même que celui de l'application.
Elles n'ont pas de thread qui tourne en permanence (sinon la batterie de nos smartphone durerait dans les 1h max ! :D )

Pour les alarmes, ils me semble que oui, puisqu'on peut programmer plusieurs "alarmes" sur le même pending intent. Mais à voir dans la documentation.

Un article intéressant sur le sujet : comment choisir quelle solution

https://plus.google.com/+AndroidDeve...ts/GdNrQciPwqo

Citation:

---

Envoyé par nicroman

Non aucune application ne fait cela....

Les "service" qu'on voit dans Android sont des "parties" d'une application (au même titre que les activités visible), mais sont absoluement inactives quand le téléphone est en veille et leur "processus" est le même que celui de l'application.
Elles n'ont pas de thread qui tourne en permanence (sinon la batterie de nos smartphone durerait dans les 1h max ! :D )

Pour les alarmes, ils me semble que oui, puisqu'on peut programmer plusieurs "alarmes" sur le même pending intent. Mais à voir dans la documentation.

---

Sûr ? Précédemment, j'avais fait un dictaphone utilisant la classe AudioRecorder qui oblige à écouter et enregistrer en permanence. Du coup, le code tournait dans un thread situé dans un service dédié à cet effet. Et le téléphone avait beau être en veille, le thread continuait de tourner (heureusement d'ailleurs). Ou alors je n'ai pas bien compris ce que tu voulais dire ?

Citation:

---

Envoyé par grunk

Un article intéressant sur le sujet : comment choisir quelle solution

https://plus.google.com/+AndroidDeve...ts/GdNrQciPwqo

---

Merci, c'est très utile ! Dommage que je cible l'API 10+, je suis obligé de faire à l'ancienne :aie:

Citation:

---

Envoyé par Volgaan

Sûr ? Précédemment, j'avais fait un dictaphone utilisant la classe AudioRecorder qui oblige à écouter et enregistrer en permanence. Du coup, le code tournait dans un thread situé dans un service dédié à cet effet. Et le téléphone avait beau être en veille, le thread continuait de tourner (heureusement d'ailleurs). Ou alors je n'ai pas bien compris ce que tu voulais dire ?

---

Ça m'étonnerait énormément.... Encore une fois, un thread qui tourne en permanence demande au CPU d'utiliser au moins un core du SoC et le résultat sera une batterie qui ne durera pas longtemps...
Il suffit de faire le test avec un compteur dans un thread de toute manière, quand le téléphone passe en veille, le thread s'arrête. Et reprend dès que le téléphone sort de veille (ce qui arrive régulièrement de toute manière).
Attention... un "wait" (ou un sleep , mais beurk sleep :P ) dans un thread n'est pas un arrêt du thread, mais juste une pause le temps qu'un événement apparaisse.


D'ailleurs, les WakeLock n'ont pas été inventés pour rien: il permettent justement aux tâches en arrière plan de continuer de fonctionner (garder le téléphone awake).

La routine d'éveil temporaire (réception d'un wake-up signal du SoC) est assez simple d'ailleurs:
* On redémarre le SoC (pas l'écran)
* On lance tous les intent en attente.
* Quand tous les intents ont été traités et qu'il n'y a plus de WakeLock actif, on arrête le SoC.

C'est pour cela qu'un service doit impérativement démarrer un thread avec WakeLock si il doit faire une opération longue durée (IntentService le fait il me semble, mais à vérifier).
C'est aussi pour cela qu'il vaut mieux passer par les services "in-house" de synchronisation (le système gérant les threads & wake-locks) plutôt que le programmer soi-même une synchronisation (au risque de faire une bêtise).

Encore une fois, merci pour toutes ces informations ;)

Du coup j'avoue ne pas comprendre pourquoi ça marche, étant donné que le thread est sensé s’interrompre :? Pourtant, je te garantie que ça fonctionne bel et bien : enregistrement lancé, application réduite en arrière-plan et écran éteint, tout est enregistré. Est-ce dû au fait que je me "binde" au service ou qu'il y a toujours une activité liée (en pause certes, mais non détruite) ? Je ne sais pas. Ou alors parce que j'ai défini la priorité du thread comme étant THREAD_PRIORITY_URGENT_AUDIO.