0

I am working on an android project with a few other developers and a bug was raised where Instance states were not being retained on garbage collection:

The actual bug reported:

The app has one activity with a bunch of fragments. If "don't keep activities" is checked in developer options and the user clicks on any button that changes the visible fragments, and then navigates away from the app and then back, it relaunches the app to its original state instead of the last state.

Another Dev on the project raised the following concern:

"The saving of instances will cause the apps in memory size to bloat. Already, because of the amount of drawables, the apps memory size is too high.

Its ok, if the app restarts after a while of non usage by the user."

My understanding was that the savedInstance Bundle actually gets written to physical memory, is that not correct? Is the above quote a valid concern?

erik
  • 4,946
  • 13
  • 70
  • 120

2 Answers2

3

My understanding was that the savedInstance Bundle actually gets written to physical memory, is that not correct?

I am interpreting "written to physical memory" as meaning "written to a file on a filesystem" (a.k.a., "persisted").

The instance state Bundle is not persisted. Android 5.0+ gives you a different hook for a PersistableBundle that is persisted and therefore survives a reboot.

However, the instance state Bundle is passed across process boundaries to a core OS process. That data can then be used if your process is terminated, but the user returns to your app while your task is still around (e.g., via the recent-tasks list).

Is the above quote a valid concern?

The only piece of that quote that could reasonably be evaluated by people here on SO is:

The saving of instances will cause the apps in memory size to bloat

Saving one byte in the Bundle will consume more memory than will saving zero bytes in the Bundle. Hence, mathematically, the quote is accurate. The key is to keep the Bundle small. They can't get too big anyway for other reasons (1MB limit for IPC calls). Small instance state Bundles should not be a problem.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • mathematically saying the saving of instances state will cause an app to bloat your math solution is fallacy of hasty generalization because one byte doesn't make a bloat. – danny117 Nov 14 '14 at 18:38
0

A correctly coded saveinstance state will survive in the background for weeks at a time and doesn't require anything more than a few bytes worst case a few k of ram.

Your other dev has a learning curve issue.

InstanceState save what you need to recreate the way the app currently looks to the user. Let's use a tic tac toe analogy. You have nine positions. Each position is x o or blank. and you save who's turn it is. A ten character string no bloat here this is not rocket science.

InstanceState for the app with a 10 drawables on the screen. you save the drawables to external storage as jpg or even bmp. Then you save the name of the drawables in the instanceState. A 1000 chars of instance state no bloat this is computer science 1k to restart a very complex app.

SaveinstanceState is not bloat ware its an awesome app.

danny117
  • 5,581
  • 1
  • 26
  • 35