Information can be stored in memory slots called variables, which you defne in the Blocks Editor. Variables are like component properties, but they’re not associated with any particular component
Here are some resources to help you learn to use the AI2 tools. A very good way to learn App Inventor is to read the free Inventor's Manual here in the AI2 free online eBook http://www.appinventor.org/book2 ... the links are at the bottom of the Web page. The book 'teaches' users how to program with AI2 blocks.
Thanks @SteveJG for helping to understand more about the structure.
Yes, I just gone through that it's all about the perspective, component and its the structure.
My answer wasn't according to the concern of perspectives.
My understanding is a component it is still a container and we can change its value or we can program that component from program blocks if we can do that why we cannot think or consider that container or or a component as a variable.
What does that change? What is that supposed to help for?
It is always desirable to define terms precisely, at least when a (practically relevant) understanding and benefis arise from it.
Hello Anke, thank you for answering, it is not a problem with any app that I am doing, it is a doubt that arises when watching tutorials. In some tutorials they use variables and in others they don't, so I wonder, is it an option of personal taste? Is it the best option to use variables or does it complicate the construction of the app? Is it mandatory to use variables in the construction of any app? Or does it depend on the complexity and size of the app? that is the doubt.
The discussion here hits at a core part of the theory of computing. To address the question, it's worth discussing at a high level three classes of computing machines.
The simplest is finite state automata (FSA), which have no memory, and accept/reject inputs by following a predefined set of steps to pattern match. Typically these are realized as regular expressions.
The second class of machines are push-down automata (PDA). They have a stack memory and can only manipulate the item on the top of the stack by pushing a new item on top of the stack or throwing the top item on the stack away. These are often used, for example, for parsing context free grammars. Push down automata are more powerful in the types of solutions you can build than finite state automata (effectively, every FSA is a PDA without a stack).
The third class of machines are Turing machines (TM). They are typically modeled using a tape-based memory, but conceptually you can think of it as a random access memory where you can update any spot of in the memory in response to some state change. These are the most powerful type of computing model and is strictly more powerful than a PDA (a PDA is essentially a Turing machine where you can only write to the end of the tape or remove what's at the end).
So what does this have to do with our discussion of variables? Well, if you really have no storage in your app, you can effectively only create programs as powerful as DFAs. If you only had a stack (say, by using recursive procedures), then you can model programs as powerful as PDAs. Once you introduce at least one variable, you can build as complex a program as one can model with any TM.
Of course, you can't really build an App Inventor app without some form of memory (the Screen serves as one and must manage app lifecycle states). Internally, each component instance (Screen1, Button1, etc.) creates a new variable that is effectively constant (you can't replace Button1 with a different button at runtime). These objects have some internal state (variables) that you can manipulate via their properties. Most people differentiate a variable (not owned by any particular object) and a field (owned by a specific object). While it's an implementation detail, variables at the blocks level are implemented as fields on the Screen, so as you can see the line between the concepts is somewhat fluid.
