tl:dr - I need to store a couple of temporary numbers from a Custom Action on my page while the user is performing a transaction. Is there any reason NOT to put them as fields on the User table, other than it could get really messy in a larger app?
From what I understand:-
Adalo doesn’t have the concept of a temporary “variable” on a page (future feature)
Adalo doesn’t allow you to set maximum values in number inputs
To get round this I have the following. All users are logged in to the app.
User enters the code, and we pull back (via Customer Action) a number that is the remaining value on the card.
If it is greater > 0 then the bottom group appears and a slider is used to limit the amount to redeem to value between 1 and that value.
So I need to “store” two values. The maximum amount and the slider value.
The maximum amount can be stored on a hidden input. However, the slider value is not directly addressable via “magic” so I am storing it on a field on the User (zero it on entry and exit from the process).
When trying to hide the “redeem” group, the only options available on the input field are equal or not equal (it is a numeric field). So I can do “not equal to zero” if needed.
However, on the field on the user I have far more options.
That got me thinking about why I wouldn’t just put the remaining amount on the User as well.
But a few other minor questions also…
Why is the input field in the Group Visibility input shown as if it was a field on the User? If I put a field on the User called “Remaining Amount” I will never know which one it is.
Why can I do more maths on a database field than an input field?
Why can’t a slider have an output to an input field?
A hacky way to store temp variables is to create invisible text input fields that you can store info in. You can use the Change Input Value action to do this, you just have to remember to set the input back to empty if you leave the screen or perform a new custom action.
Well I can definitively say that the form inputs method is at least faster because it’s all local on the phone, whereas the database option has to reach out to Adalo servers and actually update the field with each change. On the flip side, hidden form inputs can be a nightmare for building a UI sometimes.
So it looks like using “When a user visits the screen…” is also triggered after a Custom Action? If you reset the input on entry it gets reset after a Custom Action?
That means you need to do it when you leave (so nav actions)?
Hopefully, this could help but in the meantime, I also store my temporary variables in the user’s collection but as @pford mentioned this slows down the user flow “slightly” but not too noticeable for most use cases.
I usually store temp variables in Users collection.
+: they are accessible from anywhere in the app
+: mathematical and other operations can be performed with the variable value (unlike input - you can’t add a number to the input value, as for now)
-: it can’t work for a public/unregistered parts of the app, where you don’t require user registration
-: they may slow down the app a bit
In my experience, you need to use an easy-to-remember “naming convention” for such properties (not to forget why these properties exist).
Also, don’t forget to “reset” these properties - better before entering the screen where they are changed (I’ve observed strange behaviour with on-screen-enter actions when trying to “reset” the temp property on the screen and change it via elements on the screen).
Agreed, here is an example deleting a message with a confirmation prompt, when the user clicks on the chat settings this reset’s my Temp variable to false (this is when it slows down slightly), then when the user clicks on Delete message this is updated to true witch will trigger my conditional visibility for the prompt confirmation. (Sorry this app is in French)
Soon this won’t be an issue when the Custom State feature rolls out
Herein lies the problem (IMO a bug) whereby the “When user visits the page” action is being triggered by an API call. Which then, as you say, can cause issues.
If the Custom States do not persist across an API call on the page, then they will suffer the same issue.
May be bug, may be a feature
It seems that the screen is reloaded upon the Button Action, so the whole “screen enter” routine is triggered.
Sometimes it could be used as an advantage (for example, screen reloaded -> data is updated), sometimes it causes difficulties…
!
