2014-02-25 11 views
10

Ich habe ein Problem, dass, wenn ich meine Anwendung im Hintergrund schließt die GCKSocket von Chrome iOS api geht und ich erhalte diese typr Fehler von apiChrome Hintergrund-Video-Wiedergabe unterstützt iOS

-[GCKCastSocket socketDidDisconnect:withError:] socketDidDisconnect:withError: "(null)" 

und dann, wenn ich bringe die Anwendung zum Vordergrund der API erstellt den Socket automatisch und setzen Sie den Wiedergabe-Status auf Pause. Wenn ich jetzt versuche, das Video erneut abzuspielen, wird es normal abgespielt.

Ich beginne die Wiedergabe der Medien auf dem Hintergrund Thread wie folgt.

Wie kann die Wiedergabe am Leben erhalten werden, auch wenn die Anwendung in den Hintergrund wechselt?

hier ist die Protokollierung von api

2014-02-25 17:19:01.388 CastVideos[28470:60b] -[GCKCastSocket disconnect] disconnect 

2014-02-25 17:19:01.391 CastVideos[28470:60b] -[GCKCastSocket doTeardownWithError:] doTeardownWithError 

2014-02-25 17:19:01.395 CastVideos[28470:60b] -[GCKCastSocket doTeardownWithError:] notifying delegate that socket is disconnected 

2014-02-25 17:19:01.399 CastVideos[28470:60b] -[GCKHeartbeatChannel didDisconnect] disconnected - stopping heartbeat timer if necessary 

2014-02-25 17:19:01.457 CastVideos[28470:60b] -[GCKCastSocket socketDidDisconnect:withError:] socketDidDisconnect:withError: "(null)" 
+1

App im Hintergrundmodus und Hintergrund Thread sind nicht verwandt. – user523234

+0

Also welcher Hintergrundmodus sollte verwendet werden, um Chromecast-Wiedergabe wie für Airplay zu unterstützen Wir verwenden Avaudiosession mit Audio-Hintergrundmodus – hariszaman

+0

Wenn Sie nicht an AppStore senden müssen, wird jeder Hintergrundmodus vorausgesetzt, Chromecast wird im Hintergrundmodus arbeiten. Das ist mir nicht vertraut. – user523234

Antwort

10

Derzeit ist die Cast iOS SDK die Socket geschlossen, wenn Sie in den Hintergrund gehen, und das ist nicht ein konfigurierbares Element an dieser Stelle. Dies bedeutet jedoch nicht, dass Ihre Medienwiedergabe auf dem Cast-Gerät gestoppt werden sollte. das richtige Verhalten in der Tat ist die folgende:

  • , wenn der Benutzer explizit mich von dem Guss Gerät getrennt, und wenn sie das letzte angeschlossene Gerät mit dem Empfänger ist, dann sollte der Empfänger die Wiedergabe stoppen, sonst Empfänger sollte die Wiedergabe fortsetzen.

Der Schlüssel hier ist der "explizite" Teil; Wenn beispielsweise der Sender den WLAN-Bereich verlässt und die Verbindung getrennt wird oder wenn der Sender in den Ruhezustand wechselt und die Verbindung getrennt wird, gelten diese als "implizite" Verbindungsabbrüche und sollten nicht zum Stoppen des Empfängers führen.

Mit anderen Worten, es ist wirklich der Empfänger, der die Logik sollte zu entscheiden, ob es sich anzuhalten hat oder weiterspielen, und dafür zu arbeiten, hat es in der Lage sein, wenn ein Gerät trennen entschieden verursacht wurde implizit oder explizit. In den aktuellen Empfänger-SDK-APIs ist dies leider nicht im onSenderDisconnected-Ereignis enthalten, das der Empfänger erhält; in der nächsten Aktualisierung des Empfängers wird es sich ändern, so dass der Empfänger sehen kann, warum eine Trennung stattfindet, zumindest so viel wie er benötigt, um eine explizite von einer impliziten zu unterscheiden. Dann kann es die Logik implementieren. In der Zwischenzeit benötigt der Sender einen Out-of-Band-Kanal, um eine Nachricht zu senden, die seine ausdrückliche Absicht angibt.

Update: Empfänger-SDK wurde aktualisiert, um die Informationen anzuzeigen, die feststellen können, ob der Absender implizit oder explizit getrennt wurde, siehe docs.

+0

vielen Dank für Ihre Antwort, sollte ich versuchen, eine Nachricht an den Empfänger senden, sobald die App in den Ruhezustand oder Hintergrund geht? Vielleicht dem Empfänger sagen, dass es eine implizite/explizite Trennung ist – hariszaman

+0

nein, wenn Sie in den Hintergrund gehen oder außerhalb der Reichweite, Empfänger wird feststellen, dass Sie gegangen sind und Sie getrennt betrachtet und da Sie die explizite Nachricht nicht gesendet haben, sollte es interpretiert werden als implizite. Senden Sie eine Nachricht (bevor der Fix wirksam wird) nur, wenn der Benutzer explizit die Verbindung trennt –

+0

, aber die Demo-Empfängeranwendung stoppt automatisch, sobald der Absender in den Hintergrund tritt, wie wird das behoben? – hariszaman

0

Es gibt einen Hack, der hilft, die Verbindung aufrecht zu erhalten, wenn sie im Hintergrund läuft.

Sie können den Anruf für eine GCKssessionManager.suspendSession (mit :) für eine benutzerdefinierte ersetzen, die nicht getrennt wird.

extension GCKSessionManager { 
    static func ignoreAppBackgroundModeChange() { 
     let oldMethod = class_getInstanceMethod(GCKSessionManager.self, #selector(GCKSessionManager.suspendSession(with:))) 
     let newMethod = class_getInstanceMethod(GCKSessionManager.self, #selector(GCKSessionManager.suspendSessionIgnoringAppBackgrounded(with:))) 
     method_exchangeImplementations(oldMethod, newMethod) 

    } 

    func suspendSessionIgnoringAppBackgrounded(with reason: GCKConnectionSuspendReason) -> Bool { 
     guard reason != .appBackgrounded else { return false } 
     return suspendSession(with:reason) 
    } 
} 

rufen Sie einfach die Methode ignoreAppBackgroundModeChange() einmal von überall vor im Hintergrund ein.

Das Problem, das ich damit gefunden habe, ist, wenn Sie nach ein paar Sekunden zu einem Netzwerkfehler zurückkehren, weil Google Cast versucht, die Verbindung mit dem Gerät wiederherzustellen.

Ich reparierte das Wiederverbinden, wenn der Fehler passiert, mit einem Flag, um es im Hintergrund zuvor identifiziert zu identifizieren.

Referenz: How to keep GCKCastSession alive when app goes to background