title: saving instance state on memory low situations
body: <p>i have an alert dialog wrapped around by a <code>DialogFragment</code> class. the dialog has custom layout in which i show a list of items (i use a <code>ListView</code> with an appropriate adapter). the list of items is pretty huge and important, so i save it inside a <code>Fragment</code> class in my <code>DialogFragment</code>'s <code>onPause()</code>, just like in <a href="http://developer.android.com/guide/topics/resources/runtime-changes.html#RetainingAnObject" rel="nofollow">this example</a>.</p>
  
  <p>everything works perfectly, except one very rare situation: when i leave the app with the dialog window open (by pressing the "home" button) and the device gets low on memory, it kills my app's process. when i come back to my application later, it tries to recreate the dialog, but crashes (i get a <code>NullPointerException</code> inside my dialog's <code>ListView</code> adapter), because it cannot restore the list of items that was shown in my left open dialog. this happens because the <code>Fragment</code> in which i store the dialog's state is also destroyed when system kills my app's process so my <code>DialogFragment</code> cannot recreate its dialog as it has no source of data for its list adapter.</p>
  
  <p>what i want from you is to offer me a better way to save the state of my dialog window so it could be recreated even after my app process is killed or to show me a way to cancel the dialog if the list of items is <code>null</code> before it gets resumed (i mean to cancel the dialog somewhere during its recreation). i don't consider a database a good way to store that data, as it would take too long. i'd prefer a way to stop the dialog's recreation if there is no information for its adapter.</p>
  
  <p>UPDATE:</p>
  
  <p>implementing <code>Parcelable</code> to save your objects during the application's lifecycle is really a splendid idea. writing objects to <code>Parcel</code> is fast (trust me, you won't see any delay between lifecycle changes until you start using it inappropriately), and the process of saving and restoring your app's instance state is governed by <code>ActivityManager</code> process, so even if not only your <code>Activity</code>, but also the process hosting your whole application is destroyed by the Android system, <code>ActivityManager</code> maintains the <code>Parcel</code> where your objects were saved in and restores their state if <code>Activity</code> is being recreated from scratch in a new process. big thanks to @Naveed for encouraging me to try this practice!</p>
  
  <p>NOTE FOR THOSE WHO STILL DOESN'T CATCH WHAT SAVING INSTANCE STATE REALLY IS ABOUT:</p>
  
  <p>saving instance state of your <code>Activity</code> along its lifecycle events means maintaining the changes of information that are meaningful only for your application's CURRENT UI or user's CURRENT progress, but are not essential to your application or users when they explicitly stop the app (by pressing the back button) and start it again later. this particular form of information that is really temporary should be saved within the <code>onSaveInstanceState()</code> callback method in the <code>Bundle</code> object by using the <code>put...()</code> methods for primitive Java types or implementing the <code>Parcelable</code> interface in your custom classes, and later restored in <code>onCreate()</code> or <code>onRestoreInstanceState()</code> callbakcs.</p>
  
  <p>all the other data that is important for the users no matter whether they explicitly close your application or leave it just for a short time should be saved in a persistent storage, such as an <code>SQLite</code> database or a <code>SharedPreferences</code> system so it may be restored whenever the user or your application needs its previous progress again.
  you should save this form of data within <code>onPause()</code> callback method, because it is the last method guaranteed to be called before the system is able to destroy your app's process in case it needs to recover some resources. if you choose to save the data in a method called after the <code>onPause()</code>, i.e. <code>onStop()</code> or <code>onDestroy()</code>, you are in a huge risk of not getting the data saved, because those methods might never get called if the system decides to kill your app immediately in some very bad (but not necessarily rare) case.</p>
  
  <p>another thing: please only use <code>SharedPreferences</code> when storing small amount of data, as it's not built for storing lists, collections or bundles. Consider spending just a couple of hours more to implement an <code>SQLite</code> database interface for your application and use it more comfortably to maintain large chunks of information.</p>