Hi all
I read in the docs that the OnApplicationReady 'runs asynchronously, and doesn't block the render of the screens.' (https://success.outsystems.com/Documentation/11/Reference/OutSystems_Language/Platform_Utilities/System_Events/Mobile/On_Application_Ready)
I am just wanting to confirm then that it is possible that this won't have finished running by the time our screen loads - so if you were doing an action in the OnApplicationReady that would affect the UI then the UI might jump after rendering from what it was initially to what it now is since the OnApplicationReady finished running?
I've got another idea to avoid implementing the same logic in all your screens (or even avoid to reuse them in each screen), and also to avoid doing it in OnApplicationReady.
Place the logic in all your Layout webblocks. And much better if you've only one Layout in use, so it's just one place. Just keep the logic in its OnInit, and so you can even notify all of your screens with an event, rather than polling the client variable. This way you can make sure each of your screens respond to that event via a handler Client Action and then your logic is implemented correctly to handle awaiting for that simple JS to finish. In the JS itself, you can add an IF condition at broad level, to check if it has been already executed, hence avoiding any repetition.
Thanks for the idea Ravi. I think it's a good one. It does not solve the original issue though which is that is needs to happen before the screen renders I don't think- unless I am missing something? I assume this solution would need to work in conjunction with your loader idea?
Hi Nicholas, when you place it in the layout's OnInitialize, it will execute without rendering a single pixel.
If you want to show the loader while you execute that part, then better place your code inside the OnReady of your layout, and send out an event so all other consumer screens would get a notified when the miracle execution completes. On that even you can flip the toggle to show the UI, custom to each screen depending on how you want them to react.
You can share me a small sample OML file. I'll be glad to help you by modifying it to what I've suggested here.
Hi Ravi, I did not realize that the screens waited for the OnInitialise of the Layout to complete but I guess it makes sense. OML won't be necessary as I follow. Thanks for all of the assistance!
OnApplicationReady would run in a different thread, so if it affects any UI part, how would your application screen know that the OnAppReady has completed executed, before jumping to new UI changes?
I assume it could have achieved using the client variables. If that is the case, the screen won't have big UI sudden shift, but would be just usual as you would change a client variable which affects the UI components.
If the UI is very critical for you before OnAppReady finishes, and you don't want to present something which they shouldn't see, then just use a client variable which won't present anything (or a loading screen) to keep the user waiting for a moment.
Hi @Ravi Punjwani
I think I understand what you are saying but let me be a bit more clear in case.
I am setting a client variable in the ApplicationOnReady to determine if a user can or can't see something on the screen - so my question is - is it possible that they will see the thing they should not -and then suddenly it will dissappear? (or if I made it default to not show then the inverse - it would not show and then suddenly it would...)
In your case, it would only make sense to wait for the On Application Ready to finish and then only you decide to show or not show something of concern.
For the time being, you can only show an ajax loader / spinner so user could wait for the result. You can display a fake / placeholder UI loading that at least shows them the template of what is being available in a moment. Like this one:
And better with a little animation:
https://digitalsynopsis.com/wp-content/uploads/2016/06/loading-animations-preloader-gifs-ui-ux-effects-12.gif
Ok thanks Ravi
Alternatively I may just try and place a reusable client action which sets this client variable on the OnInitialise of each screen as that I believe will halt the screen from loading - and this action should be very fast.
Halting the screen won't be a good practice. It won't render anything making users think that the application is broken. At least display something on the UI by the time you calculate what to show next.
Better turn off any navigation happening from menu or links before you're ready to set the user free to do whatever.
Do you have only one landing page, or may have users navigate to anywhere during start of the app, like using deep links.
I hear you, but as I said, it should happen very fast, not sure the Loader would even show in the time it takes the action to run - that fast...
One landing page - but the issue is that the User could easily bookmark another page and access the app from there if they wanted (unless you know of a way to ensure only one entry point? Not sure if there is a built in option for this or if a work round might be needed) - meaning the logic I would have used to set the client variable did not happen when it was meant to - on the LandingPage... so I need it to happen on every page - which the OnApplicationReady is very useful for - but might show this jumpy UI - as I said, it's super fast so it shouldn't, but trying to plan for the worst case...
When I say fast - I mean a very simple JS script to get client side roles and then setting a client variable to save those - so split seconds... don't mind if the user experiences that kind delay on the page load...