Ze kunnen ook gewoon een controle inbouwen of het toestel een werkende internetverbinding heeft, i.p.v. er maar vanuit gaan dat het probleem bij de klant ligt.
Hoe wil je weten waar het probleem ligt?
A.
Het device kan geen internet hebben (wifi is bv. wel actief maar hangt in een CaptivePortal) en er is niet werkelijk verbinding met het internet. De app doet een API call aan het Device OS en ziet dat er een IP verbinding is, maar die werkt eigenlijk helemaal niet).
B.
Er is Internet, device zegt dus "ok" op navraag van de app maar ergens onderweg gaat het mis. Servers zijn onbereikbaar. Geen idee waarom. Kan 100000 oorzaken hebben.
C.
De load-balancer bij de bank, waar de (web)services achter hangen, heeft een configuratie-fout waardoor de content (via API's bv.) niet werkt. De URL welke de App naar buiten schiet werkt dus wel, wordt door de Load-balancer opgevangen maar daarna is het "tote Hosen".
D.
De server waar de App tegen praat werkt niet goed. Alles lijkt te werken maar de verwachte reply op een API-call komt niet, of er komt iets onbruikbaars terug, en geen idee wat er aan de hand is.
E.
F.
G.
H.
Zo kunnen we nog een hele tijd doorgaan. Er kunnen zo veel dingen misgaan. Dus een catch-all "Geen internet, controleer je verbinding en probeer het opnieuw." melding is dan geen slechte feedback naar de gebruiker.
Als de app verbinding heeft maar de back-end of de middle-ware heeft een issue waar de App iets mee kan, kan een gerichte (meer zinvolle) melding aan de gebruiker gepresenteerd worden. In alle andere 10000000 mogelijk gevallen -> catch all error.
Edit: ik krijg een "-1 ongewenst" voor m'n kiezen. Waar slaat dat nou weer op?
[Reactie gewijzigd door Verwijderd op 24 juli 2024 12:06]