satya - Saturday, July 10, 2010 7:49:22 PM

Read on activity life cycle

http://developer.android.com/guide/topics/fundamentals.html

You will need to understand the onSaveInstanceState and onRestoreInstanceState methods. These are useful for

When the system, rather than the user, shuts down an activity to conserve memory, the user may expect to return to the activity and find it in its previous state.

satya - Saturday, July 10, 2010 7:50:51 PM

When does android close a foreground activity?

Search for: When does android close a foreground activity?

I understand due to orientation changes or other configuration changes. when else?

satya - Saturday, July 10, 2010 7:53:44 PM

Read this URL for understanding restarts due to configuration changes

http://developer.android.com/reference/android/app/Activity.html

If the configuration of the device (as defined by the Resources.Configuration class) changes, then anything displaying a user interface will need to update to match that configuration. Because Activity is the primary mechanism for interacting with the user, it includes special support for handling configuration changes.

satya - Saturday, July 10, 2010 7:56:53 PM

android:configChanges

Search for: android:configChanges

In some special cases, you may want to bypass restarting of your activity based on one or more types of configuration changes. This is done with the android:configChanges attribute in its manifest. For any types of configuration changes you say that you handle there, you will receive a call to your current activity's onConfigurationChanged(Configuration) method instead of being restarted. If a configuration change involves any that you do not handle, however, the activity will still be restarted and onConfigurationChanged(Configuration) will not be called.

satya - Saturday, July 10, 2010 7:57:59 PM

onRetainNonConfigurationInstance

Search Google for: onRetainNonConfigurationInstance

Search Android Developers Group for: onRetainNonConfigurationInstance

Search Android Beginers Group for: onRetainNonConfigurationInstance

Search Google Code for: onRetainNonConfigurationInstance

Search Android Issues Database for: onRetainNonConfigurationInstance

satya - Saturday, July 10, 2010 8:00:30 PM

A nice article on changing orientaion

from - http://peacemoon.wordpress.com

satya - Saturday, July 10, 2010 8:05:56 PM

You also should read this

Faster Screen Orientation Change from Android

satya - Saturday, July 10, 2010 8:08:14 PM

Read up on alternate resources

satya - Saturday, July 10, 2010 9:03:13 PM

Understand how to load different layouts based on configuration

See alternate resources and how directories are organized for different possible resource settings

satya - Saturday, July 10, 2010 9:06:47 PM

This is interesting: saving state based on ids

First and foremost, you should name all your views in your activity using the android:id attribute. This attribute is important for applications that change with screen orientation, because when Android destroys activities, it saves state only for named views. For example, suppose a user changes orientation in the midst of entering some text into an EditText view. When this happens, if you?ve named the EditText view using an android:id attribute, Android will persist any existing text inside the EditText view, and restore it automatically when the activity is recreated. In contrast, if the view does not have an android:id attribute, the system will not be able to persist the text, so when it recreates the activity, any already-entered text will be lost.

...Quoting from one of the articles above

satya - Saturday, July 10, 2010 9:14:40 PM

Understand these


layout\main.xml
layout-land\main.xml
layout-port\main.xml

satya - Saturday, July 10, 2010 9:21:53 PM

General Guidelines so far


Fix orientation in the manifest to one type
In the manfiest file you handle it yourself
specify alternate resources
handle onsaveinstancestate
handle onretainnonconfigurationinstance
provide ids to views

satya - Saturday, July 10, 2010 10:07:58 PM

Follow this thread

Killi Process with files on SD card

Search Google for: Killi Process with files on SD card

Search Android Developers Group for: Killi Process with files on SD card

Search Android Beginers Group for: Killi Process with files on SD card

Search Google Code for: Killi Process with files on SD card

Search Android Issues Database for: Killi Process with files on SD card

satya - Saturday, July 10, 2010 11:04:03 PM

ohhh read this from this url: activity is restarted NOT the PROCESS

ohhh read this

The activity is restarted but not the process!!!

quote

This means that views have a reference to the entire activity and therefore to anything your activity is holding onto; usually the entire View hierarchy and all its resources. Therefore, if you leak the Context ("leak" meaning you keep a reference to it thus preventing the GC from collecting it), you leak a lot of memory. Leaking an entire activity can be really easy if you're not careful.

When the screen orientation changes the system will, by default, destroy the current activity and create a new one while preserving its state. In doing so, Android will reload the application's UI from the resources. Now imagine you wrote an application with a large bitmap that you don't want to load on every rotation. The easiest way to keep it around and not having to reload it on every rotation is to keep in a static field:

satya - Saturday, July 10, 2010 11:08:06 PM

Remembering application context

The second solution is to use the Application context. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by calling Context.getApplicationContext() or Activity.getApplication().

satya - Saturday, July 10, 2010 11:37:58 PM

java weak reference

Search for: java weak reference

satya - Saturday, July 10, 2010 11:47:11 PM

not sure if this explains it well

http://weblogs.java.net/blog/2006/05/04/understanding-weak-references

satya - Sunday, July 11, 2010 12:02:29 AM

bottom line

when you have a reference to an object and when it is weak, we are willing to let go and accept a null in its place. Pooof it goes from your program. Like a word written with a temporary ink that fades away from view, except for its shell the weak reference standing there like a ghost.

satya - Sunday, July 11, 2010 12:03:37 AM

A merchant of apples

Has a cart load of apples. Clients come and buy half of them. Late in the day when the night falls the remaining apples just melt away, except for those that were sold.

satya - Sunday, July 11, 2010 12:59:00 AM

An explanation by Rob Wilson

...The most common use of weak references is indirect - they are used internally by the WeakHashMap class. Like HashMap, WeakHashMap associates key objects with values. However, once the key object becomes inaccessible via stronger references it becomes eligible for garbage collection. When it is freed, the map entry magically disappears. The assumption here is that if you are not using the key anywhere other than in the map you will have no need to look it up, so it should be freed.

satya - Sunday, July 11, 2010 1:00:39 AM

Refernce Objects and Garbage Collection

Search for: Refernce Objects and Garbage Collection

satya - Sunday, July 11, 2010 1:06:22 AM

WeakHashMap

Search for: WeakHashMap

satya - Sunday, July 11, 2010 1:14:47 AM

weakreference API

satya - Sunday, July 11, 2010 2:27:20 AM

You can use it where deregistration is unpredictable

This can allow to cleanout resources even if deregistration from a registry is feasible

satya - Sunday, July 11, 2010 2:37:07 AM

Detailed article on weak references

Reference Objects and Garbage Collection - Monica Pawlan

satya - Sunday, July 11, 2010 2:42:06 AM

Another bottom line statement

So, weak references allow you to refer to an object without keeping it from being collected. If the garbage collector collects a weakly reachable object, all weak references to it are set to null so the object can no longer be accessed through the weak reference.

satya - Sunday, July 11, 2010 2:45:47 AM

example of a soft ref borrowed from the above article


public class DisplayImage extends Applet {

        SoftReference sr = null;

        public void init() {
            System.out.println("Initializing");
        }

        public void paint(Graphics g) {
            Image im = (
              sr == null) ? null : (Image)(
              sr.get());
            if (im == null) {
                System.out.println(
                "Fetching image");
                im = getImage(getCodeBase(),
                   "truck1.gif");
                sr = new SoftReference(im);
           }
           System.out.println("Painting");
           g.drawImage(im, 25, 25, this);
           im = null;  
        /* Clear the strong reference to the image */
        }

        public void start() {
            System.out.println("Starting");
        }

        public void stop() {
            System.out.println("Stopping");
        }

}

satya - Sunday, July 11, 2010 2:48:16 AM

another note

Soft and weak reference objects are placed in their reference queue some time after they are cleared (their reference field is set to null). Phantom reference objects are placed in their reference queue after they become phantomly reachable, but before their reference field is cleared. This is so a program can perform post-finalization cleanup and clear the phantom reference upon completion of the cleanup.

satya - Sunday, July 11, 2010 2:49:38 AM

weak references as opposed to soft references

Weak references work well in applications that need to, for example, associate extra data with an unchangeable object, such as a thread the application did not create. If you make a weak reference to the thread with a reference queue, your program can be notified when the thread is no longer strongly reachable. Upon receiving this notification, the program can perform any required cleanup of the associated data object

satya - Sunday, July 11, 2010 2:57:21 AM

Other articles from Ms Pawlan

satya - Thursday, July 29, 2010 11:01:21 PM

activity.onconfigurationchanged is only called

if the configuration change is one that can be handled by this activity. Also when this is called the activity is NOT restarted.

satya - Thursday, July 29, 2010 11:02:25 PM

Here is api for the configuration class

satya - Thursday, July 29, 2010 11:08:05 PM

onsavecreateinstancestate

You can put stuff into the bundle in this method. This bundle is then passed to the subsequent invocation oncreate() and also the "onrestoresavedinstancestate()".

satya - Thursday, July 29, 2010 11:09:44 PM

Activity A ----> B

From A you go to B. B is working hard. If you hit the back button, you will see A with its previous state. This happens most of the time. However if A is reclaimed before hitting back, then it won't have its state unless it is saved and restored.

satya - Thursday, July 29, 2010 11:16:09 PM

Activity A ----> B ----> A (Going back)

Go from A to B and then press back to go back to A. There is no reason to restore state for B as B is being shutdown. (Especially in the same app). So the savestate is not called.

satya - Thursday, July 29, 2010 11:23:04 PM

And ...

If called, this method will occur before onStop(). There are no guarantees about whether it will occur before or after onPause().

satya - Thursday, July 29, 2010 11:27:41 PM

onrestoreinstancestate is called between onstart and onPostcreate

satya - Thursday, July 29, 2010 11:28:34 PM

you should read this onsavedinstancestate docs (api)

you should read this onsavedinstancestate docs

satya - Thursday, July 29, 2010 11:31:06 PM

onRetainNonConfigurationInstance (api doc)

onRetainNonConfigurationInstance

satya - Thursday, July 29, 2010 11:43:59 PM

This function

is called, unlike save and restore, only for configuration changes. called between onstop and ondestroy. You will use method getLastConfigurationInstance() to retrieve the object. It is assumed that a new instance will be immediately created.

satya - Friday, July 30, 2010 2:03:49 PM

android activity stuck in landscape mode

Search Google for: android activity stuck in landscape mode

Search Android Developers Group for: android activity stuck in landscape mode

Search Android Beginers Group for: android activity stuck in landscape mode

Search Google Code for: android activity stuck in landscape mode

Search Android Issues Database for: android activity stuck in landscape mode

satya - Friday, July 30, 2010 4:10:07 PM

Example of a co nfiguration changed debug message


07-30 20:08:11.525: INFO/ActivityManager(67): 
Config changed: { 
  scale=1.0 
  imsi=0/0 loc=en_US 
  touch=3 
  keys=2/1/1 
  nav=3/1 
  orien=2 
  layout=18 
  uiMode=17 
  seq=39
}

satya - Saturday, July 31, 2010 11:08:23 AM

Why use OnRetainConfigurationInstance()

Search for: Why use OnRetainConfigurationInstance()

Everytime when configuration chagnes, one is guaranteed to see the save and restore instance methods. One could use the bundles in those methods to do this. why do this in the onRetainConfigurationInstance()? Because you have to maintain state anyway because you are going down and up again.

May be because, the two states could be different and there is a level of optimization you could get. For example if you have a lot of state that you need to worry about only if the configuration changes then you dont need to do that in save and restore if the configuration hasnt altered.

satya - Friday, August 20, 2010 3:16:24 PM

See this URL for more detailed transitions and their callbacks

Android Architectural Predicates

satya - Tuesday, September 27, 2011 2:31:13 PM

if you don't want your activity to flip you can force an orientation

use android:screenOrientation attribute

satya - Tuesday, September 27, 2011 2:31:32 PM

android:screenOrientation

Search for: android:screenOrientation

satya - Tuesday, September 27, 2011 2:35:57 PM

possible values for android:screenOrientation

Example

landscape
portrait
unspecified
user
behind
sensor
...and more

satya - Tuesday, September 27, 2011 2:38:21 PM

Note for landscape, portrait

Note: When you declare one of the landscape or portrait values, it is considered a hard requirement for the orientation in which the activity runs. As such, the value you declare enables filtering by services such as Android Market so your application is available only to devices that support the orientation required by your activities. For example, if you declare either "landscape", "reverseLandscape", or "sensorLandscape", then your application will be available only to devices that support landscape orientation. However, you should also explicitly declare that your application requires either portrait or landscape orientation with the <uses-feature> element. For example, <uses-feature android:name="android.hardware.screen.portrait"/>. This is purely a filtering behavior provided by Android Market (and other services that support it) and the platform itself does not control whether your app can be installed when a device supports only certain orientations.

satya - Tuesday, September 27, 2011 3:39:06 PM

android:configChanges possible values

Examples

mcc
mnc
locale
touchscreen
keyboard
keyboardHidden
navigation
screenLayout
fontScale
uiMode
orientation
screenSize
smallestScreenSize

satya - Tuesday, September 27, 2011 3:49:48 PM

android emulator switch orientation


use Ctrl-f11 or ctrl-f12
or keypad 7 and 9

satya - Wednesday, September 28, 2011 10:46:48 AM

My temporary goal: Stop the activity restart

Couple of articles seem to suggest that if I set the android:screenOrientation to portrait then it will not be restarted and will stay portrait even if the device is rotated.

However on 2.3 when I tested this couple of things happens. The view will stay portrait even if the orientation is landscape.

However it is restarting the activity!! I don't want that

satya - Wednesday, September 28, 2011 10:52:11 AM

The only way I could stop an activity restart is to use the android:configChanges

I have used the following settings to get what I wanted.


android:screenOrientation="nosensor"
android:configChanges="orientation|keyboard|keyboardHidden"

Setting the orientation to no sensor seem to stop the device from switching the configuration. The configChanges attribute seem to stop the RESTART of the activity. Ofcourse I have to override the corresponding method in the activity


@Override
public void onConfigurationChanged(Configuration newConfig) {
  super.onConfigurationChanged(newConfig);
  //Nothing to do I am going to ignore it
  Log.d(tag,"I am ignorign the configuration chagne");
}

satya - Wednesday, September 28, 2011 10:53:14 AM

android screen orientation nosensor

Search for: android screen orientation nosensor

satya - Wednesday, September 28, 2011 10:53:41 AM

if I just have nosensor will my activity get restarted?

Search for: if I just have nosensor will my activity get restarted?

satya - Wednesday, September 28, 2011 10:58:02 AM

At least in the emulator this will not stop a restart

Int he emulator the orientation flag by itself is not stopping a restart. For example if i press ctrl-f12 the emulator is rotated. This is resulting in a restart. The actual device may not do this by mere rotation if you disable the sensor reaction. However even on the device if you were to explcitly choose a particular orientation (which may be equivalent to ctrl-f12) same things may result.

it is worthwhile testing this behavior on a real device.

but for now I am satisfied to override the configuration change and ignore it as I have done above.

satya - Wednesday, September 28, 2011 11:00:05 AM

I suspect that the objects you pass wround on configuration change may be memory based...

I know there is a call back to pass model objects between view restarts due to configuration changes. These may be in memory objects.

if the data is not large you may want to prefer bundles through restore state callbacks.

satya - 8/17/2013 4:59:44 PM

An example of order of calls on flip


//Begining...
onCreate
onStart
onRestoreInstanceState
onResume


//configuration changed
onSaveInstanceState
onPause : partially visible ui
onStop: ui invisible
onRetainNonConfigurationInstance: an local objects you want to remeber
onDestroy

//Back to begining

satya - 8/17/2013 5:05:27 PM

So by the time onResume happens you restored your instance state

satya - 8/17/2013 5:08:59 PM

onRestart is called when you go to home and comeback

this means your activity is not destroyed. it is merely stopped and restarted. This also means this is not a configuration change. So save and restoreinstance methods may not be called. configurationinstance callback is not called either.

satya - 8/17/2013 5:20:10 PM

Android activity onPostCreate

Search for: Android activity onPostCreate

satya - 8/17/2013 5:21:00 PM

Docs on onPostCreate

satya - 8/17/2013 6:23:33 PM

Here is what it says

Called when activity start-up is complete (after onStart() and onRestoreInstanceState(Bundle) have been called). Applications will generally not implement this method; it is intended for system classes to do final initialization after application code has run.

Derived classes must call through to the super class's implementation of this method. If they do not, an exception will be thrown.

So it happens prior to onResume...

satya - 8/19/2013 2:52:35 PM

Behaviors to test


//Test going back and restart
New activity
Go back
Restart the app from app panel

//Test going back and revisit
Go home
Revisit the app by pressing long on home

//Test going home and restart
Go home again
Restart the app from the app panel

//Test going back and revisit
Go back
Revisit the app by pressing long home

satya - 8/19/2013 2:52:58 PM

I will tell you the calling sequence. There are some surprises.

satya - 8/19/2013 2:57:04 PM

//Test going back and restart


//New activity
onCreate
onStart
onResume

//Go back
onPause
onStop
onDestroy

//Restart the app from app panel
onCreate
onStart
onResume

satya - 8/19/2013 3:00:02 PM

The surprise part: Going back may and does destroy the activity!

When you press back you would think the activity is not destroyed as you expect to come back to the activity. But that is what is happening on "back". The activity is actually getting destroyed. As you will shortly this doesn't happen on going home.

However the activity is destroyed the process is kept in memory as you can see it by long clicking the hoem button to see the active processes.

Also, not a surprise, notice that the onRestart is not called because the activity is destroyed. so a brand new onCreate is called.

satya - 8/19/2013 3:14:19 PM

//Test going home and revisit


//Go home
onSaveInstanceState: ?? why?
onPause
onStop

//Revisit the app by pressing long on home
onRetart: Notice no oncreate
onStart
onResume: Notice no onRestoreInstancestate

May be the onRestoreInstanceState is not called because I havent' saved anything? is that a result of optimization? Not sure!!!

satya - 8/19/2013 3:16:15 PM

//Test going home and restart


//Go home again
onSaveInstanceState: ?? why?
onPause
onStop

//Restart the app from the app panelonRetart: 
Notice no oncreate
onStart
onResume: Notice no onRestoreInstancestate

The revisit and restart behavior is identical in this case.

satya - 8/19/2013 3:19:42 PM

//Test going back and revisit


//Go back
onPause
onStop
onDestroy

//Revisit the app by pressing long home
onCreate
onStart
onResume

Notice, no save instance, no non configuration object instance. The activity is destroyed with no indication or opportunity of saving the instance state.

satya - 8/19/2013 3:21:14 PM

So....

when you go home and come back, the UI state is maintained and the activity is not lost. its local pointers hang around. On back the activity is destroyed. It is as if you are restarting the activity.

However if you have a background task, when the activity starts it may want to recognize it if it is running!!!

satya - 8/19/2013 3:40:48 PM

Bottom line with Going Home/Back...

if you are going home then UI may be preserved. this means

1. you don't restore state 
2. nor configuration instance is called
3. local pointers are still valid

when you go back,

1. the whole activity is destroyed
2. No opportunity to save/restore instances
3. onNonConfiguration instance not called 
4. stop/destroy called
5. A subsequent start of the activity is a brand new start

satya - 8/19/2013 3:47:54 PM

This is what happens on flip


onSaveInstance..
onPause
onStop
onRetainNonConf...
onDestroy

//followed by
onCreate
onStart
onRestore
onResume

satya - 8/19/2013 3:49:45 PM

There may be three activity states an activity may be in


Create I - Brand new create
Restarted - Restarted with out destroying the UI
Create II - Recreated after a configuration change

satya - 8/19/2013 4:00:18 PM

3 things again


Restarted with hints to save/restore state (flip)
Restarted by keeping state intact (home/revisit)
Restarted by keeping no state at all (new start)

satya - 8/20/2013 10:30:15 AM

May be 4 states


New - A brand new activity

New like - A new activity that has left earlier a pending task
   - difficult to distinguish from the first one
   - a back may have indirectly finished the activity
   - only way to know is to indicate that you have a pending item to deal with

Same state - UI is not disturbed
   - ex: home and returning to the activity
   -     or a phone call ends 

Restart with save state hint - typically due to a config change
   - onRestoreInstanceState gets called
   - onRetainNOn... is called before during shutdown

satya - 8/20/2013 10:35:11 AM

What is you were to put a non managed dialog and : home/revisit


//Dialog is retained

//Order of calls

onSave..
onPause
onStop

onRestart
onStart
onResume

satya - 8/20/2013 10:36:25 AM

A Back on an activity may or will kill/finish the activity

satya - 8/20/2013 10:37:01 AM

where as A Back with a dialog on an activity will simply close the dialog

satya - 8/20/2013 12:51:08 PM

when you show a dialog and go back no life cycle callbacks on the acitivity gets called

As a dialog shows up on top of an activity i thought the activity will fire off life cycle dialogs. It doesn't. It behaves as if it is another view that is part of the view state...

satya - 8/21/2013 10:54:12 AM

onRetainNonConfigInstance is deprecated since API 13

satya - 8/21/2013 10:58:18 AM

Recommendation is to use fragments explicitly and use setRetainInstance

satya - 10/12/2013 9:33:42 PM

You should read this about onRetainconfiginstance although it is deprecated

These guarantees are designed so that an activity can use this API to propagate extensive state from the old to new activity instance, from loaded bitmaps, to network connections, to evenly actively running threads. Note that you should not propagate any data that may change based on the configuration, including any data loaded from resources such as strings, layouts, or drawables.

The guarantee of no message handling during the switch to the next activity simplifies use with active objects. For example if your retained state is an AsyncTask you are guaranteed that its call back functions (like onPostExecute(Result)) will not be called from the call here until you execute the next instance's onCreate(Bundle). (Note however that there is of course no such guarantee for doInBackground(Params...) since that is running in a separate thread.)

satya - 10/12/2013 9:35:48 PM

If you understand this method first, you will understand the meaning of retaining fragment instances

Retaining fragments is a generalization of this basic need that is illustrated by this method.

satya - 10/12/2013 9:45:33 PM

Key commentary on activity rebirth

If an object holds a pointer to a current activity, that activity can get restarted and the object may have a stale handle of the activity.

An example of this stand alone object could be an async task. Or it might be a large worker object that you dont want to recreate willy nilly when the device is rotated.

This object is really a part and parcel of the activity but you don't want that object to be recreated.

A simple answer (as it turns out a wrong one) is to look for the activity call backs and tell this object the new pointer of the activity.

But how does the activity knows what this object is?

You may say, pass it through a bundle. But the bundle has no API to store object pointers to reestablish that connection.

Try as hard as you may you cannot do this type reconnecting from inside the activity unless the owner of the activity provides a mechanism to reconnect them.

This is precisely the need for onRetainConfigurationInstance()! The OS is saying by calling this method, that the activity is going to restart and the OS is going to remember "ONE" and "ONLY ONE" object reference that is associated with this activity.

This allows you to ask the OS (through the newly minted activity), Hey, where is my object that I told my old activity that he/she is related to

You get that object back if you were to call the getRetainedNonConfigInstance.

This stand alone object is called, now rightfully, the "non configuration instance"! Because it is that portion of the activity that does not depend on a configuration change and wants to get re attached with every instance of the activity.

A better name would have been "THE EXTERNAL OBJECT" that stays around and associated to the activity.

satya - 10/12/2013 9:49:15 PM

So why deprecate this??

I am guessing here...

There is a drawback to this overloaded method. There is only one object root that can be done this way. what if your activity is inherited from a set of libraries where each library has extended the activity in their own way. what if each library has their own root object to be remembered across activity invocations?

that will be trouble. Only one of them can save theirs unless they cook up their own protocol and agree on a meta-root.

In comes fragments. The OS said, ok, with fragments, you can add as many fragments as you want to an activity. And if you tell them to hang around I will just bring keep them around.

Because fragments are many, now the clients have the ability to store as many roots as you want!!

satya - 10/12/2013 9:56:20 PM

Not only that being a fragment....

being a fragment you get one more contract with the activity. Not only that you can retain state, but these objects (fragments) can follow the state of the activity. An added benefit should you want that information to be put to use

satya - 10/22/2013 1:49:09 PM

An interesting note on OnDestroy

The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.

satya - 10/22/2013 1:53:24 PM

Another note on this

Note: do not count on this method being called as a place for saving data! For example, if an activity is editing data in a content provider, those edits should be committed in either onPause() or onSaveInstanceState(Bundle), not here. This method is usually implemented to free resources like threads that are associated with an activity, so that a destroyed activity does not leave such things around while the rest of its application is still running. There are situations where the system will simply kill the activity's hosting process without calling this method (or any others) in it, so it should not be used to do things that are intended to remain around after the process goes away.