블로그 이미지
ssun++

카테고리

[전체] (73)
Android (7)
JavaScript (9)
CI (5)
Language (14)
ETC (38)
Total314,893
Today21
Yesterday23

'2014/06'에 해당되는 글 2건

  1. 2014.06.17 Tasks and Back Stack (1)
  2. 2014.06.10 Android Sender App Development (1)

Tasks and Back Stack (1)

Android / 2014.06.17 00:12

원문 : http://developer.android.com/guide/components/tasks-and-back-stack.html


An application usually contains multiple activities. Each activity should be designed around a specific kind of action the user can perform and can start other activities. For example, an email application might have one activity to show a list of new email. When the user selects an email, a new activity opens to view that email.


일반적으로 앱은 여러개의 액티비티로 구성되어 있다. 각 액티비티는 사용자의 특정한 액션을 고려하여 다른 액티비티를 시작 할 수 있도록 설계되어야 한다. 예를 들어, 이메일 앱은 새로운 메일 리스트를 보여주는 액티비티를 가질 것이다. 사용자가 이메일을 선택했을 때, 새로운 액티비티가 메일을 보여주기 위해서 열릴 것이다.


An activity can even start activities that exist in other applications on the device. For example, if your application wants to send an email, you can define an intent to perform a "send" action and include some data, such as an email address and a message. An activity from another application that declares itself to handle this kind of intent then opens. In this case, the intent is to send an email, so an email application's "compose" activity starts (if multiple activities support the same intent, then the system lets the user select which one to use). When the email is sent, your activity resumes and it seems as if the email activity was part of your application. Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.


액티비티는 장치에 있는 다른 앱의 액티비티도 시작할 수 있다. 예를 들어, 앱이 이메일을 보내고 싶을 때, "send"를 수행 할 인텐트를 정의하여 주소나 메시지 등의 데이터를 포함시킨다. 이런 종류의 인텐트를 처리하도록 정의한 다른 앱의 액티비티가 열릴 것이다. 이 경우, 인텐트는 이메일을 보내는 것이고, 이메일 앱의 "compose" 액티비티가 시작한다. (복수의 액티비티가 동일한 인텐트를 지원 할 경우, 시스템은 사용자가 사용할 것을 선택하도록 한다.) 이메일이 보내지면, 액티비티는 재개되며 이메일 액티비티가 앱의 일부인 것처럼 보인다. 다른 앱의 액티비티라도, 안드로이드는 액티비티를 동일한 task로 유지하여 seamless한 사용자 경험을 유지한다.


A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the "back stack"), in the order in which each activity is opened.


task는 어떠한 job을 수행할 때 사용자와 상호 작용하는 액티비티의 콜렉션이다. 액티비티는 액티비티가 열린 순서대로 스택("back stack")에 배치 된다.


The device Home screen is the starting place for most tasks. When the user touches an icon in the application launcher (or a shortcut on the Home screen), that application's task comes to the foreground. If no task exists for the application (the application has not been used recently), then a new task is created and the "main" activity for that application opens as the root activity in the stack.


장치의 홈스크린이 대부분의 태스크의 시작점이다, 사용자가 앱 런처의 아이콘(또는 홈스크린의 숏컷)을 터치 할 때 앱의 task는 foreground로 오게 된다. 앱을 위한 task가 존재하지 않으면 (앱이 최근에 사용되지 않았다), 새로운 task가 생성되며 앱의 "main" 액티비티가 스택의 root 액티비티로 열린다.


When the current activity starts another, the new activity is pushed on the top of the stack and takes focus. The previous activity remains in the stack, but is stopped. When an activity stops, the system retains the current state of its user interface. When the user presses the Back button, the current activity is popped from the top of the stack (the activity is destroyed) and the previous activity resumes (the previous state of its UI is restored). Activities in the stack are never rearranged, only pushed and popped from the stack—pushed onto the stack when started by the current activity and popped off when the user leaves it using the Backbutton. As such, the back stack operates as a "last in, first out" object structure. Figure 1 visualizes this behavior with a timeline showing the progress between activities along with the current back stack at each point in time.


현재 액티비티가 다른 액티비티를 시작할 경우, 새로운 액티비티는 스택의 최상단으로 올라가고 포커스를 갖게 된다. 이전의 액티비티는 스택에 남아있으나 중지된다. 액티비티가 중지되면, 시스템은 UI의 현재 상태를 유지한다. 사용자가 back 버튼을 누르면, 현재 액티비티는 스택에서 빠져나가고 (액티비티가 소멸되었다) 이전의 액티비티가 재개된다 (UI의 이전 상태가 복원된다). 스택의 액티비티는 재배열되지 않으며, 들어오고 나가기만 한다 - 현재 액티비티에 의해 시작될 경우 스택에 들어오고, back 버튼을 사용해 나갈 경우 스택에서 빠져 나간다. 이렇게 back 스택은 "last in, first out" 구조로 동작한다. Fig 1은 타임라인에 따라 각 시각의 back stack에 따른 액티비티의 진행을 보여주며 동작을 시각화한다.


If the user continues to press Back, then each activity in the stack is popped off to reveal the previous one, until the user returns to the Home screen (or to whichever activity was running when the task began). When all activities are removed from the stack, the task no longer exists.


사용자가 back 버튼을 계속해서 누르면, 스택의 액티비티가 빠져나가면서 이전의 액티비티를 드러내게 되고, 사용자는 홈스크린 (또는 task가 시작된 액티비티)으로 돌아가게 된다. 스택에서 모든 액티비티가 사라지면, task는 사라지게 된다.


A task is a cohesive unit that can move to the "background" when users begin a new task or go to the Home screen, via theHome button. While in the background, all the activities in the task are stopped, but the back stack for the task remains intact—the task has simply lost focus while another task takes place, as shown in figure 2. A task can then return to the "foreground" so users can pick up where they left off. Suppose, for example, that the current task (Task A) has three activities in its stack—two under the current activity. The user presses the Homebutton, then starts a new application from the application launcher. When the Home screen appears, Task A goes into the background. When the new application starts, the system starts a task for that application (Task B) with its own stack of activities. After interacting with that application, the user returns Home again and selects the application that originally started Task A. Now, Task A comes to the foreground—all three activities in its stack are intact and the activity at the top of the stack resumes. At this point, the user can also switch back to Task B by going Home and selecting the application icon that started that task (or by selecting the app's task from the recent appsscreen). This is an example of multitasking on Android.


task는 응집력이 있는 유닛으로, 사용자가 새로운 task를 시작하거나 홈버튼을 통하여 홈스크린으로 이동하면  "background"로 이동 할 수 있다. background에 있는 동안 task의 모든 액티비티는 정지되지만, task의 back stack 온전히 남아있다 - fig2에서 볼 수 있듯이 다른 task가 자리를 차지하고 있는 동안 task는 단순히 포커스만 잃을 뿐이다. task는 "foreground"로 돌아갈 수 있다. 예를 들어, 현재 task (task A)가 스택에 3개의 액티비티를 가지고 있다 - 현재 액티비티 아래에 2개의 액티비티가 있다. 사용자가 홈 버튼을 누르고, 앱 런처에서 새로운 앱을 시작한다. 홈스크린이 나타날 때 task A는 background로 들어간다. 새 앱이 시작할 때, 시스템은 앱을 위하여 task (task B)를 시작한다. 앱과 상호작용을 끝난 후, 사용자는 홈으로 돌아가고 task A를 시작한 앱을 선택한다. 이제 task A는 foreground로 돌아온다 - 스택의 3개의 액티비티는 온전하며 스택의 최상단에 있는 액티비티가 재개된다. 이 시점에 사용자는 홈으로 가서 task를 시작한 앱을 선택하여 (또는 recent appscreen에서 앱의 task를 선택하여)task B로 전환할 수 있다.


Because the activities in the back stack are never rearranged, if your application allows users to start a particular activity from more than one activity, a new instance of that activity is created and pushed onto the stack (rather than bringing any previous instance of the activity to the top). As such, one activity in your application might be instantiated multiple times (even from different tasks), as shown in figure 3. As such, if the user navigates backward using the Back button, each instance of the activity is revealed in the order they were opened (each with their own UI state). However, you can modify this behavior if you do not want an activity to be instantiated more than once. How to do so is discussed in the later section about Managing Tasks.

back stack의 액티비티는 재배열되지 않기 때문에, 앱이 특정 액티비티를 여러곳에서 시작할 수 있도록 했을 때, 새로운 인스턴스가 생성되어 스택에 들어간다 (이전 액티비티를 최상단으로 가져가지 않고). fig3에서 볼 수 있듯이, 이런식으로 앱의 액티비티는 여러번 인스턴스화 될 수 있다 (다른 task에서도). 사용자가 back 버튼으로 뒤로 이동 할 경우, 각 인스턴스는 열린 순서대로 노출이 된다. 하지만, 한번 이상 인스턴스화 되는 것을 원하지 않는다면 이런 동작을 수정할 수 있다. 어떻게 할 수 있는지는 task 관리에 관한 나중 섹션에서 논의된다.

To summarize the default behavior for activities and tasks:

  • When Activity A starts Activity B, Activity A is stopped, but the system retains its state (such as scroll position and text entered into forms). If the user presses the Back button while in Activity B, Activity A resumes with its state restored.
  • When the user leaves a task by pressing the Home button, the current activity is stopped and its task goes into the background. The system retains the state of every activity in the task. If the user later resumes the task by selecting the launcher icon that began the task, the task comes to the foreground and resumes the activity at the top of the stack.
  • If the user presses the Back button, the current activity is popped from the stack and destroyed. The previous activity in the stack is resumed. When an activity is destroyed, the system does not retain the activity's state.
  • Activities can be instantiated multiple times, even from other tasks.

액티비티와 task의 기본 동작을 요약하자면:

  • 액티비티A가 액티비티B를 시작할 때, 액티비티 A는 정지되지만, 시스템은 그것의 모든 상태를 유지한다 (스크롤 위치, 폼에 입력된 텍스트 등). 사용자가 액티비티B에서 back 버튼을 누르면 액티비티A는 상태가 복원되어 재개된다.

  • 사용자가 홈버튼으로 task를 나갈 경우, 현재 액티비티는 멈추고, task는 background로 들어간다. 시스템이 태스크의 액티비티의 상태를 유지한다. 사용자가 나중에 task를 시작했던 런처 아이콘을 선택하여 task를 재개할 경우, task는 foreground로 오게되고 stack의 최상단 액티비티를 재개한다.

  • 사용자가 back 버튼을 누르면, 현재 액티비티는 stack에서 빠져서 소멸된다. 스택의 이전 액티비티가 재개된다. 액티비티가 소멸되면, 시스템은 액티비티의 상태를 유지하지 않는다.

  • 액티비티는 여러번 인스턴스화 될 수 있다. 


Saving Activity State


As discussed above, the system's default behavior preserves the state of an activity when it is stopped. This way, when users navigate back to a previous activity, its user interface appears the way they left it. However, you can—and should—proactively retain the state of your activities using callback methods, in case the activity is destroyed and must be recreated.

위에서 논의되었듯이, 시스템의 기본 동작은 액티비티가 정지될 때 상태를 유지한다. 사용자가 이전의 액티비티로 이동 시, 사용자가 액티비티를 떠나면서 UI가 나타난다. 하지만, 액티비티가 소멸되고 재생성 될 경우 콜백 메소드를 사용하여 액티비티의 상태를 미리 유지해야 한다. 

When the system stops one of your activities (such as when a new activity starts or the task moves to the background), the system might destroy that activity completely if it needs to recover system memory. When this happens, information about the activity state is lost. If this happens, the system still knows that the activity has a place in the back stack, but when the activity is brought to the top of the stack the system must recreate it (rather than resume it). In order to avoid losing the user's work, you should proactively retain it by implementing the onSaveInstanceState() callback methods in your activity.

시스템이 액티티비를 정지시킬 때 (새로운 액티비티가 시작되거나 태스크가 백그라운드로 들어갈 때), 시스템 메모리를 복원해야할 필요가 있다면 시스템은 액티비티를 완전히 소멸 시킬 수 있다. 이러한 경우에, 액티비티 상태에 대한 정보는 사라진다. 시스템은 액티비티가 백스택에 자리를 차지하고 있는 것을 알고있지만, 액티비티가 스택 최상단으로 올 때 시스템은 액티비티를 재생성 해야한다 (재개 하는 것이 아니라). 사용자의 작업이 유실되는 것을 막기 위해, 액티비티에 onSaveInstanceState()를 구현하여 미리 유지해야 한다.

For more information about how to save your activity state, see the Activities document.


Managing Tasks

The way Android manages tasks and the back stack, as described above—by placing all activities started in succession in the same task and in a "last in, first out" stack—works great for most applications and you shouldn't have to worry about how your activities are associated with tasks or how they exist in the back stack. However, you might decide that you want to interrupt the normal behavior. Perhaps you want an activity in your application to begin a new task when it is started (instead of being placed within the current task); or, when you start an activity, you want to bring forward an existing instance of it (instead of creating a new instance on top of the back stack); or, you want your back stack to be cleared of all activities except for the root activity when the user leaves the task.

위에서 설명했듯이, 안드로이드가 태스크와 back stack을 관리하는 방식은 -  - 대부분의 앱에서 잘 동작하고, 액티비티와 태스크가 어떻게 연관이 되거나 back stack에 어떻게 존재하는지 걱정할 필요는 없다. 하지만, 기본 동작을 간섭할지는 결정할 수 있다. 액티비티가 시작할 때 새로운 태스크를 시작하기를 바랄 수 있고 (현재 태스크 내에 위치하는 대신); 액티비티를 시작할 때, 인스턴스를 앞으로 가져오기를 원할 수 있다 (back stack 최상단에 새 인스턴스를 만드는 대신); 또는 사용자가 태스크를 떠날 때 root 액티비티를 제외하고, 액티비티의 back stack이 clear되기를 원할 수 있다.

You can do these things and more, with attributes in the <activity> manifest element and with flags in the intent that you pass to startActivity().

이런 것들을 <activity> 매니페스트 엘리먼트의 속성이나 startActivity()로 전달하는 intent의 플래그로 처리 할 수 있다.

Posted by ssun++

댓글을 달아 주세요

원문 : https://developers.google.com/cast/docs/android_sender


This overview shows how to build Google Cast sender applications for Android using the Google Cast SDK.


In this overview, sender application or Google Cast application refers to an app running on a mobile device (the sender device) and receiver application refers to an HTML application running on Chromecast or other Google Cast devices.


The Cast SDK uses an asynchronous callback design to inform the application of events and to move between various states of the Cast app life cycle.


이 개요는 구글 캐스트 SDK를 사용하여 안드로이드용 구글 캐스트 sender 앱을 어떻게 빌드하는지 보여준다.


이 개요에서, sender 앱 또는 구글 캐스트 앱은 모바일 장치 (sender 장치)에서 동작하는 앱을 말하고, receiver 앱은 크롬 캐스트 또는 다른 구글 캐스트 장치에서 동작하는 HTML 앱을 말한다.


캐스트 SDK는 비동기 콜백 디자인을 사용하여 앱에 이벤트를 전달하고, 캐스트 앱 라이프사이클의 상태간 전환을 한다.


Setup

Befor you start

  • Download the latest version of the Android SDK using the Android SDK Manager.
  • Install the Android Support Libraries through the Android SDK Manager. The support libraries need to be revision 19.0.1 or later.
  • Install the Google Play services SDK through the Android SDK Manager. The Google Play services SDK needs to be revision 4.2 or later.

The Google Cast SDK for Android is part of the Google Play services SDK and does not need to be downloaded separately.


시작하기 전에

  • Android SDK Manager를 사용하여 최신 버전의 안드로이드 SDK를 다운로드 한다.
  • Android SDK Manager를 통하여 Android Support 라이브러리를 설치한다. support 라이브러리는 19.0.1 이후의 리비전이 필요하다.
  • Android SDK Manager를 통하여 Google Play service SDK를 설치한다. Google Play services SDK는 4.2 이후의 revision이 필요하다.

구글 캐스트 SDK는 Google Play service SDK의 일부이므로 별도로 다운로드 할 필요는 없다.


Library dependencies

The following libraries are required as dependencies for your app:

  • android-support-v7-appcompat which can be found at <SDK install location>/extras/android/support/v7/appcompat
  • android-support-v7-mediarouter which can be found at <SDK install location>/extras/android/support/v7/mediarouter (this has a dependency on android-support-v7-appcompat)
  • google-play-services_lib which can be found at <SDK install location>/extras/google/google_play_services/libproject/google-play-services_lib

It is important for you to ensure that the correct Google Play services APK is installed on a user’s device since updates might not reach all users immediately.


Note: Since the libraries contribute resources, you cannot simply satisfy the dependencies by including their JAR files; instead you need to import them as library projects for your IDE.


For Eclipse, if you get errors when importing the libraries, try the following:

  • android-support-v7-mediarouter has a dependency on android-support-v7-appcompat, so make sure that is imported by selecting the android-support-v7-mediarouter project Properties, then select Android, and in the Libraries list, add android-support-v7-appcompat.
  • Ensure the build target for each of the imported libraries are correct: select the library project Properties and then select Android. Select a different Project Build Target, select "Apply", then re-select the desired target (> API 17) and hit "Apply" again.
  • In your code be careful to reference the MediaRouter classes from the v7 support version of the MediaRouter library (android.support.v7.media.*) and not the classes included in the Android framework (android.media.*).
  • You might have to clean your app project or restart Eclipse if the errors persists after trying all of the steps above.


라이브러리 의존성

아래의 라이브러리는 앱의 의존성을 위해 필요하다.

  • android-support-v7-appcompat는 <SDK install location>/extras/android/support/v7/appcompat에서 찾을 수 있다.
  • android-support-v7-mediarouter는 <SDK install location>/extras/android/support/v7/mediarouter에서 찾을 수 있다.(android-support-v7-appcompat에 의존성을 가지고 있다.)
  • google-play-services_lib는 <SDK install location>/extras/google/google_play_services/libproject/google-play-services_lib에서 찾을 수 있다.

올바른 구글 플레이 APK가 사용자의 장치에 설치되는 것을 보장해야 한다.


Note: 라이브러리가 리소스를 공유하기 때문에, JAR 파일을 include 하는 것으로는 충족되지 않는다 : 대신 라이브러리 프로젝트로 import 해야한다.


이클립스에서 라이브러리 import 시 에러가 발생하면 아래 항목들을 시도해본다:

  • android-support-v7-mediarouter는 android-support-v7-appcompat에 의존성을 가지고 있으므로, android-support-v7-mediarouter 프로젝트의 Properties에서 선택하여 import되도록 하고, Android를 선택하여 Libraries 목록에서 android-support-v7-appcompat를 추가한다.
  • import된 라이브러리의 빌드 타겟이 올바르게 되도록 한다 : 라이브러리 프로젝트의 Properties를 선택하고 Android를 선택한다.  다른 Project Build Target을 선택하고, "Apply"를 선택한다. 그리고 바람직한 타겟 (> API 17)을 선택하고 "Apply"를 다시 선택한다.
  • 코드에서 v7 support 버전 MediaRouter 라이브러리(android.support.v7.media.*)에서의 MediaRouter 클래스를 참조하도록 하고 Android framework(android.media.*)의 클래스를 참조하지 않도록 한다.
  • 위의 단계를 시도 해도 에러가 남아있다면 앱 프로젝트를 clean 하거나 이클립스를 재시작 한다.


Testing

Use a real Android device to test your code as you develop; do not use an emulator, as it does not support Cast functionality.


테스팅

개발한 코드 테스트는 실제 장비를 사용하도록 한다 : 에뮬레이터는 Cast를 지원하지 않기 때문에 사용하지 않는다.

Posted by ssun++

댓글을 달아 주세요

최근에 달린 댓글

최근에 받은 트랙백

글 보관함