Android Question Process Globals variables

[red30]

If I understand correctly, the variables that are written in Process_Globals will be created when the Activity Module is created. How long can they exist?
For example, I have the main module Main and in it I created several Process_Globals variables. When will variables in a given module be destroyed? For example, how long can I not work with this module (where these variables were created) for the variables from it to continue to exist? What will happen to them if the phone is locked, but the application is not closed?

 

[LucaMs]

I have the main module Main

Main is an Activity module, in B4A.
Process globals declared in Activities will be lost when the Activies are destroyed.

1 - create B4XPages projects
2 - put project global variables in a code module.

 

[agraham]

Process globals declared in Activities will be lost when the Activies are destroyed.

Not true I'm afraid. Variables declared in Sub Globals in an Activity are local to the Activity and are lost when the Activity is destroyed. Variables declared in Sub Process_Globals in an Activity belong, as the name implies, to the entire process and are only lost when the entire process is destroyed. See the comments about each Sub that are at the beginning of each Sub when a new project is generated.

 

[agraham]

variables that are written in Process_Globals will be created when the Activity Module is created.

No, they are created when the process is created, before the main Activity is created.

 

[red30]

More specifically, in the Main activity in Process Globals, I create a text variable. Then I work with this variable in other activity modules and periodically use this variable. I have a suspicion that at some point this variable is changed or destroyed, but when I can't catch that moment... I also use one class module. I often pass this variable to this module, perhaps it is somehow related and I need to pass a copy of this variable?

 

[LucaMs]

Not true I'm afraid. Variables declared in Sub Globals in an Activity are local to the Activity and are lost when the Activity is destroyed. Variables declared in Sub Process_Globals in an Activity belong, as the name implies, to the entire process and are only lost when the entire process is destroyed. See the comments about each Sub that are at the beginning of each Sub when a new project is generated.

Tell me how you can access a process global variable declared in an Activity that no longer exists!

 

[LucaMs]

More specifically, in the Main activity in Process Globals, I create a text variable. Then I work with this variable in other activity modules and periodically use this variable. I have a suspicion that at some point this variable is changed or destroyed, but when I can't catch that moment... I also use one class module. I often pass this variable to this module, perhaps it is somehow related and I need to pass a copy of this variable?

I insist because I am convinced: a variable that must be used by the whole project, it is better that it is declared in a code module.

 

[red30]

I insist because I am convinced: a variable that must be used by the whole project, it is better that it is declared in a code module.

Yes, it's my mistake, you're right. There will probably be correct variables that will be used by all modules to create in the code module.

 

[agraham]

Tell me how you can access a process global variable declared in an Activity that no longer exists!

ActivityName.ProcessGlobalName

Process globals are declared as static variables of the class of the Activity. As such they are present even when no instances of the Activity class are instantiated and is why they are universally accessible. On the other hand normal global variables are declared as instance variables of the Activity class and are only available to the instance of that Activity class

public class main extends Activity implements B4AActivity{

    public static double aprocessglobalvariable;
    public double aglobalvariable
     
}

 

[LucaMs]

ActivityName.ProcessGlobalName

Process globals are declared as static variables of the class of the Activity. As such they are present even when no instances of the Activity class are instantiated and why they are univerally accessible. On the other hand normal global variables are declared as instance variables of the Activity class and are only available to the instance of that Activity class

public class main extends Activity implements B4AActivity{

    public static double aprocessglobalvariable;
    public double aglobalvariable
     
}

Bad thing (we talked about something similar in another thread).
A class itself does not exist if it is not instantiated (it is not a code module), so any public "part" of it (variables or methods that are) should not exist.

 

[Erel]

I don't like code modules. They are quite limited in B4A. They do have their place, especially with constants and other primitive variables, but if there are other good options then use them.

For a B4XPages, in most cases the best place for app-global variables is in Class_Globals of B4XMainPage.
It is easily accessible and the app starts from B4XMainPage.

The only(?) case where you can't use B4XMainPage is if your B4A app starts in the background. For example with a push notification. For that cases I recommend using the starter service (Process_Globals). If it is a cross platform project then using a code module will be better.
Again, for simple constants it doesn't really matter and code modules are perfect.

 

[LucaMs]

In any case, a class, an Activity, a B4XPages should be created for a specific purpose, functionality, not to provide public variables to be used by an entire project (unless, of course, their content does not strictly depend on that component itself)

 

[agraham]

A class itself does not exist if it is not instantiated (it is not a code module), so any public "part" of it (variables or methods that are) should not exist

Wrong - you obviously don't understand static class variables. They exist as part of the class definition that is used to make instances of that class and as the class definition (the class of the class) must exist to make instances of a class then by definition the static variables are always available.

 

[LucaMs]

I don't like code modules.

This is because you don't have good taste ?

I only know two of their limits:

1 - they cannot handle events
2 - (and this is not a real limitation of code modules) for some things (serialization) you shouldn't declare custom types there.

 

[LucaMs]

Wrong - you obviously don't understand static class variables. They exist as part of the class definition that is used to make instances of that class and as the class definition (the class of the class) must exist to make instances of a class then by definition the static variables are always available.

Static variables, useful (which, btw, I miss in the subs) make sense but not in a class, in the instances of the class.

 

[Erel]

2. Wrong. There is no problem with declaring types in code modules.
3. Do not support resumable subs.

1 + 3 are important enough to prefer storing the "program state" in B4XMainPage or some other class.

 

[LucaMs]

2. Wrong. There is no problem with declaring types in code modules.

(serialization)

https://www.b4x.com/android/forum/threads/b4xobject-b4a-b4j-b4i-objects-serialization.48272/

3. Do not support resumable subs.

because...

1 - they cannot handle events

 

[agraham]

Static variables, useful (which, btw, I miss in the subs) make sense but not in a class, in the instances of the class.

Stop denying reality. Static class variables, and methods, exist in many languages. You were wrong, be a man and admit it.

 

[LucaMs]

Stop denying reality. Static class variables, and methods, exist in many languages. You were wrong, be a man and admit it.

They exist to be used by the instances of that classes, not by a whole project that nothing have to do with them!

The best AND MOST LOGICAL place to declare a variable to be used by an entire project is a code module!

End ?

 

[agraham]

They exist to be used by the instances of that classes, not by a whole project that nothing have to do with them!

Wrong yet again but I'm tired of arguing with you.