Zustände beschreiben, bevor der Ladekreisel gezeichnet wird
Dies ist ein vorgeschlagener Ablauf für eine entwicklereigene Wander-App, keine Aufzeichnung beobachteten API-Verhaltens. Die Person gibt offline maps ein, fordert historische Diskussionen an und wartet. Die App muss ein unberührtes Formular, eine offene Anfrage, zurückgegebene Datensätze, eine erfolgreiche leere Antwort und einen Fehlschlag unterscheiden. Ein einziges leeres Feld kann diese Situationen nicht vermitteln.
Beginnen Sie mit einem neutralen Ruhezustand, der den Suchgegenstand erklärt. Tippen allein muss keine Anfrage auslösen. Speichern Sie bei ausdrücklicher Absendung die Frage zusammen mit der Anfrage und zeigen Sie eine Ladebeschriftung. Halten Sie die Eingabe lesbar und verhindern Sie mehrfache Auslösung durch wiederholtes Tippen. Ein Ladekreisel zeigt Warten an, keinen nachgewiesenen Fortschritt durch das Archiv.
Eine verspätete Antwort ihrer Frage zuordnen
Stellen Sie sich vor, die wandernde Person ändert die Eingabe zu heruntergeladenen Regionen, während die Anfrage zu Offline-Karten noch aussteht. Das ist eine veranschaulichende Interaktion, kein abgerufenes Suchbeispiel. Ihre App entscheidet, ob sie wartet, eine weitere Anfrage beginnt oder die Ansicht schließen lässt. Unabhängig von Ihrer Umsetzung darf die frühere Antwort nicht stillschweigend zur Antwort auf die neue Formulierung werden.
Ordnen Sie jede Anfrage im eigenen Anwendungszustand ihrer abgesendeten Eingabe zu. Prüfen Sie beim Eintreffen, ob die Antwort noch in die aktuelle Ansicht gehört. Eine verspätete Antwort nicht mehr anzuzeigen ist nicht dasselbe wie die Serverarbeit abzubrechen: Eine bereits gesendete Anfrage kann erfolgreich enden und berechnet werden. Testen Sie diesen Unterschied in Ihrer Umsetzung.
Erfolgreich leer als Ergebnis behandeln
Zeigen Sie bei gelieferten Datensätzen die tatsächlich vorhandenen Felder und behalten Sie den Hinweis auf die historische Quelle bei. Ein leeres data-Array benötigt eine eigene Meldung, dass diese Anfrage keine Datensätze zurückgegeben hat. Bieten Sie das Ändern von Formulierung oder Filtern an und erhalten Sie beides für eine informierte Entscheidung. Ersetzen Sie leere Ergebnisse nicht durch erfundene beliebte Beiträge.
Erfolgreiche leere Abrufe kosten einen Credit, genau wie erfolgreiche Antworten mit Datensätzen. Das spricht für bewusste Abfrageänderungen, nicht dafür, leere Antworten als Fehler zu verstecken. Vermeiden Sie Aussagen, dass nirgends relevante Diskussionen existierten; das Archiv ist unvollständig, und die Antwort gehört zu einer bestimmten Abfrage in einem begrenzten Fenster.
Das technische Problem an den Betreiber geben
Eine 400-Antwort verlangt die Prüfung der Anfrageeingabe. Hat die App ein ungültiges Datum oder einen nicht unterstützten Parameter gesendet, machen Sie die wandernde Person nicht für einen Fehler im Backendvertrag verantwortlich. 401 bezeichnet einen fehlenden oder ungültigen Dienstschlüssel; Neuladen der App oder eine Anmeldung der Person repariert dieses Zugangsmerkmal nicht zwangsläufig.
402 bedeutet unzureichendes Guthaben im Dienstkonto. Leiten Sie diese Entscheidung an den Betreiber weiter, statt Wandernden eine Rechnung zu zeigen. 429 verlangt die Beachtung von Retry-After und weniger wiederholte Anfragen. Da mehrere Lesende ein App-Konto teilen können, behaupten Sie nicht automatisch, eine einzelne Person habe die Begrenzung verursacht.
Bekannten Fehlschlag und unbekannten Ausgang trennen
Das Gateway liefert 502, wenn der vorgelagerte Abruf fehlschlägt. Der reservierte Credit wird freigegeben oder als noch abzustimmen gemeldet. Erhalten Sie Abfrage und eine zuvor sichtbare Seite und bieten Sie eine begrenzte Wiederholungsentscheidung an. Wiederholte automatische Versuche können mehr Anfragen erzeugen, ohne den Ablauf für die lesende Person verständlicher zu machen.
Erhält Ihre App nie eine Antwort, weiß sie möglicherweise nicht, ob der Server gescheitert ist oder abgeschlossen hat. Halten Sie diese Ungewissheit zur Abstimmung fest; behaupten Sie weder eine sichere Erstattung noch einen sicheren Erfolg. Die öffentliche Route /v1/status prüft statisch Dienstumfang und HTTP-Antwort; sie kann diese Frage weder klären noch eine funktionierende Archivsuche bescheinigen.
Übergänge prüfen, nicht nur Bildschirmbilder
Gehen Sie den vorgeschlagenen Ablauf mit der für die App verantwortlichen Person durch: absenden, während des Wartens ändern, leeres Ergebnis erhalten, nach einem Fehler erneut versuchen, weitere Seite laden und den Bildschirm verlassen. Benennen Sie für jeden Übergang erhaltene Eingabe, sichtbaren Inhalt und nächste Aktion. Ein ansprechender Entwurf beweist nicht, dass diese Übergänge funktionieren.
Halten Sie Betreiberdiagnosen, rohe Dienstantworten und Zugangsdaten aus öffentlichen Meldungen heraus. Geben Sie Wandernden genug Kontext, um ihre Vorbereitung fortzusetzen, ohne sich auf eine nicht verfügbare Diskussionsfunktion zu verlassen. Unter /de/#field-notes finden Sie Entscheidungen zu Anfragebudget und Nachladen, die diesen Zustandsablauf prägen.
