Hi Francisco,

Thanks for the feedback!

Just to complement, can you add some examples where this feature would be useful?

Cheers,

Vasco Pessanha

I have an example/use case:

When user login, user is presented with a list of event (event name, venue, date, etc) to choose.

Then after that, all corresponding screens will only show for that chosen event only.

I tried to use Local Storage to save chosen event, then OnInitialize retrieve it and save it to variable varEventId.

But somehow, OnInitialize and Aggregate (with filter using variable varEventId) run in paralel/asynchronously.

Because my aggregate was using empty varEventId to query.

Then I tried Keystore Plugin, somehow using keystore plugin, variable varEventId successfully populated before running Aggregate, because my aggregate return correct rows.

But we have problem with Keystore plugin (some security requirement, like Android need secured lock screen) that sacrifice user experience.

When user find this "fault", user tends to uninstall it. (public, self registration).

So, in the end, we need a session variable in mobile apps, to replace keystore plugin.

Thanks.

Hi, 

I was looking for the session variable to store the role of the user in the login process, to avoid to go to the server to check his roles again.

I will try with a local entity, but yes would be nice that Outsystems provide us a Session Variables (Local Storage) to avoid that this workaround.

Thank you

We also need shared session between apps. After logging in on app A, if then you open app B you are still logged in with the same credentials, assuming A and B are apps built from the same server.

In enterprise scenarios with IdP and single-sign-on, this makes a lot of sense, and web apps have this solved already.

Hi,

I was looking for pre-filling the Username input widget, for that purpose i am supposed to store the value provided by the user in a global variable rather than storing it in a local variable or an Entity and i just want to use that global variable in various screens wherever i placed the logout functionality.

I was looking to do metrics for the user that is logged in. I want to log one entry per session. A session variable will be useful.

Would be happy to see the Session Variable, but for now I am using the Shared_Preferences Component from Forge to vaidate session using flags in mobile App.

https://www.outsystems.com/forge/component-overview/5013/android-ios-shared-user-preferences

HI,

Use the SHARED PREFERENCES Plugin available on forge that use native features like Shared Preferences & NSUserDefaults to store key values pairs on Android & iOS respectively. 

The One which we have published Shared Preferences Plugin if you would like to check this out. 

Just like we use the Shared-Preferences with native for storing local & permanent session or values across all screen, you can use this.

https://www.outsystems.com/forge/component-overview/5013/android-ios-shared-user-preferences

Cheers

Just to put an idea out there for discussion.

There could be a feature called Local Properties that works in a similar fashion to Site Properties, except it uses SharedPreferences / NSUserDefaults under the hood to store the variables locally.

Local Properties should be directly accessible from screen widgets (inputs and expressions), and getting/setting those values should not trigger performance warnings when used in the OnInitialize/OnReady/OnRender events.

Supported types could be:

• Text
• Integer
• Long Integer
• Decimal
• Boolean
• Date
• Date Time
• Time
• Phone Number
• Email
• Currency

No fancy binary data since that would kill performance.

One simple use case would be having a notification bar that is shown only once.

1. The "IsOpen" parameter from the notification bar uses the value directly from "LocalProperties.ShowNotification" which has its default value set to True.
2. If the user taps the notification bar, "LocalProperties.ShowNotification" is set to False and it does not show again, even after navigating to the same screen.
3. Currently, that kind of behaviour is tricky to be done and usually involves local storage, which is overkill for something that simple.