Viewing 4 posts - 1 through 4 (of 4 total)
May 7, 2016 at 11:00 pm
I hadn’t discovered it earlier, because of how I’d been starting my app, and my camera. If I start the app, and then the FLIR One, the app crashes as soon as it detects the FLIR One. However, the app does NOT crash if the FLIR One is running BEFORE the app is started. It then detects the FLIR One at the moment the app is started, and runs as normal. This is how I’d been testing my app, but just now tried it the other way, starting the app first, and then turning on the FLIR One, and now it crashes. Also, there’s no problem with the simulated device.
Does this sound like a problem other people have been having? Is this common? I have like a thousand lines of code in my app, so I have NO IDEA where it might be messing up. I don’t even know if it’s my app, or a bug in the SDK module. If this is a common error people are having, and it is resulting from a common set of lines of code that people tend to use, if this is the case, and there is a known fix, please let me know. I hope a FLIR employee will reply to this, preferably one who was on the team that created the FLIR One SDK in the first place, and will be able to let me know if this is a common problem, and how to fix it.
And the most terrible thing about it, is that if there was SOME WAY to connect my phone to my PC for debugging (maybe over wireless LAN), while also using the real hardware FLIR One (which means no USB cable for debugging is possible), then I could probably find exactly where the bug was in a matter of minutes. Sadly, there’s no way to use the real FLIR One hardware while debugging the app in android studio. I don’t think there’s any possibility to do debugging over wireless LAN.
May 7, 2016 at 11:39 pm
I finally figured out what’s going wrong with my app. I managed to figure out how to do exactly what I had believed to be impossible (as I stated in my opening post), and that’s to wirelessly debug an app. In so doing, I have now managed to figure out what is wrong.
When I first created my app, I had followed FLIR’s instructions for configuring the manifest of the app to recognize when the device ID for FLIR One is detected as the plugged in USB device, the app (if not already running) is started. But here’s the problem. Not only does this auto-detection of the FLIR One trigger the app to start if it’s not running already, it also triggers the onCreate event to fire again if the app is already running. Now in the onCreate event, I have all the code required to set up my app including the running of the command Device.startDiscovery(this, this);
This command needs to be run once, in order for the app to detect that the FLIR One is connected, so that all the other parts of the app can use the FLIR One for getting and using an image. Of course it is intended to be run ONLY once. Because the onCreate event is triggered a second time when the FLIR One is connected, if the app was already running, that also causes the command Device.startDiscovery(this, this); to be rerun. Needless to say, this quickly crashes the app.
I need a way of allowing the Android OS to recognize that the app is already running, and to prevent the Android OS from attempting to re-run the app when the device is detected if the app is already running. Either that, or I need a way of causing the app to skip running the onCreate event, if the app detects that it itself is already running. Is there any way to do this? Or is this a bug in the FLIR One SDK module itself, that will need to be corrected in a later version of the module (and until then, I will need to just put up with my app being buggy)?
May 8, 2016 at 12:05 am
And, it looks like I finally managed to solve my own problem. This attribute
was needed to be included in the activity tag in the manifest file for the app. This prevents the Android OS from trying to start a new instance of the app if it’s already running, when the FLIR One is connected to it.
May 9, 2016 at 12:56 pmModerator
I’m glad that you were able to resolve your issue. I’ll see if we can update the documentation on this or if this is intended.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic.