When opening and closing screens correctly, there should be no problem with screens, including memory. If you do it incorrectly, you may have a memory problem.
I made a short app that mimics exactly how my original app opens and closes the screens. In this case the screens are pretty empty but it works so the problem should not be related to screen switching.
TestNestingScreens.aia (12.9 KB)
So you answered yourself. No problem with screen switching 
. So what is the problem with this topic?
I am investigating.... because in the demo app to test screen switching everything works as I would had expected since the beginning but the app still has the problem. So, the problem is not solved but at least I eliminated one possible cause.
Yes, apps with more than 10 screens can also work well (especially if they are not too "heavy"). The 10 screens rule is only a (strong) recommendation.
1 Like
I mainly follow this rule. The aia in a previous post basically shows the screen management of my real app. I just put buttons instead logic to decide to open PlayAudio or PlayImage or PlayVideo but it is just a if.. else if checking the media file type so no far from to have 3 buttons instead.
Shortly: the app starts in Screen1 that remain active to init everything. Only the first time some TinyDBs are empty so Screen1 opens DonwloadData Screen (that is not present in my demo app) then comes back to Screen1 and then Screen1 opens Main Screen. Main Screen basically is a menu, 5 buttons to open other screens and one button to close the app. In Main Screen one button opens the Guide Screen. This is basically a QR code reader, in the QR there is a link to a media file (downoaded the 1st time, work done in DownloadData Screen automatically) and depending on the media file type it opens one of the three Play Scrrens (PlayAudio, PlayImg,PlayVideo). At the end the user closes the PlayXX Screen and then comes back to the Guide Screen. So I think to have 1 screen active and other 3 screens opened in the worst case. I could merge Screen1 and Main without much work I think. If it will be not sufficient, always with the idea t reduce the number of screen in backgroung, after having identified the type of media file instead of open the right Play screen I could close Guide screen so Main screen and from Main I could open the right Play Screen. I do not think merging the 3 Play screen in one screen may be of any help considering that seems not to be related to the total number of screens.
No.
The switching seems to be correct if you actually have a maximum of 3 screens open at the same time. If it's not a problem with the switching logic you didn't include in the example that you mention, then you can try keeping only one screen open and the rest closed.. Unless you are missing some detail that actually makes the number of open screens increase in memory.
Why no? In any case looking in the aia I found everything, no screen is missing, the call inside Guide screen neither. So, if something is missing it should be in the apk, always if the error message is correct.
Try this:
TestNestingScreens_revised.aia (15.5 KB)
Screen1 remains open to stop it be re-initialised when returning from Main. (Hence the use of tinydb on Screen1 and Main)
All other screens are closed when another screen is opened.
To test, you will need to compile to an apk for this to work properly.
The critics I made to myself is about Screen1. The 1st release of this app is old, arund 2018 and then it was updated so many times that this new release will be very far from the original. Originally Screen1 was just the "right place" to have a full screen splash screen to show until the app initialize everything but the original had few blocks, around 300 blocks. Actually it has 1065 blocks and I woud have to add some more, probably around 50-80 blocks. So, Screen1, more or less, is always active in background. Probably make sense to change the logic so that the actual Main screen becomes Screen1 and actual Screen1 becomes Init screen. Main screen is very light, only 255 blocks, so if it becomes Screen1 at the beginning it should open the Init screen, when it finishes to initialize everything can come back to Main and in this way it should not stay in memory. This could be any way a good refactoring in terms of memory used. But I really do not know if it will solve the problem.
We don't know either, because you haven't really presented us with a project that shows this problem... so it's up to you to solve it...
I can post the complete aia, if I didn't before was just to reduce the problem where it happens and because the error message. I will post the exact message in the next post to be more precise and to show it to everyone.
Screenshot of the error message for the screen PlayAudio. For the other "missing" screens just change the name of the screen, everything else is the same. Please, there is a debug notifier white message that is not related to the error, it just checks if the file to play exists. And it exists.
Trying to open another screen right after scanning? Or closing the screen? Show the logic of scanning and opening/closing the screen after scanning.
I look at your modification, if the problem is related to how much memory is used by screens your idea should solve the problem. Anyway seems a lot better then mine original implementation. I have to add some logic to understand when a screen is opened because a child screen closed, actually I manage the situation with the event WhenOtherScreenClosed that I do not believe it may work anymore, but to be sure I will modified your modified version and eventually use another TiniDb tag to manage it.
Many thanks.
Just opens a Play screen without close Guide. The logic is simple: in the AfterScan event stops the QR reader, eventually turn off the light and then there si a if.. else if... with a condition for each media type and a call to open another screen with value. So the Guide screen is not closed before to open one of the Play screens. When the Play screen is closed Guide screen become actives and when OtherScreenClosed is fired it restart the QR scan command.
First, an apology, I know this is not the place for problems related to offline versions, you can check the following link for a problem similar to yours AI2Offline / Discussion / General Discussion: 902 error screen not found
The error shows the package name from the offline version. So after importing the offline project to online, the old package names are left somewhere. So it could be the result of your messing with the offline version...