Note: most applications should not use this; there are many facilities provided by the platform for applications to operate correctly in the various power saving modes. This is only for unusual applications that need to deeply control their own execution, at the potential expense of the user’s battery life. Note that these applications greatly run the risk of showing to the user as high power consumers on their device.
I really don’t mind the battery drain, if the ignoring of battery optimizations can work. For the dynamic cards to not be reset (if the ignoring of battery optimizations don’t work), I am trying to store values of the dynamic cards to TinyDB, then load them using on app resume but it works strangely. Using local variables vs global variables have their own strange behavior. I will post it in a new topic.
But, if you have the extensions for ignoring battery optimizations, I would like to try it on my phone. I am using using oreo 8.0.0, which is supposed to work. Unless, I am misunderstanding the thunkable post.
By the way, I did read that link, but I understand none of it. I am not a programmer professionally, I only started with app inventor.
Global variables will reset when you relaunch the application too. Instead of storing the components in TinyDB, just save the content, and when user relaunches the app just create them again with a loop.
I am using global variables just for storing stuff to TinyDB. TinyDB is supposed to be permanent right? But it is behaving strangely. Please view my new post. Thank you.
Well, it literally asked whether to “let app always run in background”. The extension works! But the phone must either be lying (because my app still gets RESET to its original state [All dynamic card views GONE!], after several hours of screen off) Or App running in background can still get RESET now and then. Because I have verified with my other device, that if the app screen is up front, it won’t get RESET.
Yes. I guess, I still need to give it a try and Taifun still deserves his coffee regardless
If the phone allows the app to run in background, then it must be kodular that refuses to allow that. Ignoring the allowing of apps to run in background, so to speak.
EDIT: Before this, it was my understanding that Kodular Apps are not suggested to run in background because it drains battery. But it would like to give that as an option. And there’s no way for kodular apps to run in background, even if it wanted to. Now, I realize, it actually doesn’t want to have its apps run in the background or it doesn’t have ability to utilize the “run in background” feature by Android.
Has been like this from the very beginning. App inventor tried to give the run in background feature some years ago using services (http://services.appinventor.mit.edu). But the website now says that it is shutting it down. Bummer…
Luckily, we have hundreds of options outside Kodular/App Inventor. You see, it’s the same as if I want to make a very complex game (I like working with canvas, sprites, animation, etc.) Kodular can handle most of the things you need for a fairly decent game, but don’t expect to make a first person shooter in it! If you reach to that point, then it’s time to migrate to a new platform like Unity, Unreal, etc.
Same with your need for background services. You know it exists right?, Then all you need to do is go and learn the platform that allows that.
Totally understand your point. But currently, App Inventor is what I have the time to tinker with. It is relatively easy, tries to make things easy for non-professional or even hobbyist coders and doesn’t take much time learning its “language”.
That’s exactly why you don’t have some of the very professional features in it, like background services. Because in order to make it easy for non professionals, its architecture had to be made in a way some things got “sacrificed” to make the more important and used ones possible.
I also wish some day it will happen, but I made peace with the fact that it’s just another thing (of the many) I can’t do with Kodular/App Inventor.
