How does ConnectionLostPlease.persistIf work compared to autoconnect?



  • Dear SweetBlue Team,

    I'd like to understand a bit better which tool to use. The goal is to "always" have a BLE device connected through a foreground service.

    I understand that autoconnect is pretty much dark magic and it works in mysterious ways. However, it seems like a good solution for our use case.

    I'm curious about the persist feature of the ConnectionLostPlease. Does it set some internal parameter so that SweetBlue will keep trying to connect to that device whenever it appears or does it timeout after some time/retries? Is there any reason to use this if I'm always using autoconnect from the get go?

    Here's what I found in the documentation about what persist means:
    0_1594834484160_b4fcbad0-68d1-4c53-b5db-14de1f98b061-image.png

    Thanks a lot



  • When a connection has been deemed to be lost, the onConnectionLost() method is called. This interface must return a ConnectionLostPlease to inform the library what to do (persist in trying to get reconnected, or stop trying).

    Usually, you can achieve what you want without having to implement the logic there, and instead use the DefaultDeviceReconnectFilter. If you never want it to stop trying to connect, then set the timeout value for Interval.INFINITE. I would use infinite on the long term reconnect. Something like so:

    config.reconnectFilter = new DefaultDeviceReconnectFilter(2, 0, Interval.secs(1), Interval.FIVE_SECS, Interval.secs(3), Interval.INFINITE);
    


  • @ryanbis said in How does ConnectionLostPlease.persistIf work compared to autoconnect?:

    config.reconnectFilter = new DefaultDeviceReconnectFilter(2, 0, Interval.secs(1), Interval.FIVE_SECS, Interva

    Hi Ryan!
    I'm curious about the retryCount parameter: Does it mean that after a total of 3 connection attempts, despite indicating in INFINITE Interval for long term reconnection, SweetBlue would stop trying to find and connect to that device?
    Thanks for the clarification! Cheers



  • @alejandrohcruz No, it simply means after the retryCount has been hit, when trying the next connection attempt, we set the android parameter autoconnect to true. This parameter has different effects on different phones. Most seem to work best with it being false, but sometimes setting it to true can help, hence the option here to give X amount of retries before trying the autoconnect parameter as true. In your case, SweetBlue will keep trying to reconnect when in the LONG_TERM state indefinitely.



  • I see very interesting! Then shouldn't the retryCount also be 0, when failCountBeforeUsingAutoConnect is specified as 0?



  • @alejandrohcruz Ahh I see the confusion. The first retryCount is for the onConnectFailed() method, which only fires when initially trying the connect (the device wasnt connected prior). If you hit that retryCount, then SweetBlue will stop trying. The second argument is for the autoconnect parameter I described above.



  • @ryanbis Ah! Alright, everything's clear now. That was the confusion 🙂