Catching Back button on BluetoothMidiDevicePairingDialogue

I’m able to successfully connect Bluetooth MIDI controllers using BluetoothMidiDevicePairingDialogue::open(), but I’m so far unable to close the dialog elegantly, because Back button just closes the app, without passing through the back handles of my activity (works for everything else).

Clicking outside the table works just fine (table disappears), but Back button closes the app.

I have checked the DemoRunner app, and there it looks like the Back button disappears when the bluetooth dialog is displayed (that would also work).

Any help on this would be gladly appreciated.

Which platform? Android? iOS?

Android

Typically on Android whenever the Back button doesn’t behave as expected its related to the interaction between your Activity and whatever Fragments you may have implemented. Check that you have “app:defaultNavHost=“true”“ set for your Fragments - otherwise the default activity behaviour will be wired up, which is to quit your app when the Back button is pressed.

EDIT: see if any of the solutions proposed here make an impact:

I’m not using any Fragments in my app, apart from the ones used in JUCE code in the background.

If it can help, I’m getting the following call-stack when placing a breakpoint on my app’s activity finish() method:

finish(), (com.swarsystems.myapp)
handleBackButton:-1, ComponentPeerView (com.rmsl.juce)
backButtonPressed:405, ComponentPeerView (com.rmsl.juce)
onKeyDown:426, ComponentPeerView (com.rmsl.juce)

Also I’m on JUCE 7.0.9

It seems the issue is in juce_Windowing_android.cpp, in the handleBackButtonCallback() we try to branch to the JUCEApplicationBase backButtonPressed() method. In my case, JUCEApplicationBase::getInstance() returns NULL (I don’t think I declared that in my code).

Should an Android app have a JUCEApplicationBase instance, and if so, how to declare it?

If you have a C++/JUCE app from the ground up - where you inherit JUCEApplication and fill out the functions to suit your needs, then call START_JUCE_APPLICATION - your app instance should not be null.

Otherwise, if you’re simply calling ScopedJuceInitialiser_GUI somewhere, this is probably a weird grey area…

You’ll have to provide more context about your project so we can help you.

The app was buit over 15 years back, I think, so I don’t think it follows any of the 2 options you mentioned. I starts as a normal Android app in the Java activity, then calls a native method constructNativeClass to build the native activity that gives access to all JUCE cpp code.

Your issue is that the JUCEApplication instance is null. Work back from that.

1 Like

Yeah, it looks like this could be solved by instantiating a JUCEApplication. However, since the app is quite complex and works perfectly the way I described above, I’ll have to find out how to do that, so it doesn’t disturb the current flow.