I have a large app that makes my iPhone hot. There are several aspects of my app that may be causing the problem:
Background syncing is on (I recall Praveen (@pravse ) writing somewhere that background syncing can contribute to devices heating up)
My app is very big and complicated
I have thousands of records most of which are not read only (meaning that they are candidates for background syncing, if needed)
So, there’s a sense in which I’m not surprised that my app takes a lot of energy to run. But, what surprises me is that I can’t find discussion of the topic of apps that cause overheating and how best to make them run cooler. Am I missing something or is it really the case that there hasn’t been much discussion on the topic? If this issue hasn’t been discussed much, I’m a little surprised in part because I know that iPhone users don’t like overheating; it’s uncomfortable to hold a hot device, the battery could be damaged, and running hot probably means that the battery is getting used up more quickly. (I mention iPhones because I’m not sure if the problem occurs on Android devices.)
In my app, the “performance” seems good in the sense that I don’t feel that the app makes me wait because it is sluggish or failing to sync or whatever. The only issue I notice is the heat (phone is hot to touch).
By the way, speaking of performance, here’s a thread that I think may be related but where the issue of heat isn’t discussed directly:
From my point of view, our AppSheet apps load everything to device’s memory all at once including AppSheet itself, every settings/expressions we put in the editor, all table’s rows (either entirely or partly using partition).
Then they run things on the devices. It’s not like client-server-controlled apps (Facebook/Shopping/etc.) that feed data only need to display on current view, run smoothly.
Fortunately, only images are lazy load upon current view (not all images are downloaded at once).
So the device’s power does really matter for AppSheet apps especially apps packed with huge amount of data.
My own tricks are
1.Reuse results from expressions as much as possible. Never duplicate same expressions here and there.
2.Avoid aggregating expressions like SELECT/SUM/AVERAGE/MIN/MAX/etc. whenever possible. Any calculations out of these power hungry expressions if not so important or need to be immediately updated, I move them to be calculated in Google Sheet, let’em process on Google’s huge server instead of my tiny device. My apps only peek at results processed by server and reuse them.
3.Always test my apps on outdated/slow devices. If they run okay then no problems with newer models.
This tricks make my apps run much faster (frankly say 3 times+) and also cooler of course even with many tables and several ten thousand rows of data.
In my case, I use INDEX with slices that have already be designated (not quite the same as but similar in concept to Multitech’s user slice), to avoid SELECT() expressions. Perhpas my app would run even hotter if I hadn’t done that.
Again, my app is very big. When I get the documentation for the app (info → Properties → App Documentation → The documentation page for this app is available here), my summary is as follows:
The 1st thing is “1199 Columns”. If your tables are well normalized regarding RDBMS rules then that’s okay (nothing can be done to reduce redundancies of columns & rows causing longer sync time especially when they’re not read-only). Be aware of doing this, your app will stop working from time to time until it’s done. But it’d be worth if your situation is in the case.
The 2nd thing, my approach to avoid aggregating expressions is totally different from @MultiTech concept. With respect to his contribution in AppSheet social, I don’t think changing from SELECTs to the mix of other expressions would reduce processing quite much as long as they’re still processing in your apps which means still consuming CPU times on your device.
Instead, I create several read-only tables on GS having aggregating expressions only at their fitst cell (the A1 only), not like using old-school copy&paste the same expressions down the table’s rows in the tables containing physical data (if doing this, things are worse). Let GS takes care the rest for me automatically (maintenance free). Now in AppSheet I have many new read-only tables without any table’s settings used (label, show, required, search, etc.). They’re just sitting there quietly in my apps. All related SELECTs are changed to LOOKUPs pointing to the read-only tables (just to peek the results done on GS server). Since LOOKUP a value from a row is much much ‘much’ faster than aggregating expressions because of no extra processing required, this improves app’s performance & reduces sync time a lot. Also be aware of doing this, your apps will not be workable until it’s finished. It’s quite time consuming to re-design your data structure and modify all related components in your apps. It’s really very pain process for current running apps but the result is very satisfying to me. And of course I use this concept as normal practice in designing my new apps since then.
Wow! This is great information for me. In regard to the 1199 columns, I must admit that many are virtual columns. I’ve tried to reduce the burden on my app by limiting virtual columns as much as possible to tables that only have a few records or a relatively small number of records. But, I’m sure I could find ways to improve what I have done, especially considering the points that you have made.
For me, getting the app to do all the things I want it to do in the ways that I want it do to them has been a real challenge. Thinking about efficiency / energy use at the same time compounds the difficulty. Now that my app basically does everything I want it to do, I think I probably need to take the time to go over everything line by line to see what inefficiencies I can reduce.
It will be great if some sort of AI comes along eventually to help people like me fix their apps to run more efficiently. Or, if that’s asking too much, it would be great to have tools that provide detailed assessments of exactly what parts of an app are taking the most energy.
Even though I’ve been using AppSheet for a while now, I think I’m a complete beginner in regard to RDBMS. This is going to be hard for me, I think.
By the way, you wrote “Be aware of doing this, your app will stop working from time to time until it’s done. But it’d be worth if your situation is in the case.” What is “this” that you refer to? Rebuilding the app to conform with the rules?
1.Reorganize your GS tables using normalization methods. Each existing table would be split into 2 or more tables holding its dedicated keys and data. All keys of these tables are related to form RDBMS-wise database right on your GS file. In other words, GS does not force you to do ‘this’ like other platforms (Oracle, SQL server, Ms access, etc.) but you need to make it happend yourself especially when you’re about to take serious of making data-intensive apps. It makes your data & apps more ‘lean’, less redundancy, easier maintenance.
2.When you finish the ‘1’, your existing AppSheet app is doomed.
; your app will stop working from time to time until it’s done. But it’d be worth if your situation is in the case."
This’s a chance I’d talk about AppSheet architecture from my point of view.
AppSheet is designed to conform standard RDBMS, I’d say it’s already a good RDBMS-support platform (and this’s why I choose AppSheet). You guys are using a good (very good) stuff.
So, to build an ‘well’ AppSheet app, creators should/need to design their tables regarding RDBMS, no matter what.
But RDBMS is somewhat like a geek-limbo for most of people. This may be the reason why AppSheet also does not force/encourage creators to exercise RDBMS before creating an app (although they really should). AppSheet tries to be nice & creator-friendly as possible so it doesn’t force you anything. If you’re not creating apps for working with huge data, that’s fine. But if it’s not the case and in one day your data becomes huge, there’s no other way to go but RDBMS in order to keep your apps survived, no matter which paid-plan you are in.
The format rules and actions are what you should look at. The condition expressions used by each are evaluated in real time as you navigate (and even scroll!) through the app.
The number of tables, columns, slices, and views are not problems here.
A slice could be a problem if its expression uses CONTEXT().
My app ever had suspeciously long sync time problem because an action only refers to a VC having only tiny expression like SUM(RelatedTable[Qty]). It’s an important action that can’t be removed. After doing what I explained above, the problem’s gone.
I remember @pravse mentioned that Format Rules are evaluated while the device is runing and since you can have format rules on big views like Table views this can be hurting performance.
I have a similar app and I don’t see any of the problems described by you except that I’m trying to replace VC with real ones wherever posible to optimize it, so I also have a lot of work to do (don’t give up!) but look at how many Format Rules I have:
Data Summary
- 64 Tables - 1200 Columns - 20 Slices
UX Summary
- 210 Views - 18 Format Rules
Behavior Summary
- 270 Actions - 0 Workflow Rules
It seems like you should be able to test just by disabling the Format Rules, not necesarily deleting them:
This link is to what I think is an interesting discussion (I mean that the comments by others are interesting) from which I learned quite a lot and which helped me optimize my format rules. If anyone who is reading this is interested in improving their format rules, pay more attention to the comments than to my original post.
In regard to RDBMS, I think I would need to hire someone like you who understands RDBMS well, understands AppSheet, and could also understand (with some explanation) how my app works and why I did what I did. Then, that person could probably help me develop a plan to improve my app without destroying the functionality it currently has. I don’t think it would be practical for me to try to do it on my own at this point.
Here is the results improved by my 2nd exercise (previously over 35-40 seconds). Note that I’ve some format rules & actions benefit from the exercise because their expressions are referring to the modified VCs.
Thanks! I tried that and it still got pretty hot – though the problem may have been reduced slightly (it’s hard for me to be objective about how hot the phone gets). I’m going to try with a supposedly less powerful Android device and report back.
