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...
Thanks Ramiro, do not worry, I have the problem in AI2 and AI2 Offline also. May be the same problem, I will check soon if reimport the aia solves the problem. Before I need some refactoring on Screen1 and Main in any case because Screen1 became too heavy so I would prefer to switch between Screen1 and Main screen to have less memory used (actually Screen1 is always in background so a lot of memory is used for nothing).
No, I was using AI2 with the companion, everything worked well. Then I built the apk and the problem arised. Then, as usual, I imported the aia into AI2 Offline that shown the problem too. After the suggestion of Ramiro I watched the package name in AI2 Offline and I saw that until the previous import it was com.ai2offline..test.AudioGuideLVARS079TDB and in the "broken" import it becames com.ai2offline.test.AudioGuideLVARS079TDB.Main.scm that obviously I did not change because I imported the AI2 aia leaving selected the option for "Use default package". I do not know where I may check to see the package name given by AI2 apart searching the Android folders but something went wrong in AI2 and shown also in the name of the package imported in AI2 Offline.
After some trials I found a solution very similar to Romiro suggestion that works. I had need one more step. I just report the working one but I found it after 3 different trials.
- In AI2 Offline: Save as... the aia with a different name. (building the new aia still had the problem)
- Export the saved as aia
- Import the saved as aia selecting a new package name as com.aiotech.net.savedas
- Build the aia, install the apk and verify that everything works
- Import the saved as aia in AI2
- In AI2 build the aia, install the apk and verify that everything works
We do not help people who use a different distribution than ai2 online. We also do not solve problems with importing projects made in other distributions and compatibility. When importing your project from offline to online, ai2 gives you an error that the project was made with a different builder. Ai2 does not guarantee that projects imported from another builder will work correctly. If you want help from us, build your projects completely online, and import them to the offline version, not the other way around. We will also require you to show an appropriate project constructed in the ai2 online version that shows the problem. Otherwise, it is a waste of time for us to look for a problem that does not exist.
If you had read with some attention my answer, you should had understand that I was working using AI2 online using the companion. Using the companion it worked. Then I built the apk using AI2 and the problem arised. After that, as usual, I imported the aia in AI2 Offline that showed the same problem too. The aia with the companion worked but not the apk built by AI2 Offline.
So, the problem is born in AI2 but the way to solve it was using AI2 Offline that solved for both. If I was not using also AI2 Offline, I had not a workable solution. Hopefully Ramiro reads also this forum also if he is the maintainer of AI2 Offline. Anyway I think "Houston we have a problem" because AI2 broken my apk package while it built it.