[Android] View 문서 읽기

https://developer.android.com/reference/android/view/View

 

뷰 사용하기 

모든 뷰들을 하나의 트리 안에 배열된다. 코드로든, xml 레이아웃 파일이든 뷰들이 트리에 추가된다. 

뷰들의 트리를 생성한 후에는 다음과 같은 몇 가지 일반적인 작업을 수행할 수 있다.

 

- properteis 설정 : 예를 들면, TextView에 text를 설정하는 것. 뷰의 서브클래스마다 properties와 properties를 세팅하는 메소들이 다양하게 존재한다. xml 레이아웃 파일에서 빌드 시에 이 알려진 속성들이 설정될 수 있다.

- focus 설정 : 사용자 인풋에 따른 반응으로 프레임워크가 포커스 이동을 처리함. requestFocus()를 호출해 원하는 특정 뷰에 포커스 설정 가능

- listeners 설정 :  뷰에 무언가 일이 발생할 경우에 알림 받기 위한 리스너 설정이 가능함.

- visiblity 설정: 뷰를 보일지 숨길지 setVisibility()로 설정함.

 

뷰를 measuring, layout, drawing하는 것은 Android 프레임워크가 담당하고 있어서 ViewGroup을 구현하지 않는다면 직접 호출해서는 안된다.

 

custom view 구현하기

custom view를 구현하는 것은 프레임워크가 모든 뷰에서 호출하는 몇몇의 표준 메소드들을 오버라이드하는 것에서 시작할 수 있다. 모든 메소드들을 오버라이드할 필요는 없다. onDraw(android.graphics,Canvas)를 오버라이드하는 것만으로도 custom view를 만들 수 있다.

 

Creation. 생성
Constructure. 생성자	코드로 뷰를 생성할 때 호출하는 생성자 형식이 있고, 레이아웃 파일에서 뷰를 인플레이할 때 호출하는 생성자 형식이 있다.두번 째 형식은 레이아웃 파일에서 정의한 속성들을 분석하고 적용해야 한다.
onFinishedInflate()	XML 로부터 뷰와 모든 자녀 뷰들이 다 인플레이트된 후에 호출된다.

Layout.
onMeasure(int, int)	뷰와 모든 자녀 뷰들의 크기를 정하기 위해 호출된다.
onLayout(boolean, int, int, int, int)	뷰가 모든 자식 뷰에 크기와 위치를 할당하기 위해 호출된다.
onSizeChanged(int, int, int, int)	뷰의 사이즈가 변경되면 호출된다.

Drawing
onDraw(android.graphics.Canvas)	뷰가 자신의 콘텐츠를 만들어야할 때 호출된다.

Event Processing
onKeyDown(int, android.view.KeyEvent)	새로운 하드웨어 키 이벤트 발생시 호출된다.
onKeyUp(int, android.view.KeyEvent)	새로운 하드웨어 업 키 이벤트 발생시 호출된다.
onTrackballEvent(android.voew.MotionEvent)	트랙볼 모션 이벤트 발생시 호출된다.
onTouchEvent(android.view.MotionEvent)	스크린 터치 모션 이벤트 발생시 호출된다.

Focus
onFocusChanged(boolean, int, android.graphics.Rect)	뷰가 포커스를 얻거나 잃을 때 호출된다.
onWindowFocusChnaged(boolean)	뷰를 포함하는 윈도우가 포커스를 얻거나 잃을 때 호출된다.

Attaching
onAttachedToWindow()	뷰가 윈도우에 attached 된 경우에 호출된다.
onDetachedFromWindow()	뷰가 윈도우에 detached 된 경우에 호출된다.
onWindowVisibilityChanged(int)	뷰를 포함하는 윈도우의 visibility가 변화되었을 경우 호출된다.

 

IDs

뷰들은 정수 아이디들이 할당된다. 일반적으로 xml 파일에서 할당되고, 뷰 트리 안에서 특성 뷰를 찾는데 사용된다.

트리 전체에서 이 아이디가 고유할 필요는 없는데, 최소한 현재 보고 있는 트리 내에서는 고유하도록 확인하는 게 좋다.

 

Positions

뷰는 직사각형의 영역을 갖는다. 왼쪽 상단 좌표를 한 쌍으로 가지는 위치 값과, 너비와 높이로 표현되는 2차원 값을 가진다. 위치와 차원의 단위는 픽셀이다. 

getLeft()로 뷰를 나타내는 직사각형의 X 좌표를 반환하고, getTop()으로 뷰를 나타내는 직사각형의 Y좌표를 반환한다. 이 메소드 둘 다 부모 뷰로부터 상대적인 위치를 반환한다. 예를 들어 getLeft()로 20을 반환받는다면, 이 뷰는 직접적인 부모뷰의 왼쪽 가장자리에서 오른쪽으로 20 픽셀 떨어진 곳에 위치한 것이다.

추가로, 불필요한 계산을 막기 위해 여러 편리한 메소드들을 제공하는데, getRight(), getBottom()등이 있다. 이 메소드들은 뷰가 나타나는 정사각형의 오른쪽의 좌표를 반환하고, 아래 가장자리의 좌표를 반환한다. 예를 들어, geRight(),는 getLeft()+getWidth() 값과 비슷하다.

 

Size, padding 그리고 margins

뷰의 사이즈는 width와 height로 표현된다. 뷰는 실제로 두 쌍의 width와 height 값들을 가진다. 

첫 번째 쌍은 measured width와 measured height 이다. 이 치수는 뷰의 부모 안에서 원하는 크기를 정의한다.(자세한 것은 Layout을 참고) 이 measured 수치들은 getMeasuredWidth()와 getMeasuredHeight()를 호출해서 얻을 수 있다.

두 번째 쌍은 width와 height로 간단하게 알려져 있거나, 때때로 drawing width, drawing height로 알려져 있다. 이 수치들은 drawing time에 after layout 후에 스크린에서 뷰의 실제 사이즈를 정의한다. 이 값들은 그럴 필요는 없으나 measured width와 measured height와 다를 수 있다. width와 height는 getWidth(), getHeight()로 얻을 수 있다.

이 수치들을 측정하기 위해서 뷰는 뷰의 padding을 고려한다. padding은 뷰의 왼쪽, 상단, 오른쪽, 하단 부분이 필셀로 표현된다. padding으로 특정 픽셀만큼 뷰의 콘텐츠를 보완할 수 있다. 예를 들어, 왼쪽 2 padding은 뷰의 콘텐츠를 왼쪽 가장자리에서 오른쪽으로 2 픽셀만큼 밀어낸다. padding은 setPadding(int,int,int,int) 또는 setPaddingRelative(int,int,int,int) 메소드를 호출해 설정할 수 있고, getPaddingLeft(), getPaddingTop(), getPaddingRight(), getPaddingBottom(), getPaddingStart(), getPaddingEnd()를 호출해 질의할 수 있다.

뷰가 padding을 정의할 수 있음에도 불구하고, margin에 관한 지원은 제공할 수 없다. 그러나 뷰 그룹에서는 그런 지원이 가능하다. 더 자세한 정보는 ViewGroup과 ViewGroup.MarginLayoutParmas를 참고하라.

 

Layout

Layout은 두 단계 과정이다. 측정 단계와 레이아웃 단계이다. 측정 단계는 measure(int, int)로 구현되고, 뷰 트리에서 하향식 방향으로 진행된다. 각 뷰는 크기에 대한 명세 정보를 재귀 과정 동안 트리에 밀어 넣는다. 측정 단계 후에는 모든 뷰에 측정값이 저장된다. 두 번째 단계는 layout(int, int, int, int)에서 발생하고, 또한 하향식이다. 이 과정 동안 각 부모는 측정 단계에서 계산된 크기를 이용해 모든 자녀들을 배치시키는데에(positioning) 책임이 있다.

뷰의 measure() 메소드가 반환할 때에, 뷰의 getMeasuredWidth()와 getMeasuredHeight()값은 반드시 설정되어야 하는데, 뷰의 모든 자식들도 마찬가지다. 뷰의 측정된 너비와 측정된 높이 값은 뷰의 부모가 부과한 제약들을 준수해야 한다.  이렇게 측정 단계의 끝에서 모든 부모가 모든 자녀의 측정값을 받는다. 부모 뷰는 자녀들에게서 한 번 이상은 measure()를 호출할 수 있다. 예를 들어서, 부모는 자녀들이 얼만큼 크기를 원하는지 알아보기 위해 한 번은 불특정한 크기로 자녀를 측정할 수 있다. 그리고 나서 만약 모든 자녀들의 제한되지 않은 크기의 합이 너무 크거나 너무 작으면, 실제 숫자로 그들의 measure()를 호출한다. 

측정 단계는 크기들을 전달하기 우해  두 클래스들을 사용한다. MeasureSpect 클래스는 뷰에 의해 부모들이 얼만큼 특정되고 배치되기를 원하는지 전하기 위해 사용된다. 기본 LayoutParams 클래스는 뷰의 너미와 높이에 대해 얼마큼 큰지에 대해서만 설명한다. 각 demenstion은, 이 중에 하나만 명시한다. 

• 정확한 숫자
• MATCH_PARENT, 뷰가 (패딩을 제외하고) 부모만큼 사이즈가 크기를 원한다는 의미이다.
• WRAP_CONTENT, 뷰가 (패딩을 포함해) 단지 콘텐츠를 넣기에 충분한 사이즈이면 된다는 의미이다.

ViewGroup의 다른 하위 클래스들과는 다른 LayoutParams의 하위 클래스들이 존재한다. 예를 들어, AbsoluteLayout은 X와 Y 값을 추가한 LayoutParams의 하위 클래스이다.

 

MeasureSpec들은 부모로부터 자녀로 트리에 요구사항들을 밀어넣는데 사용된다. MeasureSpec은 세가지 모드 중 하나가 될 수 있다. 

• UNSPECIFIED : 부모가 자녀뷰의 크기를 정할 때 사용한다. 예를 들어서, LinearLayout은 높이는 UNSPECIFIED로, 너비는 EXACTLY 240으로 설정해 자녀 뷰에서 measure()를 호출해서 240 픽셀로 너비 값이 주어지면 자녀 뷰는 얼마의 높이를 갖는지 알아낼 수 있다.
• EXACTLY : 부모가 자녀 뷰에 정확한 사이즈를 지정할 때 사용한다. 자녀뷰는 이 크키를 반드시 사용해야 하고, 이 사이즈 이내에서 자녀뷰들의 모든 하위 자식들이 끼워 맞춰져야하는 것을 보장한다.
• AT_MOST : 부모가 자녀 뷰에 최대 크기를 정할 때 사용된다. 자녀뷰는 이 사이즈 이내에서 자녀뷰의 모든 하위 자식들이 끼워 맞춰져야 하는 것을 보장한다.

레이아웃을 초기화하려면, requestLayout()을 호출한다. 이 메소드는 일반적으로 현제 경계 이내에서 더이상 들어맞을 수 없다고 뷰가 믿을 때 뷰가 스스로 호출한다.

 

Drawing 그리기

그리기는 트리를 돌면서 업데이트를 원하는 어떤 뷰에든지 그리기 명령어를 기록하면 처리된다. 이후에, 전체 트리의 그리기 명령들은 화면에 실행되고 새롭게 그려진 영역들은 고정된다. 

이 트리는 대게 순서대로 기록되고 그려지는데, 부모는 본인의 자녀들보다 먼저(공간에서는 뒤 쪽에) 그려지고, 형제들은 트리에서 등장하는 순서대로 그려진다. 만약 뷰에 백그라운드 drawable을 설정한다면,  그 뷰는 본인의 onDraw() 메소드를다시 호출하기 전에 백그라운드 drawable을 그릴 것이다. 자녀의 그리기 순서는 ViewGroup의 사용자 지정 자녀 그리기 순서(custom child drawaing order)나 뷰들에서 setZ(float)로 Z 값을 사용자가 설정해서 오버라이드할 수 있다. 

뷰를 강제로 그리게 하려면, invalidate()를 호출한다.

 

이벤트 핸드링과 쓰레드 실행

뷰는 다음과 같은 기본 사이클을 가진다.

 

1. 이벤트가 밀려 들어오고, 적절한 뷰에 보내진다. 뷰는 그 이벤트를 처리하고 어떤 리스터들에게든 알려준다.

2. 만약 이벤트를 처리하는 과정에서 뷰의 경계(bounds)가 변경될 필요가 있다면, 뷰는 requestLayout()을 호출한다.

3. 비슷하게, 이벤트 처리 과정에서 뷰의 모습(appearance)이 변경될 필요가 있다면, 뷰는 invalidate()를 호출한다.

4. requestLayout()이나 invalidate() 둘 중에 하나가 호출된다면, 프레임워크는 트리를 측정하고(measuring), 설계하기(laying out), 그리기(drawing)는 것을 적적하게 처리한다.

 

주목 : 전체 뷰 트리는 단일 쓰레드로 실행된다. 어느 뷰에서든지 어떤 메소드를 호출하든지 항상 UI 쓰레드에 있어야 한다. 만약 다른 쓰레드들에서 작업하고 그 쓰레드에서 뷰의 상태를 업데이트 해야한다면, Handler를 써야 한다.

 

포커스 처리

프레임 워크는 사용자의 인풋에 반응하는 일반적인 포커스 움직임을 처리해야 한다. 이것은 뷰들이 제거되거나 사라질 때, 혹은 새로운 뷰가 사용 가능해질 때 같은 포커스의 변화도 포함한다. 뷰들은 isFocusable() 메소드를 통해 포커스를 가질 수 있는지를 보여준다. 뷰가 포커스를 가질 수 있는지 아닌지를 변경하기 위해서, setFocusable(boolean)을 호출한다. 터치 모드일 때, 뷰들은 (아래의 기록들을 보면) 뷰들은 isFocusableInTouchMode()를 통해 여전히 포커스를 가지고 싶어하는지 보여주고, setFocusableInTouchMode(boolean)을 통해 이것을 바꿀 수 있다.

 

포커스 이동은 주어진 방향으로 가장 가까운 이웃을 찾는 알고리즘을 기반으로 한다. 흔치 않은 경우에, 이 기본 알고리즘은 개발자가 의도한 행동에 맞지 않을 수도 있다. 이러한 상황에서는, layout file에서 XML 속성을 이용해 명시적으로 오버라이드할 수 있다. 

 

nextFocusDown
nextFocusLeft
nextFocusRight
nextFocusUp

 

특정 뷰가 포커스를 가지기 위해서는 requestFocus()를 호출한다.

 

터치 모드

사용자가 D-pad와 같은 방향키를 이용해 사용자 인터페이스를 돌아다니는 중에, 버튼과 같은 실행가능한 아이템에 포커스를 줘서 사용자가 무엇이 입력을 주는 볼 수 있게 하는 것은 필수적이다. 만약 장치가 터치 기능을 제공하고 사용자가 기기를 터치해서 인터페이스에 인터렉팅하기 시작한다면, 특정 뷰에 항상 강조표시를 하고, 포커스를 주는 것이 더이상 필수적이지 않다. 이것이 '터치 모드'를 이름으로 하는 인터렉션 모드의 등장 이유이다. 

 

터치가 가능한 기기들에서 사용자가 일단 스크린을 터치하면, 기기는 터치모드로 진입한다. 이 관점에서 더 나아가, 텍스트 편집 위젯들 같이 isFocusableInTouchMode()가 true인 뷰들만이 포커스를 가질 수 있다. 버튼 같이 토치가 가능한 다른 뷰들은 터치되도 포커스를 가지지 않는다. 그것들은 오직 클릭 리스너만 실행시킨다.

 

사용자가 D-pad 방향 같은 방향키를 누르는 어느 때에든지 뷰 기기는 터치모드를 나가고, 포커스를 가질 뷰를 찾는다. 그렇게 사용자는 스크린을 다시 터치하지 않고서 사용자 인터페이스와 인터렉팅을 재개한다.  

 

터치 모드 상태는 Activity들 간에 유지된다. 기기가 현재 터치 모드 상태인지 알기 위해 isInTouchMode()를 호출한다.

 

스크롤링

프레임워크는 뷰의 내용을 스크롤하기 원하는 뷰에 대해 기본적인 지원을 제공한다. 스크롤바를 그려주는 메커니즘 뿐만이 아니라 X와 Y 스크롤 오프셋을 추적하는 것들이 있다 scrollBy(int, int), scrollTo(int, int), awakenScrollBars()로 더 상세한 것들이 있다.

 

태그

ID와는 다르게, 태그는 뷰의 식별을 위해서 사용되지는 않는다. 태그는 본질적으로 뷰에 할달될 수 있는 추가적인 정보 조각이다. 태그는 뷰와 관련된 정보들을 분리된 구조에 저장하는 것보다 뷰 자체에 저장하는 편의성 때문에 자주 사용된다.

 

태그는 레이아웃 XML에서 문자열 값이나, android:tag 속성을 써서 하나의 태그나 <tag> 자녀 요소를 사용해 여러 개의 태그들로 명시될 수 있다.

 

<View ..
    android:tag="@string/mytag_value" />
<View ...>
    <tag android:id="@+id/mytag"
         android:value="@string/mytag_value" />
</View>

태그는 setTag(java.lang.Object) 또는 setTag(int, java.lang.Object)를 사용해 임의의 오브젝트로 코드에서 명시될 수 있다.

 

테마

일반적으로, 뷰들은 그들의 생성자에서 제공된 Context 객체의 테마를 이용해 생성된다. 그러나, 레이아웃 XML에서 android:theme 속성을 이용하거나 코드에서 ContextThemeWrapper를 생성하에 보내서 다른 테마를 명시할 수 있다.

 

android:theme 속성은 XML에서 사용되고, 명시된 테마는 inflation context의 테마(LayoutInflater를 보라)에 최상단에 적용되거나 다른 자녀 요소들뿐만이 아니라 뷰 자체에 사용된다.

 

다음의 예시에서, 두 뷰들 모두 Materail dark color 스키마를 이용해 생성될 것이다. 그러나, 오버레이 테마가 속성들의 하위 집합만 정의하고 있기 때문에 inflation context의 테마(e.g. Activity 테마)에서 정의된 android:colorAccent 값은 유지된다. 

 

<LinearLayout
        ...
        android:theme="@android:theme/ThemeOverlay.Material.Dark">
    <View ...>
</LinearLayout>

 

속성들

뷰 클래스는 TRNASLATION_X와 TRANSLATION_Y와 같이 여러 변환과 관련된 속성들 뿐만이 아니라 ALPHA 속성을 가진다.이 속성들은 비슷하게 이름을 가진 setter/getter 메소드(ALPHA에 대해서는 setAlpha(float)) 뿐만이 아니라 Property  형식에서 둘다 가능하다. 이 속성들은 지속적인 상태를 설정하기 위해서 뷰에서 렌더링과 관련된 속성들과 사용될 수 있다. 이 속성들과 메소드들은 또한 Animator를 기반으로 한 애니메이션들과 함께 사용될 수 있고, 자세한 것은 Animation 섹션에 있다.

 

애니메이션

 안드로이드 3.0을 시작하면서, 뷰에 애니메이션을 주는 선호되는 방법은 android.animation 패키지의 API들을 사용하는 것이다. 이 Animator 기반 클래스들은 뷰 객체의 실제로 alpha와 translationX같은 속성 값들을 바꾼다. 이 동작은 3.0 이전의 Animation 기반의 클래스들의 동작과 대조되고, 대신에 디스플레이에 뷰를 어떻게 그리는 지를 애니메이션으로 만든다. 특히, ViewPropertyAnimator 클래스는 특히 쉽고 효율적으로 뷰 속성들을 애니메이션으로 만들어준다.  

 

그 대신에, 어떻게 뷰가 렌더링되는지 애니메이션을 주고자하면 3.0 이전 애니메이션 클래스들을 사용할 수 있다. Animation 객체를 setAnimation(android.view.animation.Animation) 또는 startAnimation(android.view.animation.Animation)을 사용해서 뷰에 attach 할 수 있다. 애니메이션은 시간이 지나면서 뷰의 스케일, 회전 변환과 알파를 고칠 수 있다. 만약 애니메이션이 자식이 있는 뷰에 attach됐다면, 그 애니메이션은 노드에 의해 고정된 하위 트리 전체에 영향을 준다. 애니메이션이 시작할 때 프레임워크는 애니메이션이 끝날 때까지 적당한 뷰를 다시 그리는 것을 처리할 것이다.

 

보안

때때로 애플리케이션이 사용자의 충분한 정보와 동의를 가지고 권한 요청을 허락하거나 구매를 진행하거나 광고를 클릭하는 것과 같은 동작이 잘 수행되는 지를 확인하는 것이 필요합니다. 불행히도, 악의적인 애플리케이션은 뷰의 의도된 목적을 숨셔거 사용자를 속여 자신도 모르게 이 작업들을 진행하려고 시도합니다. 해결책으로, 프레임워크는 민감한 기능에 접근하는 것을 제공하는 뷰의 보안을 향상시키는데 쓰일 수 있는 터치 필터링 메커니즘을 제공합니다. 

 

터치 필터링을 제공하기 위해서, setFilterTouchesWhenObscured(boolean)을 호출하거나  android:filterTouchesWhenObscured layout 속성을 true로 설정한다. 가능할 때, 프레임워크는 뷰의 윈도우가 터치된 위치에 다른 보이는 윈도우에 의해 잘 보이지 않을 때마다 입력된 터치를 버릴 것이다. 결과적으로, 뷰는 터치가 토스트, 다이얼로그나 다른 윈도우를 뚫고 오는 언제든지 터치를 받지 않을 것이다.

 

보안에 대해 더 세밀한 제어를 위해서는, 고유 보안 정책을 구현하기 위해서 onFilterTouchEventForSecurity(android.view.MotionEvent) 메소드를 오버라이드하는 것을 고려하라. MotionEvent#FLAG_WINDOW_IS_OBSCURED 또한 확인하라.