Skip to main content

Notifications

Community site session details

Community site session details

Session Id :
Power Apps - Building Power Apps
Unanswered

Conditional formulas & collections loading all 'potential' screens into memory since 3.2402.14

(1) ShareShare
ReportReport
Posted on by 35
tl:dr, Big performance hit - studio version 3.24102.14 broke my deep-linking screen navigation by forcing all of the 'potential' screens to load into memory on startup. Issue also affects app.onstart collections that include screen names. Rolling back to 3.24101.10 restored expected operation. (Angry face)
 
 
Context
 
I have an app which can have one of six optional landing screens depending on a URL parameter, to provide deep linking functionality.
 
I have not been using app.startscreen to jump straight to the desired screen. Although using switch() in app.startscreen would send the user to the correct page as expected, monitor revealed that the app was loading every one of the potential screens into memory regardless of the matching value from param(). Unfortunately every YouTube video and online tutorial I could find was only concerned with a single if/else scenario for app.startscreen so I've no point of reference on this. The following working-not-working code was one of many attempts within app.startscreen before I looked at workarounds:
Switch(
        Param("scr"),
        "org",
        scr_ViewEditOrg,
        "peo",
        scr_ViewEditPeo,
        "act",
        scr_ViewEditAct,
        "ka",
        scr_ViewEditKA,
        "ttsp",
        scr_ViewEditTTSP,
        "kagf",
        scr_ViewEditKAGF
    )
 
Presuming a conflict with my expectations and how app.startscreen is intended, my workaround was to leave that blank and instead have a hidden button on the default landing screen to trigger onward navigation. The button is selected via the default landing screen's onvisible property, and simply fires off a navigate() depending on the param() value.
 
Screen onvisible:
 
If(
    !IsBlank(Param("scr")),
    Select(btn_URLParamNavigate_Landing)
)
 
button onselect:
If(
    Param("scr") = "org",
    Navigate(scr_ViewEditOrg),
    Param("scr") = "peo",
    Navigate(scr_ViewEditPeo),
    Param("scr") = "act",
    Navigate(scr_ViewEditAct),
    Param("scr") = "ka",
    Navigate(scr_ViewEditKA),
    Param("scr") = "ttsp",
    Navigate(scr_ViewEditTTSP),
    Param("scr") = "kagf",
    Navigate(scr_ViewEditKAGF)
)
Neat, tidy, worked. Happy me.
 
 
Fast forward to this week....

I pushed a minor visual update to my test environment this week, since 3.24102.14 dropped, and noted that the app was slow to load up again. Running monitor showed me that all the above screens were being pulled into memory without actually being called - deja vu.

Both in my original troubleshooting and again this week, I've verified that there are no controls etc referenced across screens. I randomly removed several of the screens from the if() statement above and confirmed in the monitor that only the remaining screens then loaded.
 
I've tried numerous different methods to alter this logic with no successful outcome. These include:
  • changing if() for a switch() function;
  • using a named formula to read the param() value and referencing the named formula in both the if() and switch() versions, in case the issue was combining param() with conditional logic;
  • creating a collection in app.onstart with a table of the possible param() values and the associated screen and doing a lookup to this in app.startscreen.
As a last ditch 'what if', I left the clearcollect() in the app.onstart, and removed any downstream logic, so nothing was using the collection, no navigate functions, nothing. The app still loaded all the screens into memory!!
 
So it seems that in 3.24102.14, merely referencing a screen name is enough to have the app load it into memory. Not good.
 
In the end, I have restored my original code above, and republished after reverting to studio version 3.24101.10 - and of course it works perfectly again....

I suppose I'm asking if I'm going mad, or if this is reproduceable by anyone else and is indeed a problem with the latest studio version. Alternatively, other avenues I should explore or any other creative methods to reference a screen name as a control rather than text that might not cause the app to think "I must grab this entire screen immediately if not sooner!!" before it's even decided whether it needs to go to it.

If you've made it this far, one shiny internet point for you :-)
  • WarrenBelz Profile Picture
    146,605 Most Valuable Professional on at
    Conditional formulas & collections loading all 'potential' screens into memory since 3.2402.14
    Hi DamonJay 
    3.2402.15 is available now (at least in Australia it is) and able to be saved under - I did an app yesterday under 14 - must admit it was a small one that worked fine, however it is now under 15
    If you use 15, you might post if it fixed the issue.
     

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

🌸 Community Spring Festival 2025 Challenge 🌸

WIN Power Platform Community Conference 2025 tickets!

Markus Franz – Community Spotlight

We are honored to recognize Markus Franz as our April 2025 Community…

Kudos to the March Top 10 Community Stars!

Thanks for all your good work in the Community!

Leaderboard

#1
WarrenBelz Profile Picture

WarrenBelz 146,605 Most Valuable Professional

#2
RandyHayes Profile Picture

RandyHayes 76,287 Super User 2024 Season 1

#3
Pstork1 Profile Picture

Pstork1 65,946 Most Valuable Professional

Leaderboard