The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
So far, we have been treating our activity like it is our entire application. Soon, we will start to get into more complex scenarios, involving multiple activities and other types of components, like services and content providers.
But, before we get into a lot of that, it is useful to understand how all of this ties into the actual OS itself. Android is based on Linux, and Linux applications run in OS processes. Understanding a bit about how Android and Linux processes inter-relate will be useful in understanding how our mixed bag of components work within these processes.
A user installs your app, goes to their home screen’s launcher, and taps on an icon representing your activity. Your activity dutifully appears on the screen.
Behind the scenes, what happened is that Android forked a copy of a process
known as the
zygote. As a result of the way your process is forked
zygote, your process contains:
Button, also shared via copy-on-write memory
Suppose that you have an app with just one activity. From the home screen’s launcher, the user taps on the icon associated with your app’s activity. Then, with your activity in the foreground, the user presses BACK.
At this point, the user is telling the OS that she is done with your activity. Control will return to whatever preceded that activity — in this case, the home screen’s launcher.
You might think that this would cause your process to be terminated. After all, that is how most desktop operating systems work. Once the user closes the last window of the application, the process hosting that application is terminated.
However, that is not how Android works. Android will keep your process around, for a little while at least. This is done for speed and power: if the user happens to want to return to your app sooner rather than later, it is more efficient to simply bring up another copy of your activity again in the existing process than it is to go set up a completely new copy of the process. This does not mean that your process will live forever; we will discuss when your process will go away later in this chapter.
Now, instead of the user pressing BACK, let’s say that the user pressed HOME instead. Visually, there is little difference: the home screen re-appears. Depending on the home screen implementation there may be a visible difference, as BACK might return to a launcher whereas HOME might return to something else on the home screen. However, in general, they feel like very similar operations.
The difference is what happens to your activity.
When the user presses BACK, your foreground activity is destroyed. We will
get into more of what that means in the next chapter. However, the key feature
is that the activity itself — the instance of your subclass of
will never be used again, and hopefully is garbage collected.
When the user presses HOME, your foreground activity is not destroyed… at least, not immediately. It remains in memory. If the user launches your app again from the home screen launcher, and if your process is still around, Android will simply bring your existing activity instance back to the foreground, rather than having to create a brand-new one (as is the case if the user pressed BACK and destroyed your activity).
What HOME literally is doing is bringing the home screen activity back to the foreground, not otherwise directly affecting your process much.
The preview of this section was fed to a gremlin, after midnight.
The preview of this section is [REDACTED].
The preview of this section was stepped on by Godzilla.