Fragment

GraphQL의 fragment 앞선 글들에서 사용되었던 방법으로는 GraphQL의 특정 블록들을 여러 번 재사용해야 하는 블록의 경우 매번 중복해서 써야한다. 예를 들어 다음 두개 Query들이 있다고 해보자. query QueryFilm1 { film(filmID: 1) { title director producers } } query QueryFilm2 { film(filmID: 2) { title director producers } } 위 쿼리들에서는 title, director, producers들이 중복해서 사용된다. 이 필드들을 하나로 묶어 하나의 필드처럼 쓸 수 있다면 중복을 줄일 수 있을 것이다. GraphQL의 fragment가 바로 이 역할을 한다. GraphQL의 fragment는..

지금까지는 하나의 컴포넌트만 사용하였다. 하지만, 안드로이드 프레임워크 같은 곳에서는 여러 컴포넌트들 간에 의존 관계가 필수적이다. 어플리케이션은 여러 액티비티(Activity)를 포함하며, 각 액티비티는 여러 프레그먼트(Fragment)를 포함할 수 있다. 즉, 각 Component들은 의존 관계가 생긴다. 따라서 의존 관계가 있는 컴포넌트는 상위 컴포넌트에 대한 참조를 포함해야 한다. Dagger2에서는 이를 위해 모듈에 포함할 수 있고, 상위 프로바이더를 사용할 수 있는 서프컴포넌트를 제공한다. 서브 컴포넌트(SubComponent) 서브 컴포넌트란 어떤 컴포넌트의 하위에 포함되는 컴포넌트를 뜻한다. 정확히는 모듈 내부에 포함되는데, 이를 통해 해당 서브컴포넌트는 부모 모듈과 컴포넌트의 프로바이더를..

목표 ViewModel을 이용하여 Fragment간에 데이터를 공유하는 방법을 안다. ViewModel의 생성 방식 ViewModel은 View(Activity 혹은 Fragment)의 Lifecycle에 Dependent한 Lifecycle을 갖는다. ViewModel 속 데이터가 살아있는 기간이 View가 살아있는 기간보다 길기 때문에 View가 살아 있는 동안은 ViewModel 속 데이터는 유지된다. 그런데 Fragment에는 조금 특이한 성질이 있다. 바로 Fragment의 생명주기는 Fragment가 붙어 있는 Activity에 Dependent한 성질이다. 이러한 성질로 인해 과 같이 하나의 Activity에는 여러 개의 Fragment가 존재할 수 있으며, 각 Fragment는 각자의 생명..

목표 ViewModel이 만들어진 이유를 이해한다. ViewModel이 필요한 이유 Android는 모바일 OS 특성상 리소스에 대한 제약이 많은 OS이다. 모바일 OS에서는 리소스를 제거해야만 하게 만드는 제어될 수 없는 이벤트가 발생하게 되는데, Android 프레임워크는 이러한 이벤트가 발생했을 때 Activity와 Fragment 같은 UI 컨트롤러에 대한 제거와 복구를 수행한다. 예를 들어 화면 회전이 이루어진다고 하자. 화면 회전이 이루어지게 되면 Activity가 파괴(onDestroy)된 다음 다시 화면이 만들어지면서(onStart) 복구 로직이(onRestoreInstanceState) 수행된다. Lifecycle에 관한 내용을 모른다면 아래(kotlinworld.com/46) 글을 참조..

목표 생성자가 무엇이고, 생성자 오버로드가 무엇인지 이해한다. Fragment의 생성자 오버로드를 하지 말아야 하는 이유에 대해 이해한다. 생성자란? 생성자란 객체의 인스턴스를 생성할 때 호출되어 객체의 인스턴스를 반환하는 메서드를 뜻한다. 예를 들어 아래와 같은 클래스가 있다고 해보자 class GalaxyTab(name: String, size: Int) GalaxyTab 객체의 인스턴스는 다음의 방식으로 만들어낼 수 있다. val tabS7 = GalaxyTab("S7", 11) 우리는 GalaxyTab(name : String, size: Int)을 생성자라고 부른다. 생성자 오버로드란? 생성자 오버로드란 class의 생성자를 두 개 이상 가지는 것을 뜻한다. Kotlin에서는 constructo..