Game Development Reference
In-Depth Information
This also has some other implications. First, all of the activities of the application (those on the
stack that are paused and the one that is active) share the same VM. They also share the same
memory heap. That can be a blessing and a curse. If you have static fields in your activities, they
will get memory on the heap as soon as they are started. Being static fields, they will survive the
destruction of the activity and the subsequent garbage collection of the activity instance. This
can lead to some bad memory leaks if you carelessly use static fields. Think twice before using a
static field.
As stated a couple of times already, we'll only ever have a single activity in our actual games.
The preceding activity starter is an exception to this rule to make our lives a little easier. But
don't worry; we'll have plenty of opportunities to get into trouble even with a single activity.
Note This is as deep as we'll get into Android UI programming. From here on, we'll always
use a single View in an activity to output things and to receive input. If you want to learn about
things like layouts, view groups, and all the bells and whistles that the Android UI library offers,
we suggest you check out Grant Allen's book, Beginning Android 4 (Apress, 2011), or the excellent
developer guide on the Android Developers site.
The Activity Life Cycle
The first thing we have to figure out when programming for Android is how an activity behaves.
On Android, this is called the activity life cycle . It describes the states and transitions between
those states through which an activity can live. Let's start by discussing the theory behind this.
In Theory
An activity can be in one of three states:
Running : In this state, it is the top-level activity that takes up the screen and
directly interacts with the user.
Paused : This happens when the activity is still visible on the screen but partially
obscured by either a transparent activity or a dialog, or if the device screen is
locked. A paused activity can be killed by the Android system at any point in
time (for example, due to low memory). Note that the activity instance itself is
still alive and kicking in the VM heap and waiting to be brought back to a
running state.
Stopped : This happens when the activity is completely obscured by another
activity and thus is no longer visible on the screen. Our AndroidBasicsStarter
activity will be in this state if we start one of the test activities, for example. It
also happens when a user presses the home button to go to the home screen
temporarily. The system can again decide to kill the activity completely and
remove it from memory if memory gets low.
In both the paused and stopped states, the Android system can decide to kill the activity at any
point in time. It can do so either politely, by first informing the activity by calling its finished()
method, or impolitely, by silently killing the activity's process.
 
Search WWH ::




Custom Search