Différences entre Intent et PendingIntent


97

J'ai lu quelques articles et les deux semblent faire la même chose et je me demandais quelle est la différence entre démarrer le service comme ça:

Intent intent = new Intent(this, HelloService.class);
startService(intent);

ou comme ça:

Calendar cal = Calendar.getInstance();
Intent intent = new Intent(this, MyService.class);
PendingIntent pintent = PendingIntent.getService(this, 0, intent, 0);
AlarmManager alarm = (AlarmManager)getSystemService(Context.ALARM_SERVICE);
alarm.setRepeating(AlarmManager.RTC_WAKEUP, cal.getTimeInMillis(), 30*1000, pintent); 

Au fur et à mesure que je lis, ces deux font la même chose, si dans le service vous retournez un paramètre START_STICKY;


Il n'y a aucune différence. Qu'est-ce qui vous fait penser qu'il y en aurait? Dans le premier cas, vous le démarrez «maintenant» et dans le second, vous le programmez simplement pour une date / des données ultérieures.
Squonk

Réponses:


150

Intention

Une intention Android est un objet portant une intention, c'est-à-dire un message d'un composant à un autre composant à l'intérieur ou à l'extérieur de l'application. Les intentions peuvent communiquer des messages entre l'un des trois composants principaux d'une application: activités, services et récepteurs de diffusion.

L'intention elle-même, un objet Intent, est une structure de données passive. Il contient une description abstraite d'une opération à effectuer.

Par exemple: disons que vous avez une activité qui doit lancer un client de messagerie et envoyer un e-mail. Pour ce faire, votre activité enverrait une intention avec l'action ACTION_SEND, ainsi que le sélecteur approprié, au résolveur d'intention Android:

Intent intent = new Intent(Intent.ACTION_SENDTO);
intent.setData(Uri.parse("mailto:")); // only email apps should handle this

Le sélecteur spécifié donne l'interface appropriée pour que l'utilisateur choisisse comment envoyer vos données de courrier électronique.

DES INVENTIONS EXPLICITES

// Explicit Intent by specifying its class name
   Intent i = new Intent(this, TargetActivity.class);
   i.putExtra("Key1", "ABC");
   i.putExtra("Key2", "123");

// Starts TargetActivity
   startActivity(i);

DES INTENTION IMPLICITES

// Implicit Intent by specifying a URI
   Intent i = new Intent(Intent.ACTION_VIEW, 
   Uri.parse("http://www.example.com"));

// Starts Implicit Activity
   startActivity(i); 

En attente d'intention

Un PendingIntent est un jeton que vous donnez à une application étrangère (par exemple NotificationManager, AlarmManager, Écran d'accueil AppWidgetManager ou d'autres applications tierces), qui permet à l'application étrangère d'utiliser les autorisations de votre application pour exécuter un morceau de code prédéfini.

En donnant un PendingIntent à une autre application, vous lui accordez le droit d'exécuter l'opération que vous avez spécifiée comme si l'autre application était vous-même (avec les mêmes autorisations et identité). En tant que tel, vous devez faire attention à la façon dont vous construisez le PendingIntent: presque toujours, par exemple, l'intention de base que vous fournissez doit avoir le nom du composant explicitement défini sur l'un de vos propres composants, pour vous assurer qu'il est finalement envoyé là-bas et nulle part ailleurs.

Exemple d'intention en attente: http://android-pending-intent.blogspot.in/

Source: intentions Android et intentions en attente Android

J'espère que cela t'aides.


26

PendingIntentest un wrapper de Intent. L'application étrangère qui reçoit le PendingIntent, ne sait pas dont le contenu Intentest enveloppé PendingIntent. La mission de l'application étrangère est de renvoyer l'intention au propriétaire lorsque certaines conditions sont remplies (Par exemple: alarme avec horaire, ou notification avec clic ...). Les conditions sont données par le propriétaire mais traitées par une application étrangère (par exemple: alarme, notification).

Si une application étrangère a envoyé une intention à votre application, cela signifie que l'application étrangère connaît le contenu de l'intention. et l'application étrangère décide d'envoyer l'intention, puis votre application doit traiter l'intention pour répondre à certaines conditions => votre application obtient la ressource de performance du système.


5

Une autre différence simple:

  • L'intention normale mourra dès que l'application sera supprimée.

  • Les intentions en suspens ne meurent jamais. Ils seront en vie aussi longtemps que nécessaire par le service d'alarme, le service de localisation ou tout autre service.


1

Démarrage régulier des services via AlarmManager

Comme pour les activités, le système Android peut interrompre le processus d'un service à tout moment pour économiser des ressources. Pour cette raison, vous ne pouvez pas simplement utiliser un TimerTaskdans le service pour vous assurer qu'il est exécuté régulièrement.

Donc, pour une planification correcte du service, utilisez la AlarmManagerclasse.

METTRE À JOUR:

Il n'y a donc aucune différence réelle entre les deux. Mais selon que vous souhaitez assurer ou non l'exécution du service, vous pouvez décider quoi utiliser car pour le premier il n'y a aucune garantie et pour le plus tard .

Plus d'informations sur AndroidServices .


2
Cela ne répond pas réellement à la question du PO qui est "quelle est la différence" entre le démarrage direct d'un service et le démarrage d'un service avec une alarme. De plus, l'OP a probablement vu l'article vers lequel vous créez un lien, car le code de l'article est presque identique à ce que l'OP a publié.
Squonk

Voulez-vous dire que démarrer un service depuis AlarmManager est plus sûr et moins susceptible d'être tué que suite à une activité? Je pense que c'est faux. Pouvez-vous s'il vous plaît expliquer. @VedPrakash. De plus, je pense que le contexte que vous transmettez lors de la création d'une intention de démarrage du service est plus important. Utiliser le contexte de l'application (getApplicationContext ()) plutôt que celui d'une activité (this), devrait être plus sûr.
Parth Kapoor

@ Eu.Dr. Je vous recommande d'utiliser un gestionnaire d'alarmes qui se déclenchera à chaque fois X ... exécuter la tâche .. Pourquoi? car si vous utilisez des services, ils peuvent être fermés à un moment donné et vous pourriez finir par sauter certaines mises à jour à un certain moment (inconnu). Pour le doute de contexte, ne l'utilisez getApplicationContext()ou ne l'utilisez jamais quand vous le voulez strictement, lisez simplement - quand-appeler-activité-contexte-ou-application-contexte ( stackoverflow.com/questions/7298731/… ).
My God

1

Fonctionnellement, il n'y a pas de différence.

La signification de PendingIntent est que vous pouvez le gérer avec une autre application qui pourra l'utiliser ultérieurement comme si l'autre application était vous-même. Voici l'explication pertinente de la documentation :

En donnant un PendingIntent à une autre application, vous lui accordez le droit d'exécuter l'opération que vous avez spécifiée comme si l'autre application était vous-même (avec les mêmes autorisations et identité). En tant que tel, vous devez faire attention à la façon dont vous construisez le PendingIntent: presque toujours, par exemple, l'intention de base que vous fournissez doit avoir le nom du composant explicitement défini sur l'un de vos propres composants, pour vous assurer qu'il est finalement envoyé là-bas et nulle part ailleurs.

Un PendingIntent lui-même est simplement une référence à un jeton maintenu par le système décrivant les données d'origine utilisées pour le récupérer.

Donc PendingIntent est juste une référence aux données qui représentent l'intention d'origine (celle utilisée pour créer PendingIntent).


4
Dire qu'il n'y a pas de différence fonctionnelle est incorrect. Si les fonctions des deux sont identiques, pourquoi en avoir deux à la première place? Différence la plus importante en ce que PendingIntent est exécuté par un composant distant (comme NotificationManager) avec les mêmes autorisations que celui du composant qui le remet (celui qui crée la notification).
Aniket Thakur
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.