Ich entwickle native Windows 10 Client LOB-Anwendungen für einen Kunden.
Die Umgebung: Windows 10 Pro (auf den mobilen Clients/Tablets und auf der Entwickler-Box), Visual Studio 2015 Professional mit Update 3, alle Updates und Patches installiert. Die Clientanwendung verwendet das neueste "IBM MobileFirst Platform SDK für Windows 8 Universal und Windows 10 Universal-Plattformen" Version 8.0.2017012514. Auf einem separaten Rechner in meinem Netzwerk habe ich den MobileFirst Platform Server mit einem Java Adapter.MobileFirst 8.0 C# WorklightResourceRequest.Send() hängt, wenn Gerät offline ist
Die Anwendung funktioniert sehr gut, wenn die Anwendung online ist und der MobileFirst Platform 8.0-Server erreicht werden kann.
Wenn der Client seine Netzwerkverbindung verliert (zum Beispiel WLAN außerhalb der Reichweite oder MFP Server offline), dann werden alle Anfragen an den Server auf unbestimmte Zeit hängen. Siehe das folgende Beispiel C# -Code:
public async Task CallMethodMfp8()
{
Value = "Start MobileFirst Method Call " + DateTime.Now + "\n" + Value;
StringBuilder uriBuilder = new StringBuilder().Append("/adapters")
.Append("/MaximoAdapter")
.Append("/admin")
.Append("/heartbeat");
WorklightResourceRequest rr = _client.ResourceRequest(new
Uri(uriBuilder.ToString(), UriKind.Relative), "GET", "");
rr.Timeout = 500;
WorklightResponse resp = await rr.Send();
if (!resp.Success)
{
Value = "NOT SUCCESSFULL " + resp.Message + "\n" + Value;
}
else
{
Value = "Request OK" + resp.ResponseText + "\n" + Value;
}
Value = "Method Call Finished " + DateTime.Now + "\n" + Value;
}
Der Aufruf von rr.Send() nicht zurückkehrt, wenn das Gerät offline ist. Auch der Timeout-Parameter scheint keine Wirkung zu haben (laut den Docs sollte dies das Timeout in Millisekunden sein).
Dieses Verhalten wirkt sich negativ auf die Nutzbarkeit der Client-Anwendung.
in die Dokumentenlese ich würde erwarten, dass der Anruf kehrt nach dem konfigurierten Timeout und dass das resp.Success Feld falsch ist.
Ich gehe davon aus, dass der Anruf zu WorklightResourceRequest.Send() nicht als offline hängen sollte und dass dies ein Fehler in der Bibliothek MobileFirst Plattform.
Gibt es eine Abhilfe für dieses oder bin ich die Bibliothek falsch verwenden?
Normalerweise beträgt die Standardzeit für die Windows UWP-Anwendung 90 Sekunden. Wird innerhalb von 90 Sekunden keine Antwort angezeigt? –
Nein, die App bleibt einfach für immer hängen (und ich habe mehrere Stunden gewartet). Selbst wenn das Netzwerk zurückkehrt, wird der Anruf nicht fortgesetzt. –
Wir können dieses Problem erneut erstellen. Dieses Problem wird in der nächsten Version behoben. Vielen Dank. –