Eine App bleibt oft geöffnet, während ihre Einstellungen verändert werden.
Das Problem: Veraltete Verbindung im laufenden Client
Serveradresse und Zugangstoken können sich ändern, während die Mail-App läuft. Eine Updateprüfung, die beide Werte einmalig festhält, verwendet danach weiter die alte Verbindung. Der Quellcode beschreibt ausdrücklich, dass dann auch wiederholtes Aktualisieren den Fehler nicht behebt.
Die Lösung: Verbindung bei jeder Prüfung neu lesen
Der Update-Service fragt den aktuellen Endpunkt bei jedem Aufruf ab. Er liest außerdem die installierte Paketversion und fragt den authentifizierten CRM-Releasekatalog ab. Nur eine höhere veröffentlichte Version wird angeboten. Die ältere README beschreibt noch GitHub-Releases; für diesen Beitrag wurde deshalb die aktuelle Implementierung zusätzlich geprüft.
Passender Build statt allgemeiner Download
Beim Installieren wird das Artefakt für die aktuelle Plattform ausgewählt. Fehlt es, meldet die Anwendung ausdrücklich, dass für diese Plattform kein Build veröffentlicht wurde. Ein allgemeiner Link zu einer Release-Seite würde diesen fehlenden Android- oder Windows-Build nicht ersetzen.
Warum wiederholtes Aktualisieren nicht geholfen hätte
Eine App bleibt oft geöffnet, während ihre Einstellungen verändert werden. Serveradresse und Authentifizierung können nach einer neuen Kopplung andere Werte haben. Wenn der Update-Service diese Werte beim Erzeugen des Objekts festhält, fragt jeder spätere Refresh weiterhin den alten Server mit dem alten Token ab. Die Oberfläche wirkt dann aktiv, aber die Anfrage verwendet nie den neuen Zustand. Der aktuelle Quellcode beschreibt dieses Problem direkt am endpoint-Feld. Die Lösung liegt deshalb nicht in einem weiteren Refresh-Knopf, sondern darin, die Verbindung bei jedem check-Aufruf erneut aus dem aktuellen Zustand zu lesen.
Der Updater erhält einen Getter statt einer Momentaufnahme
UpdateService speichert eine Funktion, die einen aktuellen UpdateEndpoint liefert. check liest zuerst die installierte Paketversion und ruft danach diesen Getter auf. Fehlt die Verbindung, wird endpointMissing gesetzt. Mit einer gültigen Verbindung erfolgt die Anfrage an den CRM-Releasekatalog. Die ältere README nennt noch GitHub-Releases. Das wäre als alleinige Grundlage für die Fehlersuche irreführend gewesen: Die tatsächlich ausgeführte Implementierung verwendet inzwischen den authentifizierten CRM-Endpunkt. Das Codefenster zeigt den relevanten Ausschnitt ohne Zugangsdaten.
class UpdateService {
// Aktuellen Zustand lesen, nicht Adresse/Token einmalig kopieren.
final Future<UpdateEndpoint?> Function() endpoint;
Future<UpdateStatus> check() async {
final current = await currentVersion();
final target = await endpoint();
if (target == null) {
return UpdateStatus(current: current, endpointMissing: true);
}
final response = await _client.get(
target.uri('/api/app-releases/$_releaseApp'),
headers: {
'accept': 'application/json',
'authorization': 'Bearer ${target.token}',
},
).timeout(const Duration(seconds: 15));
// Danach: Status, Release-Version und Plattformartefakt prüfen.
// Ausschnitt; Fehlerbehandlung siehe vollständigen Service.
}
}Eine neue Versionsnummer ohne passenden Build reicht nicht
Der Server liefert Release-Metadaten, die gegen die installierte Version verglichen werden. Nur ein neuerer Release wird angeboten. Danach braucht die Installation ein Artefakt für die aktuelle Plattform. Eine Windows-Datei löst keinen fehlenden Android-Build, auch wenn die Versionsnummer stimmt. Fehlt platformAsset, erzeugt downloadAndInstall eine ausdrückliche Meldung. Der Downloadweg wird damit nicht auf eine allgemeine Webseite umgebogen, die das eigentliche Problem verschleiern würde. Version, Plattform und Datei müssen zusammenpassen, bevor von einem installierbaren Update gesprochen werden kann.
Technische Referenz: Dart: Funktionen als Werte.
Die verbleibende Diagnosegrenze
Der aktuelle check-Pfad fängt Ausnahmen ab und liefert dann einen Status ohne verfügbaren Release. Das kann aus Nutzersicht gleich aussehen wie „kein Update vorhanden“. Die Korrektur der alten Verbindung ist somit konkret, aber noch keine vollständige Unterscheidung zwischen Netzwerkfehler und fehlendem Release. Bei der Abnahme werden deshalb fehlender Endpunkt, neuer Endpunkt nach Rekopplung, 404 ohne Release, gleiche Version, höhere Version und fehlendes Plattformartefakt getrennt geprüft. Ein erfolgreicher Metadatenabruf ersetzt schließlich nicht die Installation auf dem Gerät. Dieser letzte Schritt braucht eine eigene Bestätigung.
Weiterlesen: VoIP-Fehlersuche: Wenn das Nummernformat wie ein Routingfehler aussieht.