When you create apps, it is important to understand the timing issues that may happen. When various elements manipulate data, things could go wrong quite easily. fixing these issues however is not an easy task.
Running code
Table of Contents
When you create an app there are various places where you can insert code to read data or write data.
We can add code in the following places:
- App OnStart
- Screen OnVisible
- Timer ( On Start and On End)
- User clickable controls such as a button.
Any of the above pieces of code could conflict with each other. This means that we cannot guarantee that one has finished before the following is executed when we play the app.
Execution order
To test the order or things I created the above app and made the app OnStart, Screen OnVisible and the Timer sets a variable then call flow that waits 10 seconds and then set another variable.
Using the above tests I also redirected my app to a second screen before any of the code completed.
From the above Start and End timings of each of the pieces of code we can see that
The App On Start is started first, then the Timer on Screen 1 before the Screen OnVisible is started.
On the second screen the Timer 2 is also started before the Screen 2’s OnVisble code is run.
The important thing to notice here is that a Screen’s On Visible code is only called once all the elements on the screen have been loaded.
Completion of code
In my test I configured a few different waiting times as shown in the below table.
| Code Section | Wait time in flow | Difference between start and end |
| App OnStart | 10 | 11 |
| Screen 1 OnVisible | 10 | 12 |
| Timer Screen 1 | 1 | 2 |
| Screen 2 OnVisible | 5 | 6 |
| Timer Screen 2 | 5 | 6 |
As we can see each piece of code is running for the period of time that my flow is waiting with, as expected, a bit of overhead.
When I start my app, we can see the order in which each piece of code completes.
On the first screen I even included a button for a user to interrupt the process. Or maybe I should say not interrupt the process as the various code block will still run in the same order all at the same time. This running of code in an asynchronous way can of course cause major issues.
If your second screen in the app expects runs OnVisible code that expects the OnStart code to have been completed. Then you might run into some errors.
Protecting your apps
So what do we do to avoid these kind of issues? You could like I did in my app set variables at the end of your code blocks. Any code then relying on other code blocks to have run, will then have to wait until that variable has been set.
This way we could for example disable Timers or buttons until the OnVisible or OnStart code has completed.
You also have to consider the App.StartScreen will make your numbers look strange. It is meant to start the first screen in parallel with the App.OnStart. It is my understanding that the platform has features that ensure code does not execute until variables are initialized. I have no idea how this is done in an event driven environment. I did use the StartScreen and added a variable to the end of the App.OnStart so I can know when it is done but that is only because of the parallel nature of this design approach. I think the best design is one that makes a concerted effort to know what needs to be done/defined up-front and makes sure that is 100% done before allowing the app to proceed.