Share
Report
35I urge anyone with a deep-linking function in their canvas apps to check their app in monitor - you might have a performance issue
Like many of us, I have an app that is set up to deep link users to one of several screens depending on a URL parameter. Now, most YouTube tutorials suggest doing this with a Switch() function on the url parameter in App.StartScreen. Eg:
Like many of us, I have an app that is set up to deep link users to one of several screens depending on a URL parameter. Now, most YouTube tutorials suggest doing this with a Switch() function on the url parameter in App.StartScreen. Eg:
Switch(Param("screen"),"2",Screen2,"3",Screen3,"4",Screen4,"5",Screen5,"6",Screen6,Screen1)The problem is that whilst the user is taken to the correct screen, every other screen in that Switch also loads into memory. For an app with a lot going on, this can really grind things to a halt.
To verify what I was seeing in my primary app, I created a completely blank canvas app with six empty screens. I added a text label to each screen so I knew which was which, put the above Switch into StartScreen, published it, and then launched via the monitor.
On this run, there was no url parameter, but every screen in that Switch loaded in anyway, before finally dropping onto the expected screen:
Now imagine a normal app, where each screen has its own controls, perhaps a gallery or two, maybe some forms. ALL of them being loaded in when the app starts up....! You're going from maybe a dozen actions to potentially thousands before the user has even done anything.
On this run, there was no url parameter, but every screen in that Switch loaded in anyway, before finally dropping onto the expected screen:
Now imagine a normal app, where each screen has its own controls, perhaps a gallery or two, maybe some forms. ALL of them being loaded in when the app starts up....! You're going from maybe a dozen actions to potentially thousands before the user has even done anything.
A different method that worked better until 3.24102.14 is to leave StartScreen blank, and instead have an If() function in the Visible property of the default landing screen that checks for a parameter value. If there is, it selects a hidden button to do the navigation logic.
OnVisible:
If(!IsBlank(Param("screen")),Select(Button1))If(Param("screen") = "2",Navigate(Screen2),Param("screen") = "3",Navigate(Screen3),Param("screen") = "4",Navigate(Screen4),Param("screen") = "5",Navigate(Screen5))Slightly messier, but loaded only the intended screen, so much better on performance.
From authoring version 3.24102.14 onwards, this method is also broken. I'm getting the same problem with this workaround as the StartScreen Switch method - everything loads in if my button is triggered. Nothing in the code has changed. I've tested in 3.24102.14, 3.24102.15, 3.24102.17, and 3.24103.17.
Rolling back to 3.24101.10 and republishing restores expected behaviour, but I can't keep doing this every time I open the studio! And frankly, the original method should work anyway!
Power Apps team - please revert whatever change you made to this, or better still - FIX STARTSCREEN SWITCHING.
Power Apps team - please revert whatever change you made to this, or better still - FIX STARTSCREEN SWITCHING.
Categories:
All responses (
Answers (
