Communiquer un changement de rendez-vous dans une appli
Un plan d’essai pour les permissions, l’état d’envoi et le retour au rendez-vous de service à jour.
Le changement reste dans le système de rendez-vous
Une notification push informe d’un rendez-vous modifié. Le changement faisant foi doit d’abord être enregistré dans le système responsable. Prévoyez donc où le client trouve l’état actuel et qui suit une modification importante si le message ne lui parvient pas.
Apple et Android décrivent des permissions propres à leurs plateformes. Expliquez l’intérêt au bon moment, par exemple quand le client veut activer les alertes de rendez-vous. Un refus ne vaut pas consentement. Vérifiez le comportement sur les appareils et versions de système prévus.
Exemple et plan d’essai détaillé
Dans cet exemple fictif, la planification déplace le rendez-vous de service AP-17 de 14:00 à 15:00. Un message discret peut être : « Un rendez-vous de service a changé. Ouvrez l’application pour consulter les informations à jour. » Les détails personnels de l’intervention n’ont pas à figurer sur l’écran verrouillé.
Situation | Comportement prévu | Preuve attendue |
|---|---|---|
Permission absente | Les rendez-vous actuels restent accessibles dans l’application ; utiliser le contact convenu pour les changements importants. | L’équipe ne suppose pas un contact push réussi et connaît le rôle responsable. |
Rendez-vous modifié | Enregistrer le changement et relier clairement la notification à ce rendez-vous. | Le nouvel état est enregistré ; une tentative d’envoi ne remplace pas cet enregistrement. |
Message accepté par le fournisseur | Consigner l’état d’envoi réellement connu. | L’acceptation du fournisseur n’est pas nommée réception sur l’appareil ou lecture par le client. |
Appareil hors ligne ou message tardif | Charger l’état actuel du rendez-vous à l’ouverture. | Un ancien message ne rétablit pas un ancien état ; un échec d’actualisation est indiqué clairement. |
Appui du client sur le message | Ouvrir le rendez-vous après connexion nécessaire et contrôle des droits actuels. | Le bon rendez-vous apparaît. Si l’accès manque ou si les données ne peuvent pas être chargées, le client reçoit un retour adapté. |
Vérifier séparément l’envoi et l’action du client
FCM documente l’acceptation par le serveur et la remise au SDK de l’appareil comme événements distincts. Même cette réception ne prouve pas que le client a lu ou accepté la modification. Dans l’exemple, l’appui ne doit ni créer un autre rendez-vous ni donner automatiquement un accord requis par le processus métier.
Fixez une durée de validité adaptée au message. Un retard est possible ; une ancienne notification ne doit donc pas être la seule source de l’état du rendez-vous. Convenez du moment où le responsable relance les changements importants par le contact défini.
Essayez permissions accordées et refusées, réception tardive, absence de connexion et données impossibles à charger. Le tableau décrit les résultats attendus de cet essai. Évaluez si le client trouve le rendez-vous actuel et comprend l’action suivante nécessaire.
Sources
Écrit par
- Katharina WeberRédactrice logiciels et technologieKatharina Weber s’occupe chez ASES des articles consacrés au développement logiciel. Elle traite des questions que se posent les entreprises lorsqu’elles choisissent un logiciel, développent de nouvelles applications ou modernisent leurs systèmes existants.
À lire aussi
Tous les articles
Développement logiciel avec ASES
Logiciels sur mesure, applications web et mobiles