How does OSMF handling disconnecting? We currently have 3 scenarios where a video can stop playing b/c of a disconnect. These are:
1. Internet goes down
2. token expires at CDN
3. NetStream goes AWOL because of low bandwidth situations
For #1, we poll one of our core, small web services to get the current date from the server. If that works, we still have an internet connection b/c we ensure the service isn't cached and the return value changes all the time. That way if #2 or #3 happen, #1 allows us to confirm (at least as far as our app knows), we have to attempt to reconnect until the user's internet goes back up.
For #2, we just re-connect the NetConnection & NetStream like #1 since we'll usually get a message from the CDN stating our token's old.
For #3, if #1 doesn't catch it, we'll often just get a low bw or failed via info.code or IOError from our NetStream which we can catch and attempt a re-connect.
For #1, that's easy; the OSMF wrapper can go into our existing code base.
For #2 and #3... uh... how would I do this?
Any error from NetStream or NetConnection is encapsulated in a MediaErrorEvent which is dispatched from the MediaPlayer. If you're looking to hook in at a lower level (e.g. to try to reestablish a NetConnection), then there are a couple of ways you might attempt this (not sure which is best):
1. Override NetLoader, and have your NetLoader subclass add listeners for these failure events. When it detects one, it attempts to reload the NetConnection/NetStream. The downside is that this probably doesn't isolate the MediaPlayer client code from the state changes.
2. Create a ProxyElement that wraps up your VideoElement. This ProxyElement will listen for MediaErrorEvents. When it encounters one of the appropriate type, it gets the LoadTrait from the proxied MediaElement and attempts a reload. There's nothing NetConnection/NetStream-specific here, which may or may not be a plus. A potential plus is that the ProxyElement can shield the MediaPlayer client code from the NetConnection/NetStream going down and then up again, to the degree that it makes sense to do so. (This will become much more useful when OSMF takes advantage of the Argo feature for attaching a live NetStream to a new NetConnection.)
Thanks Brian, I'll definitely go with #2.