Dire Warning # 2 for ALL USERS - when previewing your app during development

I just noticed this last week because I can see a list of EVERY hit on my endpoints - something Airtable can’t show you - and Xano used to not be able to do. (When using Airtable and doing complex conditions on a Query, its very easy to just get a “Failed” message returned and you have no way of seeing what your formula actually sent to Airtable. You likely have a typo, but its very hard to track down. I’m not sure if the debugger can show a concise list of endpoint calls - perhaps they could add a tab to show this. The flow can get overwhelming but the debugger is cool!)

OK, so lets say you keep your phone next to you running the Preview.appgyver.com…… URL and every time you save your app as you tweak something, you want to see the change on your phone. OK, ever heard of the “stack”? I’m not sure how AG defines this… but if you have Page 1 in your app, and you click a button for Page 2, you can swipe RIGHT (you have to start all the way on the left edge) and get back to Page 1, even if you don’t have a BACK button. So lets say you go down a few pages in your app, Page 4, lets say. If you change anything on Page 4 and re-save then most likely your phone will flash several pages in front of you “all by itself” as it replays pages in its “stack”. (NOTE: Depending on if you have authorization/logins, your app may not get you all the way back to where you were. Depends on your app.)

Initially, you think this is nice, but from my ability to see the calls coming to my endpoint (something almost none of you can see), its exponentially making tons of calls to the database as you Save your app each time. I know this sounds weird. In my system I’m writing, I don’t even have any real data in it and yet after a Save I may get 50 API calls for example. Then I make a change and watch the screen redraw a few times and this time I get 100 calls. Sometimes my DOS window will scroll for 5-10 seconds because there’s so many calls coming in from the App Preview. Its crazy.

The only way to clear the stack is to kill the “SAP Appgyver” App on the phone, and restart it, and re-open the app. Then its snappy again and doesn’t have tons of garbage calls.

I thought about this tonight after reading reports of Composer acting real slow. I don’t think this is related as some of you say it happens even when initially opening the app (I think someone said).

In any event, this is another case where a bunch is going on behind the scenes and you don’t AND cannot see it. (Unless the debugger can concisely show this.) All of this is placing undue strain on the backend and could affect performance of others on your server - or unknowingly eat up bandwidth or monthly limits.

Jaymer…

1 Like

For those of you previewing on the web, you can use the Chrome Inspector to see the network traffic thats happening.

Here’s a link for Chrome to explain how to see network activity.

If you have the 5 second delay still on some Data Variables, you’ll see traffic every 5 seconds.
And if you watch this after you SAVE the app in the Composer window, you’ll see activity hitting your server.

Interesting that you mentioned this scenario, as many of us actually work this way: SAP AppGyver ON Full TIme

After what I read here that you wrote, I decided to do a little test and for each update (no matter how small) inside Composer I simply closed SAP to restart the test.

So far, performance has not degraded and he remains relatively normal.

I don’t know if there really is some kind of relationship, but it is a fact that there is a substantial improvement; at least with me it’s like that.

  1. @Leo_Sussuarana I don’t see a correlation to Composer. Perhaps they already addressed this on the back end since yall started to bring it up and it is conincidence.

  2. This issue doesn’t happen when you are using the WEB previewer… like this:
    AppGyver

because each time you SAVE in composer it causes a browser refresh and the “stack” issue isn’t there.

  1. I just went back to an existing window on my phone from the iPhone SAP application that has been open since last night. I went to a page in Composer and made a SIMPLE text only change. This was the result on my back end:

    To save you from counting, I see 26 "GET"s hitting my back end… there should only be 1.

So I’m going to make another change and see the change.
OK, so only 1 more call was added… not the “exponential” increase I originally wrote about.
Thats because my app stops on the 1st page and makes you pick something to continue. After that comes Auth, Schedule, Events, etc.

THE POINT IS that even thought ONLY 1 more GET was added after my Save for when my app restarted, the PREVIOUS 26 GETs (which are remembered out there in the stack on the phone app) also happened.
And before I had my app stop on the first screen, it would have gone several levels in and cause a lot more hits - which is probably is doing for many users who just have that app open for a long time.

and no one knows it happening.

After closing my phone app and restarting, only 1 “correct” back end call was made. Subsequent saves to Composer made the back end receive
4, 6, 8, 10 hits just to display the single initial screen.

But again, this is low only because my app isn’t flashing multiple pages on the App after the save. Its stops on the first page.

→ Lou, before, I’d see 2/3/4 different pages flash and be redrawn. Is this what you see after a Save?

1 Like

I was told right at the start of development to use the “replace” page function to avoid stacking up open pages.

1 Like

Dear friend Phil, can you give me more details about this procedure please?

I always use the Open Page navigation component. My pages are all opened with the TAP property.

Its from the component marketplace, simply called Replace page. It avoids the need to have multiple pages open. In my app there is no going forward or back, so I only wanted one page open at a time.

"Opens the target page, replacing the current page in the navigation stack.

The parameters given in the Parameters object will be available on the opened page as page parameters, though you need to first also configure them in the target page’s data configuration section."

1 Like

Gratitude for the information.

I did a search here in the components and I didn’t find it, but I found it within the flow functions.

I’m going to run some tests here to see the behavior.

Very grateful for the help!

1 Like