App response to large list and calculations

As I am working through my app I cant help but realize that I am adding to many componants and containers on one page not to mention large lists and calculations are still needed and have not been added but a few.

I’m trying to figure out if I need to distribute that info onto other pages and if more pages equal the same thing.

What am I attempting to build? My app is similar to a calculator in that I don’t need to change data but use tables to bring back numbers and that will be used for calculations. I could build 100s of pages with calculations yet as it grows, I don’t want my methods to become a problem.

Last night I came upon an issues that seemed insignificant but made me rethink my approach to my app. I’ve seen this before on other app builders (not that I have tons of experience) . I don’t think it’s just appgyver but my approach, how efficient my methods are and also not knowing how the app works in the back ground. As an example I have few lists Ive added and while loading these list, I’ve been observing the time the app loads and the time the data is actually completed loading through debugger. That said I may be pushing buttons when certain data has not yet finished filtering In or Looping doesn’t work in many cases because data is still being processes due to large lists. I’ve learned to adjust but I feel my biggest future problem is The load I am putting on my pages.

If I go into detail I can make a book on the issues I’m having and these issues kill many hours of my day. Not saying it is AppGyver but my approach as a newby. The broader question may lead me into researching my specific issues and learning to forsee the issues instead of figuring out what my issues is in this intance.

  1. I am loading my lists on app start in an app veriable (not Rest API). What is the best method to search through a list? Is it rest api, or the way I have it? I have noticed that a times composer pro lags and not others but it still makes me wonder if I’m creating this.

  2. What is the best approach to dealing with large list with in the app, searching through them. Simply put, I have like 30 text componants that will be looking int 2 large list based on 1 value. As that value changes all others componants go to work at the same time. Should I make smaller list, and would that help if I compartmentalize into groups of data? I’d rather not do this but willing to if I have to.

  3. is using too many app Variables affecting my performance?

  4. Can I overload my page with containers and componants?

Over all, I need the best methods to dealing with many large lists, rules of thumb on amounts of containers and companants per page and dealing with many pages. Creating smooth transitions, etc.

I am looking for a quick guidance or link to a small read not a book with 1000 pages that tells me about everything except my current challenges.

Thanks

Can I suggest you take one step back and storyboard your app?

No need to use a program, just a few sheets of paper showing the hand sketched rough layout, and then words beside each page saying what happens or what the pages do. Then explain how the pages link together. With this for people to look at you will get some great feedback.

Of coarse I can. looking for suggestions and tips on how to structure my app and what to stay away from doing.

Great info. I am sure someone will be able to help with all that good description.

One thing I have learnt, is that performance in composer and preview is not a great guide as to what the apps will do, so even in an incomplete state I would be doing an android /ios build and loading it to test the real app´s performance. On my app and I left that to the end, kind of fearing it might be really tricky, but found its not too bad to get things on iOS testflight and even easier on android just to install the APK.

If it turns out to just be a composer issue, then perhaps build the flows on a different page and then group them for use on the real page?

Hopefully someone like @Mevi will be able to give some tips on optimising performance with this structure.

Good luck!

Thanks. Good point. I will see if I can get test test android build. It may be fine in the end.

I have a lot of calcs in my app, and I had to optimize it to speed up output reporting to avoid delay. What I learned was calcs are faster than record retrieval. When I look at your spec, I see that you are likely to have a lot of look-ups. You will likely want to do that globally and have the info retrieved asynchronously with your calcs assuming you use a calc button. I found I had to add delays to my look-up flow to ensure I got the value as fast as possible without going into a slow poll routine.

I agree with @Phil_Evans that performance in the viewer was slower than in the compiled app (and not nearly as buggy).

You’re welcome to check out the accessible version of my app to see if anything is similar, and I can try to help. “my fuel cell friend” on Android

You will likely not get any responses from AG because your question is subjective.

Cheers,

Rob

2 Likes

Thank you very much. I will look into it.

  1. When you talk about lag in Composer Pro, do you mean in platform.appgyver.com or the preview app? Regardless, this depends on the size of your data set. By default I would say that the best for performance would be a REST API you could query with the specific thing you are searching for, instead of going through the list on the device (= in the app made in Composer). But if your data set is not large, you can do it on device via formulas (FIND comes to mind).
  2. I’m not sure I understand this question but if you try to edit data within a list, there are some bugs related to that that affect performance. See this thread. Basically for now I would recommend doing editing on a separate page if it slows down your performance considerably, but you can evaluate this by doing as @Phil_Evans suggested and building your apk/ipa.
  3. Yes at some point, if you have hundreds of app variables that you update/access often. This should not very easily become a bottleneck, but it might slow down performance in Composer (platform.appgyver.com)
  4. Yes you can, if you have a whole lot on one page. Use Recycler for long lists to lessen the load on the user’s phone.

I will look into recycler.

I did get an apk and it was similar results to the view. I don’t think. Composer is acting up. It’s mostly all the things I’ve added to a page. Which I have learned to expect.

I took a couple days searching and learned that a good REST api is faster because of the indexing on the SQL and how it manages data.

But,
Since my data is fixed (read only) and in my case, it needs to be available off line, I took another 2 days to break up data in a similar manner as SQL, I assume.

Data1, data 2, data3 and so on. In the end 1 app variable with labels, “All_data” which would return a list based on criteria I gave it. It may take many app variables but I’m willing to take this approach until I feel I completely need a Rest api.

I’m happy with the results so far. This confirms that doing lookups and searches in big records, On-device had mostly a negative effect because of the searches done every time.

If there was a way to keep the data from refreshing, I assume would be the fix. I say this because I have this app prebuild on another app builder linked to an excel spread sheet and 0 issues. It loads up the data and never refreshes. The tables have no issues. If I tryed to build tables here, it would kill my app since it forces updates every click of a button.
Thanks, to all, I feel I’m putting all the pieces together a day at a time.

Good that you’re able to get forward!

Not sure what you mean by data refreshing so this advice may not be helpful, but you can disable the logic of fetching the data again and again by opening the data logic canvas of the data variable and removing the delay? See https://docs.appgyver.com/app-logic/variables/data-variables#data-variable-logic

I tried that but at one point it would slowed the app more but I probably could have done something different. I will do it again (remove the delay) to avoid refreshing. I will play with it some more. If there is a way, I will find it. I just want sure if this was OK and now I know.

Thanks for your help.