In a Canvas App,
screens load individually when the user navigates to them. When a user navigates away from a screen, any
data not required for the next screen is removed from memory. This concept is important
to take into account when building a Canvas App
Splitting an app’s functionality
across several screens rather than combining into a single screen helps performance as long as there aren’t cross-screen dependencies. If a control in a screen takes its value from
a control in the previous screen viewed by the user, that’s fine because the
required value is retained in memory during screen transition. However, if the control takes it value from a
control in a different screen, that screen has to load into the device memory first,
to obtain the required value. This will
create a delay and is not good practice.
It should be avoided where possible and there is often a simple
workaround such as saving values to a variable or collection
A good screen
structure for an app is very important both in terms of performance and
usability. There aren’t any
recommendations from Microsoft on the maximum number of screens to use in a
canvas app. However, I would suggest that the maximum number
of screens should really be no more than 15.
This makes sense because although an app with too few screens can create
performance issues, an app with too many screens can become difficult for users
to navigate and use. Taking into account
the 500-control recommendation, for an app with 15 screen the average number of
controls per screen will be around 30
For further guidance
on the use of screens and other ways to optimise performance of a canvas app
the Microsoft Performance Guidelines are very helpful