*
* To be of use with {@link android.content.Context#startActivity
* Context.startActivity()}, all activity classes must have a corresponding
* {@link android.R.styleable#AndroidManifestActivity <activity>}
* declaration in their package's AndroidManifest.xml.
*
* Topics covered here: *
* The Activity class is an important part of an application's overall * lifecycle, and the way activities are launched and put together is a * fundamental part of the platform's application model. For a detailed * perspective on the structure of an Android application and how activities * behave, please read the * Application * Fundamentals and * Tasks and Back * Stack developer guides. *
* ** You can also find a detailed discussion about how to create activities in the * Activities developer * guide. *
** The {@link android.support.v4.app.FragmentActivity} subclass can make use of * the {@link android.support.v4.app.Fragment} class to better modularize their * code, build more sophisticated user interfaces for larger screens, and help * scale their application between small and large screens. *
* ** For more information about using fragments, read the * Fragments developer * guide. *
* * ** Activities in the system are managed as an activity stack. When a * new activity is started, it is placed on the top of the stack and becomes the * running activity -- the previous activity always remains below it in the * stack, and will not come to the foreground again until the new activity * exits. *
* ** An activity has essentially four states: *
** The following diagram shows the important state paths of an Activity. The * square rectangles represent callback methods you can implement to perform * operations when the Activity moves between states. The colored ovals are * major states the Activity can be in. *
* *
*
*
* There are three key loops you may be interested in monitoring within your * activity: * *
* The entire lifecycle of an activity is defined by the following Activity * methods. All of these are hooks that you can override to do appropriate work * when the activity changes state. All activities will implement * {@link android.app.Activity#onCreate} to do their initial setup; many will * also implement {@link android.app.Activity#onPause} to commit changes to data * and otherwise prepare to stop interacting with the user. You should always * call up to your superclass when implementing these methods. *
* * * *
* public class Activity extends ApplicationContext {
* protected void onCreate(Bundle savedInstanceState);
*
* protected void onStart();
*
* protected void onRestart();
*
* protected void onResume();
*
* protected void onPause();
*
* protected void onStop();
*
* protected void onDestroy();
* }
*
*
* * In general the movement through an activity's lifecycle looks like this: *
* *| Method | *Description | *Killable? | *Next | *||
|---|---|---|---|---|---|
| {@link android.app.Activity#onCreate * onCreate()} | *Called when the activity is first created. This is where you should do
* all of your normal static set up: create views, bind data to lists, etc. This
* method also provides you with a Bundle containing the activity's previously
* frozen state, if there was one.
*
* Always followed by |
* No | *onStart() |
* ||
| * | {@link android.app.Activity#onRestart * onRestart()} | *Called after your activity has been stopped, prior to it being started
* again.
*
* Always followed by |
* No | *onStart() |
* |
| {@link android.app.Activity#onStart * onStart()} | *Called when the activity is becoming visible to the user.
*
* Followed by |
* No | *onResume() or onStop() |
* ||
| * | {@link android.app.Activity#onResume * onResume()} | *Called when the activity will start interacting with the user. At this
* point your activity is at the top of the activity stack, with user input
* going to it.
*
* Always followed by |
* No | *onPause() |
* |
| {@link android.app.Activity#onPause * onPause()} | *Called when the system is about to start resuming a previous activity.
* This is typically used to commit unsaved changes to persistent data, stop
* animations and other things that may be consuming CPU, etc. Implementations
* of this method must be very quick because the next activity will not be
* resumed until this method returns.
*
* Followed by either |
* Pre-{@link android.os.Build.VERSION_CODES#HONEYCOMB} | *onResume() or* onStop() |
* ||
| {@link android.app.Activity#onStop * onStop()} | *Called when the activity is no longer visible to the user, because
* another activity has been resumed and is covering this one. This may happen
* either because a new activity is being started, an existing one is being
* brought in front of this one, or this one is being destroyed.
*
* Followed by either |
* Yes | *onRestart() or* onDestroy() |
* ||
| {@link android.app.Activity#onDestroy * onDestroy()} | *The final call you receive before your activity is destroyed. This can * happen either because the activity is finishing (someone called * {@link Activity#finish} on it, or because the system is temporarily * destroying this instance of the activity to save space. You can distinguish * between these two scenarios with the {@link Activity#isFinishing} * method. | *Yes | *nothing | *||
* Note the "Killable" column in the above table -- for those methods that are * marked as being killable, after that method returns the process hosting the * activity may be killed by the system at any time without another * line of its code being executed. Because of this, you should use the * {@link #onPause} method to write any persistent data (such as user edits) to * storage. In addition, the method {@link #onSaveInstanceState(Bundle)} is * called before placing the activity in such a background state, allowing you * to save away any dynamic instance state in your activity into the given * Bundle, to be later received in {@link #onCreate} if the activity needs to be * re-created. See the Process Lifecycle section * for more information on how the lifecycle of a process is tied to the * activities it is hosting. Note that it is important to save persistent data * in {@link #onPause} instead of {@link #onSaveInstanceState} because the * latter is not part of the lifecycle callbacks, so will not be called in every * situation as described in its documentation. *
* ** Be aware that these semantics will change slightly between applications * targeting platforms starting with * {@link android.os.Build.VERSION_CODES#HONEYCOMB} vs. those targeting prior * platforms. Starting with Honeycomb, an application is not in the killable * state until its {@link #onStop} has returned. This impacts when * {@link #onSaveInstanceState(Bundle)} may be called (it may be safely called * after {@link #onPause()}) and allows an application to safely wait until * {@link #onStop()} to save persistent state. *
* ** For applications targeting platforms starting with * {@link android.os.Build.VERSION_CODES#P} {@link #onSaveInstanceState(Bundle)} * will always be called after {@link #onStop}, so an application may safely * perform fragment transactions in {@link #onStop} and will be able to save * persistent state later. *
* *
* For those methods that are not marked as being killable, the activity's
* process will not be killed by the system starting from the time the method is
* called and continuing after it returns. Thus an activity is in the killable
* state, for example, between after onPause() to the start of
* onResume().
*
* If the configuration of the device (as defined by the {@link Configuration * Resources.Configuration} class) changes, then anything displaying a user * interface will need to update to match that configuration. Because Activity * is the primary mechanism for interacting with the user, it includes special * support for handling configuration changes. *
* ** Unless you specify otherwise, a configuration change (such as a change in * screen orientation, language, input devices, etc) will cause your current * activity to be destroyed, going through the normal activity * lifecycle process of {@link #onPause}, {@link #onStop}, and * {@link #onDestroy} as appropriate. If the activity had been in the foreground * or visible to the user, once {@link #onDestroy} is called in that instance * then a new instance of the activity will be created, with whatever * savedInstanceState the previous instance had generated from * {@link #onSaveInstanceState}. *
* ** This is done because any application resource, including layout files, can * change based on any configuration value. Thus the only safe way to handle a * configuration change is to re-retrieve all resources, including layouts, * drawables, and strings. Because activities must already know how to save * their state and re-create themselves from that state, this is a convenient * way to have an activity restart itself with a new configuration. *
* ** In some special cases, you may want to bypass restarting of your activity * based on one or more types of configuration changes. This is done with the * {@link android.R.attr#configChanges android:configChanges} attribute in its * manifest. For any types of configuration changes you say that you handle * there, you will receive a call to your current activity's * {@link #onConfigurationChanged} method instead of being restarted. If a * configuration change involves any that you do not handle, however, the * activity will still be restarted and {@link #onConfigurationChanged} will not * be called. *
* * ** The {@link android.app.Activity#startActivity} method is used to start a new * activity, which will be placed at the top of the activity stack. It takes a * single argument, an {@link android.content.Intent Intent}, which describes * the activity to be executed. *
* ** Sometimes you want to get a result back from an activity when it ends. For * example, you may start an activity that lets the user pick a person in a list * of contacts; when it ends, it returns the person that was selected. To do * this, you call the * {@link android.app.Activity#startActivityForResult(Intent, int)} version with * a second integer parameter identifying the call. The result will come back * through your {@link android.app.Activity#onActivityResult} method. *
* *
* When an activity exits, it can call
* {@link android.app.Activity#setResult(int)} to return data back to its
* parent. It must always supply a result code, which can be the standard
* results RESULT_CANCELED, RESULT_OK, or any custom values starting at
* RESULT_FIRST_USER. In addition, it can optionally return back an Intent
* containing any additional data it wants. All of this information appears back
* on the parent's Activity.onActivityResult(), along with the
* integer identifier it originally supplied.
*
* If a child activity fails for any reason (such as crashing), the parent * activity will receive a result with the code RESULT_CANCELED. *
* *
* public class MyActivity extends Activity {
* ...
*
* static final int PICK_CONTACT_REQUEST = 0;
*
* public boolean onKeyDown(int keyCode, KeyEvent event) {
* if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER) {
* // When the user center presses, let them pick a contact.
* startActivityForResult(
* new Intent(Intent.ACTION_PICK,
* new Uri("content://contacts")),
* PICK_CONTACT_REQUEST);
* return true;
* }
* return false;
* }
*
* protected void onActivityResult(int requestCode, int resultCode,
* Intent data) {
* if (requestCode == PICK_CONTACT_REQUEST) {
* if (resultCode == RESULT_OK) {
* // A contact was picked. Here we will just display it
* // to the user.
* startActivity(new Intent(Intent.ACTION_VIEW, data));
* }
* }
* }
* }
*
*
*
* * There are generally two kinds of persistent state than an activity will deal * with: shared document-like data (typically stored in a SQLite database using * a {@linkplain android.content.ContentProvider content provider}) and internal * state such as user preferences. *
* ** For content provider data, we suggest that activities use a "edit in place" * user model. That is, any edits a user makes are effectively made immediately * without requiring an additional confirmation step. Supporting this model is * generally a simple matter of following two rules: *
* ** When creating a new document, the backing database entry or file for it is * created immediately. For example, if the user chooses to write a new email, a * new entry for that email is created as soon as they start entering data, so * that if they go to any other activity after that point this email will now * appear in the list of drafts. *
*
* When an activity's onPause() method is called, it should commit
* to the backing content provider or file any changes the user has made. This
* ensures that those changes will be seen by any other activity that is about
* to run. You will probably want to commit your data even more aggressively at
* key times during your activity's lifecycle: for example before starting a new
* activity, before finishing your own activity, when the user switches between
* input fields, etc.
*
* This model is designed to prevent data loss when a user is navigating between * activities, and allows the system to safely kill an activity (because system * resources are needed somewhere else) at any time after it has been paused. * Note this implies that the user pressing BACK from your activity does * not mean "cancel" -- it means to leave the activity with its current * contents saved away. Canceling edits in an activity must be provided through * some other mechanism, such as an explicit "revert" or "undo" option. *
* ** See the {@linkplain android.content.ContentProvider content package} for more * information about content providers. These are a key aspect of how different * activities invoke and propagate data between themselves. *
* ** The Activity class also provides an API for managing internal persistent * state associated with an activity. This can be used, for example, to remember * the user's preferred initial display in a calendar (day view or week view) or * the user's default home page in a web browser. *
* ** Activity persistent state is managed with the method {@link #getPreferences}, * allowing you to retrieve and modify a set of name/value pairs associated with * the activity. To use preferences that are shared across multiple application * components (activities, receivers, services, providers), you can use the * underlying {@link Context#getSharedPreferences * Context.getSharedPreferences()} method to retrieve a preferences object * stored under a specific name. (Note that it is not possible to share settings * data across application packages -- for that you will need a content * provider.) *
* ** Here is an excerpt from a calendar activity that stores the user's preferred * view mode in its persistent settings: *
* *
* public class CalendarActivity extends Activity {
* ...
*
* static final int DAY_VIEW_MODE = 0;
* static final int WEEK_VIEW_MODE = 1;
*
* private SharedPreferences mPrefs;
* private int mCurViewMode;
*
* protected void onCreate(Bundle savedInstanceState) {
* super.onCreate(savedInstanceState);
*
* SharedPreferences mPrefs = getSharedPreferences();
* mCurViewMode = mPrefs.getInt("view_mode", DAY_VIEW_MODE);
* }
*
* protected void onPause() {
* super.onPause();
*
* SharedPreferences.Editor ed = mPrefs.edit();
* ed.putInt("view_mode", mCurViewMode);
* ed.commit();
* }
* }
*
*
*
* * The ability to start a particular Activity can be enforced when it is * declared in its manifest's {@link android.R.styleable#AndroidManifestActivity * <activity>} tag. By doing so, other applications will need to declare a * corresponding {@link android.R.styleable#AndroidManifestUsesPermission * <uses-permission>} element in their own manifest to be able to start * that activity. * *
* When starting an Activity you can set * {@link Intent#FLAG_GRANT_READ_URI_PERMISSION * Intent.FLAG_GRANT_READ_URI_PERMISSION} and/or * {@link Intent#FLAG_GRANT_WRITE_URI_PERMISSION * Intent.FLAG_GRANT_WRITE_URI_PERMISSION} on the Intent. This will grant the * Activity access to the specific URIs in the Intent. Access will remain until * the Activity has finished (it will remain across the hosting process being * killed and other temporary destruction). As of * {@link android.os.Build.VERSION_CODES#GINGERBREAD}, if the Activity was * already created and a new Intent is being delivered to * {@link #onNewIntent(Intent)}, any newly granted URI permissions will be added * to the existing ones it holds. * *
* See the Security and * Permissions document for more information on permissions and security in * general. * * *
* The Android system attempts to keep an application process around for as long * as possible, but eventually will need to remove old processes when memory * runs low. As described in Activity * Lifecycle, the decision about which process to remove is intimately tied * to the state of the user's interaction with it. In general, there are four * states a process can be in based on the activities running in it, listed here * in order of importance. The system will kill less important processes (the * last ones) before it resorts to killing more important processes (the first * ones). * *
* The foreground activity (the activity at the top of the screen that * the user is currently interacting with) is considered the most important. Its * process will only be killed as a last resort, if it uses more memory than is * available on the device. Generally at this point the device has reached a * memory paging state, so this is required in order to keep the user interface * responsive. *
* A visible activity (an activity that is visible to the user but not in * the foreground, such as one sitting behind a foreground dialog) is considered * extremely important and will not be killed unless that is required to keep * the foreground activity running. *
* A background activity (an activity that is not visible to the user and * has been paused) is no longer critical, so the system may safely kill its * process to reclaim memory for other foreground or visible processes. If its * process needs to be killed, when the user navigates back to the activity * (making it visible on the screen again), its {@link #onCreate} method will be * called with the savedInstanceState it had previously supplied in * {@link #onSaveInstanceState} so that it can restart itself in the same state * as the user last left it. *
* An empty process is one hosting no activities or other application * components (such as {@link Service} or * {@link android.content.BroadcastReceiver} classes). These are killed very * quickly by the system as memory becomes low. For this reason, any background * operation you do outside of an activity must be executed in the context of an * activity BroadcastReceiver or Service to ensure that the system knows it * needs to keep your process around. *
* Sometimes an Activity may need to do a long-running operation that exists * independently of the activity lifecycle itself. An example may be a camera * application that allows you to upload a picture to a web site. The upload may * take a long time, and the application should allow the user to leave the * application while it is executing. To accomplish this, your Activity should * start a {@link Service} in which the upload takes place. This allows the * system to properly prioritize your process (considering it to be more * important than other non-visible applications) for the duration of the * upload, independent of whether the original activity is paused, stopped, or * finished. */ public class Activity { /** Return the intent that started this activity. */ public Intent getIntent() { return null; } /** * Change the intent returned by {@link #getIntent}. This holds a reference to * the given intent; it does not copy it. Often used in conjunction with * {@link #onNewIntent}. * * @param newIntent The new Intent object to return from getIntent * * @see #getIntent * @see #onNewIntent */ public void setIntent(Intent newIntent) { } /** * Called when the activity is starting. This is where most initialization * should go: calling {@link #setContentView(int)} to inflate the activity's UI, * using {@link #findViewById} to programmatically interact with widgets in the * UI, calling * {@link #managedQuery(android.net.Uri , String[], String, String[], String)} * to retrieve cursors for data being displayed, etc. * *
* You can call {@link #finish} from within this function, in which case * onDestroy() will be immediately called after {@link #onCreate} without any of * the rest of the activity lifecycle ({@link #onStart}, {@link #onResume}, * {@link #onPause}, etc) executing. * *
* Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @param savedInstanceState If the activity is being re-initialized after * previously being shut down then this Bundle * contains the data it most recently supplied in * {@link #onSaveInstanceState}. Note: Otherwise * it is null. * * @see #onStart * @see #onSaveInstanceState * @see #onRestoreInstanceState * @see #onPostCreate */ protected void onCreate(Bundle savedInstanceState) { } /** * This method is called after {@link #onStart} when the activity is being * re-initialized from a previously saved state, given here in * savedInstanceState. Most implementations will simply use * {@link #onCreate} to restore their state, but it is sometimes convenient to * do it here after all of the initialization has been done or to allow * subclasses to decide whether to use your default implementation. The default * implementation of this method performs a restore of any view state that had * previously been frozen by {@link #onSaveInstanceState}. * ** This method is called between {@link #onStart} and {@link #onPostCreate}. * * @param savedInstanceState the data most recently supplied in * {@link #onSaveInstanceState}. * * @see #onCreate * @see #onPostCreate * @see #onResume * @see #onSaveInstanceState */ protected void onRestoreInstanceState(Bundle savedInstanceState) { } /** * Called when activity start-up is complete (after {@link #onStart} and * {@link #onRestoreInstanceState} have been called). Applications will * generally not implement this method; it is intended for system classes to do * final initialization after application code has run. * *
* Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @param savedInstanceState If the activity is being re-initialized after * previously being shut down then this Bundle * contains the data it most recently supplied in * {@link #onSaveInstanceState}. Note: Otherwise * it is null. * @see #onCreate */ protected void onPostCreate(Bundle savedInstanceState) { } /** * Called after {@link #onCreate} — or after {@link #onRestart} when the * activity had been stopped, but is now again being displayed to the user. It * will be followed by {@link #onResume}. * ** Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @see #onCreate * @see #onStop * @see #onResume */ protected void onStart() { } /** * Called after {@link #onRestoreInstanceState}, {@link #onRestart}, or * {@link #onPause}, for your activity to start interacting with the user. This * is a good place to begin animations, open exclusive-access devices (such as * the camera), etc. * ** Keep in mind that onResume is not the best indicator that your activity is * visible to the user; a system window such as the keyguard may be in front. * Use {@link #onWindowFocusChanged} to know for certain that your activity is * visible to the user (for example, to resume a game). * *
* Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @see #onRestoreInstanceState * @see #onRestart * @see #onPostResume * @see #onPause */ protected void onResume() { } /** * Called when activity resume is complete (after {@link #onResume} has been * called). Applications will generally not implement this method; it is * intended for system classes to do final setup after application resume code * has run. * ** Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @see #onResume */ protected void onPostResume() { } /** * This is called for activities that set launchMode to "singleTop" in their * package, or if a client used the {@link Intent#FLAG_ACTIVITY_SINGLE_TOP} flag * when calling {@link #startActivity}. In either case, when the activity is * re-launched while at the top of the activity stack instead of a new instance * of the activity being started, onNewIntent() will be called on the existing * instance with the Intent that was used to re-launch it. * ** An activity will always be paused before receiving a new intent, so you can * count on {@link #onResume} being called after this method. * *
* Note that {@link #getIntent} still returns the original Intent. You can use * {@link #setIntent} to update it to this new Intent. * * @param intent The new intent that was started for the activity. * * @see #getIntent * @see #setIntent * @see #onResume */ protected void onNewIntent(Intent intent) { } /** * Called to retrieve per-instance state from an activity before being killed so * that the state can be restored in {@link #onCreate} or * {@link #onRestoreInstanceState} (the {@link Bundle} populated by this method * will be passed to both). * *
* This method is called before an activity may be killed so that when it comes * back some time in the future it can restore its state. For example, if * activity B is launched in front of activity A, and at some point activity A * is killed to reclaim resources, activity A will have a chance to save the * current state of its user interface via this method so that when the user * returns to activity A, the state of the user interface can be restored via * {@link #onCreate} or {@link #onRestoreInstanceState}. * *
* Do not confuse this method with activity lifecycle callbacks such as * {@link #onPause}, which is always called when an activity is being placed in * the background or on its way to destruction, or {@link #onStop} which is * called before destruction. One example of when {@link #onPause} and * {@link #onStop} is called and not this method is when a user navigates back * from activity B to activity A: there is no need to call * {@link #onSaveInstanceState} on B because that particular instance will never * be restored, so the system avoids calling it. An example when * {@link #onPause} is called and not {@link #onSaveInstanceState} is when * activity B is launched in front of activity A: the system may avoid calling * {@link #onSaveInstanceState} on activity A if it isn't killed during the * lifetime of B since the state of the user interface of A will stay intact. * *
* The default implementation takes care of most of the UI per-instance state * for you by calling {@link android.view.View#onSaveInstanceState()} on each * view in the hierarchy that has an id, and by saving the id of the currently * focused view (all of which is restored by the default implementation of * {@link #onRestoreInstanceState}). If you override this method to save * additional information not captured by each individual view, you will likely * want to call through to the default implementation, otherwise be prepared to * save all of the state of each view yourself. * *
* If called, this method will occur after {@link #onStop} for applications * targeting platforms starting with {@link android.os.Build.VERSION_CODES#P}. * For applications targeting earlier platform versions this method will occur * before {@link #onStop} and there are no guarantees about whether it will * occur before or after {@link #onPause}. * * @param outState Bundle in which to place your saved state. * * @see #onCreate * @see #onRestoreInstanceState * @see #onPause */ protected void onSaveInstanceState(Bundle outState) { } /** * Called as part of the activity lifecycle when an activity is going into the * background, but has not (yet) been killed. The counterpart to * {@link #onResume}. * *
* When activity B is launched in front of activity A, this callback will be * invoked on A. B will not be created until A's {@link #onPause} returns, so be * sure to not do anything lengthy here. * *
* This callback is mostly used for saving any persistent state the activity is * editing, to present a "edit in place" model to the user and making sure * nothing is lost if there are not enough resources to start the new activity * without first killing this one. This is also a good place to do things like * stop animations and other things that consume a noticeable amount of CPU in * order to make the switch to the next activity as fast as possible, or to * close resources that are exclusive access such as the camera. * *
* In situations where the system needs more memory it may kill paused processes * to reclaim resources. Because of this, you should be sure that all of your * state is saved by the time you return from this function. In general * {@link #onSaveInstanceState} is used to save per-instance state in the * activity and this method is used to store global persistent data (in content * providers, files, etc.) * *
* After receiving this call you will usually receive a following call to * {@link #onStop} (after the next activity has been resumed and displayed), * however in some cases there will be a direct call back to {@link #onResume} * without going through the stopped state. * *
* Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @see #onResume * @see #onSaveInstanceState * @see #onStop */ protected void onPause() { } /** * Called when you are no longer visible to the user. You will next receive * either {@link #onRestart}, {@link #onDestroy}, or nothing, depending on later * user activity. * ** Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @see #onRestart * @see #onResume * @see #onSaveInstanceState * @see #onDestroy */ protected void onStop() { } /** * Perform any final cleanup before an activity is destroyed. This can happen * either because the activity is finishing (someone called {@link #finish} on * it, or because the system is temporarily destroying this instance of the * activity to save space. You can distinguish between these two scenarios with * the {@link #isFinishing} method. * ** Note: do not count on this method being called as a place for saving * data! For example, if an activity is editing data in a content provider, * those edits should be committed in either {@link #onPause} or * {@link #onSaveInstanceState}, not here. This method is usually * implemented to free resources like threads that are associated with an * activity, so that a destroyed activity does not leave such things around * while the rest of its application is still running. There are situations * where the system will simply kill the activity's hosting process without * calling this method (or any others) in it, so it should not be used to do * things that are intended to remain around after the process goes away. * *
* Derived classes must call through to the super class's implementation of * this method. If they do not, an exception will be thrown. *
* * @see #onPause * @see #onStop * @see #finish * @see #isFinishing */ protected void onDestroy() { } /** * Finds a view that was identified by the {@code android:id} XML attribute that * was processed in {@link #onCreate}. *
* Note: In most cases -- depending on compiler support -- the
* resulting view is automatically cast to the target class type. If the target
* class type is unconstrained, an explicit cast may be necessary.
*
* @param id the ID to search for
* @return a view with given ID if found, or {@code null} otherwise
* @see View#findViewById(int)
* @see Activity#requireViewById(int)
*/
public
* This method throws {@link android.content.ActivityNotFoundException} if there
* was no Activity found to run the given Intent.
*
* @param intent The intent to start.
* @param options Additional options for how the Activity should be started. See
* {@link android.content.Context#startActivity(Intent, Bundle)}
* Context.startActivity(Intent, Bundle)} for more details.
*
* @throws android.content.ActivityNotFoundException
*
* @see #startActivity(Intent)
* @see #startActivityForResult
*/
public void startActivity(Intent intent, Bundle options) {
}
/**
* Same as {@link #startActivities(Intent[], Bundle)} with no options specified.
*
* @param intents The intents to start.
*
* @throws android.content.ActivityNotFoundException
*
* @see #startActivities(Intent[], Bundle)
* @see #startActivityForResult
*/
public void startActivities(Intent[] intents) {
}
/**
* Launch a new activity. You will not receive any information about when the
* activity exits. This implementation overrides the base version, providing
* information about the activity performing the launch. Because of this
* additional information, the {@link Intent#FLAG_ACTIVITY_NEW_TASK} launch flag
* is not required; if not specified, the new activity will be added to the task
* of the caller.
*
*
* This method throws {@link android.content.ActivityNotFoundException} if there
* was no Activity found to run the given Intent.
*
* @param intents The intents to start.
* @param options Additional options for how the Activity should be started. See
* {@link android.content.Context#startActivity(Intent, Bundle)}
* Context.startActivity(Intent, Bundle)} for more details.
*
* @throws android.content.ActivityNotFoundException
*
* @see #startActivities(Intent[])
* @see #startActivityForResult
*/
public void startActivities(Intent[] intents, Bundle options) {
}
}