I created a simple test app that changes 4 screens. Screen1, Screen2, Screen3, Menu. Screen2 and Screen3 are identical. The method of screen switching is the same for Screen2, Screen3 and Menu. (Screen1 cannot be closed on iOS).
Switching between Screen1 & Screen3 works as often as you like and without any problems. Switching between Screen1 & Screen2 works a maximum of 4-5 times, then the app crashes or freezes. The problem can be reproduced as often as required.
However, switching from Screen1 to Menu and then only between Menu and Screen2 seems to work without any problems (although occasional error messages occur there).
Tested with IPA (ad hoc) on three of my test devices:
(Of course I removed the provisioning profile from the aia, as well as the app icon.)
PS: (1) I'll address numerous layout problems between Companion and IPA in another topic(s). (2) However, the fact that the Screen.Initialize events do not work (with the IPA) can apparently be caught with timers, but it is annoying and should be fixed.
By the way, I'm offering $50 to anyone who can find the cause of this (i.e. why switching between Screen1 and Screen2 only works a few times). ─ However, this reward does not apply to the MIT team.
Let's say you navigated through these screens:
Screen 1 > Screen 2 > Screen 1 > Screen 3 > Screen 1 > Screen 2 > Screen 3 > Screen 1
Although it appears that you have opened 3 screens here, you will have 8 screens open in total. You actually think that you are back to screen 1, yes you are on screen 1, but you are on an imaginary screen 1, this screen 1 is not the screen 1 where the application opens, it is Screen 1i.
So you have 8 screens,
screen 1,
Screen 1i,
Screen 1iii,
Screen 1iv,
screen 2,
Screen 2i,
screen 3,
Screen 3i.
Cycle through screens 2 and 3, never returning to screen 1, and each time turn off the previous screen.
did you try the manager screen method of switching screens?
The mixture of methods you are using (Screen1 stays open and other screens use the Tribblehunter method) probably does not work in iOS?
Btw. why don't you use one method consequently for all screens, i.e. manager screen method OR Tribblehunter method?
I don't mix anything. I do it the same way I've always done it (at least for almost all of my Android apps).
See here:
And as I said before, on iOS Screen1 cannot be closed, so there are always exactly 2 screens open at the same time after another screen from Screen1 is opened. Afterwards, all other non-Screen1 screens will be closed again as long as you do not return to Screen1. In the latter case, of course, only 1 screen (namely Screen1) is open.
So that's not the problem. Because as I already mentioned, switching between Screen1 and Screen3 works as often as you like without any problems. Switching between Screen1 and Screen3 doesn't work as often as you like, but leads to a crash after 4-5 attempts at the latest.
So there must be a problem with Screen2, even though it is identical to Screen3. By the way, I have now found the cause of this (after hours of trying). I would never have expected the result or thought it was possible as a cause.
How is it different from what I have already done? Furthermore, there is no Screen.otherScreenClosed event on iOS, at least it is not triggered, if the "close screen" block is used.
EDIT:
I have now tested the manager screen method again. When switching the non-Screen1 screens and then using the iOS back button ( < ), the current screen is called up again. Screen1 can then no longer be accessed and can only be accessed via a separate "close screen" button.
Nobody understands such a navigation and it would drive a “normal” user crazy.
For clarity's sake, on iOS all of the App Inventor screens are subclasses of UIViewController. The app itself at the top level is a UINavigationController with the root view being Screen1. Opening a screen is equivalent to pushing a new instance of the screen onto the UINavigationController's viewController stack. Closing a screen is equivalent to popping the calling screen off of that stack. This is slightly different to Android where the activity stack is managed more by the Android framework and activities can be somewhat independently closed/opened. In theory we could support something like the tribblehunter method where a screen is both open and closed within the same event handler, but I think it might be better to keep to the underlying semantics of how the stack-based view system is supposed to work since both platforms provide some form of "back" button.
The compiled app (IPA) does not work on any of my 4 iOS test devices (3 iPhones (iPhone 6s, 13, 15 Pro Max, iPad Pro 12.9).
Please test this app (as IPA) on your iOS devices. As soon as the screens have been switched 5-10 times, error messages appear, the app crashes or screens can no longer be switched.
Before we continue to discuss individual problems with components and other details, the basic problem of switching screens should first be resolved.
If this cannot be solved (satisfactorily), the only option left is to do it via “virtual screens”. This would mean a complete overhaul of existing apps and would also raise the question of whether there would be a limit to the number of blocks allowed on a single screen.
PS:
I found a way though to get this app to run (so that there are no errors and crashes), but unfortunately that doesn't solve the problem(s) of switching screens in other more complex apps. Finding the solution for this simple test app was already a long process of trial and error.
Another question is whether there is a way to switch between 2 non-Screen1 screens WITHOUT this switch first going through Screen1.
To clarify, you mean going from something like Screen2 to Screen3 without leaving Screen2 on the activity stack, correct? Otherwise, you can certainly open Screen3 from Screen2. I usually test with our BostonTourGuide app which has 3 screens but the first opens the second opens the third.
I think the stability issues may be related to garbage collection. Eventually, after opening enough screens the garbage collector gets triggered and erroneously cleans up older screens that are technically still alive. I will look further to see if that hypothesis holds up.
In my tests with real AIA when I'm in Screen2 without doing nothing after 20 or 40 seconds the app close itself. It seems your suspect over the iOS garbage collector can be right because my app close itself without any hand operation on Screen2 visible.
Yes, I noticed that in various of my apps too. That's why I first tried a simple app that doesn't have this problem. To find the cause, you must gradually remove all components until the problem no longer occurs. This is very long and tedious, but without knowing the cause, I don't see any other way.
And that's why I said that the first thing that needs to be clarified is how exactly switching works under AppInventor for iOS.
A very simple test with real AIAs. We open Screen1 with Timer and Location sensors. Then we open a Screen2 previously disabling the Timer and the GPS of Screen1. No operation is performed on Screen2. After a few seconds the App closes by itself. It is as if an iOS process deleted or stoped the App since without performing any operation, it closes by itself. The iOS operative system close the app in this case when we have the Screen1 on the second position or undergrund.
May be iOS has a special process to close the Apps in undergrund position that we don't know the selection algorithm.
I'm sorry @Anke. The real AIA has sensible data about web access and others.
But with examples happens the same (we only need wait more seconds to stop the app)
