Reputation: 529
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:
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.
Why don't you get to say what the activity is but get to say what happens on transition from state to state?
Upvotes: 3
Views: 200
Reputation: 4772
Well, developing applications on a mobile platform restricts the developer to some degree. It is not like a full os, running multiple applications at once is expensive on a mobile device. So what happens to your running application strongly depends on what the user is doing. If the user goes back to the main screen and 'closes' your application, you no longer have control over what happens to it. What you can control is what your application does while the user is interacting with it and you can respond to different events such as the loss of foreground. You can really only control what your application does based on what the user does.
Upvotes: 0
Reputation: 4443
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.
Upvotes: 1
Reputation: 25134
That wording is a little confusing, but here is what I'd say to your questions:
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.
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.
Upvotes: 1