L'intercettore consegna risposte alle richieste che hai inviato. Esiste un secondo canale asincrono separato: il osservatore di eventi, che ti informa sul stato dell'applicazione di pagamento — quando un pagamento inizia e quando termina — indipendentemente da chi lo ha avviato. Questa guida spiega quel canale e la cosa che gli sviluppatori vogliono di più da esso: riportare la propria app in primo piano al momento giusto.
Due canali, due compiti
Tieni bene a mente queste distinzioni:
-
L'intercettore (trattato in Come funziona il modello di messaggi) riceve risposte
DomainMessage— il risultato di una richiesta che hai inviato. -
L'osservatore di eventi riceve notifiche di stato
ObservableEvent— cosa sta facendo l'applicazione di pagamento in quel momento.
Registri l'osservatore di eventi all'inizializzazione dell'SDK con bindEventObserver. L'evento che ti interessa di più è ObservableEvent.TransactionStateChanged.
.bindEventObserver { event ->
when (event) {
is ObservableEvent.ServerEvent ->
Logger.d("l'app di pagamento ha emesso un evento server")
is ObservableEvent.TransactionStateChanged ->
when (event.state) {
is PaymentTransactionState -> { /* un pagamento è iniziato */ }
is IdleTransactionState -> { /* l'app di pagamento ha terminato */ }
else -> { /* ignora altri stati */ }
}
}
}
I due stati che contano
| Stato | Significato | Cosa fai tipicamente |
|---|---|---|
PaymentTransactionState | È iniziata l'elaborazione del pagamento. | Opzionale: porta la tua app in primo piano per mostrare una schermata personalizzata durante l'autorizzazione (il tuo branding, i dettagli della transazione, una pubblicità) invece dell'interfaccia predefinita dell'app di pagamento. |
IdleTransactionState | L'applicazione di pagamento ha terminato la transazione. | Consigliato: porta la tua app in primo piano per mostrare il risultato finale all'operatore. |
Il motivo per cui questo canale esiste separatamente dalle risposte: durante un pagamento, la applicazione di pagamento è in primo piano e gestisce l'interazione con la carta, non la tua app. Gli eventi di stato ti permettono di decidere quando riprendere il controllo dello schermo.
Portare la tua app in primo piano
bringToForeground(MainActivity::class.java) riporta la tua applicazione davanti all'app di pagamento. Collegalo allo stato o agli stati che ti interessano:
.bindEventObserver { event ->
when (event) {
is ObservableEvent.TransactionStateChanged ->
when (event.state) {
// Consigliato: portarsi in primo piano quando il pagamento termina,
// per mostrare il risultato.
is IdleTransactionState -> bringToForeground(MainActivity::class.java)
// Opzionale: portarsi in primo piano durante l'autorizzazione,
// ad esempio per mostrare la tua UI invece del caricamento dell'app di pagamento.
is PaymentTransactionState -> bringToForeground(MainActivity::class.java)
else -> { /* ignora */ }
}
is ObservableEvent.ServerEvent -> Logger.d("evento server")
}
}
Se la tua app ha una singola activity, passa semplicemente la classe della tua activity principale — non devi preoccuparti di quale schermata fosse visualizzata; l'SDK porta l'activity in primo piano e il tuo stato di navigazione interno viene preservato.
Permesso richiesto.
bringToForegroundfunziona solo se alla tua applicazione è stato concesso il permessoSYSTEM_ALERT_WINDOW. Senza questo permesso, la chiamata non ha effetto. Richiedilo come parte della configurazione della tua app; in molti terminali deve essere concesso esplicitamente.
Scegliere quali stati gestire
-
La maggior parte delle integrazioni gestisce solo
IdleTransactionState— portarsi in primo piano quando il pagamento termina per mostrare il risultato. Questo è il minimo consigliato. -
Gestisci anche
PaymentTransactionStatesolo se hai motivo di essere in primo piano durante l'autorizzazione — una schermata di progresso personalizzata, dettagli della transazione o pubblicità. Se non ne hai bisogno, lascia l'app di pagamento in primo piano; ha la sua interfaccia utente per il titolare della carta. - Tutto il resto può essere ignorato.
Articoli correlati
- Come funziona il modello di messaggi — il canale dell'intercettore, il corrispettivo di questo.
- Quickstart — dove l'osservatore di eventi viene registrato per la prima volta.
- Guida: pagamento — l'operazione il cui stato questi eventi tracciano.