Force view to hide after a Sync where display criteria changes?

I am wondering if there is a way for an ACTIVE view to be forcibly hidden after a Sync when its Show_If criteria has changed as a result of the Sync?

Currently, that active view remains displayed after the Sync, even when the Show_If is FALSE, until another view is chosen.


Employees view is the active view and properly displayed

After Sync, Show_If criteria for Employees view has changed to hide it. But because it was the previously active view it still is displayed.

1 23 603
  • UX
23 REPLIES 23

MultiTech
Participant V

Hmmโ€ฆ
How are you accomplishing the sync?

A Sync has occurred in two ways:

  1. I have navigations between apps. App 1 will navigate to App 2 by action. App2 Syncs. Changes are made that affect the Show_If that should hide the view in App 1. Navigate back to App 1 (via an action). App1 Syncs.

  2. I have Syncโ€™d manually. And I have changed referenced criteria manually in the sheet and then manually Syncโ€™d.

The result in either case is the same - the active view in App1 has a Show_If = False but remains the visible view.


I suspect this is a side-effect of changes introduced a while back where AppSheet โ€œremembersโ€ session context. When a user navigates away from the AppSheet app - maybe even closes the app - and then later returns, AppSheet is trying to return the user to their last known, albeit updated, state. My suspicion is that the AppSheet implementation doesnโ€™t account for the situation where the Show_If might have changed. It just shows the last accessed view regardless. Just a haunch.


So, I was hoping that with all of bright people on this Community, someone may know of a workaround.

I suspect you are correct.

Hmmmโ€ฆ

Okay, how are you storing the data that determines how a view is shown?

  • If you had that information stored inside the User table, for instance, I would assume that any data changes made to that would be faithfully respected in either app (provided each app has the updated info).
    • So if you based the show-if of your views based on data in the User table, even if the app is trying to send you back where you came from it should still take into consideration row values.

I have a single sheet used by both apps. App 2 updates values. App 1 reads the values.

Actually, I need to give credit to @LeventK. What I am trying to do is extend his 2FA capability into a stand alone app that can manage several apps and users. I working to minimize the integration into the apps being secured.

Nice one mate!


After thinking about this, I think youโ€™re 100% correct with your thought on the app taking you back to where you left off;

  • I donโ€™t think youโ€™re going to be able to get around this.

Iโ€™ve tried something like this before, now that I remember, and it did exactly what youโ€™re seeing here. Even though the view may be actually gone, the app takes me right back where I left off.

LeventK
Participant V

@WillowMobileSystems
@MultiTech_Visions
I believe it could be a very good feature provided we can have some kinda Global Variables that we can set with some expressions for this kinda hunches.

OMG yes!!! I remember that that was one of the intentions behind the UserSettings when all of that was first being conceived; but we canโ€™t change that data with an action, so no go.

@MultiTech_Visions
The good part of the UserSettings is its being device specific. Thus, provided we can somehow manipulate those values via expressions or workflows, even with AppSheet API, it might open a very different perspective to app development.

You mean something like I suggested in this Feature Request - ages ago now

@WillowMobileSystems
How you tried with appending โ€œat=โ€&(NOW()+1) suffix to your deep links?

No, I havenโ€™t. Will that force an app re-start - i.e re-trigger starting view? I do have the starting view logic coded to coincide with the Show_If criteria. Let me see if that works.

@WillowMobileSystems
It worths trying John. At least it will force a hard sync if Iโ€™m not mistaken.

I have tried using the โ€œatโ€ parameter with the LINKTOAPP() function. I was trying to avoid specifying a view since I want this to accommodate multiple apps. I hoped this function would behave much like starting the app anew.

The expression is (using & instead of # results in โ€œnot foundโ€ error):

CONCATENATE(LINKTOAPP([App ID]), "#at=", ENCODEURL((NOW()+1)))

This results in something like:

AppTest-99999#at=12%2F28%2F2020%2010%3A19%3A49

The app still returns to the last accessed view even though it should be hidden.

My testing also showed similar results. I used following approach

A. a slice to return zero records when a condition changes to FALSE. Created the view to be hidden (when the condition changes), based on that slice.

B. Also used the same condition to hide the view in viewโ€™s show_if

So as John had shown in his pictures shared, I could manage to hide the view name in the app footer as well as the view now shows zero records after condition change. So user does not see any records after the condition change. But the view essentially remains the same as indicated by the view name in the header.

Even after using a group action to move the view to a different view after the condition changes did not help.

So Johnโ€™s suggestion that the app โ€œremembersโ€ the last state seems to be correct.

MultiTech
Participant V

@WillowMobileSystems

Have you tried using a formula inside the starting view?

Yes

3X_8_6_86c1634408ca685c64d3afd40e7197fa8e973656.gif

I think youโ€™re fighting with AppSheetโ€™s automation; like you were thinking.

Would probly take a change in the functionality (or possibly an update to allow for more complicated logic) in the โ€œpick up where you left offโ€ thing.

Bahbus
Participant V

This is more or less how its gunna function I think, until they allow us to change the current view without requiring the user to initiate it - if they ever allow that.

What happens if you attempt filter at the Security Filter level? Or can you not with the data setup?

One of the use cases in my request:

Yeah, instead of a SHOW_IF, we almost need a VIEWABLE_IF (for views only obvi) that will lock out and kick users out when itโ€™s false - even if other actions would attempt to navigate to it.

Using Security Filter is a good step in the right direction. A value of โ€œFalseโ€ in the Security Filter will remove all rows. So I can simply check if user is authorized or not and apply directly in the filter.

The next hurdle is disabling buttons. While all rows can be removed, the active view could still be showing buttons. The table can be switched to โ€œREAD_ONLYโ€ using the โ€œAre updates allowed?โ€ property but this has a side effect. The app can get into a limbo state where it is trying to apply an update but updates have been disabled.

MultiTech
Participant V

I got you @WillowMobileSystems, though keep in mind - this is a complete hack work-around.

Create a dashboard for the actual view that people click on (on the bottom nav bar);

  • then put your other views inside that dashboard, with their appropriate conditional formulas.

This way the actual view the user comes back to is technically the same, but the CONTENTS of that view can change based on the data.

3X_d_5_d51363a862e7ab883241c312ac5d7f271579cdd3.gif

Thanks! That is an idea that could work!

Top Labels in this Space