Compiled iOS app (IPA) crashes when switching screens ─ $50 reward for why

[Anke]

@Ferran_SIMON

with examples happens the same

What about posting this simple example aia...

[Ferran_SIMON]

testNavigation_iOS2.aia (8.8 KB)

[ewpatton]

Thanks. I will run some tests on this and see what I can learn.

[Anke]

@Ferran_SIMON

testNavigation_iOS2.aia

@ewpatton

and see what I can learn

Unfortunately, I couldn't learn anything except what I already knew, namely that you shouldn't open any screen (especially not Screen1) twice. I have modified the app (blocks) so that switching the screens should now work properly.

But as I said, switching between Screen2 and 3 always goes through Screen1 first.

testNavigation_iOS2a.aia (17.1 KB)

[Anke]

@Anke

But as I said, switching between Screen2 and 3 always goes through Screen1 first.

So my question again:
How does switching screens work correctly in AppInventor for iOS? In other words, does navigation basically have to be done via Screen1?
@ewpatton

[ewpatton]

Again, it depends on what you are trying to accomplish, and I think the answer is that what you want to do you just cannot do with how screen switching is implemented in iOS. In iOS we have a UINavigationController at the root of the view hierarchy and its first item in its stack is Screen1. If you open Screen2, it is pushed onto the nav stack. If you want to do what your test app does which is both close and open a screen simultaneously, this results in a pop operation on the UINavigationController which goes back to Screen1 and then a push to open Screen3. On Android, the framework doesn't seem to bother drawing Screen1 when an activity is finished but an intent is pending to open a new screen but that's not the case with the iOS code.

In order for this to work, I will have to add some code to the navigation logic to detect when this sequence of events is triggered and then swap the behavior out for something more like what Android does (although what iOS does is technically correct based on the code you've written--it closes the screen then opens the new one).

[ewpatton]

@ewpatton

In order for this to work, I will have to add some code to the navigation logic to detect when this sequence of events is triggered and then swap the behavior out for something more like what Android does (although what iOS does is technically correct based on the code you've written--it closes the screen then opens the new one).

I think I have coded something that mimics this behavior. I will need to figure out how best to deploy a parallel build infrastructure for you to test it.

[ewpatton]

So in testing I was able to confirm also that the issue with the bad irritant messages when screen switching comes down to the garbage collector erroneously cleaning up some references to the other screens in the stack. I applied some code in an attempt to mitigate it but it still happens. I need to dive into that code and figure out why objects that should be marked as alive are not.

[Anke]

@ewpatton

If you want to do what your test app does which is both close and open a screen simultaneously, this results in a pop operation on the UINavigationController which goes back to Screen1 and then a push to open Screen3.

Thank you for the detailed explanations.
So if switching between Screen2 and 3 necessarily takes place first via Screen1, then that's just how it is. Then I have to adapt the navigation of my app(s) accordingly. All non-Screen1 screens should then generally be navigated (only) via Screen1.

Every non-Screen1 screen can then only be exited using the Back button (< / top left), which leads back to Screen1. I haven't noticed any problems with this way of navigation yet.

[ewpatton]

I've just posted an update to the build server thread. I think I have come up with a way to make the screen switching work similar to how it does on Android. Please take a look.

iOS build server updated to 2.64.6 (rev 3)

Hello everyone, I have updated the build server to version 2.64.6 rev 6. This update contains the following changes: Implement support for the "Tribblehunter" method of screen switching Address some memory management issues that could cause screens and event handlers to be prematurely garbage collected Fix an issue that would cause components and event handlers to be redefined Address new orientation functionality added in iOS 16 Make it so that packaged apps will quit if Screen1 is closed Co…

[Anke]

@ewpatton

I think I have come up with a way to make the screen switching work similar to how it does on Android.

WOW, great!
Works perfectly on an iPhone 15 Pro Max (iOS 17.4.1).

[Ferran_SIMON]

@ewpatton

So in testing I was able to confirm also that the issue with the bad irritant messages when screen switching comes down to the garbage collector erroneously cleaning up some references to the other screens in the stack. I applied some code in an attempt to mitigate it but it still happens. I need to dive into that code and figure out why objects that should be marked as alive are not.

Hello,
I have tested the new builder version and the Screens Navigation runs well with my real and big AIA. Now I have not the irritant error when switch from Screen2 to Screen1.
Congratulations for a good work.