Which is more demanding?

Hello fellow Makers. I come here today to ask you and the Devs about whats the best solution concerning string variables.

The matter is when I need to exchange a string variable between procedures and/or events. Which would be better to use, a Global Variable or a hidden label/text field?

By better I mean, less taxing on my user’s device memory in general. To avoid clogging its memory and thinking ahead when an app might eventually become bigger and heavier.

1 Like

I think variable is better !

3 Likes

Variables are a more professional way, but I use captions for strings …

1 Like

Always use variables for these things. :slight_smile:

1 Like

Yes in order to save the actual thing, it has to be a variable, it’ll (sometimes) work with text but, most unlikely.

1 Like

I see. Right now I’m using globals for such task and after the executing whatever I needed with such variable, I empty it to avoid any unwanted conflict in future calls for the same procedure. I do that with almost everything, although nowadays, if I need to pass a boolean variable between a component event and a procedure or vice versa, I generally prefer setting some unused property (normally the use round card for arrangements or the show feedback for buttons, for example) of such component to avoid the use of globals. Of course, this approach normally only works if you are dealing with interface components…

Of course, such approach is somewhat “risky” if you inadvertently start using such property and forget to “reroute” the " pseudo variable" (lets call it that) through some other path. That’s why I keep track of my use of these properties in my app for uses other than those expected.

My question was concerning the amount of memory (RAM, of course) a global variable (thou with an empty string) is going to require in my device during normal use as opposed to a hidden label or text field that I eventually use to fill with the string required and then empty it afterwards.

The question boils down to how much memory a hidden user interface component takes as opposed to a global variable.

(sorry -not sorry- for the long text :laughing:)

Variables are made for this purpose. Why not just use them? :joy:
Also, you don’t need to empty the variable if the procedure begins with an assignment. It’ll be overwritten anyway.

1 Like

I know variables were intended for such use but we need to keep in mind that global are kept in memory, that is, they spend memory space whether they are in use or not (i don’t really know how the GC deals with AppInventor - and other distributions - stuff) and my question stems from this point.

Concerning the emptying of variables, I make a habit of resetting them to their default state (releasing them) every time I’m done with them as a preventive measure if I somehow request those variables up ahead in the same procedure or in a new procedure or event. Them being in their default state makes it easier to avoid unwanted execution of any procedure or event. Just a minor element of control. I always know my variables are in their default state if they are not being used.

If you need to call up on a procedure from different points in your app, thus making it a little more complex than a simple linear execution of lines, its good practice to keep your control elements (such as variables) in check to make easier to spot bugs or troubleshoot a faulty result. You know where something begins and ends. But I digress…

I guess we just have different views on how to write code.

It’s all you are making it complex. Variables are used to share data between different logic. They stay in memory if they are global and local variables are freed when the parent execution completes. They don’t need to be set to default to free them from memory. Even if you do so, only the values change while still being on the memory. You can only release them if you set it to null, which isn’t even there.

As for using components for sharing data, you must know that when you drag and drop a component (visible or non-visible), an object is created which adds up to runtime overhead. That’s why using many components makes the app slow. Even their properties also use local variables to set the object’s state in field variables. You see the variables are used everywhere without worrying about the runtime overhead they bring, which is way lower.

But this cost us more on the companion app, as the code you see as blocks are interpreted by the app at runtime. However, the built apps are compiled down to Java bytecode (not Java source), so you can expect performance same as a native Java app.

4 Likes

Reasonable. So, no matter the type of variable and the length, globals are the way to go. Good to know. I was gonna delve a bit more into what I meant in previous posts concerning my use of variables but it really doesn’t matter to anyone but me. Thanks for your time.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.