Conditions that invoke launch page / starting view

Kirk_Masden · 02-26-2021 09:53 PM

I would like to explain to my users the conditions under which the page I have designated as the “starting view” or “launch page.” I sat down to begin to write the explanation and then realized that I don’t understand it well myself. So, I checked the documentation:

This well-written and concise page (thanks for all you do, @Steve!) explains how to designate the launch page but it doesn’t go into the conditions that will cause an app to go to the last page that was being used on it instead of the starting view. I actually use the app I am working a lot for my own benefit and the launch page rarely comes up. I think that’s because the app returns the user to the last page that was being worked on instead of the launch page when the period of time between use is short.

I wonder if I could get some clarification regarding the conditions that lead the app to ignore the launch page and take the user to the “last” page vs. those that cause the launch page to be shown. I know you are very busy, Steve, but if you could add that kind of explanation to your documentation page, I’d really appreciate it.

P.S. If possible, I think it would good for AppSheet to decide on either “starting view” or “launch page” and stick with that term. I occasionally notice situations in AppSheet where there are multiple ways of referring to a single function; a practice which can cause confusion and make it difficult to find discussion of the topic in this community forum.

Rafael_ANEIC-PY

Hello @Kirk_Masden, I believe those configuration options are a bit hollow at the moment, since you can only set the starting view for the first time an user launches the app, every time after that it will reopen in the view that it was left at the end of the last session.

Kirk_Masden

Thanks @Rafael_ANEIC-PY ! For the most part, that has been my experience. I wonder, though, if there isn’t a period of time after which the app reverts to showing the launch page.

I just opened the app I use very frequently on a device on which I rarely use AppSheet. I had been experimenting with another sample app there so I had to choose the app that is most important to me from the App Gallery. The result was the designated launch page – but I understand that this is a rather unusual example.

On my iPhone, on which I use my main app fairly often, I just logged is to a different app and then back to my main app in the App Gallery and the launch page appeared.

So, first time + after switch in App Gallery. I think if one doesn’t use AppSheet at all for two weeks or so one has to sign in again, so that may invoke it as well . . . but, of course, that’s harder to test.

An official explanation would be appreciated.

Koichi_Tsuji

I understand you are looking for official explanation rather than me, but this is my understanding.

Appsheet by design is runnable even off-line, which is meaning the app is running based on the data being cached to the user devices. Even you refresh, sync or whatever you do, the app is remembering what was the last page / view the user was on, and then restarts with that particular view, as the cached data is always respected in this regard.
All the fact you and we see is supporing my belief basically. “Sync” operation sounds like that app will remove old states such as "last view’ where the app use was, but it is by design. Think about when the app is synced, either manually by hitting sync button or auto-background sync whichever, then we are always prompted back to the “start-view” then it will lead to bunch of complains by all the user. Why we will be prompted back to the starting view ALL THE TIME! bra bra bra. Thats why I believe the appsheet is respecting the state which is saved and cached to retain what was the last view, even restart the app. When we restart the app, then the saved/cached data is reviewed and respected once again, even we opne the app with browser tomorrow.

Another question, you see different behavior when you open the app from app gallery. My suspection is also because of the cache.
The data being cached to your devices will not live forever. I m not sure if Appsheet is putting some mechanism to determine the length of the life of cache data, but it is also possible, the cached data will be removed from the browser storage after certain amount of the time. Also we need to make sure the space for the cached data is not unlimited. The more of the data is cached, then old ones could be removed or erased.

My best guess on your case, when you open up the app which is not frequently used, but you surely used before, you open the app and you see the starting page. I believe at the point of time you re-started app, no residue of cache data remaining on your devices, so app started as if the app is firstly used, as there is no cache avaiable to start on.

Again, all out of my guess works, as I m not engineer!

Kirk_Masden

Thank you very much for this detailed and very persuasive explanation. I think it much be correct.

Koichi_Tsuji

Just trying to be a good detective…

Sorry… i m from old school .

Koichi_Tsuji

It is depending on what is your goal and want to achieve, but this may inspire you to come up with your own solution.

As we all know, there is no native mechanism is presented by Appsheet, kinda of “auto-log-off” after certain amount of time, when the user stays INACTIVE over the app etc. This workaround is not necessarily substitute this auto-log-off feature, but provide some sort of smilar effects.

Let me quickly explain.

On your asolute starting view, place a button or action to add new row to one independent table. You simply pass the value of datetime (now) as well as user email to it. And set the virtual column to dynamically calculate the time from NOW().

When the user came to the app absolutely first time, then they have no other choice but hit button, which will add time stamp as well as useremail to record.

Then you add showif constrain to other view including this starting view.

If there is one row associated with this log in users, then show other view, else just present the starting view. If there is row, then also hide the starting view.

Once the user interact with the app, by hitting button, action then new row added, which will toggle to show/hide view.

This adding new record operators will keep holding the record when which user actually interact with the app, which will trigger as well as toggle show/hide views.

Technically, we just count the number of the row associated with login user. If count > 0, then show view else hide. Super simple.

Then we give the amount / duration of life to this particular record/row.

For instance, you want to make sure what user will come to this particular starting view EVERY DAY, then you may consider to give a life as 24 hours since last time they interact with the app.
We can easily capture home many hours since the last time they interact, just let the VC to do the calc NOW()-time stamp on that record.

If it is more than 24 hours, then don t count that row, then result of row count is 0.

Then apps main views will be hidden, the starting view is only become visible to the user.

Appsheet is pushing data from backend to the device every 30 min.

It is possible that the user leave the desk while the app is opened on the browser, then return to the desk, they see no app view, but only stating view, because of auto-refresh.

Then they hit the button again, and they add new record with the latest time stamp.

In this way, you can ensure every N amount of time, the user need to visit the starting view and hit button to interact with the app.

We have some app with those settings.

This will act as a sort of custom log in records and logs as well.

Make sure to set the app to sync on start as well.

For your reference.

I know this is not a perfect solutions, but do a bit of jobs for you?

Kirk_Masden

Thank you very much! I my case, I think I can leave the default as it is. But I think this is a really ingenious solution – as usual!

Koichi_Tsuji

Yes, have a think if it is absolutely necessary. No need to force to implement a complex mechanisum, which make the app complex! (unnecessarily)
But as usual, there is a solution with appsheet to get out of the hole.

Steve

I wish I could offer some clarity, but I am under the impression that the developers have recently changed the behavior, and may intend to change it further. I can ask, though.

Steve

Got an authoritative statement from a senior developer. Below is my understanding, not the developer’s exact words.

The starting view is intended for display only the first time the user opens the app, period. It is not intended or expected to be used at any other time.

There is a recognition that some app creators were using the starting view’s previous behavior, and that the previous behavior is desirable to some. Developers may revisit starting view behavior in light of this.

Kirk_Masden

Thanks so much, @Steve ! I really appreciate you’re taking the time to do this for me. Now I know how to write the documentation for my app.

Andrew_W

Thanks for this clarification.
I did use startup view in my apps, it was very useful and I thought the onboarding views were added at some point to provide what you have described.
I’m a bit confused now.

Kirk_Masden

Good point, @Andrew_W ! I had forgotten about onboarding because I haven’t built it in to my app. I’ve let the launch page / starting view do that work for me.

I just realized that onboarding has been announced and discussed here:

However, I couldn’t find a mention of it in the documentation. Perhaps the documentation should explain the relationship between the two features.