[4] 액티비티 라이프사이클 다루기 [3] 액티비티 stop and restart

THIS LESSON TEACHES YOU TO

  1. Stop Your Activity
  2. Start/Restart Your Activity

YOU SHOULD ALSO READ


 

Properly stopping and restarting your activity is an important process in the activity lifecycle that ensures your users perceive that your app is always alive and doesn’t lose their progress. There are a few of key scenarios in which your activity is stopped and restarted:

액티비티를 적절하게 멈추고 다시 시작하는 것은 액티비티의 라이프사이클에서 중요한 과정입니다. 사용자로 하여금 우리의 앱이 언제나 살아있고 프로그레스를 잃어버리지 않는 것처럼 인지하도록 하지요. 액티비티를 stop 하고 restart 하는 데 몇 개의 중요한 시나리오가 있습니다.

  • 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.
  • 사용자가 [Recent Apps] 창을 열고 다른 앱으로 변경합니다. 현재 foregound 에서 진행중이던 우리 앱의 액티비티는 Stop 하게 됩니다. 만약 사용자가 홈스크린 런처 아이콘이나 [Recent Apps] 윈도우에서 다시 우리의 앱을 실행하게 된다면 그 액티비티는 restart 하게 됩니다.
  • 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.
  • 사용자가 앱에서 새 액티비티를 시작하도록 액션을 수행합니다. 두 번째 액티비티가 생성될 때 현재 액티비티는 stop됩니다. 만약 사용자가 [Back]버튼을 눌른다면, 첫 번째 액티비티가 restart 합니다.
  • The user receives a phone call while using your app on his or her phone.
  • 사용자가 우리 앱을 사용하는 중 전화가 걸려옵니다.

The Activity class provides two lifecycle methods, onStop() andonRestart(), 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).

액티비티 클래스는 두 가지 라이프사이클을 제공합니다.  onStop(), onRestart() 인데요, 이 것들은 우리에게 우리의 액티비티 핸들을 stop 하고 restart 하도록 제어할 수 있게 허용합니다. 이 것들은 특정 UI 방해를 확인하는 paused 상태와는 다르게 stopped 상태는 UI가 더 이상 가시적이지 않고 사용자의 포커스는 독립된 액티비티(또는 완전히 독립된 앱)이란 것을 보증합니다.

Note: 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.

주의 : 시스템이 우리의 액티비티 인스턴스를 시스템 메모리에 유지하고 있기 때문에, 우리는 onStop()이나 inRestart()를 구현하지 않아도 괜찮습니다 (심지어 onStart() 메서드도 전혀). 대부분의 비교적 간단한 액티비티에서는, 액티비티가 stop 하고 restart just find 하고 우리는 오로지 onPause() 메서드를 사용할 필요가 있습니다. 진행중인 액션을 멈추고 시스템 리소스로부터 끊도록 말이지요.

Figure 1. When the user leaves your activity, 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). Notice that no matter what scenario causes the activity to stop, the system always calls onPause() before calling onStop().

그림 1. 사용자가 우리의 액티비티를 떠날 때, 시스템은 onStop()을 호출합니다. 그래서 액티비티를 멈추게 합니다(1). 만약 사용자가 되돌아 온다면, 파일시스템은 onRestart() 를 호출합니다(2), 빠르게 onStart()가 따라 시작되고(3), 그리고 onResume() 이 실행됩니다(4). 어떤 시나리오든 주의해야 할 것은 액티비티를 멈추게 한다는 것이고, 시스템은 언제나 onStop()을 실행하기 전에 onPause()를 실행한다는 점입니다.

액티비티 Stop 하기 – Stop Your Activity


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. 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.

액티비티가 onStop() 메서드 호출을 받으면, 더 이상 가시적이지 않고 거의 대부분의 리소스를 놓아주어야 합니다. 그 것들은 유저가 사용하지 않는 동안은 필요하지가 않지요.일단 사용자의 액티비티가 멈추게 되면, 시스템 메모리를 확보해야 하는 상황이 되면, 시스템은 인스턴스들을 끝낼 것입니다.

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.

비록 onPause() 메서드가 onStop() 메서드 이전에 불린다 하더라도, you should use onStop() to perform larger, more CPU intensive shut-down operations, such as writing information to a database.

For example, here’s an implementation of onStop() that saves the contents of a draft note to persistent storage:

예를 들어 onStop()의 구현을 보여드리겠습니다. 이 것은 임시 노트의 컨텐츠를 스토리지에 저장하는 것입니다.

@Override
protected void onStop() {
    super.onStop();  // Always call the superclass method first

    // Save the note's current draft, because the activity is stopping
    // and we want to be sure the current note progress isn't lost.
    ContentValues values = new ContentValues();
    values.put(NotePad.Notes.COLUMN_NAME_NOTE, getCurrentNoteText());
    values.put(NotePad.Notes.COLUMN_NAME_TITLE, getCurrentNoteTitle());

    getContentResolver().update(
            mUri,    // The URI for the note to update.
            values,  // The map of column names and new values to apply to them.
            null,    // No SELECT criteria are used.
            null     // No WHERE columns are used.
            );
}

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.

액티비티가 stopped 됐을 때, 액티비티 오브젝트는 메모리에 잡혀있습니다. 그리고 오브젝트는 액티비티가 resume 될 때 다시 불리게 됩니다. 우리는 컴포넌트들을 re-initialize 할 필요가 없습니다.  that were created during any of the callback methods leading up to the Resumed state. 시스템은또한 계속 레이아웃의 각각의 View 에 대한 현재 상태를 기록하고 있습니다. 그래서 유저가 텍스트를 EditText 위젯에 쳤을 때, 그 내용물은 유지됩니다. 그래서 우리는 궂이 이 것을 저장하고 다시 불러올 필요가 없습니다.

Note: 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 (the next lesson talks more about using a Bundle to save other state data in case your activity is destroyed and recreated).

주의: (사실 번역자는 주의 이 부분이 정말 해석하기 어렵더라구요…) 시스템이 우리의 액티비티를 이 것이 stopped 되었을 동안에 제거했을 지라도, 이 것은 여전히 View 오브젝트의 상태를 Bundle이라는 곳에 유지하고 있습니다(EditText의 텍스트 같은 것들). 그리고 그것들을 사용자가 같은 액티비티 인스턴스로 되돌아 온다면 복구합니다(다음 시간에 좀 더 자세히 Bundle의 사용에 대해 설명합니다. 액티비티가 제거되고 다시 생성될때 번들을 이용해서 기타 상태 데이터를 저장하는 것에 대해서요).

액티비티 Start/Restart – Start/Restart Your Activity


When your activity comes back to the foreground from the stopped state, it receives a call to 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.

액티비티가 stopped 상태에서 다시 foreground 로 돌아 올 때, onRestart() 호출을 받게 됩니다. 시스템은 또한 onStart() 메서드를 호출하게 됩니다. 이 것은 매 번 액티비티가 가시화 될 때 발생합니다 (재시작되었든 처음 생성되었든).  하지만 onRestart()메서드는 오로지 액티비티가 stopped 상태에서 재시작될 때만 호출됩니다. 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.

It’s uncommon that an app needs to use onRestart() to restore the activity’s state, so there aren’t any guidelines for this method that apply to the general population of apps. However, 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.

액티비티의 상태를 복구하기 위해서, 앱이 onRestart()를 사용하는 것은 일반적이지는 않습니다. 그래서 어떠한 가이드라인이 있지는 않습니다. 하지만 onStop()메서드는 액티비티의 리소스를 필수적으로 비워주기 때문에, 우리는 액티비티가 재시작할 때, re-instantiate 할 필요가 있습니다. 아직 우리는 액티비티가 처음 생성될 때 instantiate 할 필요가 있습니다(어떠한 액티비티의 인스턴스도 존재하지 않을 때). 이러한 이유로, 우리는 비일반적으로 onStart() 콜백 메서드를 사용합니다.  onStop()의 반대개념으로요, 왜냐하면 시스템은 onStart()를 액티비티를 생성할때, 액티비티를 stoped 상태에서 재시작할 때 호출하기 때문입니다.

For example, because the user might have been away from your app for a long time before coming back it, theonStart() method is a good place to verify that required system features are enabled:

예를 들어, 사용자가 오랜 시간동안 우리의 앱에서 벗어나 있다가 돌아왔다면, onStart()메서드가 좋습니다.

@Override
protected void onStart() {
    super.onStart();  // Always call the superclass method first
    
    // The activity is either being restarted or started for the first time
    // so this is where we should make sure that GPS is enabled
    LocationManager locationManager = 
            (LocationManager) getSystemService(Context.LOCATION_SERVICE);
    boolean gpsEnabled = locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER);
    
    if (!gpsEnabled) {
        // Create a dialog here that requests the user to enable GPS, and use an intent
        // with the android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS action
        // to take the user to the Settings screen to enable GPS when they click "OK"
    }
}

@Override
protected void onRestart() {
    super.onRestart();  // Always call the superclass method first
    
    // Activity being restarted from stopped state    
}

When the system destroys your activity, it calls the onDestroy() method for your Activity. Because you should generally have released most of your resources with onStop(), by the time you receive a call to onDestroy(), there’s not much that most apps need to do. This method is your last chance to clean out resources that could lead to a memory leak, so you should be sure that additional threads are destroyed and other long-running actions like method tracing are also stopped.

시스템이 우리의 액티비티를 없앨 때, 우리 액티비티의 onDestroy() 메서드를 사용합니다. 우리는 일반적으로 대부분의 리소스를 onStop()으로 놓아주기 때문에, there’s not much that most apps need to do. 이 메서드는, 메모리 릭을 가져올 수 있는 리소스들을 지우는 마지막 기회입니다. 그래서 추가적인 스레드를 없애고, tracing같은 롱런 액션을 멈추게 하는 것을 명심하세요.  

 


답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중