Introduction to Activities

The Activity class is a crucial component of an Android app, and the way activities are launched and put together is a fundamental part of the platform's application model. Unlike 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.

Activity 클래스는 Android app의 결정적인 요소입니다, 그리고 Activity가 시작되고 결합되는 방식은 플랫폼 애플리케이션 모델의 기본 부분입니다. app이 main()으로 시작되는 프로그래밍 패러다임과는 달리 Android 시스템은 특정한 생명주기 단계에 따라 특정 콜백 메서드를 호출하여 Activity 인스턴스에서 코드를 시작합니다.

This document introduces the concept of activities, and then provides some lightweight guidance about how to work with them. For additional information about best practices in architecting your app, see Guide to App Architecture.

이 문서는 Activity의 개념을 소개합니다, 그리고 작업 방법에 대해서 간단한 지침을 제공합니다. app architecting best practices에 대한 추가 정보는 Guide to App Architecture를 참조하세요.

The concept of activities

The mobile-app experience differs from its desktop counterpart in that a user's interaction with the app doesn't always begin in the same place. Instead, the user journey often begins non-deterministically. For instance, if you open an email app from your home screen, you might see a list of emails. By contrast, if you are using a social media app that then launches your email app, you might go directly to the email app's screen for composing an email.

모바일 app 환경은 사용자와 앱의 상호 작용이 데스크톱 환경과는 다르게 항상 같은 위치에서 시작되는 것이 아닙니다. 대신 user journey는 종종 non-deterministically적으로 시작합니다. 예를들어, 이메일 app을 홈 화면에 실행시키면 이메일 목록이 보일 것 입니다. 반면에 이메일 app을 실행하는 소셜 미디어 앱을 사용하면, 이메일 작성을 위해 이메일 app 화면으로 직접 이동할 수 있습니다.

The Activity class is designed to facilitate this paradigm. When one app invokes another, the calling app invokes an activity in the other app, rather than the app as an atomic whole. In this way, the activity serves as the entry point for an app's interaction with the user. You implement an activity as a subclass of the Activity class.

Activity 클래스는 이러한 패러다임을 용이하게 하도록 설계되었습니다. 하나의 app이 다른 app을 호출하면, 호출된 app은 app 전체가 아닌 다른 app의 activity를 호출합니다. 이러한 방식으로 activity는 app과 사용자의 상호작용을 위한 entry point 역할을 합니다. Activity 클래스의 하위 클래스로 activity를 구현 합니다.

An activity provides the window in which the app draws its UI. This window typically fills the screen, but may be smaller than the screen and float on top of other windows. Generally, one activity implements one screen in an app. For instance, one of an app’s activities may implement a Preferences screen, while another activity implements a Select Photo screen.

Activity는 app이 UI를 그릴수 있는 window를 제공합니다. window은 일반적으로 화면을 가득 채웁니다. 하지만 화면보다 더 작거나 다른 window 위에 떠있을 수 있습니다. 일반적으로, 하나의 activity는 app에서 하나의 화면을 구현합니다. 예를 들어, app의 activity 중 하나는 환경 설정 화면을 구현 하고 다른 activity는 사진 선택 화면을 구현합니다.

Most apps contain multiple screens, which means they comprise multiple activities. Typically, one activity in an app is specified as the main activity, which is the first screen to appear when the user launches the app. Each activity can then start another activity in order to perform different actions. For example, the main activity in a simple e-mail app may provide the screen that shows an e-mail inbox. From there, the main activity might launch other activities that provide screens for tasks like writing e-mails and opening individual e-mails.

대부분의 app에는 다수의 화면이 포함되므로 다수의 activity로 구성됩니다. 일반적으로, app안의 하나의 activity에 main activity로 지정됩니다. main activity는 app을 사용자가 실행시켰을 때 처음으로 보이는 화면입니다. 각각의 activity는 다른 행동을 수행하기 위해 다른 activity를 시작할 수 있습니다. 예를 들어, 간단한 e-mail app의 main activity는 e-mail 받는 편지함을 표시하는 화면을 제공 할 수 있습니다.  거기에서, main activity는 e-mail 작성과 개별적으로 mail을 여는 작업등을 위한 화면을 제공 하는 다른 activity를 시작 할 수 있습니다.

Although activities work together to form a cohesive user experience in an app, each activity is only loosely bound to the other activities; there are usually minimal dependencies among the activities in an app. In fact, activities often start up activities belonging to other apps. For example, a browser app might launch the Share activity of a social-media app.

activity가 함께 작동하여 앱에서 일관된 사용자 경험을 형성하지만, 각 activity는 다른 activity와 느슨하게 결합됩니다. 일반적으로 app의 activity 간에는 최소한의 종속성이 있습니다. activity는 종종 다른 app에 속한 activity를 시작시킵니다. 예를 들어, 브라우저 app은 소셜 미디어 app의 공유 activity를 실행시킬 수 있습니다.

To use activities in your app, you must register information about them in the app’s manifest, and you must manage activity lifecycles appropriately. The rest of this document introduces these subjects.

app에서 activity를 사용하기 위해 app의 manifest에 activity에 대한 정보를 등록하고 activity 생명주기를 적절하게 관리해야합니다. 이 문서의 나머지 부분에서는 이러한 주제를 소개합니다.

Configuring the manifest

For your app to be able to use activities, you must declare the activities, and certain of their attributes, in the manifest.

app에서 activity 사용하기 위해 manifest에 activity 와 속성을 선언해야합니다.

Declare activities

To declare your activity, open your manifest file and add an <activity> element as a child of the <application> element. For example:

activity를 선언하려면 manifest를 열어 <activity> 요소를 <application> 하위에 추가해야 합니다.

<manifest ... >
  <application ... >
      <activity android:name=".ExampleActivity" />
      ...
  </application ... >
  ...
</manifest >

The only required attribute for this element is android:name, which specifies the class name of the activity. You can also add attributes that define activity characteristics such as label, icon, or UI theme. For more information about these and other attributes, see the <activity> element reference documentation.

필수적인 요소는 activity 클래스의 이름을 지정하는 android:name입니다. label, icon 또는 UI 테마와 같은 activity 특성을 정의하는 속성을 추가 할 수도 있습니다. 이러한 속성 및 기타 속성에 대한 자세한 내용은 <activity> 요소 참조 문서를 참조하세요.

Note: After you publish your app, you should not change activity names. If you do, you might break some functionality, such as app shortcuts. For more information on changes to avoid after publishing, see Things That Cannot Change.

app을 게시 한 후에는 activity 이름을 변경해서는 안됩니다. 그렇게하면 app 바로 가기와 같은 일부 기능이 중단 될 수 있습니다. 게시 후 피해야 할 변경 사항에 대한 자세한 내용은 변경할 수없는 사항을 참조하십시오.

Declare intent filters

Intent filters are a very powerful feature of the Android platform. They provide the ability to launch an activity based not only on an explicit request, but also an implicit one. For example, an explicit request might tell the system to “Start the Send Email activity in the Gmail app". By contrast, an implicit request tells the system to “Start a Send Email screen in any activity that can do the job." When the system UI asks a user which app to use in performing a task, that’s an intent filter at work.

Intent filters는 안드로이드 플랫폼의 매우 강력한 기능입니다. 명시적 요청 뿐아니라 암시적 요청으로 activity를 시작하는 기능을 제공합니다. 예를 들어, 명시적 요청은 시스템에 "Gmail app에서 Email 보내기 activity 실행"을 요청할 수 있습니다. 반면에, 암시적 요청은 시스템에 "작업을 수행 할 수 있는 모든 activity에서 Email 보내기 화면을 실행"을 요청 할 수 있습니다.

You can take advantage of this feature by declaring an <intent-filter> attribute in the <activity> element. The definition of this element includes an <action> element and, optionally, a <category> element and/or a <data> element. These elements combine to specify the type of intent to which your activity can respond. For example, the following code snippet shows how to configure an activity that sends text data, and receives requests from other activities to do so:

<activity> 요소에서 <intent-filter> 속성을 선언하여 기능을 활용할 수 있습니다. 해당 요소의 정의에는 <action> 요소와 필요시 <category> 요소 / <data> 요소가 포함됩니다. 이러한 요소는 결합하여 activity에 응답 할 수있는 intent 유형을 지정합니다. 예를 들어, 다음 코드 snippet은 텍스트 데이터를 전송하고 다른 activity에서 요청을 수신하는 activity를 구성하는 방법입니다.

<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
        <data android:mimeType="text/plain" />
    </intent-filter>
</activity>

In this example, the <action> element specifies that this activity sends data. Declaring the <category> element as DEFAULT enables the activity to receive launch requests. The <data> element specifies the type of data that this activity can send. The following code snippet shows how to call the activity described above:

이 예시는, <action>요소는 activity가 데이터를 전송하도록 지정합니다. <category>요소를 DEFAULT로 선언하면 activity가 시작 요청을 수신 할 수 있습니다. <data>요소는 activity가 보낼 수 있는 데이터 유형을 지정합니다.

val sendIntent = Intent().apply {
    action = Intent.ACTION_SEND
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, textMessage)
}
startActivity(sendIntent)​

If you intend for your app to be self-contained and not allow other apps to activate its activities, you don't need any other intent filters. Activities that you don't want to make available to other applications should have no intent filters, and you can start them yourself using explicit intents. For more information about how your activities can respond to intents, see Intents and Intent Filters.

app이 독립적이고 다른 app이 activity를 활성화하지 못하도록하려면 다른 intent filters가 필요하지 않습니다. 다른 app에서 사용하지 않으려는 activity는 intent filter가 없어야 하고 명시적 intent를 사용하여 직접 실행 할 수 있습니다. activity가 intent에 응답하는 방법에 대한 자세한 내용은 Intents and Intent Filters를 참조하세요.

Declare permissions

You can use the manifest's <activity> tag to control which apps can start a particular activity. A parent activity cannot launch a child activity unless both activities have the same permissions in their manifest. If you declare a <uses-permission> element for a parent activity, each child activity must have a matching <uses-permission> element.

app의 특정한 activity를 시작 시키는것을 컨트롤 하기위해 manifest의 <activity> 태그를 사용할 수 있다. 부모 activity는 자식 activity를 둘 다 manifest에서 동일한 권한을 가지지 않으면 시작 할 수 없습니다. 부모 activity에 <uses-permission>을 선언하면 자식 activity들에도 선언해줘야합니다.

For example, if your app wants to use a hypothetical app named SocialApp to share a post on social media, SocialApp itself must define the permission that an app calling it must have:

예를 들어, app에서 SocialApp이라는 가상의 app을 사용하여 소셜 미디어에 게시물을 공유하려는 경우 SocialApp 자체는이를 호출하는 app이 가져야하는 권한을 정의해야합니다.

<manifest>
<activity android:name="...."
   android:permission=”com.google.socialapp.permission.SHARE_POST”

/>

그런 다음 SocialApp을 호출 할 수 있으려면 app이 SocialApp의 manifest에 설정된 권한과 일치해야합니다.

<manifest>
   <uses-permission android:name="com.google.socialapp.permission.SHARE_POST" />
</manifest>

For more information on permissions and security in general, see Security and Permissions.

일반적인 권한 및 보안에 대한 자세한 내용은 Security and Permissions을 참조하십시오.

Managing the activity lifecycle

Over the course of its lifetime, an activity goes through a number of states. You use a series of callbacks to handle transitions between states. The following sections introduce these callbacks.

lifetiem 동안 activity는 여러 상태를 거칩니다. 일련의 콜백을 사용하여 상태 간의 전환을 처리합니다. 다음 섹션에서는 이러한 콜백을 소개합니다.

onCreate()

You must implement this callback, which fires when the system creates your activity. Your implementation should initialize the essential components of your activity: For example, your app should create views and bind data to lists here. Most importantly, this is where you must call setContentView() to define the layout for the activity's user interface.

When onCreate() finishes, the next callback is always onStart().

시스템이 activity를 생성할 때 이 콜백을 구현해야합니다. activity의 필수 구성 요소를 초기화해야합니다. 예를 들어, app은 뷰를 생성하고 list에 data를 bind해야합니다. 가장 중요한건, activity의 사용자 인터페이스에 대한 레이아웃을 정의하려면 setContentView()를 호출해야합니다. onCreate()가 끝나면 항상 onStart()가 다음 콜백입니다.

onStart()

As onCreate() exits, the activity enters the Started state, and the activity becomes visible to the user. This callback contains what amounts to the activity’s final preparations for coming to the foreground and becoming interactive.

onCreate()가 종료되면 activity는 시작 상태에 들어오고 사용자에게 activity가 보여지게 됩니다. 이 콜백에는 froeground로 이동하고 상호 작용 하기위한 activity의 최종 준비의 해당됩니다.

onResume()

The system invokes this callback just before the activity starts interacting with the user. At this point, the activity is at the top of the activity stack, and captures all user input. Most of an app’s core functionality is implemented in the onResume() method.

The onPause() callback always follows onResume().

시스템은 activity가 사용자와 상호 작용을 시작하기 직전에 이 콜백을 호출합니다. 여기에서 activity는 activity stack의 맨 위에 있으며 모든 사용자의 입력을 captures합니다. 대부분의 app 핵심 기능은 onResume()에서 구현됩니다. onPause() 콜백은 항상 onResume() 뒤에 옵니다.

onPause()

The system calls onPause() when the activity loses focus and enters a Paused state. This state occurs when, for example, the user taps the Back or Recents button. When the system calls onPause() for your activity, it technically means your activity is still partially visible, but most often is an indication that the user is leaving the activity, and the activity will soon enter the Stopped or Resumed state.

시스템은 activity가 focus를 잃거나 paused 상태에 들어왔을때 onPause()를 호출합니다. 이 상태는 예를 들어 사용자가 back 또는 recents 버튼을 누를 때 발생합니다. 시스템이 activity에 대해 onPause()를 호출하면 기술적으로 activity가 여전히 부분적으로 표시된다는 것을 의미하지만 대부분 사용자가 activity를 떠나고 곧 중지되거나 재개 상태가 될 것입니다.

An activity in the Paused state may continue to update the UI if the user is expecting the UI to update. Examples of such an activity include one showing a navigation map screen or a media player playing. Even if such activities lose focus, the user expects their UI to continue updating.

Paused 상태의 activity는 사용자가 UI 업데이트를 예상하는 경우 UI를 계속 업데이트 할 수 있습니다. 예를 들어, 내비게이션지도 화면이나 재생중인 미디어 플레이어가 있습니다. activity가 focus를 잃어도 사용자는 UI가 계속 업데이트 되길 기대합니다.

You should not use onPause() to save application or user data, make network calls, or execute database transactions. For information about saving data, see Saving and restoring activity state.

onPause()를 사용하여 application 또는 user data 저장, database transaction을 실행해서는 안됩니다. 데이터 저장에 대한 정보는 Saving and restoring activity state를 참고하세요.

Once onPause() finishes executing, the next callback is either onStop() or onResume(), depending on what happens after the activity enters the Paused state.

onPause()가 실행이 끝나면, activity는 Paused 상태로 들아간 후 발생하는 상황에 따라서 onStop(), onResume()으로 갑니다.

onStop()

The system calls onStop() when the activity is no longer visible to the user. This may happen because the activity is being destroyed, a new activity is starting, or an existing activity is entering a Resumed state and is covering the stopped activity. In all of these cases, the stopped activity is no longer visible at all.

시스템은 activity가 더이상 사용자에게 보이지않을 때 onStop()을 호출합니다. 이는 activity가 소멸 중이거나, 새로운 activity가 시작중이거나, 기존 activity가 Resumed 상태가 돼서 중지된 activity를 다루고 있기 때문에 발생할 수 있습니다. 이 모든 경우에, 중지된 activity는 더이상 보이지 않습니다.

The next callback that the system calls is either onRestart(), if the activity is coming back to interact with the user, or by onDestroy() if this activity is completely terminating.

시스템이 호출하는 다음 콜백은 activity가 사용자와 상호 작용하기 위해서 돌아오면 onRestart(), activity가 완전히 종료 된 경우는 onDestroy()를 호출합니다.

onRestart()

The system invokes this callback when an activity in the Stopped state is about to restart. onRestart() restores the state of the activity from the time that it was stopped.

This callback is always followed by onStart().

시스템은 중지된 상태의 activity가 다시 시작될 때 이 콜백을 호출합니다. onRestart()는 중지된 상태의 시점부터 activity를 복원 시킵니다. 이 콜백 뒤에는 항상 onStart()가 옵니다.

onDestroy()

The system invokes this callback before an activity is destroyed.

This callback is the final one that the activity receives. onDestroy() is usually implemented to ensure that all of an activity’s resources are released when the activity, or the process containing it, is destroyed.

This section provides only an introduction to this topic. For a more detailed treatment of the activity lifecycle and its callbacks, see The Activity Lifecycle.

시스템은 activity가 파괴되기전에 이 콜백을 호출합니다. 이 콜백은 activity가 수신하는 마지막 콜백입니다. onDestroy()는 보통 activity 또는 이를 포함하는 프로세스가 파괴 될 때 activity의 모든 리소스가 해제되도록 구현합니다. 이 섹션에서는 소개하는 정도만 제공합니다. activity의 생명 주기 및 콜백에 대한 자세한 처리는 The Activity Lifecycle을 참고하세요.