Repository navigation
interne schnittstellen
Dokumentation der internen Schnittstellen und Interfaces innerhalb der App.
Zentrale Datenquelle für API-Aufrufe.
class TraewellingRepository(context: Context, prefs: PreferencesManager)Methoden:
-
getDashboard(page)/getGlobalFeed(page)- Feed mit Pagination -
likeStatus(id)/unlikeStatus(id)/deleteStatus(id)/updateStatus(id, request)- Status-Aktionen -
searchStations(query)/getNearbyStations(lat, lon)- Textsuche beziehungsweise Stationssuche überGET /api/v1/stations; der zweite Aufruf berechnet aus Breite/Länge die Query-Parametermin_lat,max_lat,min_lon,max_lonfür eine Bounding-Box. -
getStationDepartures(stationId)- Abfahrten -
getTrip(hafasTripId, lineName)- Trip-Details -
checkIn(request)- Check-in inklusive Reisegrund (CheckInRequest.business) -
getStatistics()- Statistiken -
getCurrentUser()/getUserProfile(username)/getUserStatuses(username, page)- Profile -
searchUsers(query)- Benutzer-Suche -
getStatusDetail(statusId)/getStopovers(tripId)- Status-Details -
followUser(id)/unfollowUser(id)- Follow -
getNotifications(page)/getUnreadNotificationCount()/markNotificationRead(id)/markAllNotificationsRead()- Notifications
Bei einem Check-in-Konflikt (HTTP 409) wertet das Repository data.conflicts als Liste vollständiger Status-Objekte aus. Fehlermeldungen hängen nicht von den veralteten Feldern message.status_id und message.lineName ab. Der Serverfehler wird nicht mehr als unverarbeitetes JSON in die Check-in-Oberfläche übernommen.
apiResult reicht CancellationException unverändert weiter; ein abgebrochener Auftrag wird weder als gewöhnlicher API-Fehler noch als Offline-Erfolg verarbeitet. Feed-Abrufe verwenden einen atomaren AuthSession-Snapshot und prüfen ihn vor Cache-/Antwortübernahme erneut. Der Feed-Cache ist nach Server, Zugangsdaten und Feedart getrennt.
Stations- und Zeitdaten werden über die Helfer des Datenmodells gelesen: stationId, stationName, stationIdentifier(type), effectiveArrival, effectiveDeparture und matchesStopover(other). Damit verwenden UI, ViewModels und Tracking denselben API-Vertrag.
Authentifizierungs-Operationen.
class AuthRepository(prefs: PreferencesManager)Methoden:
-
loginWithToken(serverUrl, token)- HTTPS-Server und Token prüfen, danach vollständige Session atomar speichern -
validateCurrentSession()- gespeicherte Session prüfen; nur 401/403 löschen genau diese noch aktuelle Session -
exchangeCodeForToken(...)- OAuth Token Exchange -
refreshAccessToken()- Token erneuern -
fetchAndSaveCurrentUser()- User laden -
logout()- Abmelden
OAuth-Methoden sind vorhandene Helfer, kein angebundener Login-/Auto-Refresh. Vergleichende Session-Schreiboperationen in AuthSessionStore verhindern, dass verspätete Antworten eine neuere Anmeldung überschreiben oder löschen. Logout entfernt die lokale Sitzung vor dem optionalen Netzwerkaufruf.
TransitRouteRepository(session: AuthSession) lädt den nativen Status-Linienzug über einen eigenen HTTPS-OkHttp-Client. getRoute(request: TransitRouteRequest) liefert optional eine besuchsgebundene TransitRouteGeometry; close() beendet gemeinsame Abrufe und löscht den sessiongebundenen RAM-Cache. Der Request enthält die vollständige eigene Besuchsfolge, keine Gerätepositionen. Dieser Geometrieabruf ist kein neuer Retrofit-/Status-PUT-Vertrag. Parser-, Cache- und Privacy-Grenzen stehen unter Externe Schnittstellen und GPS-Zeiten.
Alle API-Aufrufe zur Träwelling API.
OAuth-Token-Austausch (Authorization Code + PKCE, Refresh Token).
@Database(entities = [StatusEntity::class], version = 2, exportSchema = false)
abstract class AppDatabase : RoomDatabase()@Dao
interface StatusDao {
suspend fun getStatuses(type: String): List<StatusEntity>
suspend fun insertStatuses(statuses: List<StatusEntity>)
suspend fun clearStatuses(type: String)
suspend fun replaceStatuses(type: String, statuses: List<StatusEntity>)
}replaceStatuses ersetzt eine Feedpartition innerhalb einer Room-Transaktion; der zusammengesetzte Primärschlüssel ist unter Schemas dokumentiert.
Siehe PreferencesManager