Timer VS SyncServiceManager + AlarmManager

Bonjour à tous,

J'ai récemment codé un Service en background pour réaliser une tache à intervalles régulier qui doit :
- rester actif quand l'appli est tuée (STICKY)
- se relancer au reboot du device (BOOT_COMPLETED)
- pouvoir être activé/désactivé par l'utilisateur via un Switch (sync on/off)

Pour le moment j'ai donc ce service qui lance un Timer triggered toutes les 2 heures.

Ma question est simple, cette implementation est elle acceptable ou serait il préférable de faire une implementation plus "lourde" avec un SyncServiceManager utilisant un AlarmManager etc... ?

Et surtout, si cela s'avère préférable au simple Timer, pourquoi donc ?

D'avance merci pour vos réponses :)

Sa peut t'aider https://developer.android.com/traini...ng/alarms.html

Salut !

Déjà le Timer ne fonctionne pas si le téléphone est en veille... et risque de ne plus fonctionner tant qu'il est verrouillé (selon les optimisation d'applications).
Je n'aime pas trop l'approche "service background" qui fait un truc toutes les 2h pour ces raisons, mais aussi qu'il défie le principe de la programmation événementielle sur lequel est basé Android majoritairement.

L'AlarmManager (+ BOOT_COMPLETED pour recréer les alarmes) permet d'avoir un bout de code appelé toutes les 2h, quelque soit l'état du téléphone, c'est déjà mieux.

Le SyncManager permet en prime de s'affranchir des divers WakeLock à conserver (si le boulot à effectuer peut être long), mais aussi de l'état de connexion du téléphone (en mode avion, pas de sync effectué par exemple)...

L'un dans l'autre, il faut voir l'action à effectuer toutes les 2h....

Bonjour ;)

Alors oui je suis d'accord avec toi et suis actuellement en train de procéder au refactor de la chose tel que ::

- AlarmManager ::
----> setInexactRepeating() afin de regrouper les alarmes de ce même type et ne pas reveiller le device plusieurs fois inutilement
- OnBootCompletedReceiver ::
----> lance une synchro via un intentService en BG (worker thread)
----> relance l'alarm détruite lorsqu'on éteint le device
- OnAlarmReceiver ::
----> lance une synchro via un intentService en BG (worker thread)

par contre :

Citation:

---

Déjà le Timer ne fonctionne pas si le téléphone est en veille... et risque de ne plus fonctionner tant qu'il est verrouillé (selon les optimisation d'applications).

---

- en veille, si : testé et ca fonctionne (peut être parce que mon service était STICKY?)
- éteint non ;) mais l'Alarm non plus puisqu'il nous faut la recréer au BOOT_COMPLETED

Après j'aurais une dernière question sur ces alarmes :
- celle que je créé actuellement fonctionne toutes les 2h
- je teste sur le PendingIntent pour savoir si cette alarm est deja active car je ne souhaite pas la reset à chaque passage dans mon onCreate()
ma question est donc :
- le jour ou je fais une MAJ de l'application et que je change le temps à 3h, cela sera t'il pris en compte? ou faudra t'il attendre que l'utilisateur éteigne son device que l'Alarm A soit détruite et que je recréé une Alarm B au BOOT_COMPLETED ?

Et enfin ,

Citation:

---

Le SyncManager permet en prime de s'affranchir des divers WakeLock à conserver (si le boulot à effectuer peut être long), mais aussi de l'état de connexion du téléphone (en mode avion, pas de sync effectué par exemple)...
L'un dans l'autre, il faut voir l'action à effectuer toutes les 2h....

---

Pour l'instant je ne retient pas de Wakelock, dans les divers article que jai parcouru je suis tombé sur ce code :

Code:

---

1 2	WakefulIntentService.acquireStaticLock(context); //acquire a partial WakeLock context.startService(new Intent(context, TaskButlerService.class)); //start TaskButlerService

---

L'action a effectuer est une serie d'appels WebServices afin de maintenir la BDD "à jour" sans devoir faire attendre l'utilisateur à l'ouverture de l'appli.

Si j'ai bien suivi, le WakeLock permet d'empecher l'OS de tuer le service en cas de baisse de ressources c'est bien cela ?
Du coup, dans mon cas, ce service se reveille toutes les 2 heures pour effectuer un travail de quelques secondes grand maximum...
Je serai donc d'avis de dire que c'est superflu ?