블로그 이미지
ssun++

카테고리

[전체] (73)
Android (7)
JavaScript (9)
CI (5)
Language (14)
ETC (38)
Total322,318
Today10
Yesterday16

'Android'에 해당되는 글 7건

  1. 2014.06.17 Tasks and Back Stack (1)
  2. 2014.06.10 Android Sender App Development (1)
  3. 2014.05.27 Registration
  4. 2014.05.27 Developers Guide
  5. 2014.05.26 Cast Your Content to the Big Screen
  6. 2014.05.25 Keeping Your App Responsive
  7. 2013.08.11 Content Provider

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

댓글을 달아 주세요

Registration

Android/Cast / 2014.05.27 23:03

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


You must register your application if you are using the Styled Media Receiver or you are building a Custom Receiver. Once you've registered your application, you'll receive an app ID that your sender application must use to perform API calls such as to launch the receiver application.


Styled Media Receiver를 사용하거나 Custom Receiver를 만들 때 반드시 앱을 등록 해야한다. 앱을 등록하면 앱 ID를 받게되고, sender 앱이 API를 호출할 때 사용해야한다. (receiver 앱을 실행하는 등)


You must also register your Google Cast device so that it may access your receiver application before you publish it. Once you publish your receiver application, it will be available to all Google Cast devices.


또한 receiver 앱을 발행하기 전에 접근하려면 Google Cast 장치를 등록해야 한다. receiver 앱을 발행하면, 모든 Google Cast 장치에서 접근이 가능하다.


Register your application


You must register your Styled Media Receiver or Custom Receiver in order to receive an app ID that's used with API calls from the sender application.

To register your receiver app:

  1. Sign in to the Google Cast SDK Developer Console.
  2. From either the Overview page or Applications page, click Add New Application.
  3. Select the type of receiver app you will use:
    Custom Receiver
    Select this if your app requires user interface components or interaction patterns that are not provided by the Styled Media Receiver. Selecting Custom Receiver may also be necessary if your content type is not listed as one of Styled Media Receiver's supported media types.

    Be aware that this option requires that you build a complete web app for the receiver app.

    For details, read Custom Receiver Application.

    Styled Media Receiver
    Select this if your app streams video or audio content using one of the supported media types and you'd like to provide a user interface on the TV that uses either the default media player UI or a set of custom styles on top of the default media player UI.

    The custom styles you may provide allow you to define the look for various elements of the player UI (such as the splash screen and progress bar) simply by providing a CSS file—you do not need to build a receiver app.

    For details, read Styled Media Receiver.

  4. Fill in the details for you receiver app:
    1. Enter your app name.
    2. Specify the receiver app's appearance:
      • For a Custom Receiver, specify the app URL.

        Enter a URL that the Google Cast device should request when loading your receiver app. During development the URL can use HTTP but when the app is published it has to use HTTPS. The URL may be for an HTML page or other file type accessible from a web browser. It's okay for your receiver to be on an internal (NAT-registered) IP address, but not on localhost, as it is rarely a top level domain. Although the receiver app must be served over SSL (HTTPS) when published, the content loaded on the receiver app may be served over HTTP.

      • For a Styled Media Receiver, specify the app style.

        Select Default for the default media player UI. (You can later switch to Custom if you decide to provide your own UI styles.)

        Select Custom to provide your own CSS file that specifies the appearance for several elements of the media player UI. In the input field that appears, provide an HTTPS URL that points to your CSS file located on your own web site or onGoogle Drive.

        Click Preview at the bottom to view your receiver app's appearance using mock media content.

    3. Select whether the app should be published for end-users.

      Leave this set to No while developing and testing your app with a registered Google Cast device.

      When you're ready to publish your app for end-users, set this to Yes.

    4. Select the platforms on which your sender app will be available and provide the relevant identification information.
  5. Click Save.

In the list of Applications, your new app is listed with a unique Application ID. Copy this ID for use in the code for your sender app.

If you selected Styled Media Receiver, there's nothing else you need to do for the receiver app, other than provide optional CSS styling as described in the Styled Media Receiver guide.

If you selected Custom Receiver, you must provide a web app as described in the Custom Receiver Application guide.


sender 앱에서 API 호출 시 사용할 앱 ID를 받기 위해서 Styled Media Receiver 또는 Custom Receiver를 반드시 등록해야 한다. 

앱을 등록하기 위해서는 :

  1. Google Cast SDK Developer Console에 로그인 한다.
  2. Overview 또는 Applications 페이지에서, click Add New Application을 클릭한다.
  3. receiver 앱의 타입을 선택한다.

    Custom Receiver

    Styled Media Receiver가 제공하지 않는 UI 컴포넌트나 인터랙션 패턴이 필요한 경우 선택한다. 콘텐트 타입이 Styled Media Receiver의 supported media types에 나타나지 않는 경우에도 Custom Receiver를 선택한다.

    이 옵션을 선택할 경우 receiver 앱을 위해 완전한 웹앱을 구축해야 함을 알아야 한다.

    자세한 사항은 Custom Receiver Application을 읽어보자.

    Styled Media Receiver

    앱이 supported media types에 리스팅 된 비디오나 오디오 콘텐트를 전송하고, TV에서 디폴트 미디어 플레이어 UI나 상단에 커스텀 스타일을 적용한 디폴트 미디어 플레이어 UI를 제공할 경우 선택한다.

    커스텀 스타일은 단순히 CSS 파일을 제공함으로써 플레이어 UI의 다양한 엘리먼트의 룩을 정의할 수 있다 (스플래시 화면, 프로그레스 바 등) - receiver 앱을 구축할 필요가 없다.

    자세한 사항은 Styled Media Receiver을 읽어보자.

  4. receiver 앱의 상세 사항을 채우자:

    1. 앱 이름을 넣고.
    2. receiver 앱의 외양을 정한다:

      • Custom Receiver의 경우, app의 URL을 정한다.

        Google Cast 장치가 receiver 앱을 로딩할 때 요청할 URL을 입력한다. 개발하는 동안 URL은 http를 사용할 수 있지만 발행되면 https를 사용해야 한다. URL은 HTML 페이지나 웹브라우저에서 접근 가능한 파일 타입이 되어야 한다. receiver가 내부 IP를 가지는 것은 상관없으나, localhost가 되어서는 안된다. receiver 앱은 발행시 SSL을 통해 제공되어야 하지만, receiver 앱에 로드되는 콘텐츠는 HTTP를 통해 제공되어야 한다.

      • Styled Media Receiver의 경우 앱 스타일을 정한다.

        디폴트 미디어 플레이어 UI를 적용하려면 Default를 선택한다.(자체 UI 스타일을 제공하려면 나중에 Custom으로 바꿀 수 있다.)

        자체 CSS 파일을 제공하여 미디어 플레이어 UI 엘리먼트의 외양을 정하려면 Custom을 선택한다. 입력 필드에는 CSS 파일이 위치한 웹사이트나 Google Drive의 HTTPS URL을 입력한다.

        mock media content를 사용하여 receiver 앱을 보기 위해서는 하단의 Preview를 클릭한다. 

    3. 최종 사용자에게 발행할지를 선택한다.

      등록된 Google Cast 장치로 개발과 테스팅을 하는 동안은 No로 둔다.

      최종 사용자에서 발행할 준비가 되면 Yes로 결정한다.

    4. sender 앱이 구동될 플랫폼을 선택하고, 적절한 정보를 제공한다.
  5. Save를 클릭한다.

앱 목록에서, 새로운 앱은 유니크한 앱 ID와 함께 리스트 되어있다.  sender app을 위해 이 ID를 복사하자.

Syled Media Receiver를 선택했다면, Styled Media Receiver 가이드에 설명된 것처럼 추가적인 CSS 제공하는 것 외에는 receiver 앱을 위해 해야할 것은 없다.

Custom Receiver를 선택했다면, Custom Receiver Application 가이드에 에 설명된 것처럼 웹앱을 제공해야 한다.


Register your Google Cast device


By default, Google Cast devices (such as a Chromecast) are not enabled for development and testing. To turn your device into a development device and gain access to your receiver app while it is not yet published, you must register the device. Registering also makes the receiver app accessible from a remote browser window for debugging (see Debugging).


기본적으로, Google Cast 장치는 개발과 테스팅이 가능하지 않다. 장치를 개발 가능하게 하고 발행되지 않은 receiver 앱에 접근하기 위해서, 장치를 등록해야 한다. 등록을 통하여 receiver 앱을 원격 브라우저 창에서 접근 할 수 있게된다.


To register your Google Cast device:

  1. Sign in to the Google Cast SDK Developer Console.
  2. From either the Overview page or Devices page, click Add New Device.
  3. Enter the serial number of your development device. This is a 12-digit alphanumeric string printed on the device.

    The serial number on a Chromecast is laser-etched (not printed) and begins with a 3, 4 or 5. It may be easier to read if you take a picture of the serial number then enlarge it.

  4. Enter a description. This is just a friendly name for your device (it does not need to match the name you gave to the device during user setup).
  5. Click OK.

    It may take several minutes for the device to become registered and available as your development device. Once registration is complete, the Status for the device will say "Ready for Testing."

  6. Restart the Google Cast device that you have registered. Check whether you can access http://<cast-device-ip>:9222 from a chrome browser on the same WiFi network; if you can, then your device is ready for development.

Google Cast 장치 등록하기

  1. Google Cast SDK Developer Console에 로그인한다.
  2. Overview 페이지나 Devices 페이지에서 Add New Device를 선택한다.
  3. 개발 장치의 일련번호를 입력한다. 12자리의 알파벳과 숫자로 되어 장치에 프린트 되어있다.

    Chromecast의 일련번호는 레이저 각인되어 3, 4, 5로 시작한다. 사진을 찍어서 확대하면 읽기 쉬울 것이다.

  4. 설명을 입력한다. 장치를 위한 친근한 이름이다. (setup 시 입력한 이름과 일치할 필요는 없다.)
  5. OK를 클릭한다.

    장치가 등록되어 개발 장비로 사용할 수 있기 까지는 몇 분이 걸린다. 등록이 완료되면 장치의 상태가 "Ready for Testing"이 된다.

  6. 등록된 Google Cast 장치를 재시작한다. 동일한 WiFi network의 chrome browser에서 http://<cast-device-ip>:9222 로 접근이 가능한지 확인한다 : 가능하다면 장치는 개발 가능한 상태이다.


Posted by ssun++

댓글을 달아 주세요

Developers Guide

Android/Cast / 2014.05.27 21:34

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


The Google Cast SDK includes API libraries and sample application code to help you cast your applications to the big screen. These APIs are documented in the API references, and the sample code is discussed in the Sender Applications and Receiver Applications overviews.


Google Cast SDK는 API 라이브러리와 큰 화면으로 앱을 cast 할 수 있도록 도와주는 샘플 앱 코드를 포함한다. API는 API references에 문서화 되어있고, 샘플 코드는 Sender ApplicationsReceiver Applications overview에서 논의된다.


Components


Here's what you need to build a Cast app.Here's what you need to build a Cast app.

  • A sender application, written for the Android, iOS, or Chrome platform which uses the following Cast APIs:
  • A receiver application that handles communication between the sender app and the receiver device. You have the following options:
    • The Default Media Receiver presented with the Google Cast branding and styling.
    • The Styled Media Receiver for which you can develop the styles and branding. See Styled Media Receiver.
    • A custom receiver, as described in Custom receiver that implements the Receiver API and handles custom messages from your sender app; it may also interface with the media player types provided through the Media Player Library.

How you implement your receiver may depend upon which media types your application needs to support.


  • receiver 앱은 sender 앱과 receiver 장치 간 커뮤니케이션을 다룬다. 아래와 같은 옵션이 있다.
    • Google Cast 브랜딩과 스타일의 Default Media Receiver
    • Custom receiver에 설명된 것처럼 Receiver API를 구현하고 sender 앱으로부터의 custom 메세지를 다루는 Custom receiver; 또한 Media Player Library를 통해 제공되는 media player type을 인터페이스 할 수 있다.

receiver를 어떻게 구현하는지는 앱이 지원해야 할 media type에 따라 달라진다.


Get Started


  1. First, get set up for development:
    1. Install your Chromecast device and run through the Chromecast Setup instructions.
    2. Run the Chromecast app on your sender device, following the prompts as directed.
    3. Under Privacy, check the box to Send this Chromecast's serial number when checking for updates.
    4. You must select this option in order to enable your receiver device for development.
  2. Review the User Experience Guidelines showing you how to implement a UI that is consistent with other Cast apps.
  3. Download the API libraries and sample apps.
  4. Register your application.
  5. You will receive an app ID to include with your API calls.
  6. Develop your app.
    • Check out the Google Cast app development overviews:
      • Android sender
      • iOS sender
      • Chrome sender
      • Receiver
    • Peruse the API references.


  1. 먼저, 개발을 위한 준비를 한다.
    1. Chromecast 장치를 설치하고 Chromecast Setup 을 따라 한다.
    2. sender 장치에서 Chromecast 앱을 실행시키고, 하라는대로 따라 하자
    3. 개인 정보에서, "업데이트를 확인할 때 Chromecast의 일련번호를 전송" 박스를 체크한다. 
    receiver 장치에서 개발이 가능하게 하기 위해서 이 옵션을 꼭 선택해야 한다.
  2. 다른 Cast 앱들과 일관성 있는 UI를 어떻게 개발하는지 보여주는 User Experience Guidelines 를 확인한다.
  3. API 라이브러리와 샘플 앱을 Download 한다.
  4. 앱을 등록한다.
  5. API 호출 시 필요한 app ID를 받을 것이다.
  6. 앱을 개발한다.
    • Check out the Google Cast app development overviews:


Posted by ssun++

댓글을 달아 주세요

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


Google Cast is a technology that enables multi-screen experiences and lets a user send and control content like video from a small computing device like a phone, tablet, or laptop to a large display device like a television.


Google Cast는 멀티 스크린 경험을 가능하게 하고, 사용자가 폰이나 태블릿 같은 작은 장치의 콘텐트를 TV와 같이 큰 장치로 보내거나 컨트롤 할 수 있게 해주는 기술이다.


The sender may be a phone or tablet running on Android or iOS, or it may be a laptop computer running Chrome OS, Mac OS, or Windows. A sender application running on the sender device uses the Google Cast API appropriate to its operating system to discover and transmit to the receiver application running on the receiver device. You can use the sender APIs to enable your Android, iOS, or Chrome app to send content to a large display.


sender는 Android나 iOS가 탑재된 폰이나 태블릿, 또는 Chrome OS, Mac OS, Windows가 탑재된 랩탑이 될 수 있다. sender 장치의 sender 앱은 Google Cast API를 적절하게 사용하여 OS가 발견하고 receiver 장치의 receiver 앱으로 보낼 수 있도록 한다. sender API를 사용하여 Android, iOS, Chrome 앱이 큰 디스플레이로 콘텐트를 전송 할 수 있다.


The receiver device is optimized for video playback with a receiver application that receives data over Internet Protocol and transmits it to the television. The receiver API lets you customize the messaging between the sender and receiver applications for authentication and other scenarios.


receiver 장치는 재생에 최적화 되어있어서 인터넷 프로토콜을 통하여 데이터를 받아서, TV로 전달한다. receiver API를 사용하여 sender와 receiver 간의 메시징을 커스터마이징 할 수 있다.


While content is playing on a TV, a user can multitask on their device without interrupting the video playback. For example, a user can search for a video on their phone’s YouTube application and then send the video to their TV via a Google Cast device. The user can play, pause, seek, and control volume using their phone, they can search for other videos to watch, and even check their email while the content keeps playing on the TV.


TV에서 콘텐트가 재생되고 있는 동안, 사용자는 비디오 재생을 방해하지 않고 멀티 태스킹을 할 수 있다. 예를 들어, 사용자는 유튜브 앱에서 영상을 검색하고 Google Cast 장치를 통해 TV로 영상을 전송할 수 있다. 사용자는 폰을 사용하여 재생, 멈춤, seek, 볼륨 조절 등을 할 수 있고, 다른 영상을 검색하거나, 이메일을 확인 할 수 도 있다.

Posted by ssun++

댓글을 달아 주세요

원문 : http://developer.android.com/training/articles/perf-anr.html


It's possible to write code that wins every performance test in the world, but still feels sluggish, hang or freeze for significant periods, or take too long to process input. The worst thing that can happen to your app's responsiveness is an "Application Not Responding" (ANR) dialog.


성능 테스트 코드를 작성하는 것은 가능하지만, 느리거나, 특정 구간에서 멈추거나, 입력을 처리함에 매우 오랜 시간이 걸릴 수 있다. 앱의 반응에 있어서 발생할 수 있는 최악은 ANR 다이얼로그 이다.


In Android, the system guards against applications that are insufficiently responsive for a period of time by displaying a dialog that says your app has stopped responding, such as the dialog in Figure 1. At this point, your app has been unresponsive for a considerable period of time so the system offers the user an option to quit the app. It's critical to design responsiveness into your application so the system never displays an ANR dialog to the user.


안드로이드에서, 시스템은 일정 시간동안 응답이 불충분할 때, 앱의 응답이 멈추었다는 다이얼로그를 보여준다. 이 때, 앱은 일정 시간동안 응답이 없었고 시스템은 앱을 종료할 수 있도록 한다. 시스템이 ANR 다이얼로그를 보여주지 않도록 응답성을 설계하는 것은 매우 중요하다.


This document describes how the Android system determines whether an application is not responding and provides guidelines for ensuring that your application stays responsive.


이 문서는 안드로이드 시스템이 응답하지 않는 앱을 어떻게 결정하는지를 설명하고, 앱이 항상 응답하도록 보장하는 가이드라인을 제공한다.


What Triggers ANR


Generally, the system displays an ANR if an application cannot respond to user input. For example, if an application blocks on some I/O operation (frequently a network access) on the UI thread so the system can't process incoming user input events. Or perhaps the app spends too much time building an elaborate in-memory structure or computing the next move in a game on the UI thread. It's always important to make sure these computations are efficient, but even the most efficient code still takes time to run.


일반적으로, 앱이 사용자의 입력에 응답할 수 없을 대 시스템은 ANR을 출력한다. 예를 들어, 앱이 UI thread에서 어떤 IO 동작을 막아서 시스템이 사용자의 입력을 처리할 수 없는 경우이다. 또는 앱이 메모리 구조를 구축하는데 많은 시간을 사용하거나, UI thread에서 게임의 다음 동작을 계산할 때이다. 이런 연산들이 효과적으로 수행되도록 하는 것은 항상 중요하지만, 아무리 효율적인 코드라도 실행하는데 시간은 소요된다.


In any situation in which your app performs a potentially lengthy operation, you should not perform the work on the UI thread, but instead create a worker thread and do most of the work there. This keeps the UI thread (which drives the user interface event loop) running and prevents the system from concluding that your code has frozen. Because such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. (Compare this with basic code performance, which is a method-level concern.)


앱이 잠재적으로 오랜시간이 걸릴 수 있는 작업을 수행할 때, 그 작업을 UI thread에서 수행해서는 안되고, 대신 worker thread를 생성하여 수행할 수 있도록 해야한다. 이것은 UI thread가 동작될 수 있게하고, 코드가 멈추는 것을 막는다. 이러한 쓰레딩은 클래스 레벨에서 행해지기 때문에, 응답성은 클래스의 문제로 생각할 수 있다.


In Android, application responsiveness is monitored by the Activity Manager and Window Manager system services. Android will display the ANR dialog for a particular application when it detects one of the following conditions:

  • No response to an input event (such as key press or screen touch events) within 5 seconds.
  • A BroadcastReceiver hasn't finished executing within 10 seconds


안드로이드에서, Activity Manager와 Window Manager가 앱의 응답성을 관찰한다. 안드로이드는 아래의 조건이 발견될 때 ANR 다이얼로그를 출력한다.

  • 입력 이벤트에 대해서 응답이 5초간 없음
  • BroadcastReceiver가 10초 내에 실행을 완료하지 않음


How to Avoid ANRs


Android applications normally run entirely on a single thread (by default the "UI thread" or "main thread"). This means anything your application is doing in the UI thread that takes a long time to complete can trigger the ANR dialog because your application is not giving itself a chance to handle the input event or intent broadcasts.


안드로이드 앱은 일반적으로 하나의 쓰레드에서 실행된다. UI thread에서 시간이 오래 걸리는 작업을 할 경우 앱이 입력을 처리하거나 intent broadcast(?) 할 수 없어서 ANR 다이얼로그를 발생시킬 수 있다.


Therefore, any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible to set up in key life-cycle methods such as onCreate() and onResume(). Potentially long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a worker thread (or in the case of databases operations, via an asynchronous request).


따라서, UI thread에서 수행되는 메소드는 가능한 작은 작업을 수행해야 한다. 구체적으로, 액티비티는 onCreate()나 onResume()같은 생명주기 메소드에서 작은 작업을 수행해야 한다. 네트워크나 데이터베이스처럼 잠재적으로 오래 걸릴 수 있는 작업, 비트맵 리사이징처럼 계산 비용이 큰 작업은 worker thread에서 수행되어야 한다.


The most effecive way to create a worker thread for longer operations is with the AsyncTask class. Simply extend AsyncTask and implement the doInBackground() method to perform the work. To post progress changes to the user, you can call publishProgress(), which invokes the onProgressUpdate() callback method. From your implementation of onProgressUpdate() (which runs on the UI thread), you can notify the user.


오래 걸리는 작업을 위해서 worker thread를 생성하는 가장 효율적인 방법은 AsyncTask 클래스를 이용하는 것이다. AsyncTask를 상속하고 doInBackground() 메소드를 구현하면 된다. 사용자에게 진행률을 알려주기 위해서는 onProgressUpdate() 콜백을 호출하는, publishProgress()를 호출한다. onProgressUpdate()의 구현에서 사용자에게 알려줄 수 있다. (예시는 생략)


Although it's more complicated than AsyncTask, you might want to instead create your own Thread or HandlerThread class. If you do, you should set the thread priority to "background" priority by calling Process.setThreadPriority() and passing THREAD_PRIORITY_BACKGROUND. If you don't set the thread to a lower priority this way, then the thread could still slow down your app because it operates at the same priority as the UI thread by default.


AsyncTask 보다 복잡할 수 있지만, Thread나 HandlerThread를 만들 수도 있다. 이 경우, Process.setThreadPriority()를 호출하고 THREAD_PRIORITY_BACKGROUND를 전달하여 "background" priority를 set해야 한다. 이런 방식으로 쓰레드에 낮은 priority를 적용하지 않을 경우, UI thread와 동일한 priority에서 수행되어 thread가 앱을 느리게 할 수 있다.


If you implement Thread or HandlerThread, be sure that your UI thread does not block while waiting for the worker thread to complete—do not call Thread.wait() or Thread.sleep(). Instead of blocking while waiting for a worker thread to complete, your main thread should provide a Handler for the other threads to post back to upon completion. Designing your application in this way will allow your app's UI thread to remain responsive to input and thus avoid ANR dialogs caused by the 5 second input event timeout.


Thread나 HandlerThread를 구현할 때, UI thread가 worker thread를 기다리면서 block되지 않도록 해야한다. Thread.wait()나 Thread.sleep()을 호출하지 않아야한다. worker thread를 기다리면서 block되도록 하는 대신, main thread가 Handler를 제공하여 작업 완료 시 사용할 수 있도록 해야한다. 이러한 앱 디자인은 UI thread가 사용자의 입력에 응답하고 ANR을 막을 수 있도록 한다.


The specific constraint on BroadcastReceiver execution time emphasizes what broadcast receivers are meant to do: small, discrete amounts of work in the background such as saving a setting or registering a Notification. So as with other methods called in the UI thread, applications should avoid potentially long-running operations or calculations in a broadcast receiver. But instead of doing intensive tasks via worker threads, your application should start an IntentService if a potentially long running action needs to be taken in response to an intent broadcast.


BroadcastReceiver 실행 시간에 대한 제약사항은 broadcast receiver가 해야할 것들을 강조한다 : 설정의 저장이나 Notification의 등록과 같은 background에서 작고, 분산된 양의 작업. UI thread에서 다른 메소드들이 불리는 것처럼,  앱은 잠재적으로 오랜시간이 걸릴 수 있는 연산이나 계산을 피해야한다. 하지만  intent broadcast의 응답에 잠재적으로 오래 걸리는 작업을 해야한다면, worker thread에서 집중적인 작업을 하는 대신, IntentService를 시작해야한다.


Tip: You can use StrictMode to help find potentially long running operations such as network or database operations that you might accidentally be doing your main thread


Reinforce Responsiveness


Generally, 100 to 200ms is the threshold beyond which users will perceive slowness in an application. As such, here are some additional tips beyond what you should do to avoid ANR and make your application seem responsive to users:

  • If your application is doing work in the background in response to user input, show that progress is being made (such as with a ProgressBar in your UI).
  • For games specifically, do calculations for moves in a worker thread.
  • If your application has a time-consuming initial setup phase, consider showing a splash screen or rendering the main view as quickly as possible, indicate that loading is in progress and fill the information asynchronously. In either case, you should indicate somehow that progress is being made, lest the user perceive that the application is frozen.
  • Use performance tools such as Systrace and Traceview to determine bottlenecks in your app's responsiveness.


일반적으로 100~200ms가 사용자가 느림을 인식하는 경계이다. ANR을 방지하고 사용자에게 응답성을 보여주기위한 추가적인 팁이다.

  • 사용자 입력에 반응하기 위해 background에서 작업하는 경우 progress를 보여주기
  • 게임인 경우, worker thread에서 연산
  • 초기 셋업에 시간이 소요되는 경우, 스플래시를 보여주거나 메인 뷰를 가능한 빨리 보여주고, 로딩이 진행중임을 보여주고 비동기로 정보를 보여주기. 어떤 경우든 프로그레스를 보여주어서 사용자가 block 상태를 알 수 없도록 해야한다.
  • 앱의 반응성에서 병목 구간을 결정하기 위해서 Systrace나 Traceview같은 성능 도구를 사용한다.

Posted by ssun++

댓글을 달아 주세요

Content Provider

Android / 2013.08.11 14:59

원문http://developer.android.com/guide/topics/providers/content-providers.html


Content providers manage access to a structured set of data. They encapsulate the data, and provide mechanisms for defining data security. Content providers are the standard interface that connects data in one process with code running in another process.


CP는 데이터에 접근하는 것을 관리한다. 데이터를 캡슐화 하고, 데이터의 보안을 정의하는 메커니즘을 제공한다. CP는 하나의 프로세스에서 다른 프로세스의 데이터로 접근할 수 있는 표준 인터페이스다.


When you want to access data in a content provider, you use the ContentResolver object in your application's Context to communicate with the provider as a client. The ContentResolver object communicates with the provider object, an instance of a class that implements ContentProvider. The provider object receives data requests from clients, performs the requested action, and returns the results.


CP에 있는 데이터로 접근할 때, CP와 통신할 클라이언트로 ContentResolver 객체를 사용할 수 있다. ContentResolver 객체는 ContentProvider 구현 클래스의 객체와 통신한다. CP 객체는 클라이언트로 부터의 데이터 요청을 받고, 요청받은 동작을 수행하며, 결과를 반환한다. 


You don't need to develop your own provider if you don't intend to share your data with other applications. However, you do need your own provider to provide custom search suggestions in your own application. You also need your own provider if you want to copy and paste complex data or files from your application to other applications.


앱의 데이터를 공유할 목적이 아니라면, CP를 반드시 개발할 필요는 없다. 그러나 앱에서 검색 제안을 제공하기 위해 CP가 필요할 수 있다. 또한 복잡한 데이터/파일을 다른 앱으로 복사/붙여넣기 할때 CP가 필요할 수 있다.


Android itself includes content providers that manage data such as audio, video, images, and personal contact information. You can see some of them listed in the reference documentation for the android.provider package. With some restrictions, these providers are accessible to any Android application.


안드로이드는 오디오, 비디오, 이미지, 주소록 정보를 관리하기 위한 CP를 포함하고 있다. 레퍼런스 문서의 android.provider 패키지에서 이들을 볼 수 있다. 약간의 제약이 있지만 다른 안드로이드 앱에서 접근 가능하다.

Posted by ssun++

댓글을 달아 주세요

최근에 달린 댓글

최근에 받은 트랙백

글 보관함