I think @leehu covered all the important points. Modal loops are completely unsupported on Android, so code that uses modal loops cannot be ported. Code that was written with modal loops disabled from the outset should be portable with no additional changes.
For the most part, modal functions have asynchronous equivalents, and it should be reasonably straightforward to convert modal code to be asynchronous.
In a future release of JUCE, we are planning to set JUCE_MODAL_LOOPS_PERMITTED to zero on all platforms by default, which should make it easier to write completely portable code. Of course, it will still be possible to enable modal loops on platforms that support this feature, for backwards compatibility.
hi - thx. yes, have seen that. sorry, some of the text got missed form my last post as I wondered if there are any hints anywhere as to how to rewrite existing code, such as the bit I provided, without using modal loops?
The example projects (e.g. the WidgetsDemo) shows how to use CallOutBox::launchAsynchronously, and the class docs for CallOutBox has a code snippet showing how this function can be used.
@tpoole updated all of the demo projects to avoid modal loops, so those are probably a good place to start if you’re unsure how to rewrite usages of modal functions.
That’s more a job for @FigBug, since he wrote Gin. I assume that this will happen rather sooner than later. We are using Gin, but mainly for the Image functions and some odds and ends.