Acitivity (3)

\AndroidStudioProjects\FirstApplication\app\src\main\java\com\example\lee\firstapplication\MainActivity.java

package com.example.lee.firstapplication;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

위의 onCreate() 메소드가 setContentView() 메소드를 호출하면, 이
setContentView() 메소드는 매개변수 R.layout.activity_main을 갖고 스크린을 구성합니다. 

/res/layout/activity_main.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    tools:context="com.example.lee.firstapplication.MainActivity">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Hello Clara and Angela!"
        android:textSize="24sp"/>
</RelativeLayout>
res/layout 디렉터리에 작성된 위의 activity_main.xml은 스크린에 보이는 레이아웃을 정의합니다.
RelativeLayout은 Layout 내부에서 view들이 parent view와의 관계에서 상대적으로 위치가 정해지는 레이아웃입니다.
TextView는 문자열을 보여주는 역할을 하며, 문자열은 android:text에 지정하면 됩니다.

public class Activity extends ContextThemeWrapper  implements LayoutInflater.Factory2, Window.Callback, KeyEvent.Callback,View.OnCreateContextMenuListener, ComponentCallbacks2
java.lang.Object
   ↳
android.content.Context
 
   ↳
android.content.ContextWrapper
 
 
   ↳
android.view.ContextThemeWrapper
 
 
 
   ↳
android.app.Activity
Known Direct Subclasses
AccountAuthenticatorActivity, ActivityGroup, AliasActivity, ExpandableListActivity, FragmentActivity, ListActivity, NativeActivity
Known Indirect Subclasses
ActionBarActivity, AppCompatActivity, LauncherActivity, PreferenceActivity, TabActivity

activity는 사용자가 할 수 있는 집중된 한 가지입니다.
An activity is a single, focused thing that the user can do. 
대부분의 모든 activitiy들은 사용자와 상호작용 하기 때문에, Activity 클래스는, 개발자가 setContentView(View)로 UI를 위치시키는, 창을 만드는 것을 다룹니다.
Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with setContentView(View). 
activity들은 full-screen 창으로 사용자에게 자주 제시되지만, 다른 방식으로도 사용될 수 있습니다: 
floating 창들(windowIsFloating set를 가진 theme를 경유한) 
또는 
embed된 다른 activity의 내부(ActivityGroup을 사용한). 
Activity의 대부분의 서브클래스들이 구현할 메소드는 2가지 입니다:
While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with windowIsFloating set) or embedded inside of another activity (usingActivityGroup). There are two methods almost all subclasses of Activity will implement:
onCreate(Bundle)는 activity를 초기화하는 곳입니다.
onCreate(Bundle) is where you initialize your activity.
가장 중요하게, 여기서 UI를 정의하는, 그리고 프로그램적으로 상호작용할 필요가 있는 UI안에서 위젯을 검색하기 위하여,  findViewById(int)를 사용하는, 레이아웃 리소스를 가진 setContentView(int)를 통상적으로 호출합니다. 
Most importantly, here you will usually call setContentView(int) with a layout resource defining your UI, and using findViewById(int) to retrieve the widgets in that UI that you need to interact with programmatically.
onPause()는  activity를 떠나는 사용자를 처리합니다.
가장 중요한 것은, 사용자가 변경시킨 모든 것이 여기서 수행되어야 한다는 점입니다(보통은 데이터를 보유한 ContentProvider에 대하여).
onPause() is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed (usually to the ContentProvider holding the data).
Context.startActivity()가 쓸모 있으려면 모든 activity 클래스들은 package의 AndroidManifest.xml안에 해당 <activity> 선언을 해야 합니다. 
To be of use with Context.startActivity(), all activity classes must have a corresponding <activity> declaration in their package'sAndroidManifest.xml.
Topics covered here:
Fragments
Activity Lifecycle
Configuration Changes
Starting Activities and Getting Results
Saving Persistent State
Permissions
Process Lifecycle
개발자 가이드   Developer Guides
Activity 클래스는 애플리케이션의 전반적 라이프사이클의 중요한 부분이며, activity들이 실행되고 합쳐지는 방식은 플랫폼의 애플리케이션 모델의 근본적인 부분입니다.
Android 애플리케이션의 구조에 관한 상세한 전망 및 activities의 동작방법에 관하여는, Application Fundamentals과 Tasks and Back Stack 개발자 가이드를 읽으세요.
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.
Activities 개발자 가이드에 activities를 만드는 방법에 관한 상세한 내용이 있습니다.
You can also find a detailed discussion about how to create activities in the Activities developer guide.
Fragments
HONEYCOMB으로 시작하는 Activity 구현은 code를 보다 잘 모듈라이즈 하기 위하여, 대형 스크린에 보다 정교한 UI를 만들기 위하여, 소형 스크린 및 대형 스크린간에 애플리케이션을 확대하는 것을 돕기 위하여, Fragment class를 사용할 수 있습니다.
Starting with HONEYCOMB, Activity implementations can make use of the 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.
Activity Lifecycle
시스템 안의 Activity들은 activity stack으로 관리됩니다.
새로운 activity가 시작되면, activity는 stack의 맨 위에 위치되어 실행 중인 activity가 됩니다 -- 앞선 activity는 stack에서 항상 새 activity의 아래에 남아 있으며, 새 activity가 존재하는 한 다시 앞 쪽으로 가지 않을 것입니다.
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.
activity는 본질적으로 4개의 state를 갖고 있습니다:
An activity has essentially four states:
activity가 screen의 앞 (stack의 맨 위)에 있다면, 그 activity는 active 또는 running입니다.
If an activity is in the foreground of the screen (at the top of the stack), it is active or running.
activity가 focus를 잃었지만 여전히 보인다면 (즉, 새로운 full-sized가 아닌 또는 transparent activity가 activity의 맨 위에 focus를 갖고 있다면), 그 activity는 pause됩니다.
paused activity는 완전히 살아있지만 (이 activity가 all state 및 member 정보를 유지하고 window manager에 부착되어 있지만), extreme low memory situations 안에서 시스템에 의하여 사라질 수 있습니다.
If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
다른 activity가 어떤 activity를 완전히 obscure 한다면, 그 activity는 중단됩니다.
그 activity는 여전히 It still retains all state and member information를 보유하고 있지만, 사용자에게는 더 이상 보이지 않고 따라서 그 윈도우는 감춰지고, 다른 곳에서 메모리가 필요한 경우 자주 kill 됩니다.
If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
activity가 일시 정지되거나 중단되는 경우, 시스템은 activity를 종료시키도록 요청하거나 단순히 프로세스를 죽여서, 메모리로부터 activity를 떨어 뜨립니다.
activity가 사용자에게 다시 디스플레이되면, 완전히 재시작되어 이전 상태로 복원되어야 합니다.
If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.

다음 diagram은 Activity의 중요한 state paths를 보여주고 있습니다.
직사각형은 Activity가 states 사이에서 이동할 때 operation을 수행하기 위하여 구현할 수 있는 call back 메소드를 표현합니다. 
색이 있는 ovals은 Activity가 존재할 수 있는 주요 state들 입니다.
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:
activity의 entire lifetime은 onCreate(Bundle)에 대한 firat call과 onDestroy()에 대한 단일 final call까지에 걸쳐, 그 사이에서 발생됩니다.
activity는 onCreate()에서 "global" state의 모든 셋업을 하고, onDestroy()에서 남아있는 모든 resources를 release 합니다.
예를 들면, 이것이 네트웍으로부터 데이터를 다운로드 하기 위하여 백그라운드에서 실행 중인 thread를 갖고 있다면, 이것은 onCreate()에서 해당 thread를 만들고 onDestroy()에서 그 thread를 중단시킬 수 있습니다.
The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy(). An activity will do all setup of "global" state in onCreate(), and release all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().
activity의 visible lifetime은 onStop()에 대한 상응하는 call 까지 onStart()에 대한 call 사이에서 발생됩니다. 
activity on-screen이 foreground에 있지 않더라도 그리고 사용자와 상호작용하지 않더라도, 이 기간 동안 사용자는 activity on-screen을 볼 수 있습니다.
이들 두 모듈 사이에서 사용자에게 activity를 보여주는 데 필요한 리소스를 유지시킬 수 있습니다.
예를 들어, UI에 영향을 주는 변경을 모니터하기 위하여 onStart() 안에 BroadcastReceiver를 등록할 수 있으며, displaying되고 있는 것을 사용자가 더 이상 보지 않을 때는 onStop() 안에서 그것을 unregister 합니다.
activity가 사용자에게 보이고 감춰지면서 onStart()와 onStop() methods는 여러 번 호출될 수 있습니다.
The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user no longer sees what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity becomes visible and hidden to the user.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight.
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 onCreate(Bundle) to do their initial setup; many will also implement 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
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 onStart().
No
onStart()
    
onRestart()
Called after your activity has been stopped, prior to it being started again.
Always followed by onStart()
No
onStart()
onStart()
Called when the activity is becoming visible to the user.
Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.
No
onResume()or onStop()
    
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 onPause().
No
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 onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user.
Pre-HONEYCOMB
onResume()or
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 onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away.
Yes
onRestart()or
onDestroy()
onDestroy()
The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called 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 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 onPause() method to write any persistent data (such as user edits) to storage. In addition, the method 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 inonCreate(Bundle) 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 onPause() instead of onSaveInstanceState(Bundle) 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 HONEYCOMB vs. those targeting prior platforms. Starting with Honeycomb, an application is not in the killable state until its onStop() has returned. This impacts whenonSaveInstanceState(Bundle) may be called (it may be safely called after onPause() and allows and application to safely wait until onStop() to save persistent state.
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().
Configuration Changes
If the configuration of the device (as defined by the 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 onPause(), onStop(), and onDestroy() as appropriate. If the activity had been in the foreground or visible to the user, once 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 onSaveInstanceState(Bundle).
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 theandroid: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 onConfigurationChanged(Configuration) method instead of being restarted. If a configuration change involves any that you do not handle, however, the activity will still be restarted and onConfigurationChanged(Configuration) will not be called.
Starting Activities and Getting Results
The startActivity(Intent) method is used to start a new activity, which will be placed at the top of the activity stack. It takes a single argument, anIntent, 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 startActivityForResult(Intent, int) version with a second integer parameter identifying the call. The result will come back through your onActivityResult(int, int, Intent) method.
When an activity exits, it can call 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));
             }
         }
     }
 }
 
Saving Persistent State
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 acontent 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 e-mail, a new entry for that e-mail is created as soon as they start entering data, so that if they go to any other activity after that point this e-mail 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 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 getPreferences(int), 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 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();
     }
 }
 
Permissions
The ability to start a particular Activity can be enforced when it is declared in its manifest's <activity> tag. By doing so, other applications will need to declare a corresponding <uses-permission> element in their own manifest to be able to start that activity.
When starting an Activity you can set Intent.FLAG_GRANT_READ_URI_PERMISSION and/or 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 GINGERBREAD, if the Activity was already created and a new Intent is being delivered toonNewIntent(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.
Process Lifecycle
The Android system attempts to keep 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 onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied inonSaveInstanceState(Bundle) 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 Service or 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 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.
Summary
Constants
int
DEFAULT_KEYS_DIALER
Use with setDefaultKeyMode(int) to launch the dialer during default key handling.
int
DEFAULT_KEYS_DISABLE
Use with setDefaultKeyMode(int) to turn off default handling of keys.
int
DEFAULT_KEYS_SEARCH_GLOBAL
Use with setDefaultKeyMode(int) to specify that unhandled keystrokes will start a global search (typically web search, but some platforms may define alternate methods for global search)
See android.app.SearchManager for more details.
int
DEFAULT_KEYS_SEARCH_LOCAL
Use with setDefaultKeyMode(int) to specify that unhandled keystrokes will start an application-defined search.
int
DEFAULT_KEYS_SHORTCUT
Use with setDefaultKeyMode(int) to execute a menu shortcut in default key handling.
int
RESULT_CANCELED
Standard activity result: operation canceled.
int
RESULT_FIRST_USER
Start of user-defined activity results.
int
RESULT_OK
Standard activity result: operation succeeded.
Inherited constants
From class android.content.Context
From interface android.content.ComponentCallbacks2
Fields
protected static final int[]
FOCUSED_STATE_SET
Public constructors
Activity()
Public methods
void
addContentView(View view, ViewGroup.LayoutParams params)
Add an additional content view to the activity.
void
closeContextMenu()
Programmatically closes the most recently opened context menu, if showing.
void
closeOptionsMenu()
Progammatically closes the options menu.
PendingIntent
createPendingResult(int requestCode, Intent data, int flags)
Create a new PendingIntent object which you can hand to others for them to use to send result data back to youronActivityResult(int, int, Intent) callback.
final void
dismissDialog(int id)
This method was deprecated in API level 13. Use the new DialogFragment class with FragmentManager instead; this is also available on older platforms through the Android compatibility package.
boolean
dispatchGenericMotionEvent(MotionEvent ev)
Called to process generic motion events.