How to replicate app going into background mode?

This seems to apply to both iOS and Android.

After leaving my app closed for a while ( a day or so ) the app seems to go into background mode and when it is opened again it shows the splash screen again and takes a while to start up.

This is fine (although slow) but on some devices it has an error as all the local data / variables have been cleared (except the logged in firebase user).

This causes an error in the app which I can’t replicate as it does not appear to happen on my devices.
It may be the device is clearing the data to conserve memory on devices with low storage?

Is there a way to replicate this issue by forcing my app into background mode?
I need to test recovering from this state. I have the user so it should be possible I just need to test it.

1 Like

There should be logic placed in the app startup that handles the clearing/fetching/updating the local data/ variables.

as for replicating, you would need to get the device in question and manually trigger this.

Unfortunately I can’t replicate this on any of my own devices it only happens in production for a handful of users.

It is hard to test the code if I can’t replicate the issue.

There is a way but paid of course. You can use BrowserStack to create the device the user is having issues on. This is one way to test.

You can pretty much create any device. Here is a list of them all.

1 Like

Thanks not ideal but definitely an option.
I have used Browserstack before.

So just to clarify.

Once the device comes out of background mode and has decided to clear the apps data it will run the constructor in app.component.ts again the same as if the user first opened the app.

Thanks for the help on this!

3 Likes

As far as I understood your issue and my experience with capacitor: After some time in the background, the OS will kill the app. The OS will keep a screenshot of the app to show in the recently used apps (ios: double click home, swipe up far; android: switch app button). All data the app needs to restore its state should be stored in something more persistent than application variables (e.g. local-storage, native-storage, indexed-db, etc…). You can test this in the browser by closing and reopening the application tab.