Starscream: isConnected is no longer a property on the websocket?

[NickNeedsAName]

What the title says. Is there a workaround? Did the value move to a different object? What is the logic behind getting rid of this?

[moslienko]

You can see how it should now look in the example in SimpleTest/ViewController.swift in this repository.

[NickNeedsAName]

Okay obviously you can use the delegate methods to track isConnected yourself, I don't want to have to do that though. The websocket connects or doesn't. Why doesn't the websocket have any information about it's own state? That seems like an extremely poor design decision unless there's an edge case I'm unaware of?

[daltoniam]

It was intentionally not added in the 4.0.0 upgrade. It was a race condition variable and was unreliable in its reporting of when the socket was connected or not. Tracking it through the delegate ensures the connected state is happening on the same queue versus the old race behavior of isConnected.

[NickNeedsAName]

Why not just control read and write access to the variable with its own DispatchQueue?

That would guarantee state tracking happens on the same queue and there is no race condition.

I don't know enough about the goals of this lib to know if that's an okay solution, but if you're fine with it I'm more than happy to write up a quick pull request

[thbaja]

I agree with Nick on this. I thinks it's reasonable that the socket knows about it's own state.
This also seems to be pretty standard in other Websocket implementations on other platforms.

I also believe that a lot of people rely on this, so it would make the transition easier.

Would you be open to a PR for this @daltoniam, as @NickNeedsAName kindly offers?