Our current solution is that 3rd party apps depend on the Flic app to deliver the button events (easiest is through intents). There are multiple reasons for that:
We can provide a small simple open source library that is easy to integrate.
The 3rd party app does not need to run a service in foreground mode (BLE connection apps need that in order to not be terminated while in the background).
It simplifies when multiple apps wants to use the same button. Most important, the Flic doesn't need to have a pairing to each app (and force the user to run the pairing process).
If we find and fix bugs or do improvements in our BLE code those fixes can be rolled out directly so that each 3rd party app doesn't have to upgrade their Flic SDK version.
@yuvalshu No, the 500 ms delay can not be changed. If you want something else then you would have to implement your own logic to distinguish between click/doubleClick/hold using the raw down/up events.
@jacques You are correct. On the iOS version of the PbF framework we decided to build in support for both PbF and Flic buttons in the same framework. This was done simply to avoid some problems with namespace clashes, as well as some other unwanted issues. On Android it was more straight forward so we could might as well keep them separated. If anyone want to use PbF + Flic on Android then they can just use both libraries without any issues.
well all i needed flic to do was to interface with an android device accessibility options to act as a switch but flic doesnt show up as a bluetooth device therefore cant be used as a switch to control the device. I did find the warranty policy but i did not find a way to return the product. where do you click to start the return process?
If you feel like you want to return the product then please contact email@example.com and they will help you out. Regarding HID functionally on Android we really wanted to add support for that, but unfortunately we could not do that since Android has some stability issues with HID devices.