buttonDidConnect / didDisconnect called very late

[jvanakker]

In our app (iOS 13) we have implemented all the flic2lib delegate calls. In general, it works fine. However, we are experiencing that the "buttonDidConnect" and "didDisconnectWithError" delegate methods are pretty often called very late (and sometimes not called at all), when the buttons comes in range or gets out of range.

This does not directly impact the reliability of actually clicking on a flic2 button. Clicking on a paired button that is in range, will ALWAYS correctly trigger a "didReceiveButtonClick", so that's fine. It it will just also quickly trigger a "buttonDidConnect" in case this wasn't called yet.

Our app just visually shows if the button is currently connected or not, which is often factually incorrect because buttonDidConnect/Disconnect are called late.

Is there anything we can do to make the buttonDidConnect/Disconnect delegates more reliable and called more quickly?

[AntonMeier]

I can't say for sure, but I believe what you are seeing is just a result of how the Flic's bluetooth advertisement works. Whenever the Flic and iOS device go out of reach of each other, the Flic will start advertising so that they can re-establish connection when they come back within range. In order to save battery, the Flic will only use a very long advertisement interval which means that it can take a relatively long time for the iOS device to discover it.

However, once the Flic is clicked, then we know that we need to "hurry up", so Flic will then switch to the lowest possible advertisement interval. This usually results in the iOS device immediately discovering it and then connecting so that the click events can be delivered.

Do you think this is what you are seeing? Or do you think that it could be a different issue?

[jvanakker]

Thanks for the info, I think this is what we are seeing indeed.

So in other words, this means that in real-world scenarios, the connected status is not reliable, as it can often represent the wrong state;

• It can show "disconnected" for very long times, even though the button is perfectly in range and working fine when you click on it
• It can sometimes show "connected" even if a button is out of range for a while

We are now considering to remove this status info from our UI, so the user cannot see this anymore. Only leaving the info of a paired/stored button name.

Is that what you would advise for apps using flic2lib, or is there anything else that we (or you) can do to improve this?

[Emill]

I don't think we represent the "wrong" state. The "connected" status does NOT indicate if the Flic is in range or not. It just means if there is an established Bluetooth connection between the devices.

Yes it can show "connected" for a few seconds if you for example remove the battery of the Flic, since the Bluetooth connection has a timeout of a few seconds.

In the Flic app we use the term "standby" when disconnected. But yeah it's hard to know from a user experience point of view how the connectivity status should be presented. We honestly don't know ourselves the best way to present this. But I think it's good to in some way show to the user if the button is connected or not, for troubleshooting purposes etc.

[jvanakker]

To get back to this issue, we've updated to the latest version of flic2lib-ios, and the buttonDidConnect and didDisconnect methods are now called much more consistently and faster, that's great! However, there is one more issue.

We test this with a Flic2 button, "simulate" it getting out of range by wrapping it in foil and/or placing it in a metal box, it will call didDisconnect very promptly, and after you get the button out it will call didConnect very quickly, unlike our previous experiences early 2020! So that's very good.

Now one more problem still remains: all of the above is only the case after you have clicked the button at least once (which will trigger an initial didConnect). Before that, there doesn't seem to be for the app to know if a restored button is in range or not.

So the question is: is there a way for the iOS app know if a (stored) button is in range, before it has been clicked?

[Emill]

As mentioned earlier, if the button has not been clicked, it will use very long advertisement interval, which means it will probably going to take some time to be discovered. The button also has a timeout so that it stops advertising after a while in order to save battery. So no, it's not possible to know for sure if it's in range or not.

[jvanakker]

As mentioned earlier, if the button has not been clicked, it will use very long advertisement interval, which means it will probably going to take some time to be discovered. The button also has a timeout so that it stops advertising after a while in order to save battery. So no, it's not possible to know for sure if it's in range or not.

Thanks for confirming, that's what I thought! Nevertheless good that status after 1st click is now more reliable.