Ogni sessione App2App inizia con un login, e una sessione può essere invalidata da eventi al di fuori del tuo controllo. Gestire correttamente questo ciclo di vita è la differenza tra un'integrazione che "funziona sulla mia macchina" e una che sopravvive all'uso reale del terminale — riavvii, aggiornamenti e connessioni interrotte. Questa guida spiega quando esiste una sessione, cosa la invalida e come mantenerla attiva.
Perché il login viene prima
Fino a quando non ricevi una risposta di login riuscito, l'applicazione di pagamento considera ogni tua richiesta non autorizzata e la ignora silenziosamente. Non c'è errore, nessuna eccezione — la tua richiesta di pagamento, stato o amministrativa semplicemente non produce risposta. Uno sviluppatore che salta il login passa ore a chiedersi perché non arriva nulla.
Quindi la regola è assoluta: una RetailerLoginResponse riuscita apre la sessione, e nulla funziona finché non succede.
viewModelScope.launch {
clientSDK.sendLoginRequest()
}
// Attendi SuccessRetailerLoginResponse nel tuo interceptor prima
// di inviare qualsiasi altra richiesta.
Cosa invalida una sessione
Una sessione non è permanente. Qualsiasi di questi eventi la termina, e la tua prossima richiesta sarà ignorata finché non effettui nuovamente il login:
- L'applicazione di pagamento viene aggiornata — una nuova versione dell'app di pagamento resetta la sessione.
- L'applicazione di pagamento si riavvia — per qualsiasi motivo, incluso un riavvio del dispositivo.
- La tua applicazione si riavvia — il tuo processo viene terminato e ricreato, perdendo la sessione.
- La connessione tra le due app viene persa — il binding IPC è caduto.
-
Hai inviato una richiesta di logout — un esplicito
sendLogoutRequest()termina la sessione deliberatamente.
L'idea unificante: una sessione collega due specifiche istanze di app in esecuzione. Se una delle due app si riavvia, o il collegamento tra di esse si interrompe, la sessione condivisa non esiste più — anche se il tuo codice tiene ancora un oggetto SDK che sembra pronto all'uso.
Quando e come effettuare nuovamente il login
Non puoi prevedere in modo affidabile questi eventi, quindi non provarci. Invece, struttura la tua app in modo che il nuovo login sia economico e automatico:
Effettua il login all'avvio. Attiva sendLoginRequest() quando la tua applicazione si avvia. Questo copre gratuitamente il caso "la tua app si è riavviata".
Effettua nuovamente il login quando le risposte smettono di arrivare. Se invii una richiesta e la risposta attesa non arriva mai (puoi rilevarlo con un timeout, ad esempio in modalità bloccante), consideralo come una possibile sessione persa e effettua nuovamente il login prima di riprovare. Una risposta di login riuscito conferma che la sessione è di nuovo attiva.
Il nuovo login è praticamente idempotente. Chiamare il login quando una sessione è già aperta è sicuro — ottieni semplicemente un'altra risposta di login riuscita. Quindi "effettua il login ogni volta che hai dubbi" è una strategia valida; non danneggerai nulla effettuando il login più spesso del necessario.
Un pattern comune e robusto: incapsula la tua logica di invio in modo che se un'operazione scade, invii automaticamente un login, attenda il successo, quindi ritenti l'operazione originale una volta. Questo recupera in modo trasparente dai casi di invalidazione più comuni senza che l'utente veda mai un errore.
Il logout è opzionale
Non devi per forza effettuare il logout. Una sessione persiste finché non si verifica uno degli eventi di invalidazione sopra elencati, quindi la maggior parte delle integrazioni non chiama mai sendLogoutRequest() — lasciano semplicemente la sessione attiva.
Effettua il logout solo quando vuoi terminare deliberatamente la sessione — per esempio, quando cambi operatore su un terminale condiviso, o per forzare un login pulito. Effettuare il logout e poi il login è anche un modo valido per resettare una sessione che sospetti sia in uno stato errato.
Correlati
- Quickstart — dove il login appare per la prima volta, nel contesto.
- Come funziona il modello dei messaggi — perché il risultato del login arriva nell'interceptor anziché dalla chiamata.
- Risoluzione problemi: richieste ignorate / nessuna risposta — il sintomo prodotto da un login mancante o perso.
- Risoluzione problemi: il login restituisce BUSY — l'unico errore di login che significa "ritenta", non "correggi la tua richiesta."