(Quick mention: this is a cross-post of an issue we posted on the meteor issue tracker)
While playing with different reload-on-resume and the new Reloader - Package, I now finally found out why none of those would fix our issue: They weren’t the ones causing the reloads on every task-switch - it was the Android OS, quickly ending (destroying?) (Android lifecycle docs) the app almost immediately after switching away from it to another slightly memory intensive app (eg. “Gmail” or something similar, or another Meteor Crosswalk App), thus forcing a restart when returning to our app.
Now the thing is, I understand the need for the OS to free the memory and everything. The thing is though: We’d like to allow the user to switch away for a few seconds, eg. to copy a password from an Email or something like this, and when coming back, not having the user to fill in his username again / navigate to the right place again because the app restarted immediately.
And also we’d prefer not to do a lot of lifecycle management ourselves inside of our app, as that seems to be a whole new can of worms we wouldn’t like to get into if it’s not necessary
Is there anything we can do? Some mobile-config.js - setting we could provide perhaps, or some Cordova-API we could use for this?
Actually that’s kind of a real problem for meteor apps I start thinking now, because the reload always takes some time with Meteor Apps anyway, and if we add another few seconds for something like Reloader - it quickly could become rather painful to build something the user would like to go back and forth to for some reason or another.
The device used for testing was mainly an LG G2 (32 GB / 2 GB Ram).
Theres really nothing you can do about this in javascript aside from lowering your memory footprint, and attempting to turn off as much execution as you can when your app enters the background. But again, this will vary by OS, hardware specs and if your Android OS has battery saving features on.
Now with that said there are some hacks you can use to accomplish what you want. You can use this plugin to attempt to tell the OS that your app should not be shut off. The android plugin specifically starts your app up and makes a service connection to your application from a service, which I believe means you will see a notification in the app bar with some text saying your app is still running.
Heres the plugin :
Now with that said, if your phone does have power saving features on, even that might not work.
I have the same issue - users on my app often need to switch apps, copy & paste. Coming back to find the app has restarted does not maketh a happy user.
Does anyone have any further tips on how to reduce the likelihood of this?
@pmwisdom some good ideas there, thank you. Regarding memory, do you have any info on how much is a reasonable size for an app’s footprint? And I presume Chome’s developer tool is the best way to see and ‘debug’ this footprint? And how do you “turn off execution” in Javascript?
A reasonable app footprint is all dependent on the hardware limitations / status of your device. Aka a device with 4GB RAM Free and a full charge is going to be less likely to kill your app than a device with 1GB RAM free with 10% battery life. If iOS, you can check actual memory footprints of your application in xCode, for android i’m not sure.
If you actually are running into memory warnings, I would take a hard look at whats causing the strain. More than a few times i’ve had a cordova plugin with a memory leak. JS developers aren’t always the best Java / Obj C developers.
By turning off execution I meant that when your app enters the background (you can attach a function to the “background” cordova state), you can stop any looping activities that might occur. Basically attempt to stop any data syncing you might do in the background, stop any DOM manipulations, etc.
Actually I now suspect that the error might stem from using a package using ye olde mdg:camera - package, which itself uses the cordova-camera-plugin or somesuch, but in such a way that it asks the cordova camera package to return the image data as data URI, which can lead to memory explosion, i mean exception issues.
It might be worth it to screw around with the camera package to try to use the filesystem for storing and retrieving files, but I didn’t get around to that yet.
I appear to be facing this same issue on a build that I am working on. Kind of breaking on my end, because every time the Android app tries to hit up an external application (like say the Gallery to upload an image), the app refreshes itself.
Would like to hear if anyone managed to get this resolved. Tried a fresh build of a bare bones Meteor app, added android platform, building to android-device and the behaviour persists. Does not seem to be a plugin related issue.
This behaviour is specific to Android. Worked fine on iOS. Tested it on a first gen Moto X / 2GB ram.
