What is retained in memory while app in on pause in Android?

103 views
Skip to first unread message

Barbarur

unread,
Aug 31, 2022, 1:33:33 PM8/31/22
to Kivy users support
Hello everyone,

I'm setting up on_pause and on_resume. I wonder what is retained of the app, if any, in the mobile memory in Android.

At the moment I just want to save on which screen user was at the moment app goes on_pause. But not sure if I can simply save it on a variable to use late for on_resume, or I better save it on the app internal storage, maybe a txt file.

Tomek CEDRO

unread,
Aug 31, 2022, 2:30:36 PM8/31/22
to kivy-...@googlegroups.com
On Wed, Aug 31, 2022 at 7:33 PM Barbarur wrote:
> At the moment I just want to save on which screen user was at the moment app goes on_pause. But not sure if I can simply save it on a variable to use late for on_resume, or I better save it on the app internal storage, maybe a txt file.

From what I remember in the doc the app going to background will be
stopped. I may be wrong but that would imply nothing is preserved
except what you store yourself. If you want something working in the
background on Android you would need an Android Service that runs
periodically. I do not know yet if Kivy has support for services,
sorry.

I am using config file (`self.config`) to store application state. In
app constructor there is a call to `self.load_config()` and when app
is closed / moved to background `on_stop()` is called that contains
`self.config.write()`. You also need to provide `build_config()`
method that will create default values when config file does not exist
with `config.setdefaults()`. I did not test that on Android yet, maybe
`on_pause()` needs to call `self.config.write()` as well.

Here is the docs:

https://kivy.org/doc/stable/api-kivy.app.html?highlight=on_resume#pause-mode

Quoting:

Warning:
Both on_pause and on_stop must save important data because after
on_pause is called, on_resume may not be called at all.


--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Robert

unread,
Aug 31, 2022, 6:04:31 PM8/31/22
to Kivy users support
App state is saved on_pause and restored on_resume.

But you don't know if the state after on_pause is going to be on_resume, or on_start
on_stop may not be called.

Most of the time the transition will be pause->resume , so most of the time it just works.

If the device has limited memory and too many apps in memory, or if the user explicitly removes the app from the task list then the transition will be (effectively) pause -> start.

That said there is some anomalous behavior if the back button/gesture is used to pause the app, not certain if that would impact the answer to your question,  work in progress.

Barbarur

unread,
Sep 1, 2022, 1:34:10 PM9/1/22
to Kivy users support
Actually I'm now a bit more confuse.

Currently on my app I have a simple:
def on_pause(self):
     return True

If i move the app to the background, do something else and come back relatively soon the app, the app open correctly to the same stage as before. But if too many apps, or I take some time to return to the app, the app is just a black screen. My understanding, this behavior is expected as per documentation states "there is no guarantee the app will reopen again".

I will modify on_pause to save some essential pieces of information like the current screen and other statues. Do these pieces of information will be retained on the memory?
- If yes, I would just add them in a variable to the code
- If not, I would save it in the internal memory?

Then when returning to the app. How can I guarantee the app would reopen correctly? Should I add my actions inside on_resume and on_start? so I can ensure whichever is the transition the app would open. Or there is any other recommended setup to ensure user won't end up with a black screen after returning to the app?

Robert

unread,
Sep 1, 2022, 5:52:15 PM9/1/22
to Kivy users support

It just works unless the user or Android kills your app for their own reasons. This event is equivalent to a reset.
If you want a reset to not be a reset, save stuff to a file on_pause and read the file on_start

Barbarur

unread,
Sep 4, 2022, 3:01:36 AM9/4/22
to Kivy users support
OK, I think I got it.

If data is still on memory, on_resume() would be called and app continues performing as normal.
If data is not on memory, on_start() would be called were we can load data we saved during on_pause().

Is there any best practices on how to handle this data? This is so far what I have in mind:

on_pause()
Save important data on the DB.
Save temporal data of the app status on a file. I might use a simple .txt file.

on_resume()
Delete the file, as app status data is still on memory and app has been resumed correctly.

on_start()
If .txt file exist (meaning the app is been open), load with the app status data from the .txt
If .txt file doesn't exist (meaning the app is freshly opening), no action taken and continue with the normal flow of the app.


Does doing something like this make sense?

Tomek CEDRO

unread,
Sep 4, 2022, 4:44:09 AM9/4/22
to kivy-...@googlegroups.com
On Sun, Sep 4, 2022 at 9:01 AM Barbarur wrote:
> OK, I think I got it.
> If data is still on memory, on_resume() would be called and app continues performing as normal.
> If data is not on memory, on_start() would be called were we can load data we saved during on_pause().

Did you verify that in practice?


> Is there any best practices on how to handle this data? This is so far what I have in mind:

I told you in the first reply, this is described in the docs:

https://kivy.org/doc/stable/api-kivy.app.html?highlight=on_resume#pause-mode


> on_pause()
> Save important data on the DB.
> Save temporal data of the app status on a file. I might use a simple .txt file.

Yes, if you use DB then you need to store data, flush it, and close
it. Just like on_stop(). Because there is no guarantee that
application will work after that.


> on_resume()
> Delete the file, as app status data is still on memory and app has been resumed correctly.
>
> on_start()
> If .txt file exist (meaning the app is been open), load with the app status data from the .txt
> If .txt file doesn't exist (meaning the app is freshly opening), no action taken and continue with the normal flow of the app.
>
> Does doing something like this make sense?

There is a "Config" infrastructure provided in Kivy. It uses plaintext
variable = value syntax (like *.ini file). This is also described in
the docs and my first answer. There are "sections" in that config, you
can have "state" section.

It is good to understand and use "Finite State Machine" model. Your
device and/or application has predefined states it can be in, and
transitions between those states. This way you always know what state
application is, and you can control allowed/forbidden transitions
between these states. For instance you have a web shop, you wan to
have states: select item, add item, add shipping info, payment,
shipment, shipment tracking, order completed, transitions between
these states can co only go one after, and it it forbidden to jump
over to shipment when payment is not completed (i.e. from shipping
info state). By storing state in the config file user will always come
back to the place where he/she was last time.

https://www.freecodecamp.org/news/state-machines-basics-of-computer-science-d42855debc66/

Robert

unread,
Sep 4, 2022, 7:21:02 PM9/4/22
to Kivy users support
The easiest thing to do is keep the app state in the App class as a Python dict. Read/write the dict as a json file.

But regaining app state based on a web db is a problem if the user at some point does not have a net connection, if the user proceeds what is the true new state of the app?

Your story is pretty much what happens in this example https://github.com/Android-for-Python/cloud_storage_examples/blob/main/rest_firestore_example/main.py  It not exactly the same, as in the example as the state is only a cloud storage key, and it is is also need every hour. But in the context of your question it is pretty much similar.

One point, between pause and resume we don't know (or care) what happens the app memory image, we do know it will be there on_resume.
Reply all
Reply to author
Forward
0 new messages