Data Binding을 통해 객체, 필드 또는 컬렉션을 식별 가능하게 만들 수 있습니다.

식별 가능성 객체가 데이터 변경에 관해 다른 객체에 알릴 수 있는 기능

Data Binding을 사용하면 데이터 변경 시 리스너에 알리는 기능을 데이터 객체에 제공할 수 있는데, 이를 통해 UI를 자동으로 업데이트할 수 있습니다.

식별 가능한 필드

필드는 일반 Observable 클래스 및 Observable Primitive 클래스를 사용하여 식별 가능하게 만들 수 있습니다.

식별 가능한 필드는 단일 필드가 있는 독립적 객체입니다. Primitive 버전은 액세스 작업 중에 박싱 및 언박싱을 방지해야 하기 때문에 읽기 전용 속성으로 만들어야 합니다.

class User {
    val firstName = ObservableField<String>()
    val lastName = ObservableField<String>()
    val age = ObservableInt()
}

식별 가능한 컬렉션

식별 가능한 컬렉션은 키를 통해 접근할 수 있습니다.

키가 참조 유형일 때는 ObservableArrayMap 클래스가 유용합니다.

ObservableArrayMap<String, Any>().apply {
    put("firstName", "Google")
    put("lastName", "Inc.")
    put("age", 17)
}    

<data>
    <import type="android.databinding.ObservableMap" />
    <variable name="user" type="ObservableMap<String, Object>" />
</data>

<TextView
    android:text="@{user['lastName']}"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" />

키가 정수일 때는 ObsevableArrayList 클래스가 유용합니다.

ObservableArrayList<Any>().apply {
    add("Google")
    add("Inc.")
    add(17)
} 

<data>
    <import type="android.databinding.ObservableList"/>
    <import type="com.example.my.app.Fields"/>
    <variable name="user" type="ObservableList<Object>"/>
</data>

<TextView
    android:text='@{String.valueOf(1 + (Integer)user[Fields.AGE])}'
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"/>

식별 가능한 객체

Observable 인터페이스를 구현하면 식별 가능한 객체의 변경에 관한 알림을 받는 리스너를 등록할 수 있습니다.

Data Binding 라이브러리는 리스너 등록 메커니즘을 구현하는 BaseObservable 클래스를 제공합니다.

class User : BaseObservable() {

    @get:Bindable
    var firstName: String = ""
        set(value) {
            field = value
            notifyPropertyChanged(BR.firstName)
        }

    @get:Bindable
    var lastName: String = ""
        set(value) {
            field = value
            notifyPropertyChanged(BR.lastName)
        }
}

Data Binding은 데이터 바인딩에 사용된 리소스의 ID를 포함하는 모듈 패키지에 이름이 BR인 클래스를 생성합니다. Bindable 주석은 컴파일하는 동안 BR 클래스 파일에 항목을 생성합니다.

📌 바인딩 어댑터

바인딩 어댑터는 적절한 프레임워크를 호출하여 값을 설정하는 작업을 담당합니다.

속성 값 설정

결합된 값이 변경될 때마다 생성된 결합 클래스는 결합 표현식을 사용하여 속성 값을 설정해야 합니다.

자동 메서드 선택

라이브러리는 속성의 이름과 타입을 토대로 관련된 setter 메서드를 찾습니다. 예를 들어 android:text="@{user.name}" 표현식이 있는 경우 라이브러리는 user.getName()에서 반환한 타입을 허용하는 setText(arg) 메서드를 찾습니다.

맞춤 메서드 이름 지정

일부 속성에는 이름이 일치하지 않는 setter가 있습니다. 이러한 상황에서 속성은 BindingMethods 주석을 사용하여 setter와 연결될 수도 있습니다. 주석은 클래스와 함께 사용되며 이름이 바뀐 각 메서드에 하나씩 여러 BindingMethod 주석을 포함할 수 있습니다.

@BindingMethods(value = [
    BindingMethod(
        type = android.widget.ImageView::class,
        attribute = "android:tint",
        method = "setImageTintList")])

위 예에서 android:tint 속성은 setTint() 메서드가 아닌 setImageTintList(ColorStateList) 메서드와 연결됩니다.

맞춤 로직 제공

일부 속성에는 맞춤 결합 로직이 필요합니다. BindingAdapter 주석이 있는 정적 바인딩 어댑터 메서드를 사용하면 속성의 setter가 호출되는 방식을 맞춤설정할 수 있습니다.

@BindingAdapter("android:paddingLeft")
fun setPaddingLeft(view: View, padding: Int) {
    view.setPadding(padding,
                view.getPaddingTop(),
                view.getPaddingRight(),
                view.getPaddingBottom())
}

바인딩 어댑터 메서드에서 첫 번째 매개변수는 속성과 연결된 뷰의 타입을 결정합니다. 두 번째 매개변수는 지정된 속성의 결합 표현식에서 허용되는 타입을 결정합니다.

개발자가 정의하는 바인딩 어댑터는 충돌이 발생하면 Android 프레임워크에서 제공하는 기본 어댑터보다 우선 적용됩니다.

여러 속성을 받는 어댑터도 있을 수 있습니다.

@BindingAdapter("imageUrl", "error")
fun loadImage(view: ImageView, url: String, error: Drawable) {
    Picasso.get().load(url).error(error).into(view)
}

속성이 하나라도 설정될 때 어댑터가 호출되도록 하려면 다음 예에서와 같이 어댑터의 선택적 requireAll 플래그를 false로 설정할 수 있습니다.

@BindingAdapter(value = ["imageUrl", "placeholder"], requireAll = false)
fun setImageUrl(imageView: ImageView, url: String?, placeHolder: Drawable?) {
    if (url == null) {
        imageView.setImageDrawable(placeholder);
    } else {
        MyImageLoader.loadInto(imageView, url, placeholder);
    }
}

바인딩 어댑터 메서드는 선택적으로 핸들러의 이전 값을 사용할 수 있습니다. 이전 값과 새 값을 사용하는 메서드는 아래 예에서와 같이 속성의 모든 이전 값을 먼저 선언한 후 새 값을 선언해야 합니다.

    @BindingAdapter("android:paddingLeft")
    fun setPaddingLeft(view: View, oldPadding: Int, newPadding: Int) {
        if (oldPadding != newPadding) {
            view.setPadding(padding,
                        view.getPaddingTop(),
                        view.getPaddingRight(),
                        view.getPaddingBottom())
        }
    }

이벤트 핸들러는 다음 예에서와 같이 하나의 추상 메서드가 있는 인터페이스 또는 추상 클래스에서만 사용할 수 있습니다.

@BindingAdapter("android:onLayoutChange")
fun setOnLayoutChangeListener(
        view: View,
        oldValue: View.OnLayoutChangeListener?,
        newValue: View.OnLayoutChangeListener?
) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        if (oldValue != null) {
                view.removeOnLayoutChangeListener(oldValue)
        }
        if (newValue != null) {
            view.addOnLayoutChangeListener(newValue)
        }
    }
}

Reference

• Android Developers - DataBinding

Data Binding은 UI 구성요소와 앱의 데이터 소스를 선언적으로 연결할 수 있게 하는 라이브러리입니다.

레이아웃 파일에서 UI 구성요소를 앱 데이터와 연결하면 액티비티에서 UI 프레임워크의 호출을 줄일 수 있어서 코드가 간결해지고 유지관리가 쉬워진다는 장점이 있습니다. 또한 앱 성능이 향상되며, 메모리 누수 및 Null Pointer 예외를 방지할 수 있습니다.

레이아웃 파일

Data Binding 라이브러리는 레이아웃의 뷰를 데이터 객체와 결합하는데 필요한 클래스를 자동으로 생성합니다.

레이아웃 파일 작성

Data Binding을 사용하는 레이아웃 파일은 layout이라는 루트 태그로 시작하고 그 안에 해당 레이아웃에서 사용할 데이터를 data 태그를 통해 명시합니다. 그런 다음 레이아웃을 구성할 뷰들을 배치합니다.

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android">
   <data>
       <variable name="user" type="com.example.User"/>
   </data>
   <LinearLayout
       android:orientation="vertical"
       android:layout_width="match_parent"
       android:layout_height="match_parent">
       <TextView 
           android:layout_width="wrap_content"
           android:layout_height="wrap_content"
           android:text="@{user.firstName}"/>
       <TextView 
           android:layout_width="wrap_content"
           android:layout_height="wrap_content"
           android:text="@{user.lastName}"/>
   </LinearLayout>
</layout>

앱의 데이터는 @{} 구문을 통해 뷰의 특정 속성에 지정됩니다.

표현식

@{} 표현식에는 this, super, new, 명시적 제네릭 호출을 제외한 여러 연산자와 키워드를 사용할 수 있습니다.

<TextView
    android:text="@{String.valueOf(index + 1)}"
    android:visibility="@{age > 13 ? View.GONE : View.VISIBLE}" />

또한 표현식에는 Null 병합 연산자를 사용할 수 있습니다.

<TextView
    android:text="@{user.displayName ?? user.lastName}" />

Null 병합 연산자 왼쪽 피연산자가 NULL이 아니면 왼쪽 피연산자를 선택, NULL이면 오른쪽 피연산자를 선택

표현식은 ID를 통해 레이아웃의 다른 뷰를 참조할 수도 있습니다.

<EditText
    android:id="@+id/example_text"
    android:layout_height="wrap_content"
    android:layout_width="match_parent"/>
<TextView
    android:id="@+id/example_output"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@{exampleText.text}"/> 

데이터 결합

Data Binding도 각 레이아웃 파일의 바인딩 클래스를 생성하는데요, 이 클래스는 View Binding처럼 레이아웃 파일 이름을 파스칼 표기법으로 변환한 뒤, Binding이라는 접미사를 추가한 이름을 갖습니다.

이 바인딩 클래스에는 레이아웃 속성(데이터 변수 등)에서부터 레이아웃 뷰까지 모든 바인딩을 갖고 있으며, 어떻게 바인딩 표현식의 값을 할당할지도 알고 있습니다.

바인딩 객체 생성 방법

권장되는 결합 생성 방법은 레이아웃이 inflating을 하는 동안에 생성하는 것입니다.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    val binding: ActivityMainBinding = DataBindingUtil.setContentView(
            this, R.layout.activity_main)

    binding.user = User("Test", "User")
}

다른 방법으로는 LayoutInflater를 이용하는 것이 있습니다.

val binding: ActivityMainBinding = ActivityMainBinding.inflate(getLayoutInflater())    

Fragment, ListView, RecyclerView 어댑터 내에서 Data Binding을 사용한다면 inflate() 메서드를 사용하여 바인딩 객체를 생성할 수 있습니다.

val listItemBinding = ListItemBinding.inflate(layoutInflater, viewGroup, false)
// or
val listItemBinding = DataBindingUtil.inflate(layoutInflater, R.layout.list_item, viewGroup, false)

이벤트 처리

Data Binding을 사용하면 뷰에서 전달되는 표현식 처리 이벤트를 작성할 수 있습니다. 이벤트 속성의 이름은 대부분 리스너 메서드의 이름에 따라 결정됩니다.

메서드 참조

Data Binding에서 표현식이 메서드 참조로 계산되면 리스너에서 메서드 참조 및 소유자 객체를 래핑하고, 타겟 뷰에서 이 리스너를 설정합니다.

이벤트는 android:onClick이 액티비티의 메서드에 할당되는 방식과 유사하게 핸들러 메서드에 직접 결합될 수 있는데요, Data Binding의 메서드 참조는 표현식이 컴파일 타임에 처리된다는 장점이 있습니다.

class MyHandlers {
    fun onClickFriend(view: View) { ... }
}

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android">
   <data>
       <variable name="handlers" type="com.example.MyHandlers" />
       <variable name="user" type="com.example.User" />
   </data>
   <LinearLayout
       android:orientation="vertical"
       android:layout_width="match_parent"
       android:layout_height="match_parent">
       <TextView
           android:layout_width="wrap_content"
           android:layout_height="wrap_content"
           android:text="@{user.firstName}"
           android:onClick="@{handlers::onClickFriend}" />
   </LinearLayout>
</layout>

메서드의 매개변수는 이벤트 리스너의 매개변수와 일치해야 합니다.

메서드 참조이 리스너 결합과 다른 점은 실제 리스너 구현이 이벤트가 트리거될 때가 아닌, 데이터가 결합될 때 생성된다는 것입니다. 따라서 이벤트가 발생할 때 표현식을 계산하려면 리스너 결합을 사용해야 합니다.

리스너 결합

리스너 결합은 메서드 참조와 달리 이벤트가 발생할 때 실행되는 결합 표현식이며, 메서드와 이벤트 리스너의 반환 값만 일치하면 됩니다.

class Presenter {
    fun onSaveClick(task: Task){}
}

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android">
    <data>
        <variable name="task" type="com.android.example.Task" />
        <variable name="presenter" type="com.android.example.Presenter" />
    </data>
    <LinearLayout 
        android:layout_width="match_parent" 
        android:layout_height="match_parent">
        <Button
            android:layout_width="wrap_content" android:layout_height="wrap_content"
            android:onClick="@{() -> presenter.onSaveClick(task)}" />
    </LinearLayout>
</layout>

표현식에 콜백을 사용하면 데이터 결합은 필요한 리스너를 자동으로 생성하여 이벤트에 등록합니다.

리스너 결합에서는 모든 매개변수를 무시하거나, 모든 매개변수의 이름을 지정하여 매개변수를 선택할 수 있습니다. 매개변수 이름을 지정하면 표현식에 매개변수를 사용할 수 있습니다.

<Button
    android:layout_width="wrap_content" android:layout_height="wrap_content"
    android:onClick="@{(theView) -> presenter.onSaveClick(theView, task)}" />

class Presenter {
    fun onSaveClick(view: View, task: Task){}
}

import, variable, include

• import를 사용하면 레이아웃 파일 내에서 클래스를 참조할 수 있습니다.
• variable을 사용하면 결합 표현식에 사용할 수 있는 속성을 설명할 수 있습니다.
• include를 사용하면 앱 전체에서 복잡한 레이아웃을 재사용할 수 있습니다.

import

data 태그 내에 0개 이상의 import 요소를 사용할 수 있습니다.

<data>
    <import type="android.view.View" />
</data>

<TextView
   android:text="@{user.lastName}"
   android:layout_width="wrap_content"
   android:layout_height="wrap_content"
   android:visibility="@{user.isAdult ? View.VISIBLE : View.GONE}" />

이처럼 import를 통해 클래스를 가져오면 표현식에서 해당 클래스를 참조할 수 있습니다.

별칭을 사용하여 클래스 이름 충돌을 해결할 수 있습니다.

<import type="android.view.View"/>
<import type="com.example.real.estate.View"
        alias="Vista"/>

가져온 클래스는 변수 및 표현식에서 유형 참조로 사용할 수도 있습니다

<data>
    <import type="com.example.User" />
    <import type="java.util.List" />
    <variable name="user" type="User" />
    <variable name="userList" type="List&lt;User>" />
</data>

형변환 또한 가능합니다.

<TextView
   android:text="@{((User)(user.connection)).lastName}"
   android:layout_width="wrap_content"
   android:layout_height="wrap_content" />

variable

data 태그 내에 여러 variable 요소를 사용할 수 있습니다.

<data>
    <import type="android.graphics.drawable.Drawable"/>
    <variable name="user" type="com.example.User"/>
    <variable name="image" type="Drawable"/>
    <variable name="note" type="String"/>
</data>

include

속성에 앱 네임스페이스 및 변수 이름을 사용함으로써 포함하는 레이아웃에서 포함된 레이아웃의 결합으로 변수를 전달할 수 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
       xmlns:bind="http://schemas.android.com/apk/res-auto">
   <data>
       <variable name="user" type="com.example.User"/>
   </data>
   <LinearLayout
       android:orientation="vertical"
       android:layout_width="match_parent"
       android:layout_height="match_parent">
       <include 
            layout="@layout/name"
            bind:user="@{user}"/>
       <include 
            layout="@layout/contact"
            bind:user="@{user}"/>
   </LinearLayout>
</layout>

Reference

• Android Developers - DataBinding

View Binding은 뷰와 상호작용하는 코드를 쉽게 작성할 수 있도록 만들어 주는 기능입니다.

모듈에서 View Binding을 사용하도록 설정하면 모듈에 있는 XML 레이아웃 파일들의 바인딩 클래스가 생성됩니다. 이 바인딩 클래스의 인스턴스에는 해당 레이아웃에서 ID를 가지고 있는 모든 뷰와 루트 뷰의 직접 참조가 포함되어 있습니다. 그래서 대부분의 경우 View Binding은 findViewById를 대체할 수 있습니다.

모듈에서 View Binding 사용 설정

View Binding은 모듈 단위로 사용 설정되며, build.gradle 파일에 View Binding 사용 여부를 명시합니다.

// android studio 4.0 이하
android {
    viewBinding {
        enabled = true
    }
}

---------------------------

// android studio 4.0 이상
android { 
    buildFeatures { 
        viewBinding = true 
    }
}

특정 레이아웃 무시

특정 레이아웃의 바인딩 클래스를 생성하지 않으려면 tools:viewBindingIgnore="true" 속성을 루트 뷰에 추가해야 합니다.

<LinearLayout
        tools:viewBindingIgnore="true">
</LinearLayout>

바인딩 클래스

모듈에 View Binding 사용하도록 설정되면 XML 레이아웃 파일의 이름을 파스칼 표기법으로 변환하고 끝에 Binding을 추가한 이름을 가진 바인딩 클래스가 생성됩니다.

<LinearLayout ... >
        <TextView android:id="@+id/name" />
        <ImageView android:cropToPadding="true" />
        <Button android:id="@+id/btn" />
</LinearLayout>

예를 들어 레이아웃 파일 이름이 result_profile.xml인 경우 ResultProfileBinding이라는 바인딩 클래스가 생성되며, 이 클래스에는 name이라는 TextView 필드와 btn이라는 Button 필드가 있습니다. ImageView는 ID가 없기 때문에 바인딩 클래스에 참조가 존재하지 않습니다.

루트뷰 접근

모든 바인딩 클래스에는 해당 레이아웃의 루트 뷰에 관한 직접 참조를 제공하는 getRoot() 메서드가 포함되어 있습니다. 따라서 레이아웃의 루트 뷰는 ID가 없어도 바인딩 클래스를 통해 직접 접근할 수 있습니다.

View Binding 사용

Activity에서 View Binding 사용

생성된 바인딩 클래스의 inflate() 메서드를 호출하면 바인딩 클래스의 인스턴스가 생성됩니다.

인스턴스가 생성되면 getRoot() 메서드를 통해 루트 뷰 참조를 가져오고 이 루트 뷰를 onCreate()에서 setContentView() 메서드에 전달하여 레이아웃을 활성 뷰로 만듭니다.

private lateinit var binding: ResultProfileBinding

override fun onCreate(savedInstanceState: Bundle) {
    super.onCreate(savedInstanceState)
    binding = ResultProfileBinding.inflate(latoutInflater)
    val view = binding.root
    setContentView(view)
}

이후에는 인스턴스를 사용하여 뷰를 참조합니다.

binding.name.text = viewModel.name
binding.btn.setOnClickListener { viewModel.userClicked() }

Fragment에서 View Binding 사용

Activity에서 View Binding을 사용하는 것과 거의 동일하며, 활성 뷰로 만드는 부분에서만 차이가 있습니다.

Fragment에서는 onCreateView()에서 루트 뷰를 반환하여 레이아웃을 활성 뷰로 만듭니다.

private var _binding: ResultProfileBinding? = null
private val binding get() = _binding!!

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View? {
    _binding = ResultProfileBinding.inflate(inflater, container, false)
    val view = binding.root
    return view
}

override fun onDestroyView() {
    super.onDestroyView()
    _binding = null
}

findViewById와의 차이점

Null Safety

• View Binding은 뷰의 직접 참조를 생성하므로 유효하지 않은 뷰 ID로 인해 Null Pointer 예외가 발생하지 않습니다.
• 레이아웃에 포함된 뷰가 특정 조건에서만 존재하는 경우, 바인딩 클래스는 해당 필드를 @Nullable로 마크하여 참조 실수를 방지할 수 있게 해줍니다.

Type Safety

• 각 바인딩 클래스에 있는 필드의 타입이 XML 파일에서 참조하는 뷰의 타입과 일치합니다. 즉, 클래스 변환 예외가 발생할 위험이 없습니다.

예외 탐지

• View Binding은 Null Safety하고 Type Safety하기 때문에 레이아웃과 코드 사이의 비호환성이 발생하면 findViewById와 달리 런타임이 아닌 컴파일 타임에 예외를 탐지할 수 있습니다.

Data Binding과의 차이

View Binding과 Data Binding 모두 뷰를 직접 참조하는데 사용할 수 있는 바인딩 클래스를 생성합니다. 다만, View Binding은 보다 단순한 경우에 사용합니다.

View Binding이 더 나은 점

• 주석 처리가 필요하지 않기 때문에 컴파일 시간이 더 짧습니다.
• XML에 태그를 추가할 필요없고, 사용 설정하면 모든 레이아웃에 View Binding이 자동 적용되기 때문에 편리합니다.

  View Binding이 더 안좋은 점

• XML 레이아웃 파일에서 직접 동적 UI 컨텐츠를 선언하는데 사용할 수 없습니다.
• 양방향 데이터 바인딩을 지원하지 않습니다.

Reference

• Android Developers - ViewBinding

안드로이드 앱을 사용하다보면 종종 첫화면 전에 빈 화면이 잠깐 나오는 것을 볼 수 있는데요, 이는 앱을 새로 실행하는 경우 첫 화면을 그리는데 시간이 필요하기 때문입니다.

안드로이드 시스템은 이 시간 동안 비어있는 Placeholder Screen을 앱의 windowBackground color로 채우는데요, 액티비티 테마를 이용한다면 이 Placeholder Screen을 단순히 색깔만 가진 화면에서 Splash Screen으로 확장시킬 수 있습니다.

<!-- splash_drawable.xml -->

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">

  <!-- background color -->
  <item android:drawable="@android:color/white"/>

  <!-- App logo -->
  <item>
      <bitmap
          android:src="@drawable/app_logo"
          android:gravity="center">
      </bitmap>
  </item>

</layer-list>

먼저 <layer-list>를 통해 Splash Screen으로 사용될 drawable을 만듭니다.

<!-- styles.xml -->

<resources>

  <style name="SplashTheme" parent="Theme.AppCompat.DayNight.NoActionBar">
    <item name="android:windowBackground">@drawable/splash_drawable</item>
  </style>

</resources>

그런 다음 Spash Screen을 위한 테마를 만들고 windowBackground 속성에 앞에서 만든 drawable을 지정해줍니다.

<!-- AndroidManifest.xml -->

<manifest xmlns:android="http://schemas.android.com/apk/res/android" 
  package="com.~~~">

  <application
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:roundIcon="@mipmap/ic_launcher_round"
    android:supportsRtl="true"
    android:theme="@style/AppTheme">

    <activity android:name=".MainActivity"
      android:theme="@style/SplashTheme">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>

  </application>

</manifest>

만들어진 테마를 첫 화면이 될 액티비티에 적용하면 앱 실행 시 빈화면이 아닌 Splash Screen이 보여지게 됩니다.

/* MainActivity.kt */

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        setTheme(R.style.AppTheme)
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

액티비티가 Splash Screen과는 다른 테마를 가져야 한다면, 해당 액티비티 onCreate()에서 setTheme() 메소드를 사용하여 Splash Screen 이후에는 기존 테마가 적용되록 만들어줘야 합니다.

이 방식을 이용한다면 첫 화면을 그리는 동안 빈 화면이 아닌 Splash Screen을 보여줌으로써 사용자 경험을 개선할 수 있지만, Splash Screen에 애니메이션이나 Progress Bar를 포함할 수는 없다는 단점이 있습니다.

⌛ Handler, Runnable 그리고 Timer

많은 앱들은 Splash Screen을 위해 별도의 액티비티를 만들고 해당 액티비티에서 일정시간 대기한 후 로직에 따라 다른 액티비티로 이동하는 방식을 사용합니다.

이 방식은 주로 Handler와 Runnable 클래스를 통해 구현됩니다.

/* MainActivity.kt */

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        Handler().postDelayed(2000) {
            var intent = Intent(this@MainActivity, NextActivity::class.java)
            startActivity(intent)
            finish()
        }
    }

    override fun onDestroy() {
        handler.removeCallbacksAndMessages(null)
        super.onDestroy()
    }
}

이 방식은 Splash Screen에 애니메이션이나 Progress Bar를 사용할 수 있고, 좀 더 자유로운 Splash Screen 화면을 구성할 수 있습니다. 또한 특정 액티비티로 리다이렉션 하는 로직도 추가할 수 있습니다.

그러나 하드웨어의 뒤로가기 버튼을 누르는 경우 handler의 동작을 취소할 수 없고 예약된 동작으로 인해 화면이 랜덤하게 팝업된다는 단점이 있습니다. 이는 메모리 누수를 발생시키거나 데이터 손실을 유발할 수 있습니다.

이를 해결하기 위해서 Timer 클래스를 사용하기도 합니다.

/* MainActivity.kt */

class MainActivity : AppCompatActivity() {

    var timer = Timer()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_timer_splash)

        timer.schedule(2000) {
            var intent = Intent(this@MainActivity, NextActivity::class.java)
            startActivity(intent)
            finish()
        }
    }

    override fun onPause() {
        timer.cancel()
        super.onPause()
    }
}

Timer는 Handler와 달리 동작을 취소할 수 있습니다. 다만 Timer는 완전히 새로운 쓰레드를 백그라운드에 생성하기 때문에 TimerTask 객체 안에서 UI와 상호작용할 수 없고, 메모리 측면에서 무거운 작업이며, 쓰레드 스위칭으로 인해 느리다는 단점이 있습니다.

💡 Coroutine 사용

Handler와 Runnable 클래스 대신에 코틀린의 Coroutine을 이용할 수도 있습니다.

/* MainActivity.kt */

class MainActivity : AppCompatActivity() {

    val activityScope = CoroutineScope(Dispatchers.Main)

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_coroutines_splash)

        activityScope.launch {
            delay(2000)

            var intent = Intent(this@MainActivity, NextActivity::class.java)
            startActivity(intent)
            finish()
        }
    }

    override fun onPause() {
        activityScope.cancel()
        super.onPause()
    }
}

이 방식은 CoroutineScope가 Dispatchers.Main을 사용하기 때문에 작업을 Main UI Thread에서 수행하며, Thread Switching이 없습니다. 또한 코루틴의 동작을 취소할 수도 있습니다.

즉, Coroutine은 빠르고 안정적이며 메모리를 덜 쓰고, UI에 접근할 수 있다는 장점이 있습니다.

Reference

• A Guide on Splash Screen in Android in 2020

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

git add의 동작 원리

git status

• 워킹트리와 스테이지, 그리고 헤드 커밋에 저장된 파일의 차이를 비교해서 보여주는 명령어
• 새로 생성된 파일은 워킹트리에 저장됨

git hash-object

$ git hash-object <file name>

• 파일의 Checksum을 확인하는 명령어
• 파일은 내용이 같다면 언제나 똑같은 Checksum을 가짐
• 다른 파일이지만 내용이 같다면 똑같은 Checksum을 가짐

git add

• 워킹트리에 존재하는 파일을 스테이지에 추가하는 명령어
• 최초로 git add를 실행하면 .git 폴더에 index 파일이 생성되는데, 이 index 파일이 Git stage임
• 또 .git/objects 폴더에 파일 Checksum의 앞 두자리를 폴더명으로 하는 폴더가 생성됨
• 해당 폴더에는 파일 Checksum의 앞 두자리를 제외한 문자열을 파일명으로 하는 git object가 생성됨
• 이 git object의 파일 형식은 blob임

git commit의 동작 원리

git commit

• 스테이지의 내용으로 커밋을 생성하는 명령어
• git commit을 실행하면 .git/objects 폴더에 git add 때와 같은 방식으로 git object가 생성됨
• 이 git object는 커밋 객체임
• 커밋 객체는 각자 고유한 Checksum을 가짐

commit 후 워킹트리, 스테이지, 헤드

• commit 후에 스테이지에서 파일이 제거될거라고 생각하기 쉬운데 사실을 그렇지 않음
• 워킹트리, 스테이지, 헤드에 속한 파일이 모두 똑같아짐 → 이를 clean하다고 함

Git tree 객체

• git commit을 실행하면 .git/objects 폴더에 git tree object도 생성됨
• 이 트리는 스테이지의 객체로 만들어진 트리임
• 스테이지의 객체가 동일하다면 트리 객체는 항상 동일한 Checksum을 가짐
• 트리 객체는 해당 트리를 생성한 커밋 객체에 포함됨

파일을 수정했을 때

파일 수정

• 이미 한번 커밋한 파일을 수정하는 경우 워킹트리에 속한 파일의 Checksum만 바뀜
• 이 경우 파일은 modified 상태가 되는데, 이는 워킹트리 속 파일 Checksum이 스테이지 속 파일 Checksum과 다른 경우를 말함

수정된 파일 add

• 수정된 파일을 git add 명령어를 통해 스테이지에 추가한 경우, 스테이지 속 파일의 Checksum이 워킹트리 속 파일의 Checksum과 같아지게 됨
• 이 경우 파일의 상태는 staged가 됨

중복 파일 관리

• Git에서 파일들은 blob으로 관리되며, 이 blob은 파일의 제목이나 생성 날짜와는 관계 없이 내용이 같을 경우 같은 CheckSum을 가짐
• 따라서 같은 내용을 같은 파일을 여러개 만들어도 Git은 하나의 blob으로 해당 파일들을 관리함
• 파일 목록은 index 파일에 Checksum과 함께 저장되어 있기 때문에, 동일한 내용을 같는 파일을 하나의 blob으로 관리할 수 있음

Git branch의 동작 원리

branch 생성

• branch를 생성하면 .git/refs/heads 폴더에 branch명으로 파일이 생성됨
• 해당 파일에는 그 branch가 가리키고 있는 커밋의 Checksum이 저장되어 있음

checkout

• 해당 branch 파일에 저장된 커밋으로 HEAD를 이동시킴
• 스테이지와 워킹트리를 HEAD가 가리키는 커밋과 동일한 내용으로 변경함

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

Git Branch

Commit tree

• 커밋 히스토리는 각 커밋들이 부모 커밋(base commit)을 가리키고 있는 트리 그림으로 표현할 수 있음
• 실제로 커밋을 하면 커밋 객체가 생성되는데, 이 커밋 객체에는 부모 커밋에 대한 참조와 실제 커밋을 구성하는 파일 객체가 들어 있음
• 부모 커밋은 자식 커밋에 대한 정보를 담고 있지 않음

Branch

• 개념적으로 branch는 특정 커밋과 그 조상들을 지칭
• 실제로 branch는 단순히 커밋 객체 하나를 가리키는 포인터

Branch 사용 이유

• 새로운 기능 추가 (feature branch)
• 버그 수정 (hotFix branch 혹은 bugFix branch)
• merge와 rebase 테스트
• 이전 코드 개선

HEAD

• 기본적으로 현재 작업 중인 branch의 최근 커밋을 가리키는 포인터
• detached HEAD: checkout 등에 의해 branch의 최근 커밋이 아닌 다른 커밋을 가리키는 헤드
• HEAD~<숫자>: HEAD~는 헤드의 부모, HEAD~n은 헤드의 n번째 조상을 의미
• HEAD^<숫자>: HEAD^는 헤드의 부모, HEAD^n은 헤드의 n번째 부모를 의미. 병합 커밋처럼 부모가 둘 이상인 커밋에서만 의미가 있음

Tag

$git tag -a -m <message> <tag> [branch or checksum]

• -a: 주석이 있는 태그 생성 옵션
• branch나 checksum을 생략하면 헤드에 태그 생성

3-Way Merge

• 위 그림처럼 feature branch를 생성하여 다른 작업을 수행하던 중, 이전에 완료한 커밋의 코드를 수정해야할 상황이 발생

• 수정할 코드가 있는 커밋에서 hotFix branch를 생성하여 코드 수정

• hotFix branch를 master branch에 병합
• master branch의 최신 커밋을 base로 hotFix branch의 커밋을 생성했기 때문에 fast-forward 병합이 발생
• 병합이 완료된 hotFix branch는 삭제함

• 원래 작업을 수행 중이던 feature branch는 2번 커밋을 base로 작업 중이었기 때문에 4번 커밋을 병합해야 함
• Conflict이 발생할 수 있으며 Confilct을 해결한 병합 커밋이 추가로 생성됨

3-Way Merge와 rebase 비교

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

Git 명령어

init

$ git init

• 현재 폴더에 Git 저장소를 생성
• .git 폴더가 생성되며 이 폴더가 로컬저장소임

Git 저장소

• Git 명령으로 관리할 수 있는 폴더 전체
• 공식 문서에서는 로컬저장소를 지칭

로컬 저장소 커밋과 커밋을 구성하는 객체, 스테이지가 저장되는 폴더

status

$ git status

• Git 워킹트리의 상태를 보여주는 명령어
• Git 워킹트리가 아닌 폴더에서 실행하면 오류 발생

$ git status -s

• Git 워킹트리의 상태를 짧게 요약해서 보여주는 명령어
• 변경된 파일이 많을 때 유용

Git working tree

• 사용자가 파일과 하위 폴더를 만들고 작업 결과물을 저장하는 곳
• 워킹 디렉토리 혹은 작업 디렉토리라고도 함
• 정확하게는 작업 중인 폴더에서 .git 폴더를 뺀 나머지 부분을 지칭함

config

$ git config [--global | --local | --system] <option>

• 지정한 범위의 옵션 내용을 보여주는 명령어
• --global: 현재 사용자를 위한 옵션
• --local: 현재 Git 저장소에서만 유효한 옵션
• --system: PC 전체의 사용자를 위한 옵션

$ git config [--global | --local | --system]

- 지정한 범위의 옵션 값을 새로 설정

$ git config [--global | --local | --system] --unset

- 지정한 범위의 옵션 값을 삭제

$ git config --list

- 현재 프로젝트의 모든 옵션을 보여주는 명령어

### reset

$ git reset

- `reset` 명령어는 커밋을 이전 상태로 돌리는 기능 이외에 스테이지 영역에 있는 파일을 `unstaging`하기도 함

### log

$ git log

commit [commit id] (HEAD -> master) Author: [user_name] [user_email] Date: Fri Jul 26 14:38:16

[commit message]

- Git의 커밋 히스토리를 보여주는 명령어

> **Commit ID**
- 40자리 16진수로 SHA1 해시 체크섬 값
- 전 세계에서 유일한 값이며 커밋 객체를 구별하는데 사용됨

> **Commit message 7가지 규칙**
- 제목과 분문을 빈 줄로 분리
- 제목은 50자 이내로 
- 제목을 영어로 쓸 경우 첫 글자는 대문자로
- 제목에 마침표를 넣지 않음
- 제목을 영어로 쓸 경우 동사원형(현재형)으로 시작
- 본문을 72자 단위로 줄바꿈
- 어떻게 보다 무엇과 왜를 설명

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

amend

$ git add new_file.txt
$ git commit --amend 

• 커밋에 반영되었어야 할 내용이 누락된 경우 새로운 커밋을 생성할 필요없이, amend 명령어를 통해서 기존 커밋에 추가할 수 있음
• amend 명령어로 커밋 메시지도 수정할 수 있음
• 원격저장소에 이미 push된 커밋을 amend로 수정한 경우 원격저장소에 force push하여 변경된 커밋으로 덮어 씌워야 함

cherry-pick

$ git cherry-pick [selected commit id]

• 다른 branch에 속한 커밋 중 원하는 하나만 현재 branch로 반영하는 기능
• 선택된 커밋 이전의 커밋이나 이후의 커밋은 현재 branch로 반영되지 않음

reset

$ git reset --mixed [commit]
$ git reset --soft [commit]
$ git reset --hard [commit]

• branch를 옛날 커밋으로 되돌리는 기능
• --mixed: reset의 기본 옵션으로, 선택한 커밋 이후의 변경사항들은 없애지 않고 unstaged 상태(untracked 혹은 modified)로 남겨두는 옵션
• --soft: --mixed와 유사하지만 변경사항들을 staged 상태로 남겨두는 옵션
• --hard: 변경사항들을 모두 없애고 완전히 깔끔한 상태로 변경하는 옵션

revert

$ git revert [commit]

• 잘못된 커밋을 생성한 경우 해당 커밋 이전으로 reset할 수도 있지만, 변경사항 되돌리는 커밋을 새로 생성하는 것이 더 좋음
• revert: 선택한 커밋 이전의 커밋 상태를 가지고 와서 새로운 커밋을 생성하는 명령어
• 즉, 잘못된 커밋을 제거하는 것이 아닌, 그 이전의 상태로 다시 덮어 씌우는 작업

stash

$ git stash
$ git stash apply

• stash: 커밋하지 않은 변경 사항을 서랍에 넣어두기
• stash apply 서랍에 넣어둔 작업들을 다시 가져오기
• tracked 상태인 파일들만 서랍에 넣을 수 있음

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

원본저장소 복사

• 기본적으로 원본저장소에 커밋을 직접 push하는 것은 그 저장소를 만든 사람만 할 수 있음
• 다른 사람이 push하기 위해선 저장소 소유자가 그 사람을 협력자로 등록해야 함
• 협력자가 늘어날 수록 원본저장소를 관리하기가 어려워짐

  fork

• 협력자를 추가하는 대신, 원본저장소를 fork로 다른 원격저장소에 복사하고 추가로 코드를 작성한 뒤, pull request를 통해 원본저장소에 반영하는 방식을 사용
• fork시 branch를 포함한 원본 저장소의 모든 커밋을 복사함
• branch를 통해 코드 분기점을 만들고 pull request를 통해 병합하는 과정과 유사하지만 fork한 원격저장소는 branch와는 달리 원본 저장소로부터 독립되어 동작함
• fork한 원격저장소는 clone으로 로컬저장소에 내려받은 뒤 작업을 함

원본저장소에 Pull Request

• fork한 원격저장소의 한 branch를 원본저장소의 한 branch에 병합하는 작업
• 오픈소스에 pull reqeust를 보내기 전에 Contribution Guideline이 있는지 확인하는 것이 좋음
• pull request가 받아들여지면 fork한 사용자가 원본저장소에 Contributor로 등록됨

Commit 이력 조작하기

• fork한 원격저장소는 fork한 시점의 원본저장소 커밋 이력을 복사함
• 이후 원본저장소에 새로운 커밋이 생겨도 fork한 원격저장소는 해당 커밋에 대해 알지 못 함
• 이러한 상황에서 pull request를 한다면 Conflict이 발생할 수 있음
• 병합시 Conflict을 해결한 커밋이 추가로 생성됨

  여러 원격저장소 추적

• fork한 원격저장소를 내려받은 로컬저장소는 fork한 원격저장소를 origin이라는 이름을 붙이고 추적함
• 로컬저장소에서 원본저장소의 히스토리를 보기 위해선 원본저장소도 추적해야 함
• $ git add remote upstream [원본저장소 주소]: 원본저장소는 관용적으로 upstream이라는 이름을 붙임

  fetch

  
• 원격저장소의 커밋 이력을 가져와 로컬저장소의 커밋 이력을 업데이트하는 기능
• 커밋 이력을 가져와 최신 코드를 내 코드에 반영하는 pull과는 달리 커밋 이력만 가져옴

  rebase

  
• 커밋의 base commit을 바꾸는 기능
• 위 예시에서 1, 2번 커밋의 base를 0번 커밋에서 4번 커밋으로 바꾸는 과정 1) 1번 커밋과 4번 커밋을 비교하여 충돌을 확인하고 해결 2) 충돌을 해결한 1번 커밋을 4번 커밋과 연결 3) 1'번 커밋과 2번 커밋을 비교하여 충돌을 확인하고 해결 4) 충돌을 해결한 2번 커밋을 1'번 커밋과 연결
• 커밋 히스토리를 바꾸는 것이기 때문에 히스토리가 꼬이지 않도록 혼자 쓰는 branch에서 rebase해야 함
• rebase한 커밋 이력을 원격저장소에 반영할 경우 force push로 강제 푸쉬해야 함

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

Branch란?

Branch 생성 이유

• branch 없이 커밋 한다면 기본 branch인 master의 커밋이 됨
• master 커밋은 한 줄로, 시간 순으로 쌓이며 각 커밋들은 이전 커밋을 가리키고 있음

• 한 커밋을 기준으로 여러 사람이 각각 새로운 버전을 생성한 경우 생성된 버전들은 이전 커밋을 가리켜야 하기 때문에 한 줄로 연결될 수 없음
• branch라는 새로운 작업 줄기를 생성하여 병렬적으로 연결해야 함

Branch는 포인터

• branch는 일종의 포인터로 해당 branch에서 생성한 커밋 중 가장 최신 커밋을 가리킴
• 분기를 만들 때 프로젝트를 통째로 복사해야 하는 SVN 같은 버전 관리 툴과는 달리 Git은 포인터로 분기를 만들기 때문에 가볍고 빠름
• 복사된 커밋이 아닌 동일한 커밋을 다른 branch가 가리킬 수도 있음

HEAD

• 많고 여러 갈래로 나뉜 커밋 중에서 현재 어디에 위치하고 있는지 가리키는 포인터
• 예를 들어 git checkout을 통해 Master Commit 2로 이동했다면 HEAD는 Master Commit 2를 가리키고 있음
• HEAD가 master branch의 포인터와는 다른 커밋을 가리킨다면 HEAD는 Detached HEAD 상태가 됨

Branch 생성 및 이동

feature branch

• 일반적으로 master branch에는 직접 커밋하지 않음
• 일반적으로 기능 개발을 위한 branch는 feature/[기능 이름]으로 생성함
• feature branch에서 기능 개발이 끝나면 master branch에 합침
• 병합되어 더 이상 필요하지 않은 feature branch는 삭제

checkout

• branch를 생성할 때 기준(base)이 될 커밋으로 이동하기 위한 기능

Branch 합치기

Branch 합치기(merge)는 두 버전(커밋)의 합집합을 구하고 하나의 branch 에 속하도록 만드는 것을 말함

Fast-forward

• 두 커밋의 합집합이 둘 중 하나와 동일한 경우
• 새로운 커밋 생성 없이 합집합과 동일한 커밋을 branch가 가리키도록 함

Conflict

• 두 커밋이 동일한 부분을 서로 다르게 수정한 경우 Conflict이 발생함
• Conflict이 발생할 경우를 대비해 일반적으로 먼저 feature branch로 master branch의 커밋을 병합함
• feature branch로 병합했을 때 Conflict이 발생하면 Conflict을 해결하고 커밋 한 뒤, 해당 커밋을 master branch와 병합함
• Conflict를 해결한 커밋은 Fast-forward로 master branch와 합쳐짐

Merge Commit

• Fast-forward도 아니고 Conflict도 발생하지 않는 경우 두 커밋을 합집합한 새로운 Merge Commit이 생성됨

Pull Request

• 협력자에게 branch 병합을 요청하는 메시지를 보내는 GitHub의 기능
• base branch로 compare branch의 커밋이 병합되는 형태
• 코드의 라인마다 댓글을 달 수 있어서 해당 코드가 왜 고쳐졌는지, 어떻게 개선할 수 있는지 토론할 수 있음
• pull request가 승낙되면 GitHub를 통해 병합이 진행되므로 병합 후 내 로컬 저장소로 pull하는 과정이 필요함

프로젝트 Release

프로그램 Version

• 프로그램 개발 과정에서 의미있는 특정 시점들을 버전으로 명시함
• Major upgrade: 사용자들이 크게 변화를 느끼도록 프로그램을 바꿨을 경우 메이저 버전을 올림 (1.2.6 -> 2.0.0)
• Minor upgrade: 작은 변화가 생겼을 경우 마이너 버전을 올림 (1.2.6 -> 1.3.0)
• Maintenance upgrade: 버그나 유지보수 등 작은 수정을 했을 경우 메인터넌스 버전을 올림 (1.2.6 -> 1.2.7)

  Tag

• Release: 프로그램을 사용자들이 쓸 수 있도록 배포하는 것
• Tag: 코드 버전 등 커밋에 간단한 태그를 붙일 때 사용하는 기능
• 태그도 일종의 포인터여서 해당 태그가 붙은 커밋을 가리키고 있음

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

Git과 다른 버전 관리 시스템의 차이

다른 버전 관리 시스템

  Prev commit              Next commit

---README.txt---         ---README.txt---
| 1. 가나다     |         |              |
| 2. 라마바     |    -    |              |
|              |         | 3. 사아자     |
----------------         ----------------

• SVN(SubVersion)과 같은 버전 관리 시스템은 커밋에 변경사항만 부분적으로 저장함
• 각 버전의 소스 코드를 볼 때 맨 처음 커밋부터 거슬러 올라가 바뀐 점을 모두 반영하는 작업을 해야함

Git

  Prev commit              Next commit

---README.txt---         ---README.txt---
| 1. 가나다     |         | 1. 가나다     |
| 2. 라마바     |    -    | 2. 라마바     |
|              |         | 3. 사아자     |
----------------         ----------------

• Git은 커밋에 변경된 파일을 통째로 저장함 (Snapshot)
• 각 버전의 소스 코드를 볼 때 바로 앞 커밋이랑만 비교하면 됨
• 바뀌지 않은 파일은 이전 커밋의 파일 링크만 저장

Git으로 관리하는 파일 상태

untracked

• untracked: 한 번도 커밋된 적이 없는 파일의 상태

  tracked

• staged: add 명령어를 통해 stage에 올라온 파일의 상태
• unmodified: stage에 속한 파일들은 commit 명령어 실행시 해당 버전에 저장되고 unmodified 상태가 됨
• modified: 커밋된 적이 있고 마지막 커밋 이후로 내용이 변경된 파일의 상태

팀 개발을 위한 Git, GitHub 시작하기(정호영, 진유림 지음)으로 공부한 내용을 정리한 글입니다.

Git과 GitHub

Git

소스 코드 데이터를 저장하고 내가 원하는 시점의 소스 코드 데이터로 이동할 수 있게 해주는 버전 관리 툴

GitHub

Git으로 관리하는 프로젝트를 올려둘 수 있는 Git 호스팅 사이트 중 하나. 다른 호스팅 사이트로는 GitLab과 BitBucket 등이 있음

오픈소스

누구든지 볼 수 있고 기여할 수 있는 공개 프로젝트. Git은 오픈소스 활동을 전 세계로 확장시킨 일등공신

Git 기본 사용

Initialize

Git 로컬 저장소 만들기

$ git init

• 내 컴퓨터에 존재하는 폴더를 Git과 연결하는 CLI
• 명령어를 실행하고 나면 .git 폴더가 생성되는데, 이 폴더에는 Git으로 생성한 버전들의 정보와 원격저장소 주소 등이 들어 있음
• 일반적으로 .git 폴더를 로컬저장소라고 부름

CLI Command-Line Interface. 가상 터미널 또는 텍스트 터미널을 통해 사용자와 컴퓨터가 상호 작용하는 방식 (출처: 위키백과)

Git에 내 정보 등록

$ git config --global user.name "user name"

$ git config --global user.email "user email"

• 버전 생성자 확인을 위해 정보 등록
• 연동할 Git 호스팅 사이트 계정 정보와 동일하게 입력하는 것이 좋음

Commit

Commit 파일 추가

$ git add [file name]

• 특정 파일 추가

$ git add .

• 모든 파일 추가

Commit 하기

$ git commit -m "commit message"

• Git에 새 버전 생성

지금까지 Commit한 내역 확인

$ git log

commit [commit id] (HEAD -> master)
Author: [user_name] [user_email]
Date: Fri Jul 26 14:38:16

[commit message]

commit [commit id]
Author: [user_name] [user_email]
Date: Fri Jul 26 14:34:43

[commit message]

• 최신 커밋부터 오래된 커밋 순으로 보여줌

특정 Commit으로 코드 되돌리기

$ git checkout [commit id]

• commit id는 앞 7자리까지만 써도 됨

최신 Commit으로 코드 되돌리기

$ git checkout -

• -는 최신 커밋을 의미

GitHub 기본 사용법

GitHub에 Commit 올리기

원격저장소 주소 등록

$ git remote add origin [address]

• GitHub에 Repository를 생성하고 그 주소를 Git에 등록
• origin: 원격저장소의 닉네임

GitHub에 Commit Push

$ git push origin [branch name]

• 등록된 원격저장소에 커밋 내용이 업로드 됨
• branch name: 커밋을 올리는 줄기 이름
• master: 기본 branch 이름. 따로 줄기를 생성하지 않으면 Git은 master에 커밋을 올림

GitHub에서 Commit 내려받기

Clone

$ git clone [repository address] .

• 원격저장소의 주소와 코드, 그리고 버전 전체를 내 컴퓨터로 내려받음
• .은 현재 폴더에 내려받겠다는 뜻
• .이 없으면 repository 제목으로 폴더가 생성되고 그곳에 내려받아짐
• GitHub에서 [Download ZIP]을 통해 원격저장소나 버전들은 제외하고 파일들만을 내려받을 수도 있음

Pull

$ git pull origin master

• 원격저장소에 새로운 커밋들이 있다면 해당 커밋들은 내 로컬저장소로 내려받음

안드로이드의 저장 공간은 크게 내부 저장소와 외부 저장소로 구분됩니다. Scoped Storage는 외부 저장소에 적용되는 개념으로, 안드로이드 10(Android Q) 버전에서 보안 강화를 목적으로 등장했습니다. Scoped Storage의 등장으로 외부 저장소 관리는 Android Q 이전과는 완전히 달라지게 되었습니다.

Android Q 이전의 저장 공간

안드로이드의 내부 저장소는 시스템과 기기에 설치된 앱들이 사용하는 공간입니다. 각 앱들은 개별적인 공간을 할당 받으며, 이 곳에 앱 동작에 필요한 파일들을 저장합니다. 또 각자의 공간은 권한 없이 접근할 수 있으나, 다른 앱의 공간엔 아예 접근할 수 없습니다. 내부 저장소는 샌드박스 구조로 되어 있기 때문에 시스템에 의해 안전하게 보호됩니다.

샌드박스(sandbox) 외부로부터 들어온 프로그램이 보호된 영역에서 동작해 시스템이 부정하게 조작되는 것을 막는 보안 형태 (출처: 위키피디아)

외부 저장소는 모든 앱들이 공유하는 하나의 공용 저장소로, 외부 저장소 접근 권한이 있다면 외부 저장소 내의 모든 파일에 접근 가능합니다. 외부 저장소 내에도 내부 저장소처럼 각 앱들을 위한 개별적인 공간이 존재하며, 이 공간 역시 권한이 있다면 마음껏 접근할 수 있습니다. 개별 공간이 공유 공간과 다른점은 해당 공간을 소유한 앱은 권한이 없어도 해당 공간에 접근할 수 있고 해당 앱이 삭제되면 할당되었던 공간이 해제된다는 점입니다.

이러한 특성을 가지고 있는 외부 저장소는 다른 앱의 파일에 쉽게 접근할 수 있다는 점에서 보안적으로 취약하다고 볼 수 있습니다.

Android Q 이후의 저장 공간

Scoped Storage가 적용된 Android Q 이후의 외부 저장소는 Android Q 이전의 외부 저장소와 개념적으로 완전히 달라지게 됩니다.

먼저, 개별 공간은 샌드박스 구조로 바뀌었습니다. 해당 공간을 소유한 앱은 권한 없이 해당 공간에 접근할 수 있으나 그렇지 않은 앱들은 해당 공간에 직접적으로 접근할 수 없습니다.

공용 공간은 개별 공간의 파일들을 개념적으로 모아놓은 영역으로 사진 및 동영상 / 음악 / 다운로드로 영역이 구분되어 있습니다. 공용 공간에는 타입에 맞는 파일만 저장할 수 있으며(다운로드는 제한 없음) MediaStore를 통해서만 접근할 수 있습니다. 각 영역에 파일을 생성하거나 자신이 생성한 파일을 읽을 땐 추가 권한이 필요하지 않습니다. 그러나 다른 앱이 생성한 파일을 읽기 위해선 여전히 권한이 필요하고 해당 파일에 쓰는 것은 쓰기 권한이 없어졌기 때문에 불가능합니다. 앱이 삭제되도 해당 앱이 생성(소유)한 공용 공간의 파일은 삭제되지 않습니다.

Reference

• 안드로이드 Q Scoped Storage 이해하기
• Preparing for scoped storage
• Android 11의 현대식 저장소

안드로이드 좌표계

안드로이드는 화면의 좌측 상단을 (0, 0)으로 하고 x좌표는 오른쪽으로 갈수록 증가하며 y좌표는 아래쪽으로 갈수록 증가하는 좌표계를 갖습니다. 상태바는 윈도우에 오버레이 되어 있는 것이기 때문에 상태바의 좌측 상단이 (0, 0)입니다.

View의 위치와 크기 표현

View는 실제 모양과 달리 직사각형의 형상을 가집니다. View는 left와 top의 쌍으로 위치를 표현하고, width와 height로 2차원의 크기를 표현합니다. 각가의 단위는 픽셀입니다.

메소드

• getLeft()와 getTop(): View를 표현하는 직사각형의 좌측 상단의 X, Y좌표를 반환하며 반환된 좌표는 View의 부모를 기준으로한 상대 좌표입니다.
• getRight(): left + width를 반환합니다.
• getBottom(): Top + height를 반환합니다.

View Size

View의 크기는 width와 height의 쌍으로 표현됩니다. 실제로 View는 두 가지의 width, height 쌍을 가집니다.

• measured width와 measured height: View의 부모 내에서 View가 어느정도의 크기를 갖는지 정의하는 값입니다.
• width와 height: drawing width, drawing height라고도 하며, 레이아웃이 그려지고 난 뒤 화면에 그려질 View의 실제 크기를 정의하는 값입니다. measured width, measured height와는 다른 값을 가질 수도 있습니다.

메소드

• getMeasuredWidth()와 getMeasuredHeight(): measured width와 measured height 값을 반환합니다.
• getWidth()와 getHeight(): width와 height 값을 반환합니다.

Layout

Layout은 측정 단계와 레이아웃 단계로 이루어집니다.

측정 단계

측정 단계는 measure(widthMeasureSpec, heightMeasureSpec) 메소드로 발생하며, View tree를 top-down 방식으로 순회하면서 동작합니다. 측정값은 각 View에 저장됩니다. 측정된 너비와 높이는 부모의 제약 조건을 만족해야 합니다. 이를 통해 측정 단계가 끝나면 모든 부모가 그들의 자식들의 측정값을 수용하는 것을 보장합니다.

레이아웃 단계

레이아웃 단계는 layout(l, t, r, b) 메소드로 발생하며, 역시 View tree를 top-down 방식으로 순회하며 동작합니다. 이 단계를 진행하면서 각 부모들은 측정 단계에서 계산된 사이즈를 이용하여 자식들의 위치를 결정해야 합니다.

translation

View를 setTranslationX(), setTranslationY() 메소드를 통해서 이동시킬 수 있다. 이 이동은 View가 레이아웃에 배치되고 난 후에 이동시키고 싶을 때 사용하는 이동입니다.

메소드

• getX(): left + translationX의 값을 반환합니다. 이는 translation 후의 X 좌표를 나타냅니다.
• getY(): top + translationY의 값을 반환합니다. 이는 translation 후의 Y 좌표를 나타냅니다.

Reference

1. Android Developers - View
2. Stackoverflow

Scope Functions은 객체의 컨텍스트 내에서 코드 블록을 실행할 수 있게 하는 함수입니다. lambda expression이 제공된 객체에서 Scope Function을 호출하면 해당 함수는 일시적인 범위를 형성하며, 이 범위에서는 객체 이름 없이 객체에 접근할 수 있습니다.

Scope Function의 일반적인 형태는 다음과 같습니다.

Person("Alice", 20, "Amsterdam").let {
    println(it)
    it.moveTo("London")
    it.incrementAge()
    println(it)
}

만약 Scope Function을 사용하지 않는다면 위의 코드는 아래와 같이 작성되어야 합니다.

val alice = Person("Alice", 20, "Amsterdam")
println(alice)
alice.moveTo("London")
alice.incrementAge()
println(alice)

Scope Function은 새로운 기술 기능을 도입하지는 않지만 코드를 보다 간결하고 읽기 쉽게 만들 수 있습니다.

Kotlin에서 제공하는 Scope Function으로는 let, run, with, apply 그리고 also가 존재합니다. 기본적으로 이 함수들은 객체의 코드 블럭을 실행한다는 공통점을 갖습니다. 차이점은 코드 블럭 내에서 객체에 어떻게 접근하는지와 블럭 내 코드의 결과가 무엇이냐입니다.

Context object: this or it

Scope Function의 lambda expression 내부에서 컨텍스트 객체는 실제 이름 대신 짧은 참조를 통해 사용가능합니다. 이 짧은 참조는 lambda receiver인 this 혹은 lambda argument인 it입니다.

fun main() {
    val str = "Hello"
    // this
    str.run {
        println("The receiver string length: $length")
        //println("The receiver string length: ${this.length}") // does the same
    }

    // it
    str.let {
        println("The receiver string's length is ${it.length}")
    }
}

this

run, with 그리고 apply는 컨텍스트 객체를 this를 통해 사용합니다. 그래서 객체를 일반적인 클래스 함수 내부에서 사용하는 것처럼 사용할 수 있습니다. 대부분의 경우 객체 멤버에 할당을 할 때 this를 생략할 수 있습니다. 다만 외부 객체나 함수와 구분하기 힘들어지므로 this를 사용하는 것을 권장합니다.

val adam = Person("Adam").apply { 
    age = 20                       // same as this.age = 20 or adam.age = 20
    city = "London"
}

it

let과 also는 컨텍스트 객체를 lambda argument처럼 가지고 있습니다. 따라서 it을 통해 컨텍스트 객체에 접근할 수 있습니다. it은 this보다 짧고 it을 사용한 표현식은 보통 읽기 쉽습니다. 하지만 객체의 함수나 프로퍼티를 호출할 때 this처럼 암시적으로 사용할 수는 없습니다.

fun getRandomInt(): Int {
    return Random.nextInt(100).also {
        writeToLog("getRandomInt() generated value $it")
    }
}

추가로 컨텍스트 객체를 argument로 전달한다면 컨텍스트 객체에 이름을 부여할 수 있습니다.

fun getRandomInt(): Int {
    return Random.nextInt(100).also { value ->
        writeToLog("getRandomInt() generated value $value")
    }
}

Return value

Scope Function은 코드 블럭이 반환하는 결과에서 차이를 보입니다. 따라서 Scope Function을 실행한 뒤 어떤 작업을 하냐에 따라 사용할 Scope Function을 결정합니다.

Context object

apply와 also는 해당 코드 블럭의 컨텍스트 객체를 반환합니다. 따라서 이 두 함수는 같은 객체에 대한 call chain을 가질 수 있습니다.

val numberList = mutableListOf<Double>()
numberList.also { println("Populating the list") }
    .apply {
        add(2.71)
        add(3.14)
        add(1.0)
    }
    .also { println("Sorting the list") }
    .sort()

또한 이들은 return 문에 사용될 수 있습니다.

fun getRandomInt(): Int {
    return Random.nextInt(100).also {
        writeToLog("getRandomInt() generated value $it")
    }
}

Lambda result

let, run 그리고 with는 lambda result를 반환합니다. 따라서 이 두 함수의 결과는 변수에 할당될 수 있습니다.

val numbers = mutableListOf("one", "two", "three")
val countEndsWithE = numbers.run { 
    add("four")
    add("five")
    count { it.endsWith("e") }
}
println("There are $countEndsWithE elements that end with e.")

추가적으로 lambda result는 무시될 수 있으며, Scope Function을 변수에 대한 임시 범위를 생성하는데 사용할 수 있습니다.

val numbers = mutableListOf("one", "two", "three")
with(numbers) {
    val firstItem = first()
    val lastItem = last()        
    println("First item: $firstItem, last item: $lastItem")
}

Functions

let

let은 컨텍스트 객체를 argument(it)처럼 사용할 수 있고 lambda result를 반환합니다. let은 호출 체인의 결과에 대해 하나 이상의 함수를 호출하는데 사용할 수 있습니다.

val numbers = mutableListOf("one", "two", "three", "four", "five")
numbers.map { it.length }.filter { it > 3 }.let { 
    println(it)
    // and more function calls if needed
} 

만약 코드 블럭이 it을 인자로 가지는 함수 하나만 담고 있다면 lambda expression 대신 ::을 사용할 수 있습니다.

val numbers = mutableListOf("one", "two", "three", "four", "five")
numbers.map { it.length }.filter { it > 3 }.let(::println)

let은 종종 non-null 객체에 코드 블럭을 생성할 때 사용합니다. 또 코드 가독성을 높이기 위해 코드 블럭에 지역 변수를 제공할 때 사용합니다.

with

with는 컨텍스트 객체를 argument로 전달하지만 내부에선 this를 통해 사용가능합니다. 그리고 lambda result를 반환합니다. with는 코드 블럭 내에서 lambda result 반환없이 함수를 호출할 때 사용할 것을 추천합니다.

val numbers = mutableListOf("one", "two", "three")
// with this object, do the following.
with(numbers) {
    println("'with' is called with argument $this")
    println("It contains $size elements")
}

run

run은 컨텍스트 객체를 this를 통해 사용하며, lambda result를 반환합니다. run은 코드 블럭 내에 객체 초기화와 반환 값 계산을 둘다 담고 있는 경우 유용합니다.

val service = MultiportService("https://example.kotlinlang.org", 80)

val result = service.run {
    port = 8080
    query(prepareRequest() + " to port $port")
}

// the same code written with let() function:
val letResult = service.let {
    it.port = 8080
    it.query(it.prepareRequest() + " to port ${it.port}")
}

apply

apply는 컨텍스트 객체를 this를 통해 사용하며, 컨텍스트 객체를 반환합니다. apply는 코드 블럭이 값을 반환하지 않고 주로 컨텍스트 객체의 멤버들로 동작하는 경우 사용합니다. 이에 해당하는 예시로는 객체 설정이 있습니다.

// apply the following assignments to the object.
val adam = Person("Adam").apply {
    age = 32
    city = "London"        
}
println(adam)

also

also는 컨텍스트 객체를argument(it)처럼 사용할 수 있고, 컨텍스트 객체를 반환합니다. also는 컨텍스트 객체를 인자처럼 사용하는 액션에 유용합니다. 또 객체의 프로퍼티나 함수에 대한 참조가 아니라 객체 자체에 대한 참조가 필요한 액션에 유용합니다.

val numbers = mutableListOf("one", "two", "three")
// and also do the following with the object.
numbers
    .also { println("The list elements before adding new one: $it") }
    .add("four")

정리

takeIf and takeUnless

추가적으로 Scope Function에는 takeIf와 takeUnless도 존재합니다. 이 함수들은 call chain에 객체의 상태를 확인하는 작업을 추가하는 함수입니다. takeIf는 조건문을 만족하면 해당 객체를 반환하며, 그렇지 않으면 null을 반환합니다. takeUnless는 takeIf와 반대로 동작합니다. 이 두 함수는 컨텍스트 객체를 argument(it)처럼 사용합니다.

val number = Random.nextInt(100)

val evenOrNull = number.takeIf { it % 2 == 0 }
val oddOrNull = number.takeUnless { it % 2 == 0 }
println("even: $evenOrNull, odd: $oddOrNull")

두 함수가 null을 반환할 수 있기 때문에 반환된 값을 사용하려는 경우 null check를 해야합니다. 또 두 함수는 다른 Scope Function과 함께 사용할 때 유용합니다.

fun displaySubstringPosition(input: String, sub: String) {
    input.indexOf(sub).takeIf { it >= 0 }?.let {
        println("The substring $sub is found in $input.")
        println("Its start position is $it.")
    }
}

📖 Reference

Kotlin Language - Scope Functions

❗ 안드로이드 앱 마인드 블루밍의 개발 과정을 포스팅한 글입니다.

🥇 객체 드래그

객체 드래그는 활성 포인터의 최초 위치를 기록📝하고 포인터가 이동한 거리를 계산한 뒤, 개체를 새 위치로 이동시키는 과정을 거쳐 이루어집니다. 단, 이러한 과정 속에서 추가 포인터의 가능성을 올바르게 관리해야 합니다.

❗ 추가 포인터 관리

드래그 작업 중이라면 앱은 손가락👆이 추가로 화면에 놓이더라도 기존의 포인터를 계속 추적해야 합니다. 기존 포인터와 후속 포인터의 구별은 ACTION_POINTER_DOWN 이벤트 및 ACTION_POINTER_UP 이벤트를 통해 할 수 있습니다. 두 이벤트는 onTouchEvent() 콜백에 전달됩니다.

멀티터치 이벤트

• ACTION_DOWN: 화면을 터치하는 첫 번째 포인터의 이벤트. 이 이벤트가 동작을 시작
• ACTION_UP: 마지막 포인터가 화면 밖으로 나갈 때 발생하는 이벤트
• ACTION_MOVE: 누르기 동작 중에 변경사항이 있으면 발생하는 이벤트
• ACTION_POINTER_DOWN: 추가 포인터 발생 이벤트
• ACTION_POINTER_UP: 포인터가 두 개 이상인 상황에서 한 포인터가 위로 올라갔을때 발생하는 이벤트

아래 코드는 첫 번째 포인터와 추가 포인터를 추적하여 객체 이동 위치를 계산하는 코드입니다.

// active pointer: 현재 객체를 이동시키고 있는 포인터
private var mActivePointerId = INVALID_POINTER_ID

override fun onTouchEvent(ev: MotionEvent): Boolean {
    // ScaleGestureDetector가 모든 이벤트를 감시하도록 설정
    mScaleDetector.onTouchEvent(ev)

    // MotionEvent의 작업 가져옴
    val action = MotionEventCompat.getActionMasked(ev)

    when (action) {
        MotionEvent.ACTION_DOWN -> {
            MotionEventCompat.getActionIndex(ev).also { pointerIndex ->
                // 드래그 시작 위치 기록
                mLastTouchX = MotionEventCompat.getX(ev, pointerIndex)
                mLastTouchY = MotionEventCompat.getY(ev, pointerIndex)
            }

            // active pointer 설정
            mActivePointerId = MotionEventCompat.getPointerId(ev, 0)
        }

        MotionEvent.ACTION_MOVE -> {
            // active pointer가 이동한 위치를 기록
            val (x: Float, y: Float) =
                    MotionEventCompat.findPointerIndex(ev, mActivePointerId).let { pointerIndex ->
                        // to: pair를 만드는 키워드
                        MotionEventCompat.getX(ev, pointerIndex) to
                               MotionEventCompat.getY(ev, pointerIndex)
                    }
            // 이동할 위치 계산
            mPosX += x - mLastTouchX
            mPosY += y - mLastTouchY

            // view 무효화. view가 visible 상태이면 곧 `onDraw()`가 자동으로 호출됨
            invalidate()

            // 이동한 위치 기록
            mLastTouchX = x
            mLastTouchY = y
        }

        MotionEvent.ACTION_UP, MotionEvent.ACTION_CANCEL -> {
            // 첫번째 포인터가 사라졌을 때 active pointer가 추가 포인터를 참조하지 않도록 설정
            mActivePointerId = INVALID_POINTER_ID
        }

        MotionEvent.ACTION_POINTER_UP -> {
            MotionEventCompat.getActionIndex(ev).also { pointerIndex ->
                MotionEventCompat.getPointerId(ev, pointerIndex)
                        .takeIf { it == mActivePointerId }
                        ?.run {
                            // active pointer가 위로 올라갔을 때 추가 포인터를 active pointer로 설정
                            val newPointerIndex = if (pointerIndex == 0) 1 else 0
                            mLastTouchX = MotionEventCompat.getX(ev, newPointerIndex)
                            mLastTouchY = MotionEventCompat.getY(ev, newPointerIndex)
                            mActivePointerId = MotionEventCompat.getPointerId(ev, newPointerIndex)
                        }
            }
        }
    }
    return true
}

🥈 드래그하여 화면 이동

드래그를 통한 화면 이동은 사용자의 드래그 모션으로 스크롤이 x축과 y축 모두를 따라 이루어지는 것입니다. 이를 위해 GestureDetector.SimpleOnGestureListener에서 onScroll()을 재정의합니다.

// viewport: 현재 디스플레이 되고 있는 뷰의 도메인과 범위를 표현하는 사각형
private val mCurrentViewport = RectF(AXIS_X_MIN, AXIS_Y_MIN, AXIS_X_MAX, AXIS_Y_MAX)
// 데이터가 그려질 목표 사각형 (픽셀 좌표계)
private val mContentRect: Rect? = null

private val mGestureListener = object : GestureDetector.SimpleOnGestureListener() {
    // ...
    override fun onScroll(
            e1: MotionEvent,
            e2: MotionEvent,
            distanceX: Float,
            distanceY: Float
    ): Boolean {
        // 스크롤링은 픽셀이 아닌 viewport 기반의 수학을 사용 
        mContentRect?.apply {
            // 픽셀 단위를 viewport 단위로 변경
            val viewportOffsetX = distanceX * mCurrentViewport.width() / width()
            val viewportOffsetY = -distanceY * mCurrentViewport.height() / height()

            // viewport를 변경하고 리프레쉬
            setViewportBottomLeft(
                mCurrentViewport.left + viewportOffsetX,
                mCurrentViewport.bottom + viewportOffsetY
            )
        }
        return true
    } 
}

// 현재 viewport를 주어진 x, y 포지션에 따라 설정
private fun setViewportBottomLeft(x: Float, y: Float) {
    /*
    * Constrains within the scroll range. The scroll range is simply the viewport
    * extremes (AXIS_X_MAX, etc.) minus the viewport size. For example, if the
    * extremes were 0 and 10, and the viewport size was 2, the scroll range would
    * be 0 to 8.
    */
    val curWidth: Float = mCurrentViewport.width()
    val curHeight: Float = mCurrentViewport.height()
    val newX: Float = Math.max(AXIS_X_MIN, Math.min(x, AXIS_X_MAX - curWidth))
    val newY: Float = Math.max(AXIS_Y_MIN + curHeight, Math.min(y, AXIS_Y_MAX))

    mCurrentViewport.set(newX, newY - curHeight, newX + curWidth, newY)
    // 화면을 업데이트하기 위해 뷰를 무효화
    ViewCompat.postInvalidateOnAnimation(this)
}

🥉 터치를 사용하여 확장

Android에서는 확장을 위해 ScaleGestureDetector를 제공합니다.

private var mScaleFactor = 1f

private val scaleListener = object : ScaleGestureDetector.SimpleOnScaleGestureListener() {

    override fun onScale(detector: ScaleGestureDetector): Boolean {
        mScaleFactor *= detector.scaleFactor

        // 최대 크기와 최소 크기 제한을 둬야함
        mScaleFactor = Math.max(0.1f, Math.min(mScaleFactor, 5.0f))
        invalidate()
        return true
    }
}

private val mScaleDetector = ScaleGestureDetector(context, scaleListener)

override fun onTouchEvent(ev: MotionEvent): Boolean {
    // ScaleGestureDetector 모든 이벤트를 감지하도록 설정
    mScaleDetector.onTouchEvent(ev)
    return true
}

override fun onDraw(canvas: Canvas?) {
    super.onDraw(canvas)

    canvas?.apply {
        save()
        scale(mScaleFactor, mScaleFactor)
        // onDraw() code goes here
        restore()
    }
}    

📖 Reference

1. Android Developer - 드래그 및 확대
2. Android Developer - 멀티터치 동작 처리하기
3. Example Code

❗ 안드로이드 앱 마인드 블루밍의 개발 과정을 포스팅한 글입니다.

권한 요청

마인드 블루밍은 사진 업로드 혹은 사진·PDF로 내보내기 등의 이유로 외부 저장소📀에 대한 읽기, 쓰기 권한이 필요합니다.

마인드 블루밍에서는 ActivityResult API를 사용하여 권한 요청 로직을 작성✍했습니다.

private val requestMultiplePermissions =
    registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions())
    { permissions ->
        run {
            if (permissions[Manifest.permission.READ_EXTERNAL_STORAGE] == true
                        && permissions[Manifest.permission.WRITE_EXTERNAL_STORAGE] == true) {
                // permission granted
            } else {
                // permission denied
            }
        }
    }

먼저 ActivityResultLauncher 변수를 생성합니다. ActivityResultLauncher는 registerForActivityResult의 반환값으로, 인자로 주어진 ActivityResultContract를 실행하고 해당 작업이 완료되면 callback📞을 받아 처리하는laucher입니다.

여기서는 RequestMultiplePermissions()가 ActivityResultContract이기 때문에 권한 획득 관련 작업🔨을 수행합니다.

private fun setPermissions() {
    if (checkGranted(Manifest.permission.READ_EXTERNAL_STORAGE)
            && checkGranted(Manifest.permission.WRITE_EXTERNAL_STORAGE)) {
        // permission already granted
    } else {
        // permission not granted
        requestMultiplePermissions.launch(
                arrayOf(
                        Manifest.permission.READ_EXTERNAL_STORAGE,
                        Manifest.permission.WRITE_EXTERNAL_STORAGE
                )
        )
    }
}

private fun checkGranted(permission: String): Boolean {
    return ContextCompat.checkSelfPermission(this, permission) == PackageManager.PERMISSION_GRANTED
}

checkSelfPermission() 메소드를 통해 먼저 권한을 이미 획득했는지 확인🧐합니다. 만약 권한을 획득하지 못했다면 ActivityResultLauncher 변수의 launch() 메소드를 통해 권한 획득 관련 작업을 시작합니다.

Can only use lower 16 bits for requestCode Error

ActivityResult API를 사용하여 권한 요청 로직을 개발하던 중 다음과 같은 오류🚫가 발생했습니다.

ActivityResult API의 launch() 메소드를 사용하면 FragmentActivity.java의 checkForValidRequestCode() 메소드에서 requestCode의 하위 16비트만 set되어 있는지 확인🧐합니다. 여기서 requestCode는 ActivityResultRegistry.java에서 자동으로 생성되는 유니크한 String key를 통해 만들어집니다. 그렇기 때문에 상위 16비트에 set된 비트가 존재하는 requestCode가 생성될 수 있고, 위와 같은 오류가 발생하는 것입니다. 😥

이러한 문제를 해결한 것이 바로 androidx.fragment 라이브러리 종속성 ver 1.3.0-alpha05 입니다. 👏

// kotlin - build.gradle(app)
implementation 'androidx.activity:activity-ktx:1.2.0-rc01'
implementation 'androidx.fragment:fragment-ktx:1.3.0-rc01'

📢 결론적으로 ActivityResult API 사용하면서 "Can only use lower 16 bits for requestCode" 오류를 피하기 위해선 위와 같이 1.2.0 버전 이상의 androidx.activity 종속성과 1.3.0-alpha05 버전 이상의 androidx.fragment 종속성 모두 사용해야 합니다.

❗ 안드로이드 앱 마인드 블루밍의 개발 과정을 포스팅한 글입니다.

1. 로딩 화면

로딩 화면에는 앱 아이콘과 앱 타이틀 로고를 배치합니다.

2. 인트로 화면

인트로 화면은 앱을 소개하는 이미지를 배치하고 우측 하단에 페이지를 표시합니다.

3. 아이디어 리스트 화면

기본	선택

앱의 메인 화면이며 탭으로 다이어그램 종류를 구분합니다. 아이디어 리스트 원소를 long touch한 경우 아이디어를 선택하는 로직이 수행됩니다.

추가	검색

우측 하단에 floating button을 누르면 bottom sheet가 올라와 생성할 다이어그램을 선택할 수 있게 합니다. 또 우측 상단에 검색 버튼을 누르면 앱 타이틀 부분이 검색할 수 있는 영역으로 바뀌게 됩니다.

메뉴

좌측 상단에 메뉴 버튼을 누르면 앱 아이콘과 로고, 그리고 앱 버전을 확인할 수 있습니다. 또한 내보내기, 즐겨찾기, 설정, 시리즈 보기 등의 네비게이션 버튼이 존재합니다.

4. 즐겨찾기 / 시리즈 보기 화면

즐겨찾기 혹은 시리즈에 포함된 아이디어 리스트를 볼 수 있는 화면이며 다이어그램 구분이 없습니다.

5. 내보내기 화면

내보낼 아이디어 선택	내보내기
메뉴에서 내보내기를 선택하면 내보낼 아이디어를 선택하는 화면으로 넘어가며, 사진으로 내보낼지 PDF로 내보낼지를 선택한 후 해당 형식으로 내부 저장소에 저장합니다.

6. 설정 화면

설정	정렬 설정	테마 설정

7. 아이디어 보기 화면

8. 아이디어 편집 화면

관심사 분리 🥇

✍ 코드를 작성할 때 Activity 혹은 Fragment와 같은 UI 기반의 클래스는 📌 UI 및 OS 상호작용을 처리하는 로직만 포함해야 합니다. 이는 UI 클래스를 최대한 가볍게 유지하여 Lifecycle 관련 문제를 피하기 위함입니다.

UI 클래스는 무언가를 소유하는 것이 아닌 OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐이며, 따라서 OS는 메모리 부족과 같은 특정 상황이 발생하면 언제든지 UI 클래스를 제거할 수 있습니다.

요약하자면, UI 클래스로부터 UI, OS 상호작용을 제외한 다른 로직을 분리하여 📌 UI 클래스에 대한 의존성을 최소화하는 것이 앱 관리 측면에서 좋습니다. 👍

모델에서 UI 만들기 🥈

UI는 Model에서 만들어져야 합니다. Model은 앱의 데이터 처리를 담당하는 컴포넌트로, 📌 앱의 View 객체 및 앱 컴포넌트와 독립되어 있으므로 앱의 Lifecycle에 영향을 받지 않습니다.

Model은 가급적 지속적인 Model을 사용하는 것이 👍 좋은데, 이는 지속 Model을 사용하면 OS에서 리소스 확보를 위해 앱을 제거해도 사용자 데이터가 삭제되지 않고 네트워크에 문제가 있어도 앱이 계속 작동📳하게 할 수 있기 때문입니다.

AAC란?

AAC(Android Architecture Components)는 테스트와 유지보수가 쉬운 앱을 디자인할 수 있도록 돕는 라이브러리의 모음입니다.

ViewModel 🥇

ViewModel은 앱의 Lifecycle을 고려하여 📌 UI 관련 데이터를 저장하고 관리하는 컴포넌트입니다.

UI Controller로부터 UI 관련 데이터 저장 및 관리를 분리하여 ViewModel이 담당하도록 하면 다음과 같은 문제를 해결🔧할 수 있습니다.

• 안드로이드 프레임워크는 특정 작업이나 완전히 통제할 수 없는 기기 이벤트에 대한 응답으로 UI Controller를 제거하거나 다시 만들 수 있는데, 이런 경우 UI Controller에 저장된 모든 일시적인 UI 관련 데이터가 삭제됩니다. 단순한 데이터의 경우 onSaveInstanceState() 메서드를 사용하여 복구할 수 있지만 대용량의 데이터의 경우엔 불가능합니다.

• UI Controller에서 데이터를 위한 비동기 호출을 한다면 메모리 누수 가능성을 방지하기 위한 많은 유지 관리가 필요하며, 위에서와 같이 데이터를 복귀해야 하는 경우 비동기 호출을 다시해야 해서 리소스가 낭비됩니다.

• UI Controller에서 DB나 네트워크로부터 데이터를 로드하도록 하면 다른 클래스로 작업이 위임되지 않고 단일 클래스가 혼자서 앱의 모든 작업을 처리하려고 할 수 있습니다. 이 경우 테스트가 훨씬 더 어려워집니다.

ViewModel은 ViewModel 클래스를 상속받아 구현합니다.

class MyViewModel : ViewModel() {
    /* by lazy: val 데이터의 늦은 초기화 방법 */
    private val users: MutableLiveData<List<User>> by lazy {
        /* .also: scope function */
        MutableLiveDate().also {
            loadUsers()
        }
    }

    fun getUsers(): LiveData<List<User>> {
        return users
    }

    private fun loadUsers() {
        // Do an asynchronous operation to fetch users.
    }
}

UI 클래스에서는 다음과 같은 방법으로 ViewModel에 접근할 수 있습니다.

class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        /* by viewModels(): model의 getValue/setValue 동작을
                 viewModels의 getValue/setValue의 동작에 위임  */
        val model: MyViewModel by viewModels()
        model.getUsers().observe(this, Observer<List<User>>{ users ->
            // update UI
        })
    }
}

ViewModel 객체는 뷰 또는 LifecycleOwners보다 오래 지속되도록 설계되었으며, ViewModel을 가져올 때 ViewModelProvider에 전달되는 LifecycleOwners에 따라 Lifecycle이 달라집니다. 만약 액티비티가 전달되었다면 액티비티가 종료될 때까지, 프래그먼트가 전달되었다면 프래그먼트가 분리될 때까지 ViewModel은 메모리에 남아 있습니다.

LiveData 🥈

LiveData는 📌 식별 가능한 데이터 홀더 클래스로 다른 앱 컴포넌트의 Lifecycle을 인식하며, 이를 통해 📌 활성 상태에 있는 앱 컴포넌트 옵저버에게만 업데이트 정보를 알립니다.

LiveData를 사용하면 다음과 같은 이점이 있습니다.

• UI와 데이터 상태의 일치 보장: LiveData는 Observer Pattern을 따르며 Lifecycle 상태가 변경될 때마다 Observer 객체에 알립니다. 또 앱 데이터의 변경이 발생할 때마다 관찰자에게 알려 UI를 업데이트할 수 있도록 합니다.
• 메모리 누수 없음: Observer는 Lifecycle 객체에 결합되어 있으며 연결된 객체의 Lifecycle이 끝나면 자동으로 삭제됩니다.
• 중지된 활동으로 인한 비정상 종료 없음: 활동이 백 스택에 있을 때를 비롯하여 Observer가 비활성 상태에 있으면 어떤 LiveData 이벤트도 받지 않습니다.
• Lifecycle을 더 이상 수동으로 처리하지 않음: UI 컴포넌트는 관련 데이터를 관찰하기만 할 뿐 관찰을 중지하거나 다시 시작하지 않으며, LiveData가 이를 자동으로 관리합니다.
• 최신 데이터 유지: 컴포넌트가 비활성화되면 다시 활성화될 때 최신 데이터를 수신합니다.
• 적절한 구성 변경: 기기 회전과 같은 구성 변경으로 인해 액티비티나 프래그먼트가 다시 생성되면 최신 데이터를 즉시 받게 됩니다.
• 리소스 공유: 앱에서 시스템 서비스를 공유할 수 있도록 싱글톤 패턴을 사용하는 LiveData 객체를 확장하여 시스템 서비스를 래핑할 수 있습니다.

LiveData 객체는 다음과 같은 순서로 사용됩니다.

1. ViewModel 클래스 내에서 특정 유형의 데이터를 보유할 LiveData의 인스턴스를 만듭니다.
2. onChanged() 메서드를 정의하는 Observer 객체를 UI Controller에 만듭니다. onChanged() 메서드는 LiveData 객체가 보유한 데이터가 변경될 경우 발생하는 작업을 제어합니다.
3. observe() 메서드를 사용하여 LiveData 객체에 Observer 객체를 연결합니다.
4. LiveData 객체를 업데이트하는 경우 MutableLiveData 클래스는 setValue(T) 또는 postValue(T) 메서드로 LiveData 객체에 저장된 값을 수정합니다.

Room 🥉

Room 라이브러리는 SQLite에 추상화 레이어를 제공하여 원활한 DB 액세스를 지원하고 SQLite를 완벽히 활용할 수 있게 하는 라이브러리입니다.

Room 라이브러리 사용법

Room 라이브러리를 사용하면 앱을 실행하는 기기에서 앱 데이터의 캐시를 만들 수 있으며, 이 캐시를 통해 사용자는 인터넷 연결 여부와 관계없이 앱에 있는 주요 정보를 일관된 형태로 볼 수 있습니다.

📖 Reference

1. Android 아키텍처 구성요소
2. 앱 아키텍처 가이드
3. ViewModel 개요
4. LiveData 개요
5. Room 지속성 라이브러리

❗ 안드로이드 앱 마인드 블루밍의 개발 과정을 포스팅한 글입니다.

1. 무엇을 하는 서비스인가?

마인드 블루밍은 갑자기 떠오른 아이디어💡를 마인드맵 혹은 플로우 차트로 도식화할 수 있는 안드로이드 앱📱입니다.

2. 기본적인 서비스 구조

마인드 블루밍의 가장 기본적인 서비스 구조는 📌"아이디어를 도식화하여 저장하고 저장된 아이디어 보는 것"입니다.

3. 사용자의 예상 사용 방식

4. 마인드맵

🌐 https://www.mindmeister.com/1751527526

5. 어플리케이션 맵

6. 서비스 플로우 차트

7. 화면 흐름도