Home > Flashcards > Print Preview
The flashcards below were created by user
on FreezingBlue Flashcards. What would you like to do?
T/F android apps have a method like the main method that allows for each ap to only be started at that point?
False. Apps can be started from multiple points through androids broadcast / intent system.
What is an Activity's life cycle and what are the corresponding methods?
- A set states the Activity goes through as the user launches, uses, and finally quits the activity.
Will the system manage the resources
your activity consumes when it is still intact and in the background?
No. How the user expects the app to behave when in the background and whether the app is consuming system resources depends on the way the lifecycle methods were coded by the programmer.
Contrary to a main method approach,
how does Android manage the start of an app's lifecycle?
Unlike other programming paradigms in which apps are launched with a main() method, the Android system initiates code in an Activity instance by invoking specific callback methods that correspond to specific stages of its lifecycle. There is a sequence of callback methods that start up an activity and as sequence of callback methods that tear down an activity.
What are some examples of consequences when the lifecycle methods are not programmed accordingly for the app?
- Crash if the user receives a phone call or switches to another app while using your app.
- Consumption of valuable system resources when the user is not actively using it.
- Loses the user's progress if they leave your app and return to it at a later time.
- Crashes or loses the user's progress when the screen rotates between landscape and portrait orientation.
What is the Resumed state?
In this state, the activity is in the foreground and the user can interact with it. (Also sometimes referred to as the "running" state.)
What is the Stopped state?
In this state, the activity is completely hidden and not visible to the user; it is considered to be in the background. While stopped, the activity instance and all its state information such as member variables is retained, but it cannot execute any code.
What is the Paused state?
- During normal app use, the foreground
- activity is sometimes obstructed by other visual components that cause the activity to pause. For example, when a semi-transparent activity opens (such as one in the style of a
- dialog), the previous activity pauses. As long as the activity is still partially visible but currently not the activity in focus, it
- remains paused.
As your activity enters the paused state, the system calls the onPause() method on your Activity, which allows you to stop ongoing actions that should not continue while paused (such as a video) or persist any information that should be permanently saved in case the user continues to leave your app. If the user returns to your activity from the paused state, the system resumes it and calls the onResume() method.
- When your activity receives a call to onPause(), it may be an indication that the activity will be paused for a moment
- and the user may return focus to your activity. However, it's usually the first indication that the user is leaving your activity.
Can an Activity be in more than one of
the following main 3 states: Resumed, Paused, Stopped?
No. The activity can exist in one of only three states for an extended period of time:
What are all the states a simple android app can be in?
What is meant that Created and Started
states are transient?
- Once the onCreate() finishes execution, the system calls the onStart() and onResume()
- methods in quick succession. Your activity never resides in the Created or Started states. Technically, the activity becomes visible
- to the user when onStart() is called, but onResume() quickly follows and the activity remains in the Resumed state until
- something occurs to change that, such as when a phone call is received, the user navigates to another activity, or the device
- screen turns off.
When the user selects your app icon from
the Home screen what happens?
The system calls the onCreate() method for the Activity in your app that you've declared to be the "launcher" (or "main") activity (defined in AndroidManifest.xml) This is the activity that serves as the main entry point to your app's user interface. Then the onStart is called quickly and then the onResume is finally called to put the app in the resume state.
How is the MAIN action or LAUNCHER
category used by the system?
If either the MAIN action or LAUNCHER category are not declared for one of your activities, then your app icon will not appear in the Home screen's list of apps.
Suppose we have two Activities: MainActivity and SecondActivity. We keep going back and forth between MainActivity and SecondActivity. With respect to resources, what does the SecondActivities lifecycle look like?
Why are fragments more efficient than
What is the last lifecycle callback your app received by the android system?
onDestroy is the last callback your app process sees before it is removed from system memory.
When moving from one state to another in
an Activities lifecyle why is the onCreate parameter savedInstanceState important?
It holds the state of the app before it was put in the stopped state. We will be able to recover a user's previous session.
How should a programmer use the onStop, onPause, and onDestroy?
- Most apps don't need to implement the
- onDestroy because local class references are destroyed with the activity by system default and your activity should perform most cleanup during onPause() and onStop().
- However, if your activity includes background threads that you created during onCreate()
- or other long-running resources that could potentially leak memory if not properly closed, you should kill them during onDestroy().
For what one exception does the system
not call the onDestroy after it has already called onPause and onStop?
The system calls onDestroy() after it has already called onPause() and onStop() in all situations except one: when you call finish() from within the onCreate() method. In some cases, such as when your activity operates as a temporary decision maker to launch another activity, you might call finish() from within onCreate() to destroy the activity. In this case, the system immediately calls onDestroy() without calling any of the other lifecycle methods.
How should a programmer handle the onPause state?
- Stop animations or other ongoing actions that could consume CPU.
- Commit unsaved changes, but only if users expect such changes to be permanently saved when they leave (such as a draft email).
- Release system resources, such as broadcast receivers, handles to sensors (like GPS), or any resources that may affect battery life while your activity is paused and the user does not need them. For example, if your application uses the Camera, the onPause() method is a good place to release it.
Should a programmer use the onPause to store user changes?
Generally, you should not use onPause() to store user changes (such as personal information entered into a form) to permanent storage. The only time you should persist user changes to permanent storage within onPause() is when you're certain users expect the changes to be auto-saved (such as when drafting an email).
Is it ok to perform CPU-intensive work during the onPause?
No because it can slow the visible transition to the next activity (you should instead perform heavy-load shutdown operations during onStop()). For example, writing to a database is CPU intensive and should instead being coded in the onStop.
Suppose after the system has called the onPause callback method of your app, then the user resumed your app, must wenre-initialize components that were created during any of the callback methods leading up to the Resumed state (onCreate, onStart)?
No. When your activity is paused, the Activity instance is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state such as onCreate and onStart.
When is the onResume called by the system?
Every time your activity comes into the foreground, including when it's created for the first time. As such, you should implement onResume() to initialize components that you release during onPause() and perform any other initializations that must occur each time the activity enters the Resumed state (such as begin animations and initialize components only used while the activity has user focus).
With respect to a users progress, how should the app behave for the users perception?
The app is always alive and doesn't lose their progress.
What are examples of when an Activity is restarted?
- The user opens the Recent Apps window and switches from your app to another app. The activity in your app that's currently in the foreground is stopped. If the user returns to your app from the Home screen launcher icon or the Recent Apps window, the activity restarts.
- The user performs an action in your app that starts a new activity. The current activity is stopped when the second activity is created. If the user then presses the Back button, the first activity is restarted.
- The user receives a phone call while using your app on his or her phone.
What 2 lifecycle methods does an Activity give the programmer for handling the app being stopped and restarted?
- The Activity class provides two lifecycle methods, onStop() and onRestart(),
- which allow you to specifically handle how your activity handles being stopped and restarted. Unlike the paused state, which
- identifies a partial UI obstruction, the stopped state guarantees that the UI is no longer visible and the user's focus is in a separate activity (or an entirely separate app).
For simple android apps must a programmer implement onStop() and onRestart()?
Because the system retains your Activity instance in system memory when it is stopped, it's possible that you don't need to implement the onStop() and onRestart() (or even onStart() methods at all. For most activities that are relatively simple, the activity will stop and restart just fine and you might only need to use onPause() to pause ongoing actions and disconnect from system resources.
Does the system always call onPause before onStop?
Describe the lifecycle callbacks made when a user leaves your activity and then returns?
The system calls onStop() to stop the activity (1). If the user returns while the activity is stopped, the system calls onRestart() (2), quickly followed by onStart() (3) and onResume() (4).
How should the onStop method be implemented?
- When your activity receives a call to the onStop() method, it's no longer visible and should release almost all resources that aren't needed while the user is not using it. Once
- your activity is stopped, the system might destroy the instance if it needs to recover system memory. Although the onPause()
- method is called before onStop(), you should use onStop() to perform larger, more CPU intensive shut-down operations, such as writing information to a database.
When using resources why is it important to implement the onStop?
In extreme cases, the system might simply kill your app process without calling the activity's final onDestroy() callback, so it's important you use onStop() to release resources that might leak memory.
When the Activity is stopped, is it still in memory?
- When your activity is stopped, the Activity object is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state.
- The system also keeps track of the current state for each View in the layout, so if the user entered text into an EditText widget, that content is retained so you don't need to save and restore it.
What if the Activity object is destroyed while it is stopped, will the View objects be restored when you return to it?
Even if the system destroys your activity while it's stopped, it still retains the state of the View objects (such as text in an EditText)in a Bundle(a blob of key-value pairs) and restores them if the user navigates back to the same instance of the activity.
What lifecycle callback is called when an Activity comes back to the foreground from the stopped state?
onRestart(). The system also calls the onStart() method, which happens every time your activity becomes visible(whether being restarted or created for the first time). The onRestart() method, however, is called only when the activity resumes from the stopped state, so you can use it to perform special restoration work that might be necessary only if the activity was previously stopped, but not destroyed.
How should a programmer use the onStart method?
Because your onStop()method should essentially clean up all your activity's resources,you'll need to re-instantiate them when the activity restarts. Yet,you also need to instantiate them when your activity is created for the first time (when there's no existing instance of the activity).For this reason, you should usually use the onStart() callback method as the counterpart to the onStop() method, because the system calls onStart() both when it creates your activity and when it restarts the activity from the stopped state. Thus the onStart() method is a good place to verify that required system features are enabled.
What normal scenarios cause an Activity to be destroyed?
- User presses the Back button.
- Activity signals its own destruction by calling finish().
- The system may destroy your activity if it's currently stopped and hasn't been used in a long time.
- The foreground activity requires more resources so the system must shut down background processes to recover memory.
In the case that an Activity needed to be destroyed to give more resources to other apps, if a user navigates back to the app, how will the data be retained?
Although the actual Activity instance is gone, the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the "instancestate" and is a collection of key-value pairs stored in a Bundleobject.
What happens to an Activity when a user rotates the screen?
Your activity will be destroyed and recreated each time the user rotates the screen. When the screen changes orientation, the system destroys and recreates the foreground activity because the screen configuration has changed and your activity might need to load alternative resources (such as the layout).
What is the most basic approach to keeping an Activity from being destroyed during a phone rotation?
android:screenOrientation="portrait" in the manifest XML keeps the app from rotating.
By default, how does the system use the Bundle instance?
By default, the system uses the Bundle instance state to save information about each View object in your activity layout (such as the text value entered into an EditText object). So, if your activity instance is destroyed and recreated,the state of the layout is restored to its previous state with no code required by you. However, your activity might have more state information that you'd like to restore, such as member variables that track the user's progress in the activity.
What must be true for the Android system to restore the state of the views in an Activity?
In order for the Android system to restore the state of the views in your activity, each view must have a unique ID, supplied by the android:id attribute.
What must a programmer do to save additional data about the activity state?
Override the onSaveInstanceState() callback method. The system calls this method when the user is leaving your activity and passes it the Bundle object that will be saved in the event that your activity isdestroyed unexpectedly. If the system must recreate the activity instance later, it passes the same Bundle object to both the onRestoreInstanceState() and onCreate()methods.
With respect to restoring a bundle with previous specific system state information besides default view hierarcy, how should a
programmer code the onCreate?
- Because the onCreate() method is called whether the system is creating a
- new instance of your activity or recreating a previous one, you must check whether the state Bundle is null before you attempt to read it. If it is null, then the system is creating a new instance of the activity, instead of restoring a previous one that was destroyed.
What is an alternative to checking/restoring for a previous Activity state in the onCreate?
Instead of restoring the state during onCreate() you may choose to implement onRestoreInstanceState(),which the system calls after the onStart() method. The system calls onRestoreInstanceState() only if there is a saved state to restore, so you do not need to check whether the Bundle is null.
In all Activity methods: onCreate, onStart, onResume, onPause, onStop, and onRestoreInstanceState, should the super implementation methods be called first or last?
All methods call the super methods at the first line except for onRestoreInstanceState.
We are in Activity A and want to start Activity B. How do we do it?
- 1. Create an intent with the context of the Activity were in 'this' and the class we want to send to Activity B 'ActivityB.class'.
- 2. Use the putExtras method of intent to save a key-value pair to send to Activity B.
- 3. Use startActivity method and pass the intent.