[Discussion] PA Objects are live all the time. How does that affect app performance?

[Anonymous]

So, I was watching this video from Microsoft Ignite. Link here: https://youtu.be/14yqmGBY12I

The presentor says at 7:04 that "the entire app is live all the time."

How does this idea translate to having a ton of screens with a ton of objects? Is this why the editing apps takes so much time and processing power? What performance hits could possibly arise from this?

[Sienna]

Yes that was the problem since beginning specially when I was filtering database in a gallery on multiple screens and adding multiple lines on other screen into the same database. The performance went to subzero with more records added to the database. I tried to switch it off with variable and filter the database only when I'm on the screen which helped a bit but not completely (my app was really massive). I was told they will change that but obviously they arn't yet. I asked them just to at least add automatically some waiting spinning image in the middle of the screen so the app doesn't look like it is frozen but that isn't here either. It was long time ago but I thing they said they will make the apps running quicker so no waiting image will not be necessary in the future (or something like that)

[BrendonBrooksP1]

I remember hearing that as well. I'm debating on recreating one of my apps (for funzies) and having two screens with the following:

1. Formuals

2. Data references

Would it make more sense for a screen to just reference formulas? I'm trying to reduce the amount of calls the application has to make to the server when refreshing data for various records. 

[Anonymous]

@Sienna --

Well, that's dumb. (The response from the dev team, not you) The dev team can't possibly expect that loading times will always be practically instantaneous. Even if the optimize the hell out of PA, there are still other external factors to consider. (Like connection speed, for instance)

That's why I don't usually use query functions (e.g. Filter(), LookUp()) directly in properties like Items. I use global variables and collections as intermediaries. It might make my app and code a lot more complicated and less intuitive but at least it runs relatively consistently, albeit slow.

@BrendonBrooksP1 --

Who the hell does PA for funzies?! lol. I did before I was disillusioned of PA. *does dramatic pose* Wish you best of luck on that one. 

And also, I have no idea what you meant by having a screen reference formulas. Did you mean, like, just give a screen a formula that evaluates to a dataset which all objects under that screen can use so that boundaries on refreshing data sources, and in extension, data sets can be easily defined? (Run-on sentence, yay!)

@anybody -- Don't you just love how this board, despite it being titled General Discussion, assumes everybody who would post in it would only post questions/problems? There's Accept as Solution buttons everywhere!  (That was sarcasm, in case people don't notice)

[BrendonBrooksP1]

@Anonymous

Something like that. I'm more or less trying to reduce the amount calls the application has to do my SQL server. For example, I have a list of locations where an item could be.

Sometimes we add new locations, so rather than have change every drop down array in my app, I just update a table in my SQL server.   Would I be better off just having that list of locations on one screen and then have the app reference those locations within the app?

I'm guilty of playing around PA for funzies sometimes. I haven't done this lately because I'm learning MVC. I'm almost at the point where I'd rather just recreate all the apps that I have in MVC and just host them in Azure. 

[Anonymous]

@BrendonBrooksP1 --

Oh. I think I did have a similar problem with PA. Not with the number of server calls but with the inconsistent refreshing of data from the server. What I did, IIRC, was just cache the data I need to a collection or global variable and reference those in my controls. I think that removes PA's auto-refreshing thing since it unlinks the table from the data source (or something. I might be wrong). Then, I do the refreshing by myself using a Timer or with a user action (OnSelect).

And for the locations? I think I used something like that for one of my app's navigation. By design, I wanted there to a link to most of the screens to each screen but I didn't want to have to edit all nav objects at each screen when the list of screens (or names of the screens) changes.

So, I defined a table on the OnStart property of the app (found at the first screen) and used that to populate a gallery I'll use for my navigation. So, I only have to duplicate the gallery and when minor changes (such as name changes and references to screens) have to be made, I only have to edit that table. (It only works for content changes though. If I had to, for example, change the formatting (colors, fonts, etc.), then I have re-copy all the galleries across the screens).

Screenshots, for greater clarity.

In consequence, however, there are times where the gallery had to re-render itself or something when the screens turn visible so I have this weird effect of the navigation expanding when navigating. (Word play!)

Anyway, I digress. 

But MVC? Hosting in Azure? Boy, this does make me feel small. I don't even know where to start in those things. Lol. I do admire your dedication to experimenting, learning, and general fun! 

[mr-dang]

---

@Anonymous wrote:

That's why I don't usually use query functions (e.g. Filter(), LookUp()) directly in properties like Items. I use global variables and collections as intermediaries. It might make my app and code a lot more complicated and less intuitive but at least it runs relatively consistently, albeit slow.

---

I cached stuff for the longest time, but then the time it took to cache was defeating the purpose of using the app. So lately I've been going the opposite direction--rebuilding apps so they can deal with Filter() directly in the Items property.

The main kind of changes I made were to the way I reconfigured datasources and objects in galleries. I've also been storing more lookups and conditions in Toggles and Radio controls--a main part of my slowdown in galleries was due to the many conditions it needed to resolve. 

I tried SQL, but ultimately, CDS seems to be the fastest datasource.

[Sienna]

@Anonymous

Yes exactly. As I said my app was really massive with a lot of codes in practically every items. With the fact the app is live all the time, surprisingly, I didn't experience any slowing down apart from filtering large databases as mentioned above. Turning the filtering off while I'm on the other screen adding records into the database, helped adding records into the database but it creates another problem. Once you click on the button which get you back on the screen with gallery what filtering the database, app simply froze for few seconds (time depend on the size of database) and you simply couldn't do anything with it. And that is why I wanted them to automatically disable galleries when we are on other screens and show the waiting image when we navigate back so the user knows that the app is working. (you can't make to show waiting image in PA in this scenario). Same as with patch function. I noticed that it take some time to patch a record into the database but while it is patching the user of the app will have no idea what is going on... why it takes so long...

[Anonymous]

@mr-dang --

Yeah. I do agree that caching takes a ton of time. For our apps, there are bits of code we expect to have loading times of around 30s to 60s.

But my main problem with having all that query code (Filter(), LookUp(), etc.) directly in the properties is that there's no way of knowing, AFAIK, whether the query either returned no results or is still loading other than that crawling thing we get at the top of the screen. That's not really eye-catching and I'd like to have a way to control my visuals to let my users know, in a more visible way, that data is loading and the app hasn't frozen or anything. With an Excel connection or occasionally with a SQL Server one, some lag is bound to happen.

And also that reading and maintaining the code if it's just in one place is much easier. It's really slow to move from one property to another. (Oh, god. The lag.) I'm surprised they haven't improved that ridiculous dropdown.

I do wish they post and bring to the attention of the community best practices regarding data querying written by the devs who know how PA is supposed to be used. Then again, the PA dev team doesn't really have much of a reputation here so don't get your hopes up.

Spoiler tag here because I kind of digressed off-topic about the CDS.

Spoiler

And about the CDS? Paying extra for an app we weren't even sure was going to work and continue going to work (my supervisor's disillusioned with PA ever since the two massive updates they released that broke our apps) was out of the question. And even if they would be amenable to paying, I wouldn't recommend it. When I had the Trial Plan 2 and tried out the CDS in its early stages, the UI was a nightmare. The method for setting up tables, getting in test data, updating table structure, and directly updating current data -- basic functions one would expect from a database -- was too convoluted and unintuitive for me. And from what I hear from this community, the CDS ain't that reliable anyway. It was cheaper to just extend the SQL Server set-up that was already there.

So, back on topic. How did moving all the querying from the caches to the controls improve your app? Did it improve general loading times? Did you have awkward visuals in the screens when the data is initially being queried? If so, how often? The updating of the evaluation of property formulas is also reported to be run parallel. Did that affect the way you queried the data at all?

[Anonymous]

@Sienna --

I know. It's ridiculous that they market PA as this no-code, worry-free platform when most of what we do is tear our hair off trying to work with what they thought fulfilled their promises. There's a lot of stuff that makes sense to be in an app creator platform that's just not in PA. I know this is a new product (general availability, my ass. it still feels like beta) and I can deal with that, given that the developers actually communicate well -- which, well, they really don't do well.