Activities Lifecycle

Question

The Oreily Book Says:

Programming for Android is conceptually different than programming for some other environments. In Android, you find yourself more responding to certain changes in the state of your application rather than driving that change yourself.

It is a managed, container-based environment similar to programming for Java applets or servlets.

[...]

So, when it comes to activity lifecycle, you don’t get to say what state the activity is in but you have plenty of opportunity to say what happens on transitions from state to state.

Two Questions:

1. What do they mean you find yourself more responding to certain changes in the state of your application rather than the driving the changes yourself" Please give an example.

2. Why don't you get to say what the activity is but get to say what happens on transition from state to state?

Answer 1

That wording is a little confusing, but here is what I'd say to your questions:

1. The part about "responding" refers to the event-based nature of a lot of Android programming. For example, each Activity has standard methods like onCreate(..) and onResume(...) that are invoked automatically at certain stages in your application lifecycle. It is your job to respond correctly to these lifecycle changes.

2. I am not sure what you mean by "don't get to say what the activity is", but I'll take a guess. Basically, an Activity is not just some screen or action you define in a block of code and then display on the screen with a single call. You simple manage the state of the Activity and perform different actions at each point. For example, when the Activity starts and onCreate is called you should probably load your views and set the appearance of the Activity.

Answer 2

What they mean is basically that you are only really working on one side of an event queue. The events are all pre-defined along with the different states of your application. You just add in the listeners and decide how to react.