I have the same o similar mistakes as @Anke . I can well to go from Screen1 to Screen2 and all runs well. But when I return from Screen2 to Screen1 I have several irritants errors on the Screen1. @ewpatton What can I do? I was waiting a lot of time for this version to correct this mistake.
The build server update aimed to address issues with the screen not initializing. If you're also having issues with closed screens that is a technically different issue. It's best for me if you can produce a small example project that fails so I can incorporate it into my testing.
However, I figured out how to prevent it. It was an endless process of trial and error... I didn't change anything about the blocks. But then it works without any issues. However, it makes no sense at all why it works then. So I'd rather not share my supposed solution for now.
Append with easy example. It is a very simple AIA that includes the Apple profile to compile your IPA. You need test with a builder IPA. And only use blocks for open and close screens.
Only just navigate from Scrren1 to Sceren2 and return from Screen2 to Screen1. I never close Screen1, which is main. I only close Screen2 every time that I return to Screen1.
If you do the cycle of going and returning to the 5 or 6 times, the irritating error appears. In my real app that has many blocks, the error is generated only wiht 1 or 2 times of navigation between screens.
You can also see another error in Screen1 that the OtherScreenClosed block is never executed as @Anke has reported
I think it only happens if you have the Timer, but I haven't verified this. The screens are all scrolling=responsive.
I have not tried from Screen2 to Screen3 like Anke because if I fail this basic one with only 2 Screens less will work with 3 Screens.
If I detect more things I will report them to help.
@Anke , could you share by PM the workaround that you have found?. I don't know if is possible to have a workarounf for this issue waiting a MIT solution. Thank you.
and then OtherScreenClosed will receive the screen name and value.
The BackPressed event will only work on iOS 16+ right now (we are using navigationItem.backAction to override the default behavior but this was only added in iOS 16). If you intercept the BackPressed you are responsible for calling one of the close screen blocks just like on the Android version.
Ok, so the “< Screen1” button doesn’t trigger the “BackPressed” event?
If so, I need to disable “TitleVisible” because this button (“< Screen1”) doesn't trigger an event and therefore I don't know which screen was closed.
About the current problems in the Screen Navigation when we have a Runtime Error if we use Timer and / or repeat the navigation a few times I think that I have a easy solution.
Test you the attached aia, (only with IPAs), please. May be you can see more things about what is happening in this isssue. This example has a 3 screens full circular navigations between all the screens (1 go/back 2-3, 2 go/back 3-1 and 3 go/back1-2 with Buttons and also with BackPressed).
The most important topic I have found is Close and Re-Open the Screen1 in the OtherScreenClose event of the Screen1.
I would appreciate your analysis and comments. Thanks.
@ewpatton . May be you can see why is it happen different as Android (in Android we have always Open the Screen1). It is very curious topic from my point of view. This solution runs well in Android and Apple but the Sreen1 is re-open and for the App is not a good solution because the Screen1 is not in the last call-screens position (for my App is good, but may be for others Apps it is not a good solution).
I have carried out different tests on the topic of Screen Navigation. I have found a fairly simple and easy solution to avoid the Runtime Error in iOS after a few navigation steps when you have an active Timer on Screen1.
@ewpatton
For me it is a good solution managing with the same AIA when I'm in Android or iOS.
Additional visual improvement comment: If you test both AIA you can see what in Android the change between screens is not visible. In iOS we have always a intermediate Screen1 visible between we are moving for example from Screen2 to Screen3 (I think this issue was before reported for @Anke). For me is not problematic.
