AW203: GridLayout, 안드로이드 컴포넌트 이름의 역사 등

by Realm Korea

May 18 2016

아카데미로 돌아가기

Android Weekly는 매주 발행되는 안드로이드 뉴스레터입니다. 영어 기사를 정독할 시간이 없는 분을 위해 핵심 꼭지를 요약했습니다.

주간 안드로이드 뉴스를 요약해 드립니다. Android Weekly 203 원문도 읽어보세요.

Grid Layout 사용해보기

어떤 레이아웃을 사용할까는 항상 안드로이드 개발자들에게 고민일 겁니다. GridLayout이 출시된지는 조금 지났는데요, 이에 대한 개발자들의 반응은 아래 중 하나가 아닐까요.

GridLayout이 있는지도 모른다.
GridLayout이 있는 것은 알지만 어떤 이유에서든 사용하지는 않는다.
GridLayout에 시간을 투자해 적극적으로 활용한다. (아마 소수 개발자들이..) 위 상황 중 3번이 아니시라면 안드로이드 그리드 레이아웃 (Android Grid Layout) 내용을 참고하세요.

왜 Grid Layout이 필요한가

GridLayout은 하나의 루트 뷰로 격자 레이아웃을 생성해줍니다. 성능문제를 생각하면 LinearLayout을 네스트하는 방법은 적절하지 않습니다. 또한 RelativeLayout으로 격자 레이아웃을 만드는 것은 다음과 같은 문제가 있습니다.
↓ 두 개 축에 대해 동시에 alignment를 통제하기 어려움

↓ 여러줄의 텍스트는 오버랩되는 문제 발생

↓ 위 문제를 해결하기 위해 우리는 GridLayout을 사용합니다.

Grid Layout 사용시 주의점

루트 뷰로 GridLayout을 선언하고 android:columnCount속성을 지정
만약 하나의 row 또는 column 크기가 아니라 더 큰 사이즈를 할당하고 싶다면 layout_columnSpan, layout_rowSpan attribute를 지정
뷰가 사용가능한 모든 공간을 사용할 수 있도록 하려면 width=”0dp”, layout_gravity=”fill” 로 지정 (match_parent아님!)

이런 개발 뉴스를 더 만나보세요

GridLayout의 장단점

-장점: 유연성과 하나의 루트 레이아웃 -단점: 학습이 필요함과 유지보수

안드로이드 컴포넌트 의미 파악하기: Process, Thread, Application, Activity, Task, Fragment, Context 제대로 알기

혹시 AsyncTasks가 lifecycle과 밀접히 묶여 있지 않다는 것이 문제가 된다고 생각하시나요? 그렇다면 지금 소개하는 글을 주목해보세요! 이건 문제가 아닙니다. 단지 그 특성이 그럴 뿐이죠.

다시금 기초를 짚고 넘어 갈 수 있는 좋은 글 소개해드립니다! 안드로이드 네이밍 컨벤션 이해하기 (Understanding Android Naming Conventions)에서 저자는 Robert Martin의 Clean Code를 다시 읽고 대표적인 안드로이드 컴포넌트에 대한 아주 기초적인 정보를 정리하고 있습니다. 꼼꼼히 살펴보시고 혹시 잘못 알고있던 부분이 있다면 수정하는 기회가 되었으면 좋겠습니다.

프로세스 (Process) 프로세스는 일반적인 컴퓨팅 프로세스를 의마합니다.
- 사용자나 개발자가 고려하는 것이라기 보다는 컴퓨터가 처리해주는 것
- 안드로이드에서 각각의 어플리케이션은 고유한 Linux 프로세스로 시작함
- 다섯가지 프로세스 상태: foreground, visible, service, background, empty
- 결국 프로세스는 시스템이 메모리가 필요하다면 프로세스를 죽이는 등 일련의 명령셋과 메모리 공간과 같은 의미로 이해 가능
태스크 (Task) 안드로이드 디바이스가 풀어야 할 기본 문제는 바로 사용자들이 어떤 작업을 하도록 도와주는 것입니다. 이게 바로 태스크입니다. 일상적 비유를 하자면 태스크는 청소하기, 출근하기, 쇼핑하기 등 사용자 중심 용어로써 특정 목표 수행이라는 공통 주제를 가지고 있습니다.
- 사용자는 런처 아이콘을 클릭해 태스크를 시작
- 최근 작업 목록에서 여러 태스크를 볼 수 있고 전환하거나 끝낼 수 있음
- 한 시점에는 하나의 작업만 할 수 있음
액티비티 (Activity) 하나의 태스크는 하나 이상의 액티비티로 구성됩니다. 예컨대 집 청소라는 태스크에는 빨래를 접는 것, 빨래 접기가 끝나면 화장실 청소를 시작하는 것 등이 각각의 액티비티로 포함될 것입니다.
- 액티비티 역시 한 시점에는 하나의 액티비티만 수행 가능: 한 번에 하나의 액티비티와 인터렉션
- 사용자 측면의 개념으로 사용자가 수행하는 것 의미
- 액티비티 간 이동시 그 전 액티비티가 무엇인지 기억하고 다시 백스택으로 돌릴 수 있음
- 사용자에게 어떤 것들을 보여주고 사용자의 입력에 응답해야 하는 책임
- 화면 뒤 조작들 예를 들어 DB 읽거나 쓰기, 웹 요청 처리, 긴 시간이 소요되는 계산 등과 관련되어서는 안됨: 단 configuration change와 같이 사용자에게 직접적인 영향을 미치는 변화는 예외
프래그먼트 (Fragment) 액티비티의 일부 조각을 만약 “subactivity”, “component”, “part”등의 이름을 붙인다면 어떨까요. Martin이 주장하듯 의도하는 내용과 다른, 이미 익숙해진 널리 사용되는 용어들은 피해야 합니다. 모호함이나 오해를 불러일으킬 수 있는 것을 방지해야 하기 때문이죠. 아마도 이런 이유에서 초기 개발자들이 가장 이름 붙이기 어려웠지 싶은 것이 바로 이 fragment입니다.
- 액티비티가 너무 커서 쪼개야 할 필요에 의해 탄생
- 액티비티처럼 프래그먼트도 어떤 작업 수행을 도움(액티비티보다 더 작은 스케일): 예컨대 화장실과 부엌 청소라는 각각의 액티비티는 모두 청소도구 가져오기라는 작은 작업으로부터 시작할 수 있습니다.
- 액티비티의 내용과는 별도로 재사용이 가능한 부분
- 한 태스크를 종료하거나 태스크 내의 한 액티비티를 종료한다면 프래그먼트도 함께 종료됨
- 액티비티는 0개 이상의 프래그먼트를 가질 수 있음
- 두 개의 액티비티가 같은 프래그먼트에 대한 독립된 인스턴스를 가질 수 있음
- 프래그먼트 사이즈가 작고 연관되어 있다면 master/detail 디자인 패턴 이용 가능
- 개발자의 선택에 따라 백버튼으로 이전 프래그먼트로 돌아갈 수 있음
- 액티비티처럼 프래그먼트에서도 비동기작업을 시작해서는 안됨
쓰레드 (Thread) 프로세스와 마찬가지로 쓰레드도 기초 컴퓨터과학 개념입니다. 안드로이드는 Java의 쓰레드를 따르고 있어 안드로이드의 대부분 쓰레드는 Java 쓰레드입니다. 편리하게 HandlerThread를 만들기 위해 한 번 subclass인 Thread를 사용하면 됩니다.
- 쓰레드를 사용하는 것은 한 번에 여러가지 일을 하도록 하는 한 방법
- 하나의 프로세스 내에 여러 쓰레스 인스턴스가 존재할 수 있음
- 사용자는 어떤 쓰레드에서 어떤 일이 일어나는지, 몇 개의 쓰레드가 동작하는지 전혀 알 필요가 없음
- 개발자는 쓰레드를 단지 컴퓨터와 소통하는 방법으로 여기고 좀 더 빨리 작업할 수 있도록 요청 가능
- 쓰레드는 사람 차원이 아닌 컴퓨터 차원의 메모리 접근 등 컴퓨터 중심 개념으로 상대적으로 어렵게 느낄 수 있음
“메인쓰레드 또는 UI쓰레드”
- 쓰레드 중 메인쓰레드 또는 UI쓰레드라고 하는 것은 사용자와 커뮤니케이션하는 책임이 있음
- 메인쓰레드에서 화면 뒤 조작들(필요하다면 HandlerThread를 통해 수행)을 해선 안됨
- 모든 액티비티는 이 쓰레드에 살아가면서 수행되어야 함
- 각 앱은 하나의 쓰레드에서 시작해 개발자의 결정에 따라 여러 쓰레스를 가질 수 있음
어플리케이션 (Application) 어플리케이션 역시 컴퓨터 과학 기본 개념이고, 소프트웨어의 한 종류로써 사용자가 어떤 태스크를 수행하는 것을 돕습니다. 수퍼마켓에 비유하자면 사람들(사용자)은 직접 물건을 고르고 구매하지만 동시에 이것이 가능하도록 수퍼마켓 뒤편(소매점이나 회계사무실)에서도 작업은 수행되고 있습니다.
- 어플리케이션은 기본적으로 개발자가 사용자의 태스크 수행을 위해 작성한 전체 코드 묶음
- 만약 카메라 어플리케이션 사용 중 사진을 첨부해 이메일을 보내려면 카메라와 이메일 어플리케이션이 같은 태스크에 존재
- 새로운 태스크를 시작하는 것은 새로운 액티비티를 시작한다는 것이고 안드로이드는 어플리케이션을 시작하게 됨
- 일반적으로 개발자는 여러 액티비티를 포함하는 하나의 어플리케이션을 만들고, 사용자가 모든 액티비티를 다 수행했다면 안드로이드는 그 어플리케이션을 닫고 종료시킴
- 만약 사용자가 이메일 어플리케이션 사용 중 종료한다면 시스템은 이메일 어플리케이션 안의 액티비티를 멈춤
- 종료 대신 잠시 멈추었다가 다시 시작하면 시스템은 즉이 이메일 어플리케이션의 액티비티를 재실행
- 위 상황에 추가해 사용자가 직접 이메일 어플리케이션을 실행하면 시스템은 새로운 태스크를 시작
- 이전 카메라 어플리케이션에서 시작했던 이메일 어플리케이션의 액티비티는 새로 시작하는 이메일 어플리케이션의 액티비티들과는 전혀 영향을 주고받지 않음
- 즉, 같은 액티비티지만 두개의 다른 태스크에 각 각 별도로 인스턴스가 존재
- 어플리케이션은 사용자가 액티비티와 상호작용하지 않는 상황에서도 존재할 수 있음(액티비티 없이 뒤에서 작업)
컨텍스트 (Context) 컨텍스트는 OS로 들어가는 손집이와 같습니다. 왜냐하면 시스템이 액티비티를 시작시키기때문에 여러분은 컨텍스트를 사용해 액티비티를 실행해달라고 요청하기 때문이죠. 화면을 그리는 것(inflate), 브로드캐스트 보내기 등도 그렇게 요청해야 함니다. (컨텍스트와 관련된 더 자세한 심도있는 정보를 원하신다면 Dave Smith의 Context의 종류를 참고하세요.)
- 시스템은 우리가 어플리케이션 안이 어떤 액티비티에서 작업중인지 알 수 없습
- 따라서 그냥 레이아웃을 그려달라고 요청하는 것이 아니라 어떤 컨텍스트에서 작업을 요청하는지 정보를 주어야 함(이게 바로 컨텍스트!)
- 컨텍스트에는 여러 서브클래스들이 있으며 대표적인 것이 어플리케이션, 액티비티, 서비스
- 어플리케이션, 액티비티 서비스 등 컨첵스트는 시스템에 무언가를 요청할 때 각각 다른 컨텍스트 내용을 다룸
- 컨텍스트는 일시적이고 계속 변화하는 특징
- 따라서 컨텍스트를 파라미터로 전달하는 것을 피할 것!
- 라이프사이클에 의해 액티비티가 종료되면 컨텍스트는 가비지컬렉트처리 되지 않아 메모리 누수 문제 발생 가능

public void doSomething(Context context) {
    // 누군가 보낸 컨텍스트가 여러분의 필요에 맞는 컨텍스트라고 섣불리 가정하지 마세요
    // mContext = context; 

    // ... 대신 ApplicationContext를 사용하세요~
    mContext = context.getApplicationContext(); 
    ...
}

정리 Y라는 작업을 하기 위해 X를 어떻게 사용하는지 묻기 전에 X가 Y를 해야 하는가?에 대한 생각 해보세요. 각 컴포넌트의 이름으로부터 고유 의미와 책임을 생각해볼 수 있습니다.
- 솔루션 도메인 용어: 프로세스, 쓰레드, 어플리케이션 (개발자라면 이해할 수 있는 용어들..)
- 문제(problem) 도메인 용어: 태스크, 액티비티, 컨텍스트, 프래그먼트 (일상 생활 비유에서 사용할 수 있는 용어들)

오픈소스 라이브러리

Agera Agera는 기능적인, 비동기 리액티브 어플리케이션 개발을 위한 클래스와 인터페이스를 제공합니다. SDK 버전 9이상을 지원합니다.
Flaggr-android 컨텍스트에 대해 어떤 작업을 보다 편리하게 할 수 있게 해주는 라이브러리입니다.
RxDrive Google Drive Android API에 대한 RxJava 래퍼를 제공합니다. 일일이 콜백을 구현하지 않고 편리하게 사용해보세요.