Replying back to the list. Most (all?) platforms' model is process == application (more or less).
In Android, there really is no such thing as "the application" (there is, but it is useful to ignore it at first). Therefore, one should unlearn that equality between "application" and process The unit of installation is package, and the unit of execution is component. Components come in various shapes: activity, broadcast receiver, service, content provider, etc. These components have well defined lifecycles with callbacks. On the other hand, a process is more or less just an implementation detail, having to do more with memory and file protection, crash handling, dealing with out of memory situations, etc. Android keeps processes running as long as possible while there is enough memory. This significantly improves performance if the user or the system again needs one of the components provided by this process. Well written code detects when it's in the background and stops CPU intensive work, so it just sits there dormant, not consuming the CPU & battery resources. Mark Murphy compares this model to a web application: just because the user left a page, doesn't mean the web server is stopped right away. I see a similarity to Microsoft COM. Android components are similar to COM objects with a well defined interface (Automation?). Releasing a COM object is not the same as stopping its process, one could keep the process around for a while in case another of its objects is needed (although I don't remember is Windows actually does that....). There is a hack an application can use to stop its process, but it is seen by Android as an application crash, and may have unplesant side effects, so I'm not going to provide it here. Bottom line - don't worry about process lifetimes too much yourself, and tell users who do that they need to "learn to stop worrying and love the Android way of managing resources". -- Kostya 2011/5/29 Anirvan <[email protected]> > thanks for your patience and responses kostya. i really appreciate it. > > the tip for tracking the process state through the ddms is a good one. > so far, i've only used the ddms to track memory usage, cpu load and > log comments. and yes, you're right. even upon pressing 'back' from > the one and only main activity does NOT kill the process. > > i wonder why :[ - it feels very counter-intuitive. i understand that > pressing the 'home' button while the app runs, puts the app's state > into a stack which android can recover again. but i certainly feel > that pressing back from the main activity should kill the process > unless explicitly programmed not to do so. > > at this point, i'll need to work around this new found knowledge about > process lifecycles. > > while you mentioned that there doesn't exist a callback mechanism for > process kills, but is there a way through which the app process can be > killed programmatically from within an app? > > > On May 29, 2:14 am, Kostya Vasilyev <[email protected]> wrote: > > Your application logic should be coded in such a way that the process can > be > > killed at any time (usually once it's in the background), or not be > killed, > > and still work correctly. There is no callback when the process is > killed. > > > > Pressing the back key always finishes the current activity - the back key > > tells Android that the user is done with whatever he was doing in that > > activity, and will not come back. But this does not kill the process, > > because activity != process. > > > > Try pressing the home key instead - the activity will be paused / > stopped, > > but not terminated, then come back by long-pressing the home key - you > > should see onStart / onResume, but not onCreate. > > > > All of this is explained very well here: > > > > http://developer.android.com/guide/topics/fundamentals/activities.htm... > > > > http://developer.android.com/guide/topics/fundamentals/processes-and-... > > > > For debugging purposes, use "adb shell ps" (the usual Unix "ps" - process > > state), look for your application within the process list, and note its > > process ID. > > > > Or use the DDMS perspective in Eclipse - the second column in the Devices > > panel, under Online, is also the process ID. > > > > -- Kostya > > 2011/5/29 Anirvan <[email protected]> > > > > > > > > > > > > > > > > > thanks for the response Kostya. but i does one truly determine that > > > the application 'process' has terminated? > > > > > for testing, i've created a single Activity which serves as the Main. > > > when i press the back button after launching this activity, the app > > > ends. i've also verified that the app is no longer running by checking > > > the Task Manager. > > > > > is there some other check that i can make from my program to make sure > > > that the app process has terminated? > > > > > On May 29, 12:33 am, Kostya Vasilyev <[email protected]> wrote: > > > > Statics do live as long as the process. > > > > > > onDestroy is not an indication that the process is exiting - your > > > activity > > > > is getting destroyed, but the process may (and in your case, does) > live > > > on. > > > > When you come back to the application, Android uses the same process > to > > > > create another instance of your activity and call onCreate (and other > > > > callbacks). > > > > > > Try stopping your application in the Settings application. > > > > > > Making a small code change and relaunching the debug session is > another > > > way > > > > to make sure you get a brand new process. > > > > > > -- Kostya > > > > > > 2011/5/28 Anirvan <[email protected]> > > > > > > > hello, > > > > > > > for quite some time i was blissfully of the opinion that static > > > > > [instance] variables exist as long as the app runs. however, to my > > > > > dismay, and much alarm, i feel that it's not true. > > > > > > > for mere testing, i created a static list of strings, and in my > main > > > > > activity class overrode the onDestroy method to print a message to > > > > > verify that the app exited. in the onCreate method i simply added a > > > > > new string, and printed the contents of the list. what i've found > is > > > > > that the size of the list keeps on increasing, and all the string > > > > > values added previously are still present. > > > > > > > is there some cardinal mistake in what i assumed should be the > > > > > behaviour of instance variables, or is there something that i > should > > > > > keep in mind when dealing with instance variables? > > > > > > > what gives? > > > > > > > thanks for your time and help. > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "Android Developers" group. > > > > > To post to this group, send email to > > > [email protected] > > > > > To unsubscribe from this group, send email to > > > > > [email protected] > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/android-developers?hl=en > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > [email protected] > > > To unsubscribe from this group, send email to > > > [email protected] > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
