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.
Hmmโฆ
How are you accomplishing the sync?
A Sync has occurred in two ways:
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.
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?
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โ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.
@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.
Yes
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.
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.
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);
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.
Thanks! That is an idea that could work!
User | Count |
---|---|
43 | |
26 | |
24 | |
14 | |
12 |