Make flic button send keyboard input to Android
I'm currently developing an android application and looking for the possibility to make the flic buttons to send keyboard input directly to Android. The application is built in Unity and is therefore a bit tricky (impossible?) to use the SDK supplied by you. I cannot find any option in the built in list of actions in the Flic application. Are there some easy solutions you guys here knows of? Looked a bit on the Intent option in the application, but it also seems like a dead end... I would like a mode where the buttons can be used as keys on a keyboard for example. Is this doable?
Thanks for the update and I have now further investigated the changes and the 300 ms input lag is gone in active mode as suspected. Very appreciated! The reaction times are now more or less correct when compared to other applications. Maybe still a little slower in measuring reaction times using these buttons together with the Unity Engine. It's however hard to say where the bottleneck is, if it is in the button detecting and sending the presses to the Android OS, or in Unity Engine detecting the press events etc.
Thank you for the feedback provided in this tread.
Have a nice day!
@brainstimulationab Seems like active mode for some reason doesn't work correctly in latest app versions. Will investigate the problem and release new app next week.
I've semi-solved the problem by using an external activity, much like the demo one to connect the Flic buttons to it and simbly make a Unity wrapper class that asks it if a button has been pressed. Not a nice fancy solution but a dirty one that at least has the functionality!
In my experiments I've measured the input delay on active mode and it seems to be around 300 ms, is that something you can confirm or deny? It may depend on the hardware receiving the signals as well...
For other people looking for Unity integration of their Flic buttons I would recommend to do this way at least for now, remember to read up on launching activities from Unity, how to communicate with these and how to structure everything in the project. I can't share any of my code but there are some good starting advice.
@Emil Yeah, that's what I figured from the sounds, The active mode surely have lower latency but playing a flappy-incarnation with that delay was... special :) Where can you active this mode for other applications? Via the SDK or settings in the applications? I looked around and did not find anything...
I want to measure reaction times with my application and I think that the Flic buttons are not fully suitable for this purpose due to the input latency, however they could be if the latency is constant and do you have any public datasheet with these kind of specifications for the buttons?
I'm not an expert on the Android system so I don't really know what would be the best approach in this case, however I do know from my experiments the last couple of days that as you use the SDK today is not compatible with Unity based applications for Android.
In an Unity based application the flow is as described below:
The main Unity Activity is fetch in a C# java object wrapper. The C# code then instantiates a Java holder class with the main activity passed as a parameter. The C# code then calls a method of the newly created Java object to start a new Activity (which hold the code for grabbing the buttons). The activity is created, then from the C# code the started activity is fetched into a Java wrapper object. Then C# code calls the initiation of the buttons as explained in the "Tutorial". The Flic Grabber screen is shown and I can choose which Flic I would like to grab. So far, so good.
Then when the grabber thinks it is done it is closed, but since I cannot make the Unity main activity have the onActivityResult method the result from the Flic grabber is not processed correctly (I think) when the onActivityResult method is implemented in the Java activity i instantiated.
Do this make any sense to you or do I need to explain more?
I'm glad you are taking your time to look into this! Have a nice day,
I've read up on broadcast receivers and stuff and it seems to be a possible solution for Unity applications.
@brainstimulationab We have an intentional delay of half a second or so in order to be able to distinguish click / double click / hold. However with our SDK you also have button up / down so you get lower latency. You can also activate something we call "active mode" which lowers the Bluetooth connection interval, making it even more responsive. You can try our "Flappy Flic" game on Google Play to see the latency in action.
If we modified the SDK, would it work if we dropped the startActivityForResult/onActivityResult and used other way to bring up the activity from our application and then delivered the result to your app as for example an intent through a broadcastreceiver instead?
Oh, that did not sound good at all, I can understand that decision. However it seems very hard to connect the flic buttons to an Android Unity application since the SDK needs to use the main activity. I have tried to work around it, but I think I cannot do anything more since the usage of onActivityResult(int, int, Intent) method and one can't really extend the Unity activity to use the required function, or is there a convenient way you or some other user know of?
I have noticed that the flic buttons does not react instantly to input, there is a small delay, or rather a small delay until the button press sound is played on the android device, is there a input delay in the button before sending the press signal or is it in the android device? You have any idea?
@brainstimulationab Actually we did implement functionality a while ago that enabled Flic to send generic keyboard events to the Android system using the HID profile. The problem that we noticed though was that Android had a lot of bugs/issues that caused bluetooth to become very unstable when using the HID profile. Actually the bugs were so severe that it would cause the phone to randomly crash and reboot. On some occasions it would even drop bonding keys randomly.. Due to this we had to make the decision to not release it. Apart from this I unfortunately do not have a good solution.