Within Canvas Apps it is quite common to navigate from one screen to another screen. During app health checks I often find code after the navigate function. Is this a good idea? Or do we need to be careful?
The Navigate Function
Table of Contents
The navigate function can be used when you want a user to click on for example a next icon or a save button.
Typically something like this is used to navigate to the next screen:
Navigate('Next Screen',ScreenTransition.Cover);
Now if you have a form that sits in front of your screen that you want to hide, it is not uncommon to set a variable that controls the visibility of that popup and an overlay to make sure that the user can’t do anything outside the popup.
![Code after the navigate function in Canvas Power Apps Code after the navigate function](https://i0.wp.com/sharepains.com/wp-content/uploads/2024/06/image-6.png?resize=640%2C356&ssl=1)
Or maybe you had a long running data operation running and while your app is fetching a lot of data your presenting one of those annoying spinners and at the point of completion you want to hide the spinner.
All these simple operations can be done after the Navigate function. Although you could also consider doing whatever you need to do on the OnVisible code of the screen that you are navigating to of course. Personally I like to control each screen by code that is part of that screen.
But how about long running code after the navigate function?
Code after the navigate function
Long running code after the navigate function is something completely different.
Consider running some code after the navigate function that takes a bit longer.
Navigate('Next Screen');
Another30secondflow.Run();
Set(varVisible, false);
And in the Next Screen we have the following code in the onVisible property
Set(varVisible, true);
Can you now still predict the value of the varVisible variable?
Well anything could happen. So as soon as code after the navigate function or an onVisible uses variables or collections set after the navigate functions then it is better to review/adjust your code. Even if it all seems to work alright at the first attempt. Timings can be a tricky thing, once you move an app into production and you find that collecting that data takes just that little bit longer when you have real data to deal with.
Discover more from SharePains by Microsoft MVP Pieter Veenstra
Subscribe to get the latest posts to your email.