Screen1 "not returning" after other screen closed

[Vincent Goudreault]

Fellows App Inventors,

I am currently developing a relatively complex, multi-screen application (the blocks of one screen need 2 lateral and 7 vertical scrolls at maximum zoom out to cover all the events and procedures, and I have 6 screens with user interface widgets already, so I suppose it qualifies as pretty complex). One of the capability I want to build-in is support for multiple languages, where all the button captions, labels and dialogues are housed in language-coded files (which could even be supplemented by users), one of which is read as a function of the user-selected language, copied in TinyDB, and then accessed by all the relevant screen and used to set up all the relevant text bits through a series of statements in the various screens "Initialize" event.

In order to streamline processing, the actual reading of the language file and the loading of the TinyDB record is done by an auxiliary "shadow" screen, which is opened when the application initializes for the first time, and again should the user select a different language from the currently defined one (through a list picker .AfterPicking event), which is supposed to then override the TinyDB record with the different language captions. That screen is supposed to "close screen with value" at the end of the reading and loading into TinyDB, and hopefully return control to the screen that did the calling, where it should trigger the appropriate ".OtherScreenClosed" event, which will then call whatever procedure to update all the relevant captions and labels in the alternate language using the copy passed through the TinyDB tag.

Except that it doesn't.

When launching the application for the first time, it starts with Screen1, as expected, which then checks if there is an appropriate "loaded language" tag in TinyDB and upon not finding one, calls the language read routine to load the default English file. That screen is supposed to complete the reading and return to Screen1, but all I get after waiting an inordinate amount of time is a blank emulator screen, while the web browser development page in "http://ai2.appinventor.mit.edu/" switches back to the Screen1 block page, indicating that the file reading screen is supposed to be finished with its processing and closing... but somehow the Screen1.OtherScreenClosed event is not triggered.

Not seeing where this comes from, I peppered the code with progress caption markers at the start and end of most concerned procedures and event blocks, directed to a log file that I can visit thereafter. And I do have the proper sequence of 

• "Screen1 calls language reading screen" (that statement is placed just ahead of the "open other screen" call)
  
• "Language reading screen initiate" (at the head of the Initialize block) and the 
  
• "Language reading screen about to return" (at the end of the .GotText block that loaded all into the TinyDB)

being issued, but the expected Screen1.Initialize that ought to follow the return, let alone the message at the start of the Screen1.OtherScreenClosed event block, never comes. And I have waited something like 15 minutes before stopping the emulator and running my "message log file visit" application (where on Earth is /sdcard anyway? I tried searching for the filename across all directories, and can only conclude that this directory is hidden or somehow "encoded". Having to rely on a custom application just to look at the content of the log file is some kind of an additional annoyance).

What is stalling the code?

Are there some additional, little known and poorly documented limitations in the emulator, or in App Inventor 2 itself, like a maximum number of pending processes, that I am unaware of?

For the record, the "aia" file is 648 KB. Even taking all the other files that are supposed to be part of the installation into account (images, data files, icon, etc) brings the total memory requirement to 1.23 MB, far from the limit, as far as I can understand.

I have been at it for over a week already, and not showing any progress; and now, on top of it all, I am out of ideas what to try next.

So, does anyone have anything to suggest? 

Any help would be much appreciated.

Thanks

CBVG

[Taifun]

see here

The recommended method of switching screens in App Inventor

Current limitations of the AI Companion app:

1. The close screen block triggers the Initialize event instead of the OtherScreenClosed event.
2. The close screen with value block triggers both the Initialize and OtherScreenClosed events instead of only the OtherScreenClosed event.
3. The close application block does not work, a message 'Closing forms is not currently supported during development' will be displayed instead.

Taifun

---

Trying to push the limits of App Inventor! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun. 

[Vincent Goudreault]

Did you miss the bit about "close screen with value" visibly NOT triggering either Initialize or OtherScreenClosed, on account of my trace messages not showing any access to those blocks?

I am switching screens EXACTLY following the "recommended method".

[Taifun]

to test switching screens, build you app and test using the apk file

Taifun

[Evan Patton]

Hi Vincent,

Looking at the sources it should be the case that OtherScreenClosed should be triggered. Can you give us an AIA that demonstrates the problem? Regarding Initialize, it will only be called when the Screen is created (analogous to constructors in object oriented languages) so do not expect it to be called when returning from a screen.

Thanks,
Evan

[Vincent Goudreault]

That could take some doing. For the time being, I have disabled to feature so that I can concentrate on checking and debugging the rest of the app; I am wondering if there could be some bad interaction between the pages that are hurting the behaviour in a silent way (given that the emulator will mure error reporting for 5 seconds following the first one, and since the code does so much behind the scene housekeeping, who knows what goes in there at this point in time).

When I can get the other pages to run without error, I will check to see if the OtehrScreenClosed logic is still an issue. If it is, then I will make a most lightweight version of the app featuring the problem for posting. That may take some time.

Thanks for now

CBVG

[Taifun]

as already said: use the apk file for your tests and follow the manager screen method

The recommended method of switching screens in App Inventor

Taifun

[Vincent Goudreault]

After many attempts, and a whole lot of efforts, I think that I managed to corner the issue.

I do not know if this is limited to the emulator or would manifest also on a bona fide Android device, but here goes.

My application is quite lavish in terms of data presented, as I indicated before. Some of those were put in TableArrangement. And I think that they are to blame for it. I completely rebuilt the pages using HorizontalArrangement nested in VerticalArrangement (that alone took well over 16 hours of work; told you it was complex) and now the page opens.

For the record, each TableArrangement had content of their own, Label and TextBox mostly, so that they would be arranged in neat columns and rows, and presumably between the fixed dimensions and some "Automatic" ones, that was apparently enough to stall the emulator completely. Switching between pages featuring TableArrangement and those that did not was apparently what caused the issue, I could not even start the emulation on the page that had such a table, but could on those that didn't, and those that didn't could then not swap pages to those that had tables.

It is far from over yet, as far as I am concerned, as I have now to migrate the data processing blocks to the new table-free page. The backpack will be useful, but cannot help wonder why the Designer does not have a feature for copying components; that would have significantly reduced the time taken to set-up the alternate, table-free screen.

CBVG