Cool concept for reducing repetition

[RandyHayes]

So, this is not a "problem" posting, this is just to share a concept that has saved me a ton of copy/paste and constant maintaining. 

The Scenario:

One of our apps has a variable set of activities.  Each activity has a specific screen for it. The list of activities is maintained in a SharePoint list and is adjustable there (thus not having to "re-code" the app all the time).  This is all fine. 

BUT - the problem was that we had several places in the App where the user could choose activities based on a menu (gallery) of items (filtered by conditions).

The goal was for them to click on the item and then go to that activity screen.  We had the Screen Name in the SharePoint list, and then had to use a nasty long Switch statement to match the SharePoint string name and then Navigate to the actual screen. (Because you can't Navigate to a screen by a string name - see my Idea posting here and vote if you would like that.)  Again, all fine - except - this had to be maintained in several places in the App...got to be a pain.

So, here was the solution:

On the OnSelect of all the Galleries that need to go to an action, instead of the Switch statement, we set a global variable - Set(JumpToAction, nameOfScreenFromList)

In the app somewhere (and in our case we have a screen for "app stuff" only - not user exposed), we put a good ol' Toggle Control on it.

In the OnCheck of the Toggle we put the nasty switch statement. 

   Navigate(
      Switch(JumpToAction, 

          "scrnActionA", scrnActionA,

          "scrnActionB", scrnActionB,

          scrnNotSupported),
      Cover)

So, because the Toggle will respond globally, we set the Default property of the Toggle to !IsBlank(JumpToAction)

This way, any time the JumpToAction variable has a value, the toggle will "Check" and the statement will execute.

The only thing we had to do in the process was set a temp variable so that we could clear the JumpToAction variable to make the Toggle "re-arm".

SO...here is the result:

All Galleries that need to navigate based on the variable screen name in the OnSelect action:

    Set(JumpToAction, ThisItem.ScreenName)

In the Toggle:

   Default - !IsBlank(JumpToAction)

   OnCheck:

       UpdateContext({tempJumpTo:JumpToAction});
       Set(JumpToAction,"");

       Navigate(
           Switch(tempJumpTo,
              "scrnActionA", scrnActionA,

              "scrnActionB", scrnActionB,

              ... and so on ...

              scrnNotSupported),
         Cover)

That was it!  We now had a global routine for Navigating to screens that only had one place where we needed to maintain the "code".  

We do this also for global resets of Collections.  This way your Collect statement is in one place and when you need to reset it, you can just flip a switch with a variable.

I hope this is helpful to others.

[KickingApps]

Excellent solution; thanks for sharing this.  I am going to give it a go in one of my apps.

[timl]

Thanks for sharing this @RandyHayes. That's a really useful technique, to be able to trigger common code from a toggle. Well done!

[Mickyw]

Thanks for sharing. I'm curious: how Back() function behaves in this case? Does it route to last user screen or to staff screen?

Mick

[RandyHayes · Accepted solution]

@MickywBack will return to the screen that was last "on the stack".  With this method, the toggle fires and the Navigate gets executed, but the screen with the toggle and formulas is never navigated to, so, therefore, it is not "on the stack".

In other words - wherever you Set the trigger for the toggle (Set(JumpToAction,...)) is the one that the Back function will go to.  The end user NEVER sees or gets stuck on the trigger page because it is never navigated to.

[BrownMango69]

Wickedly clever - thanks for sharing this.

[Dlabar]

Does this hack work from an actual component?   Say I have an actual component that is a menu with multiple options on it, each going to a separate screen, and an output component property that is your "JumpToAction".  Will setting this output property trigger the toggle in the app?

[mike528]

@RandyHayes 

I built a header component to drive a process where each step marker (circle) launched a specific screen when clicked/tapped as well as a next and previous step button. In order to get around the issue of not being able reference any app specific variables, I created a property of the component called Steps that is set to a collection created in the App.StartUp. This collection has a row for each step including the step label, a status (that changes the color of the step marker) and a reference to the screen it should launch. 

ClearCollect(
colSteps,
{
Order: 1,
Label: "Verification",
Screen: scnVerification,
Status: 0,
ErrorCount: 0,
ErrorMessage: "",
MissingInfoMessage: ""
},
{
Order: 2,
Label: "Survey",
Screen: scnSurvey,
Status: 0,
ErrorCount: 0,
ErrorMessage: "",
MissingInfoMessage: ""
},...)

Then when the marker is clicked, step 4 for example, the component queries the collection for step 4 then navigates to that screen.

Navigate(First(Filter(Parent.Steps, Order=1)).Screen, None)

I was using code to generically determine which screen I was on by comparing First(Filter(Parent.Steps, Screen.Name = App.ActiveScreen.Name)).Order

However, with a recent PowerApp update, properties on the colSteps.Screen object are no longer returned. Intellisense shows them when typing the expression, but all properties return a blank value!

Anyway, though I'd share a slightly different approach to referencing screen to Navigate to.

Thanks

[lg-power]

Hi there @RandyHayes ,

Great solution indeed.  

In my implementation everything works fine in the studio environment. However when in published app the toggle on my "app stuff" page does not seem to trigger. I have checked that my global variable does get set on every click in the navigation gallery but the toggle does not seem to 'check'. 

It does trigger when I put the toggle on my active screen. 

Edit: 

Also, when I put a label on my screen that the navigation should be triggered from as: 

Toggle.Value 

Then the Toggle does trigger..  

How does this work in your scenario? 

[RandyHayes]

@lg-power 

Yes, this is a known issue (or as I am told..."by design").

Toggle controls will not respond when their default values changed if they are on another screen and not referenced on the current screen.  And, this only happens in play mode.

So, the way we worked around that was to simply have a label (not visible) on the current screen that referenced something about the toggle...like the Value property - i.e.  Label.Text : yourToggle.Value

This then made the toggle on the other screen respond properly.