maven-XCode built app has runtime error on iOS simulator because of getDisplayWidth function

41 views
Skip to first unread message

P5music

unread,
May 6, 2021, 2:49:54 AM5/6/21
to CodenameOne Discussions

I am trying to execute my app on iOS simulator by means of the maven build system, I have a runtime issue now, for the
getDisplayWidth
function.
This happens at the beginning of the app, where some metrics are calculated for the main form.
Is this error due to my code or to the build or what else?
I provide some file attachments, where you can find all necessary information from XCode.
Thanks in advance
runtime_issues_05052021.rtf
function_issue_05052021.rtf
buildtime_warnings_05052021.rtf

P5music

unread,
May 6, 2021, 4:54:26 AM5/6/21
to CodenameOne Discussions
(please also read the previous message)
I have to say that this is what I found at the end of the XCode compilation (the app started and then closed but I did not see that, I was not watching), but after some time I tried to run the app and it started without error.
It just does not work as expected, but I do not think it is related to the mentioned issue, because metrics are correct.
[The app just does not let the user to click buttons.
In the iOS simulator when I click a button in my special CommandDialog instances, I see that the underlying BrowserComponents in the layout blink black for a moment, but the button click has no effect.
It seems that the dialog is not closing, so I have to check that.]
Regards

Steve Hannah

unread,
May 6, 2021, 10:04:00 AM5/6/21
to codenameone...@googlegroups.com
Native components (e.g. Browser Component) are flaky in the Xcode simulator.  If you make heavy use of them, you should debug on device and skip the Xcode simulator.
(NOTE: for people finding this out of context, I'm just referring to the iOS Xcode simulator that ships with Apple's development tools - not to be confused with the Codename One simulator, on which native components such as BrowserComponent work find).

--
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 codenameone-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/9becf1ea-6c5f-4c51-b64f-16b616f9786cn%40googlegroups.com.


--
Steve Hannah
Software Developer
Codename One

P5music

unread,
May 6, 2021, 11:34:10 AM5/6/21
to CodenameOne Discussions
The blocking issue happens also on real iPad II device, that is, the CommandDialog not closing. But the button are pressed and the action is executed as far as I understand by testing.
The issue is not happening on Android or CN simulator instead.
I would like to know if there are differences in threading such that the CommandDialog mechanism does not work.

The CommandDialog has a background AlertDialog and it has another AlertDialog upon the background one.
After one of the buttons is pressed the action is executed and both the dialogs are closed.

There is a blocking instruction inside that is released.
But I would like to know if it is differently handled on iOS.
invokeAndBlock(runnable);
is the instruction, where

runnable=new Runnable() {
    @Override
    public void run() {
  thread=Thread.currentThread();
        try {
            Thread.sleep(60*60*1000);
        } catch (InterruptedException e) {
            afterActions();
        }

    }
};

and

button.addActionListener(new ActionListener() {
                    @Override
                    public void actionPerformed(ActionEvent evt) {
                        globalCommand = command;
                        System.out.println("button listener called");
                        thread.interrupt();
                    }
                });

Furthermore, I do not know if it is relevant,
but I created a method
fakeShow()
that has to be called in the form's showListener,
creating and closing a fake CommandDialog, this somehow allowed the subsequent CommandDialogs to work, maybe making some initial "cleaning".

(in the showListener of forms)
CommandDialog emptyDialogToBeOpenedForOtherDialogsToSpread=
                        new CommandDialog(currentForm);
                emptyDialogToBeOpenedForOtherDialogsToSpread.fakeShow();

I cannot recall exactly, but it fixed similar issue on Android and CN simulator, so I wonder if on iOS there is something similar but that the workaround is not useful to fix.

Thanks
Regards

Shai Almog

unread,
May 6, 2021, 10:47:15 PM5/6/21
to CodenameOne Discussions
I would recommend removing the invokeAndBlock if possible. There are sometimes complex side effects to using it.
Also, is CommandDialog an InteractionDialog or Dialog?

P5music

unread,
May 7, 2021, 7:49:13 AM5/7/21
to CodenameOne Discussions
CommandDialog is made of InteractonDialogs.
My app is very simple, so nothing is going on while the dialog block it. It is not harmful.
It works on Android and CN simulator in fact.

I just need some powerful method to interrupt the thread (see my code above), because
thread.interrupt() maybe is not enough for iOS in this case.
I debugged in the iOS simulator (iPad 8th gen, new OS) and the execution gets inside the button listener but the thread is not interrupted. The same happens or a real device (iPad II, old OS)
Maybe some other instructions help this happen.

Regards

Shai Almog

unread,
May 8, 2021, 12:14:55 AM5/8/21
to CodenameOne Discussions
It doesn't matter what you do in the background. It matters where you invoke the block from and in which chain.
If it's simple you're better off using asynchronous callbacks and it will be more performant.
Reply all
Reply to author
Forward
0 new messages