Hello to all,
after more than 40 years of programming experience, I have real difficulties with the designation of “global variables” in Kodular. For me, these objects are nothing more than local screen variables. Now I have seen that the global variables in Thunkable actually have an app-wide validity.
In my view, that would be a real milestone for Kodular. What actually speaks against it from your point of view.
regards Franz
Hi @franz1
I don’t think there is any need for universal variables as we have TinyDB already available for that.
But if you can explain the benefits of universal variables then Kodular team can think to implement it.
For now let me move this topic to #feedback:iwant category.
A separate screen is a separate Activity, and is to should be treated like a separate application for most purposes. The global variables are global. Thunkable must be working around this by breaking the normal structure of an Android app.
Hi Sunny,
thx for the quick response. First of all I want to say that you all do a great job. I would like to show you some advantages from my point of view. I will also be happy to discuss this topic with the development team.
In my opinion, handling a global variable via Tinydb creates a great deal of programming overhead. I have to take care of explicitly loading this value from the Tinydb in every screen and I have to make sure to write this value back into the Tinydb before calling up another screen.
TinyDB is a database, which means that these “global pseudo variable” value of the last write-back is thestartup value of the next call to the app. In my view, this is a somewhat dangerous starting value.
As I found out from my own experience, this TinyDb is overwritten with every version upload of the app. Another point that I would call dangerous and a source of error.
You have to know which global values are stored in the TinyDb. This is particularly important for development teams. Anyone can see immediately when using real global variables!
Hi Kanishka_Developer,
That may be that the development team at Google thought at that time. But then you shouldn’t pass any parameters to other screens, because you are also contradicting the encapsulation ! I would like to say that of course you can always strictly follow the original guidelines once agreed. However, this mostly hinders the sensible further development of a system.
comments are welcome
Franz
PS.: I could have saved myself a lot of trouble if I had known that the TinyDB would be reset with every download to the mobile phone. Please leave a note in the documentation.
if you increment version number and version code in the Screen1 properties, then after installing a new version of your app the data in TinyDB will be kept…
Taifun
Not sure what your point is. A separate screen is a separate Activity; does not mean that you cannot pass arguments. 
The Android operating system has handled apps like this for as long as I can remember. One App Inventor distribution breaking the normal app structure with unknown consequences does not mean the industry has to follow. Your screenshot was from Thunkable X, which is an absolute monstrosity in every regard.
You had a question (“How do I pass values to other screens?”), you got the answer (“Use TinyDB.”).
One way (and a recommended one at that) is to create pseudoscreens, at least for the screens that will be closely interconnected.
Make every “screen” a VerticalArrangement in the parent screen. Toggle Visibility to “switch” screens. All global variables are shared in this method, for obvious reasons. Who knows, maybe this is what Thunkable X is doing. 
Hello Taifun,
many thx for this information, this is very helpful.
But where ist this Info in the documentation ?
Who in the team is actually responsible for maintaining the documentation?
Franz
Hello Kanishka,
It may be that Thunkable X differs from the standard here, I don’t know the systems well enough yet. Perhaps this is also due to the fact that this system also supports IOS and Windows, whether paid or not. I find your answer somewhat arrogant.
I don’t jump from a tower just because someone says jump! 
Because without my pennedrant questions I would not know
One of my old professors studying computer science always said that there are no stupid questions, only stupid answers. A better or more complete documentation can prevent such stupid questions as I’ve just asked.
regards Franz
TinyDB’s data wouldn’t be lost until you re-install app.
Changing version name every time you update your app is necessary if you want to upload app to Play Store or any other store.
Hi Sunny,
many thx for this informations. The circle of questions regarding the handling of global variables via the TinyDb is slowly closing. These now new facts for me in the behavior of TinyDb are fundamental and should also be reflected in the documentation. It is also clear to me that this area of programming is often neglected due to the overload. I am happy to help out here.
Franz
If you have any doubts regarding TinyDB then docs are here to help you:
https://docs.kodular.io/components/storage/tiny-db/
I know this information, but all of these facts are missing in this documentation !
Honestly I have never read documentation for any component.
Everything I post is either based on my experience or is generated by Google search.
So I have no idea which information is missing.
If think that something can/should be added then open a new topic in #feedback:iwant category with proper details.
That is not a reproach for you, I’m so glad, that some experienced users bring their know-how to the table. But first I try to get an overview based on the documentation before I contact the forum.
I did not mean to come off as arrogant. My sincere apologies.
https://appinventor.mit.edu/explore/ai2/google-play.html
http://ai2.appinventor.mit.edu/reference/components/storage.html
Additional resources:
http://ai2.appinventor.mit.edu/reference/other/manyscreens.html
Hello Kanishka,
You don’t have to apologize for anything, I don’t expect this from anyone. But of course I’m also pretty straightforward in my speech. So don’t worry about it now. I think that the problem rather lies in the way of documentation. Many of the really well thought out options lose their value due to the fact that this is not well documented. But that shouldn’t be your problem.
regards to India
Franz