I am trying to understand how the handling of screes is done, but fail to find clear information
For example, how does this basic case work:
Screen1 with global variables initalized, and an “initialize block”
Screen2 opened by screen one
Screen2 closed
Now we are back at Screen1, but:
Will global variables be initialized again, or do they have their previous values?
Will the “Initialize” block run again?
If there is an “Other screen closed” block, will it run before, after or instead of “initialize”?
I guess the higher level question is are screens are treated like a stack, such that each “open screen” puts the opened screen on top, and each “close sceen” removes the current screen from the stack, such that the calling screen is back. Or if a screen is “gone” (as an entity with a state) once it has called another screen, and restarted from scratch when that screen closes.
The practical case I am trying to achieve is a “history” screen2 in an app which does something on screen1, and opens screen2 with a datastructure that is the history of what is done. Screen2 displays that, in a nice way, and then closes. My wish is to continue from where I was on screen1, but it seems to reset things much more than I would want. But i fail to sort out exactly what it does
I am readig this: App Inventor Tutorials and Examples: Manager Screen | Pura Vida Apps, and my impression is that the screen handling is indeed a proper stack, but that the companion cannot deal with that, so it runs the initialize block even though it should not. Is that so?
So what does this text mean, on the link i provided:
Current limitations of the AI Companion app:
The close screen block triggers the Initialize event instead of the OtherScreenClosed event.
The close screen with value block triggers both the Initialize and OtherScreenClosed events instead of only the OtherScreenClosed event.
The close application block does not work, a message ‘Closing forms is not currently supported during development’ will be displayed instead.
Item 1 and 2 implies very clearly to me that the Initialize should NOT be run when when returning to a screen after another screen closes. The
Also, various advice on how to close a screen to return to the previous one rathe than opening the previous one again, to avoid running out of memory, implies that SOMETHING is saved relating to the first screen. What is that, if not the state of it?
Actually, I find it odd (to the point where it is hard to believe) to not treat the screens as stack of contexts, where you pop the item relating to a screen when you close it.
The silly thing is that I cannot test using an APK; as my mobile phone is not allowing APK’s from untrusted sources (it is my employers policy, so I cannot change it). And on my older private phone, the APK is for some reason refusing to install. The released version of the app works just fine on both, but an APK cannot be installed, for some reason
I pass data through the start value to the second screen, but have no interest in passing any data back. And I know how to use TinyDB, but it would be a ridiculous amount of work for this case: I have a complex multilevel dictionary structure, created from a JSON-file, and as I pull things from it, I create alist of pulled things, which I want to display. Saving and storing that structure with TinyDB just to show a quick status dialog is not realistic.
I can achieve some very rudimentary and ugly version of what i want to do by displaying an alert (which is what i did so far), but wanted to do it a little neater.
I cannot say i understand exactly what you say, but can you please read the link i sent, and tell me if you claim it is wrong? If it is right, I cannot see that I need to expect Initialize to run again upon rhe other screen being closed.
After doing some testing with a version released for internal testing on Google PLay, only to test this, I can conclude that you are likely wrong (or I completely fail to understand what you are trying to say).
Upon “close screen” for screen 2, I get back to screen1, with NO “initialize” being run, no changes to global variables, and everything is the same as it was when i left Screen1 using a “Open other screen” for screen 2. “Other screen closed” is execute for Screen1, which is explicitly different than “initialize”
Things thus seem to work as I would have expected (screen contexts are pushed to a stack as screen opens, and popped when the screen is closed, and the app works on the current top context, basically). The only catch is that this is apparently not working in the companion, which is a very severe limitation of the development environment. But described on the link I posted (and in the text i quoted).
So, it seems there is no need to do some awkward TinyDB tricks to keep the state when opening and then closing another screen. At least so far, it works as I had hoped (except my testing, at least of this part, now needs to happen on released versions on play store, which is annoying and time consuming).
The Companion is pretty good for most things but it certainly has some limitations. I’ve only ever used virtual screens to create multi-screen apps so don’t know how well real screens work on the Companion. The best thing to do is compile an apk and test on that, even though it can be a little annoying.
correct
therefore you will have to test the switching of screens (as it originally was intented by MIT App Inventor using the manager screen method) in an apk file as the companion does have these limitations
alternatively store everything in TinyDB and follow this advice
I cannot install an apk on my phone, as it is governed by my employers policy to not allow apks from unsecure sources. And on my otter phone, the apk refuses to install at all. So apks are not an option. I ended up creating versions för internal test on Google play. The app works fine there, but testing in the companion is not working. I have implemented some workarounds only to get pasta tjat, to be able to test.
My Main screen which opens one secondary screen, which then closes, to return to the main screen, is perfectly fine.
I an surprised it is not better described how this is implemented, instead of complicated advice on how to use it.
The way i understand it, a screen has its entire environment put on the equivalent a call stack, like a function call. When it closes, it is like the function returning, and the environment is removed from the stack.
If you know that, you understand what you need to do, and why the manager screen approach is wise.
If you know this, you also know when you need to use TinyDB. Which is certainly not the case in my case
I honestly have no idea. Trying to install the APK; the phone just says “Something went wrong. The app was not installed”. This is true also for apk’s I installed prevoously, so I suspect something has changed in android, or my settings, as a result of an update (I dd not change anything actively) but I cannot figure out what.
That said, testing using an apk is not efficient compared to using the companion, and testing using an “internal test” version on Google Play is only marginally less efficient that using an apk, so I can live with the apk not working.
Thank you!
The app is released in a version using the second screen the way I tried all along, but failed to get to work in the companion. In the released version, it works as intended, and probably would have done so from the very beginning. Lots of time wasted on what was really just a limitation in the Companion.
