I have used the listDirectory method. It is fairly simple but seemed to return all the Shared files on the device without regard to the directory that is specified if Shared scope is used. Legacy scope worked as expected. I didn't try the other scopes as my data is coming from /Download (external to the app).
The order things appear in the text string supplied by the user is important and changes what happens in the big loop. The only thing I can see that can work is to process the list and pre-fetch all the datafiles. This means I have to have enough available memory to hold every byte of every file even though I will eventually be discarding much of it. The ability to read a line or a fixed buffer length could eliminate this penalty.
The files are generated outside the app. I am already using tinydb to handle sharing between pages and to save the state of the app for later invocations. Is tinydb memory-based or "disk"-based? I didn't see many details in the docs.
Thanks for the info. Processing one huge XML file (padded with tags) multiple times doesn't sound very good for the battery life (used by someone above to justify event-driven system) as compared to having the ability to read the original files line by line or buffer by buffer. I do think MIT/Google didn't think this through very well. Treat file handling like the basic operation it is (my comment on addition above applies). Use the event handling loop to deal with user interactions like the methodology was originally designed to do.
As much as I hate Java, that's probably the way to resolve this. Reading a file just sounded so basic that I thought there should be a way to do it in a function.
By the way, the wait for event block I suggested at the beginning is still event-driven. It simply allows the "when file1.GotText" block to remain within the function's scope. When it is encountered the system can process the event loop like it normally does. Upon triggering instead of jumping to just after the separate "when" block, execution would return to just after the wait block inside the function. It would require the context of the function to be saved at the time of the "wait" and restored before continuing with the function execution.
If you want to speed up, try the local sqlite database... see my extension here App Inventor Extensions: SQlite | Pura Vida Apps there are also other sqlite extensions...
See also a speed comparison between TinyDB and Sqlite in Q9 there
AI2 as it stands is broken. I don't believe all the detours suggested make even the slightest bit of sense. This gigantic hole needs to be fixed in its base. I think it is best to just try to forget that I ever looked into this mess.
I don't understand why we don't get a simple example (at least of the text file and the expected result) to see what it's all about. And please also post a small test aia. I have to read here for a long time to guess what this topic could be about.
Note: Make it as easy as possible for those who are helping.
See also here.
Please write a function to return the contents of a file as a list. It doesn't appear to be possible in AI2. See the picture I posted above (can't get much simpler than that). There is no way to get the result from the 'when' block back to the function for it to return it to the calling block without blocking the event loop. The code in the picture returns global filedata even if the 'when' block hasn't yet been activated to set it to the contents of the file. It doesn't allow the event loop to run and activate the 'when' block if the disabled block is enabled.
The suggestions I made in the second paragraph of the original post allow AI2 to be a useful "language". When I say 'wait' (or 'sleep') I don't mean an idle loop, but instead am intending for it to add an event to the queue with execution proceeding immediately after the 'wait' block (like the current AI2 event proceed to a point immediately following a 'when' block) upon the event firing. A tcl 'update' is somewhat similar as it defers execution back to the event loop and gets scheduled to resume when the event queue has been otherwise been emptied.
For those who think in terms of pictures of blocks, the language needs to add a 'when' block that has the shape of the 'set' blocks shown in the picture. I gave it a different name because it also indicates the blocks processing is complete until the event fires at some time in the future.
As you found out yourself, reading a file works asynchronously... read the file and after a little bit of time depending on the size of the file you get the content of the file back in the event GotFile
If you think you have to duplicate blocks to get a result, you are doing something wrong... are you familiar with procedures? it looks like you first have to understand more about the architecture of App Inventor ... see again the links provided earlier in this thread by @ABG ...
And what about following the suggestion from @Anke
You said
This is not necessary, the only thing you have to do is to design your logic event orientated...