Elke App2App-sessie begint met een login, en een sessie kan ongeldig worden gemaakt door gebeurtenissen buiten uw controle. Het goed begrijpen van deze levenscyclus is het verschil tussen een integratie die "werkt op mijn machine" en een die echte terminalgebruik overleeft — herstarts, updates en verbroken verbindingen. Deze gids legt uit wanneer een sessie bestaat, wat deze ongeldig maakt en hoe u een sessie actief houdt.
Waarom login eerst komt
Totdat u een succesvolle loginrespons ontvangt, behandelt de betaalapplicatie elk verzoek dat u verstuurt als niet-geautoriseerd en negeert dit stilzwijgend. Er is geen foutmelding, geen uitzondering — uw betaal-, status- of adminverzoek levert simpelweg geen reactie op. Een ontwikkelaar die de login overslaat, besteedt uren aan het zich afvragen waarom er niets terugkomt.
Dus de regel is absoluut: een succesvolle RetailerLoginResponse opent de sessie, en niets anders werkt totdat dat gebeurt.
viewModelScope.launch {
clientSDK.sendLoginRequest()
}
// Wacht op SuccessRetailerLoginResponse in uw interceptor voordat
// u een ander verzoek verzendt.
Wat maakt een sessie ongeldig
Een sessie is niet permanent. Elk van deze gebeurtenissen beëindigt deze, en uw volgende verzoek wordt genegeerd totdat u opnieuw inlogt:
- De betaalapplicatie wordt bijgewerkt — een nieuwe versie van de betaalapp reset de sessie.
- De betaalapplicatie wordt opnieuw gestart — om welke reden dan ook, inclusief een herstart van het apparaat.
- Uw applicatie wordt opnieuw gestart — uw proces wordt beëindigd en opnieuw aangemaakt, waardoor de sessie verloren gaat.
- De verbinding tussen de twee apps wordt verbroken — de IPC-verbinding is verbroken.
-
U heeft een uitlogverzoek verzonden — een expliciete
sendLogoutRequest()beëindigt de sessie opzettelijk.
Het overkoepelende idee: een sessie verbindt twee specifieke draaiende app-instanties. Als een van beide apps opnieuw start, of de verbinding tussen hen wordt verbroken, bestaat de gedeelde sessie niet meer — ook al houdt uw code nog steeds een SDK-object vast dat klaar lijkt voor gebruik.
Wanneer en hoe opnieuw inloggen
U kunt deze gebeurtenissen niet betrouwbaar voorspellen, dus probeer dat ook niet. Structureer uw app in plaats daarvan zo dat opnieuw inloggen goedkoop en automatisch is:
Log in bij het opstarten. Activeer sendLoginRequest() wanneer uw applicatie start. Dit dekt de situatie "uw app is opnieuw gestart" gratis af.
Log opnieuw in wanneer reacties niet meer binnenkomen. Als u een verzoek verzendt en de verwachte reactie nooit komt (dit kunt u detecteren met een time-out, bijvoorbeeld via blokkerende modus), behandel dit dan als een mogelijk verloren sessie en log opnieuw in voordat u het opnieuw probeert. Een succesvolle loginrespons bevestigt dat de sessie weer actief is.
Opnieuw inloggen is in de praktijk idempotent. Inloggen wanneer een sessie al open is, is veilig — u krijgt gewoon een andere succesvolle loginrespons. Dus "log in wanneer u twijfelt" is een geldige strategie; u veroorzaakt geen schade door vaker in te loggen dan strikt noodzakelijk.
Een veelvoorkomend, robuust patroon: wikkel uw verzendlogica zo in dat als een bewerking time-out krijgt, u automatisch een login verstuurt, wacht op succes, en daarna de oorspronkelijke bewerking één keer opnieuw probeert. Dit herstelt transparant van de meest voorkomende ongeldigmakende gevallen zonder dat de gebruiker ooit een fout ziet.
Uitloggen is optioneel
U hoeft niet uit te loggen. Een sessie blijft bestaan totdat een van de hierboven genoemde ongeldigmakende gebeurtenissen plaatsvindt, dus de meeste integraties roepen sendLogoutRequest() helemaal niet aan — ze laten de sessie gewoon voortduren.
Log alleen uit wanneer u de sessie bewust wilt beëindigen — bijvoorbeeld bij het wisselen van operatoren op een gedeelde terminal, of om een schone herlogin af te dwingen. Uitloggen en opnieuw inloggen is ook een geldige manier om een sessie te resetten waarvan u vermoedt dat deze in een slechte staat verkeert.
Gerelateerd
- Quickstart — waar login voor het eerst verschijnt, in context.
- Hoe het berichtmodel werkt — waarom het loginresultaat in de interceptor aankomt in plaats van via de oproep.
- Probleemoplossing: verzoeken worden genegeerd / geen reactie — het symptoom dat een ontbrekende of verloren login veroorzaakt.
- Probleemoplossing: login retourneert BUSY — de enige loginfout die "probeer opnieuw" betekent, niet "corrigeer uw verzoek."