Power Platform Community Forum Thread Details

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 :-)

Categories:

Building Power Apps