Singleton classes for Client.shared and socket reconnect

[noobs2ninjas]

Not sure if anyone else agrees, but it seems kind of a pain to have to initialize the client yourself then set shared to your initialization. Unless im doing something wrong.

Also, Im having to call Client.shared.reconnect() before I can even do a query.subscribe().Otherwise SRWebSocket throws the following

Invalid State: Cannot call send: until connection is open

Ive actually actually have started rewriting shared as a proper singleton already I just didn't know if this was meant to function this way for a reason. I didn't show that reconnect or socket was set in the main init.

Also I noticed that disconnect boolean used in subscribe is set in disconnect() but not reconnect(). In those same reguards some of the subscribe logic seems backwards. Disconnected seems like it would default to true so that you could simply go

if socket == nil || disconnected{ reconnect() }

I just found out on another thread that what is currently in place should be acting as a singleton.

Perhapse this works better if I where to do whats in the repository example of

let liveQueryClient = ParseLiveQuery.Client(server: "http://localhost:1337")

subscription = liveQueryClient
            .subscribe(messagesQuery)
            .handle(Event.Created) { _, message in
                self.printMessage(message)

I havent tried it but this is not the way it says it works on the main page here. All im doing is query.subscribe() and I get Invalid State: Cannot call send: until connection is open

I have to do

        let client = Client.init()
        Client.shared = client
        Client.shared.reconnect()

and not a line less or else it will throw the error mentioned above

[noobs2ninjas]

I just managed to get it down to the last line

Client.shared.reconnect

Thats the line that is absolutely crucial before any subscribe can happen.

[noobs2ninjas]

I figured it out! The reason it was throwing an error was because I was subscribing to 2 queries in quick succession. The first one would call reconnect. The socket would be initialized but not connected by the time the 2nd subscription would be submitted. This meant that the 2nd subscription was calling send before the initial reconnect could even complete! Adding a quick reconnect boolean fixed this. Added a pull request!