Hi all!

I came across with some examples of screens that have variables that are only used in one of the screen actions. These variables should inside that screen action, because they use unnecessary memory, am I correct?

When the screen action flow ends its execution, the memory used in variables defined inside that action are freed, in opposition to screen variables, whose memory usage are freed only when the user exits that particular screen, right?
So, this kind of pattern wastes memory and should be avoided.

What is the behavior of the platform in these kind of patterns and how memory is managed in screens?

Thanks in advance!

Hi José,

Your general thinking is correct. If your variable is only needed in one screen action, then declare it in the screen action, instead of the screen.

Note that screen variables are stored in the viewstate, which is exchanged between the browser and the server on every postback. So, they don't count significantly in terms of server memory - but they are relevant because as the viewstate size gets higher, it increases the page size, leading to a slower user experience (not because the server / app is slow but because more data has to be sent / loaded by the browser). That's also why you should avoid having recordlists as screen variables.

Interesting and valuable information.

- Why does service studio does not generate a warning when you have screen/webblock -variables as recordlists ?

- what's the desired approach when you think you are in need of screen-variables of recordlists (say you get a RL from an action with a refresh)

Statler & Waldorf wrote: Often you really need to have lists in the viewstate - when presenting an editable list, for example. What I meant was, it all cames down to data size. Although it's not usual, you can have more data in a text variable than in a list, so you have to keep in mind how the data will grow.

As a side note, if you have a simple query feeding a table/list records widget, the fields present in the viewstate are automatically optimized by the platform. So, if you don't use a particular field, the platform will not include it in the viewstate. This helps keeping its size reasonable.

Regarding the 2nd question, it should to be evaluated case by case... on some scenarios, you may even store that information in the server (database, session...), if it's too big for including it in the viewstate. You have to evaluate the impact in both bandwidth/latency and DB/frontend. For most simple cases, the viewstate is still probably the best option (it's a simple pattern, so it simplifies maintenance and avoids a penalty in the infrastructure capacity, specially if you have lots of concurrent users).

Indeed some value information.

Sometimes use a RL as an variable to 'store' the retrieved data. On this way I can loop trough the RL (filling another RL) without needing to query the results again. Having this in mind can change my point of view in some of that cases.

Kind regards,
Evert

Hi,

The reason there is no warning when using RL in screens/weblocks is because the optimizer does a lot of work to reduce the viewstate if possible.

For example, in the use case of using a variable as a local  inside the screen action, if in all possible paths the variable is always written before it is read, then nothing goes to viewstate and the value will not be set in any other call/action.

Think of the optimizer as a shrondinger box. If you look inside you may get a different result.  ;)

Regards,
João Rosado

A follow-up question, why does OutSystems keep the viewstate in the page itself?
I know it's default for .NET but there are ways to keep the viewstate on server-side.