One way to resolve this problem by making your MapLayout's
layoutContainer() method resilient to re-entry.
E.g.
private boolean inLayout;
public void layoutContainer(Container c) {
if (inLayout) {
return;
}
inLayout = true;
try {
... the current body of your layoutContainer method
} finally {
inLayout = false;
}
}
I'll likely make a similar change to ours.
On Sun, Aug 12, 2018 at 9:47 PM, Thomas <[email protected]> wrote:
> I don't think that the current cn1 native map implementation has an
> asynchronous version of functions for transforming screen position from/to
> geo position.
> Anyway, there is something I am not sure to understand in how CN1
> invokeAndBlock
> works. I thought that with an invokeAndBlock call, the whole app process
> was paused until what is in the block complete (so if it is a call to a
> native android call like here, it will wait for android to answer befor
> pursuing). So how can this result into nested mutiple invokeAndBlock
> calls? once the first invokeAndBlock call is called (by the
> calcScreenPosition
> of the first marker of the map), wouldn't the process wait for the android
> answer before pursuing to the next calcScreenPosition (for the next
> marker) that will be processed with an invokeAndBlock too, that should
> block any further line of code /loop step to be executed until android
> answer and so on...?
>
> On Monday, August 13, 2018 at 6:31:54 AM UTC+2, Shai Almog wrote:
>
>> You will notice in the stack trace several calls to calcScreenPosition
>> which trigger native synchronous calls and effectively call a deep nest of
>> invokeAndBlock.
>> What happens is this:
>>
>> - You ask for screen coordinates
>> - Map cn1lib goes into Android and asks for this but because this needs
>> to run on the native android thread it uses invokeAndBlock to wait for the
>> Android native thread
>> - Android takes a while to complete the answer
>> - While Android is taking its time you ask for screen coordinates again
>> and again...
>>
>> This ends up nesting invoke and block calls which creates problems after
>> some depth. It's a powerful tool but it's meant for coarse things not
>> things you do often. I'm not sure if the current maps have an asynchronous
>> version of the API but if it does you need to use that API. If not we'll
>> need to add such an API.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "CodenameOne Discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> Visit this group at https://groups.google.com/
> group/codenameone-discussions.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/codenameone-discussions/5f472865-69b7-4c70-b54f-
> c37ec89147ca%40googlegroups.com
> <https://groups.google.com/d/msgid/codenameone-discussions/5f472865-69b7-4c70-b54f-c37ec89147ca%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Steve Hannah
Software Developer
Codename One
http://www.codenameone.com
--
You received this message because you are subscribed to the Google Groups
"CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/CAGOYrKVsVZekZ%3Dbcxr%2BWXyD2L0DG_d8N4qD-LCf_54dzT5%3DeVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
