Changements d'état et remise au premier plan de votre application

  • Mise à jour

L'intercepteur délivre des réponses aux requêtes que vous avez envoyées. Il existe un second canal asynchrone distinct : l'observateur d'événements, qui vous informe de l’état de l’application de paiement — quand un paiement commence et quand il se termine — indépendamment de qui l’a initié. Ce guide explique ce canal et la chose que les développeurs désirent le plus : ramener votre propre application au premier plan au bon moment.


Deux canaux, deux fonctions

Gardez-les bien distincts dans votre esprit :

  • L'intercepteur (abordé dans Comment fonctionne le modèle de messages) reçoit des réponses DomainMessage — le résultat d’une requête que vous avez envoyée.
  • L’observateur d’événements reçoit des notifications d’état ObservableEvent — ce que fait l’application de paiement à l’instant.

Vous enregistrez l’observateur d’événements à l’initialisation du SDK avec bindEventObserver. L’événement qui vous intéresse le plus est ObservableEvent.TransactionStateChanged.

.bindEventObserver { event ->
    when (event) {
        is ObservableEvent.ServerEvent ->
            Logger.d("l'application de paiement a émis un événement serveur")
        is ObservableEvent.TransactionStateChanged ->
            when (event.state) {
                is PaymentTransactionState -> { /* un paiement a démarré */ }
                is IdleTransactionState    -> { /* l'application de paiement a terminé */ }
                else -> { /* ignorer les autres états */ }
            }
    }
}

Les deux états qui comptent

ÉtatSignificationCe que vous faites typiquement
PaymentTransactionStateLe traitement du paiement a commencé. Optionnel : ramener votre application au premier plan pour afficher un écran personnalisé durant l’autorisation (votre image de marque, les détails de la transaction, une publicité) au lieu de l’interface par défaut de l’application de paiement.
IdleTransactionStateL’application de paiement a terminé la transaction. Recommandé : ramener votre application au premier plan pour afficher le résultat final à l’opérateur.

La raison pour laquelle ce canal existe séparément des réponses : pendant un paiement, l’application de paiement est au premier plan et gère l’interaction avec la carte, pas votre application. Les événements d’état vous permettent de décider quand reprendre l’écran.


Ramener votre application au premier plan

bringToForeground(MainActivity::class.java) ramène votre application devant l’application de paiement. Connectez-le aux états qui vous intéressent :

.bindEventObserver { event ->
    when (event) {
        is ObservableEvent.TransactionStateChanged ->
            when (event.state) {
                // Recommandé : venir au premier plan lorsque le paiement se termine,
                // pour afficher le résultat.
                is IdleTransactionState -> bringToForeground(MainActivity::class.java)
                // Optionnel : venir au premier plan pendant l’autorisation,
                // par exemple pour afficher votre propre interface au lieu du spinner de l’application de paiement.
                is PaymentTransactionState -> bringToForeground(MainActivity::class.java)
                else -> { /* ignorer */ }
            }
        is ObservableEvent.ServerEvent -> Logger.d("événement serveur")
    }
}

Si votre application est mono-activité, il suffit de passer la classe de votre activité principale — vous n’avez pas besoin de vous soucier de l’écran affiché ; le SDK ramène l’activité au premier plan et votre propre état de navigation est conservé.

Permission requise. bringToForeground ne fonctionne que si votre application a reçu la permission SYSTEM_ALERT_WINDOW. Sans elle, l’appel ne fait rien. Demandez-la lors de la configuration de votre application ; sur de nombreux terminaux, elle doit être accordée explicitement.


Choisir les états à gérer

  • La plupart des intégrations ne gèrent que IdleTransactionState — venir au premier plan à la fin du paiement pour afficher le résultat. C’est le minimum recommandé.
  • Gérez aussi PaymentTransactionState uniquement si vous avez une raison d’être au premier plan pendant l’autorisation — un écran de progression personnalisé, les détails de la transaction ou une publicité. Sinon, laissez l’application de paiement au premier plan ; elle possède sa propre interface pour le titulaire de la carte.
  • Tout le reste peut être ignoré.

Articles liés

  • Comment fonctionne le modèle de messages — le canal de l’intercepteur, le pendant de celui-ci.
  • Démarrage rapide — où l’observateur d’événements est enregistré pour la première fois.
  • Guide : paiement — l’opération dont ces événements suivent l’état.

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 0 sur 0