나만 보는 개발 로그

Medium 으로 이사합니다

DwEnn — Wed, 6 Apr 2022 00:36:02 +0900

Medium 에서 새로 포스팅을 시작하려 합니다.

'나만 보는 개발 로그' 가 아닌 모두가 볼 수 있는 기록을 공유하고 싶어졌습니다.

기존에는 단순 아카이빙용으로 티스토리를 활용하였습니다.(아닌 글들도 존재하지만 소수였지요 ) 이제는 저의 정리 형태를 바꾸어 보려고 합니다. 노션을 아카이빙용으로, medium 을 공유하는 글을 올리는 용도로 활용하고자 합니다.
공유하는 글을 작성하고자 노력함으로써 공부하는 기술에 대한 개요 뿐만 아닌 동작 원리에 대해 이해하고자 합니다.
또한 단순히 어떤 기술의 사용법을 공유하는 것이 아닌 +@ 의 특성을 가지는 글을 작성하고자 합니다.
이를 위해서 기존의 글을 수정, 삭제하는 것보다는 새로운 곳에서 다시 시작하는것이 괜찮겠다고 판단했습니다.
이젠 아래에서 양질의 글을 공유하도록 하겠습니다.

DwEnn – Medium

Read writing from DwEnn on Medium. Android Dev. Every day, DwEnn and thousands of other voices read, write, and share important stories on Medium.

medium.com

DataBinding, Binding 객체 생성

DwEnn — Sun, 11 Jul 2021 20:39:05 +0900

DataBinding 객체 생성 1b2701ed69ce423aa66c3e5f69f25406

DataBinding, Binding 객체 생성

나는 DatabindingUtil 클래스로 bindng 객체를 생성해서 사용하고 있었다.

하지만 다른 사람들이 작성한 databinding 코드들을 보면 여러 방법으로 binding 객체를 생성해주는 것을 보고 내가 제대로 쓰고 있는 것에 대한 의문이 들었다.

inflate(), bind() 의 차이도 궁금하던 차였고 ..

이러한 의문들을 해결하기 위해 대표적인 Activity, Fragment 에서의 사용법을 분석해보았다.

Activity

ActivityMainBinding.inflate(inflater: LayoutInflator)


override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)
}

생성된 Binding 객체의 static api 를 사용하여 레이아웃 inflation

Activity 의 layoutInflater 전달하여 Binding 객체를 생성
Binding 객체의 root view 를 파라미터로 setContentView(view: View) 호출하여 레이아웃 inflation

LayoutInflater : xml 을 View 객체로 변환시켜 준다. 컴파일 시점에 완성된 xml 파일에 대해서만 변환이 가능하다.

DataBindingUtil.setContentView(activity: Activity, int layoutId)


xxxxxxxxxx
override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val binding = DataBindingUtil.setContentView<ActivityMainBinding>(this, R.layout.activity_main)
}

DataBindingUtil 클래스의 static api 를 사용하여 레이아웃 inflation

Activity, layout 의 리소스 아이디를 전달하여 Binding 객체를 생성 및 레이아웃 inflation

ActivityMainBinding.inflate() 와 다르게 setContentView(view: View) 를 호출하지 않는데 메소드의 내부 동작을 살펴보면 그 이유를 알 수 있다.

DataBindingUtil.java


public static <T extends ViewDataBinding> T setContentView(@NonNull Activity activity,
            int layoutId, @Nullable DataBindingComponent bindingComponent) {
        activity.setContentView(layoutId);
        View decorView = activity.getWindow().getDecorView();
        ViewGroup contentView = (ViewGroup) decorView.findViewById(android.R.id.content);
        return bindToAddedViews(bindingComponent, contentView, 0, layoutId);
}

API 내부적으로 파라미터로 전달받은 Activity 의 setContentView() 호출해주고 있다.

왜 이런 차이가 있는 걸까 ?

ActivityMainBinding 클래스와 DataBindingUtil 클래스의 사용 상 차이를 살펴보면, ActivityMainBinding 객체 내에는 resId(?)를 포함하고 있기 때문에 resId 전달 없이 Binding 객체를 생성할 수 있는 것으로 추측된다.

정말 그럴까 ? build 폴더 내 생성된 클래스 파일을 열어 보았다.

ActivityMainBinding.class


xxxxxxxxxx
@NonNull
    public static ActivityMainBinding inflate(@NonNull LayoutInflater inflater) {
        return inflate(inflater, DataBindingUtil.getDefaultComponent());
}
/** @deprecated */
@Deprecated
@NonNull
public static ActivityMainBinding inflate(@NonNull LayoutInflater inflater, @Nullable Object component) {
  return (ActivityMainBinding)ViewDataBinding.inflateInternal(inflater,2131296284,(ViewGroup)null, false, component);
}

API 콜 스택 : inflate(inflater: LayoutInflator) → inflateLayoutInflater inflater, Object component) → static <T extends ViewDataBinding> T inflateInternal(LayoutInflater inflater, int layoutId, ViewGroup parent, boolean attachToParent, Object bindingComponent)

추측한대로 ViewDataBinding.inflateInternal() 호출 시에 전달하는 activity_main.xml 의 layoutId 값이 클래스 파일 내에 정의 되어 있었다.

Fragment, ListView or RecyclerView

Activity 처럼 setContentView() 호출이 필요하지 않고 binding 객체를 생성하여 모든 작업이 가능하다.

FragmentMainBinding.inflate(inflater: LayoutInflator, parent: ViewGroup, attachToParent: Boolean)


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

생성된 Binding 객체의 static api 를 사용하여 View 를 리턴

DataBindingUtil.inflate(inflater: LayoutInflator, int: layoutId, parent: ViewGroup, attachToParent: Boolean)


xxxxxxxxxx
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
  binding = DataBindingUtil.inflate(inflater, R.layout.fragment_main, container, false)
  return binding.root
}

DataBindingUtil 클래스의 static api 를 사용하여 View 를 리턴

DataBindingUtil 은 resId 를 모르기 때문에, FragmentMainBinding.inflate() 와 다르게 추가로 layoutResId 를 전달하는 것 외에는 별다른 특이점은 보이지 않는다.

FragmentMainBinding.bind(view: View)&DataBindingUtil.bind(view: View)

또 다른 Binding 객체를 생성하기 위한 방법으로 bind() 를 사용하는 방법이 있다. inflate() 와는 다르게 이미 inflate 된 view 를 전달 받는 방식이기 때문에 view 만을 파라미터로 받는다.


xxxxxxxxxx
private lateinit var binding : FragmentMainBinding
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
                // LayoutInflater 를 통해 미리 View 를 생성
        val view = inflater.inflate(R.layout.fragment_main, container, false)
        binding = DataBindingUtil.bind(view)!! or
        binding = FragmentMainBinding.bind(view)
        return binding.root
    }

이 처럼 Fragment 에서 사용 가능하고 한 가지 특이점은 DataBindingUtil.bind(view: View) 는 nullable 객체를 리턴한다는 것이다. 때문에 !! 를 추가하여 lateinit 을 적용하였는데,

이것 역시 내부 동작을 보면 이해 가능하다.

FragmentMainBinding.class


xxxxxxxxxx
/** @deprecated */
    @Deprecated
    public static FragmentMainBinding bind(@NonNull View view, @Nullable Object component) {
        return (FragmentMainBinding)bind(component, view, 2131427358);
    }

빌드된 클래스 파일을 보면 view 를 전달 받았지만 내부적으로 resId 를 전달하며 기능을 수행하는 모습이다.

DataBindingUtil.class


xxxxxxxxxx
@Nullable
    public static <T extends ViewDataBinding> T bind(@NonNull View root) {
        return bind(root, sDefaultComponent);
    }

내부 동작을 보면 전달받은 view 의 태그를 통해 DataBinderMapper 에 저장된 binding 객체를 전달하는 동작을 수행한다. 때문에 찾지 못한 경우를 위한 예외 처리로 nullable 을 리턴해주고 있는것 같다.

결론

binding 객체를 생성하기 위한 여러 방법들이 제공되고 있으니 경우에 알맞게 적용하면 된다 !!

...

나는 아래처럼 BaseActivity, BaseFragment 내에 정의해서 사용하고 있다.

(피드백 주시는 고수님 감사합니다.)


xxxxxxxxxx
// BaseActivity
abstract class BaseActivity : AppCompatActivity() {
        protected inline fun <reified T : ViewDataBinding> bindingView(
        @LayoutRes resID: Int
    ): Lazy<T> =
        lazy {
            DataBindingUtil.setContentView<T>(this, resID)
                .apply { this.lifecycleOwner = this@BaseActivity }
        }
}
// BaseFragment
abstract class BaseFragment : Fragment() {
        protected inline fun <reified T : ViewDataBinding> binding(
        lifecycleOwner: LifecycleOwner,
        @LayoutRes resID: Int
    ): Lazy<T> =
        lazy {
            DataBindingUtil.setContentView<T>(this, resID)
                .apply { this.lifecycleOwner = lifecycleOwner }
        }
}

References

https://developer.android.com/topic/libraries/data-binding/generated-binding#create

String API, isBlank() vs isEmpty()

DwEnn — Sun, 14 Jun 2020 18:22:04 +0900

String API, isBlank() vs isEmpty()

우린 Android 에서 java 언어로 String 의 null or empty check 를 TextUtils.isEmpty() 로 하곤 했을 것이다.

코틀린에서는 String 클래스 내 API 로 isBlank() 와 isEmpty() 두 가지를 제공한다.

사용 시 자주 헷갈리는 두 API 차이를 분석해보자.

isBlank()

fun CharSequence.isBlank(): Boolean

문자열이 비어 있거나 공백 문자만으로 구성되어 있으면 true 를 리턴한다.

Kotlin, isBlank

isEmpty()

fun CharSequence.isEmpty(): Boolean

문자열이 비어있으면 true 를 리턴한다.

Kotlin, isEmpty

두 API 에 대한 설명을 코틀린 공식 문서에서 가져왔다.

정의만 보아서는 확실히 이해가 되지 않기 때문에 간단한 테스트를 해보았다.

Test String

val s1 = ""
val s2 = " "
val s3 = "\\n"
val s4 = "NotEmpty"
val s5 = """ 
        
""".trimIndent()

테스트 결과

// isEmpty()
s1 true
s2 false
s3 false
s4 false
s5 false

// isBlank()
s1 true
s2 true
s3 true
s4 false
s5 true

결론

isEmpty() 는 단순히 문자열이 비어 있는지 여부를 검사하며,

isBlank() 는 문자열이 개행 문자를 포함하고 있는지 여부까지 검사한다.

즉, 아래의 두 결과는 일치한다는 것을 알 수 있다.

val s2 = " "
println("s2 ${s2.isBlank()}")   // print true
println("s2 ${s2.trim().isEmpty()}")   // print true

[Android] getLocationOnScreen vs getLocationInWindow()

DwEnn — Sun, 19 Jan 2020 17:00:18 +0900

getLocationOnScreen vs getLocationInWindow()

두 메소드 모두 뷰의 좌표값을 얻기 위해 종종 쓰는 메소드이다.

둘의 차이를 비교하기 전에 Android Developers 에서의 정의를 살펴보자.

public void getLoactionInWindow(int[] outLocation)

@param outLocation int : 좌표를 보유할 두 정수 배열

window 에서 view 의 좌표를 계산한다. 메소드가 리턴 된 후, 배열에는 x 밑 y 위치가 순서대로 포함된다.

public void getLocationOnScreen(int[] outLocation)

@param outLocation int : 좌표를 보유할 두 정수 배열

screen 에서 view 의 좌표를 계산한다. 메소드가 리턴 된 후, 배열에는 x 밑 y 위치가 순서대로 포함된다.

[참조] https://developer.android.com/reference/android/view/View

정의된 문서를 보면, 좌표값을 가져오는 기준이 window / screen 의 차이라는 것을 알 수 있다.

그렇다면 window 영역과 screen 영역의 다른점은 무엇일까 ?

이곳 을 보면 아래와 같이 설명하고 있다.

|--phone screen-----activity window---| 
|--------status bar-------------------| 
|                                     | 
|                                     | 
|-------------------------------------|

우리가 보는 휴대폰 화면은 이와같은 영역으로 구분되며,

getLocationOnScreen() 은 phone screen 을

getLocationInWindow() 는 activity window 를 기준으로 한다고 한다.

하지만 이것만 보고는 명확히 차이를 인지할수가 없었고 다른 답변을 보고 차이를 인지할 수 있었는데, 이와 같이 설명하고 있다.

일반적으로 window 의 크기는 screen 크기와 동일하기 때문에 getLocationOnScreen() 과 getLocationInWindow() 는 대부분 같은 값을 리턴한다. 그러나 때때로 window 가 screen 보다 작을 때가 있다. ( 예, dialog 나 custom system keyboard 에서 )
그렇기에 원하는 좌표가 screen 과 관계가 있다면, 대부분 activity 에서, getLocationOnScreen() 을 쓰는것이 좋고
만약 screen 보다 window 의 view 를 사용하는 경우, dialog 나 custom keyboard, getLocationInWindow() 를 사용하는 것이 적절하다.

간단한 테스트를 해보고 알맞게 사용해보자.

screen 과 window 의 크기가 동일한 activity 를 만들고

onCreate() 에서 이와같이 로그를 찍었다.

        final Button btn = (Button) findViewById(R.id.dt_btn);
        btn.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                int[] loc = new int[2];
                int[] loc1 = new int[2];

                btn.getLocationInWindow(loc);
                Log.e(TAG, "loc in window : " + loc[0] + ", " + loc[1]);

                btn.getLocationOnScreen(loc1);
                Log.e(TAG, "loc on screen : " + loc1[0] + ", " + loc1[1]);

                int left = btn.getLeft();
                int top = btn.getTop();
                int right = btn.getRight();
                int bottom = btn.getBottom();
                Log.e(TAG, "btn left : " + left + ", right : " + right + ", top : " + top + ", bottom : " + bottom);
            }
        });

여기서 주의할 점이 onCreate() 시점에 해당 뷰의 좌표값을 얻으려 하면 0 을 리턴한다는 것이다.

뷰가 완전히 그려지기 이전에 좌표값을 구하려하기 때문이라는데 button 의 onclick event 로 값을 얻어오는 것으로 구현하여 해결하였다.

이 테스트를 진행하며 getLeft(), getRight() .. 값도 테스트 하였는데,

이 메소드들은 해당 뷰와 부모 뷰와의 관계 값을 리턴해준다.

loc in window : 520, 1248
loc on screen : 520, 1248
btn left : 520, right : 920, top : 928, bottom : 1120

결과를 보면 두 메소드 모두 같은 좌표 값을 리턴해준다.

다음 테스트로 window 와 screen 이 크기가 다른 경우를 보기 위해

button 의 크기만을 window 로 가지는 custom dialog 를 만들어 테스트 해보았다.

로그를 찍는 코드는 위와 동일하다.

loc in window : 64, 64
loc on screen : 520, 1136
btn left : 0, right : 400, top : 0, bottom : 192

두 메소드가 다른 좌표값을 리턴해주는 것을 확인할 수 있다.

getLocationOnScreen() 은 기존과 유사한 좌표값을 주지만 getLoccationInWindow() 는 생성된 custom dialog 의 window 영역 내에서 view 좌표 값을 리턴해준다.

마찬가지로, left/right/top/bottom 값도 부모 뷰의 크기 변화에 따라 값이 달라진 것을 알 수 있다.

위 내용을 토대로 Window 와 Screen 의 차이를 이해하고 상황에 맞는 메소드를 쓰도록 해보자

[Android] Architecture Components 사용 시의 5가지 일반적인 실수

DwEnn — Sun, 20 Oct 2019 18:43:43 +0900

Architecture Components 사용 시의 5가지 일반적인 실수

주의 : 이 글은 원문이 존재하는 글로, 본인은 그저 번역 / 의역한 것일뿐임을 알림.

원문 : https://proandroiddev.com/5-common-mistakes-when-using-architecture-components-403e9899f4cb

다소 심각한 결과를 초래하는 것들 - 만약 당신이 이러한 실수들을 저지르지 않더라도, 언젠가 같은 문제에 직면하는 것을 피하기 위해 명심할 가치가 있다. 이 글을 아래의 내용들을 설명한다.

Leaking LiveData observers in Fragments
Reloading data after every rotation
Leaking ViewModels
Exposing LiveData as mutable to Views
Creating ViewModel's dependencies after every configuration change

1. Leaking LiveData observers in Fragments

fragment 는 까다로운 lifecycle 을 가지고 있고 fragment 가 detach 또는 re-attach 될 때 항상 실제로 파괴되지 않는다. 예로, configuration change 가 발생하는 동안 Fragment 는 파괴되지 않는다.configuration change 동안 fragment 의 instance 는 살아남고 오직 view 만 파괴된다. 따라서 onDestroy() 는 호출되지 않고 DESTROYED 상태에 도달하지 않는다.

이 문제는 우리가 LiveData 를 아래와 같이 onCreateView() 에서 옵저빙을 시작하거나, ( 때떄로 onActivityCreated() 에서도 ) LifecycleOwner 로 fragment 를 전달할 때 발생한다.

class BooksFragment: Fragment() {

    private lateinit var viewModel: BooksViewModel

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, 
                              savedInstanceState: Bundle?): View? {
        return inflater.inflate(R.layout.fragment_books, container)
    }

    override fun onActivityCreated(savedInstanceState: Bundle?) {
        super.onActivityCreated(savedInstanceState)
        viewModel = ViewModelProviders.of(this).get(BooksViewModel::class.java)

        // Risky: Passing Fragment as LifecycleOwner
        viewModel.liveData.observe(this, Observer { updateViews(it) })  
    }
    
    ...
}

fragment 의 LifecycleOwner 가 DESTROYED 상태에 도달하지 않았기 때문에 기존의 observer instance 를 제거하기도 전에 fragment 가 re-attach 될 때마다 observer 의 새로운 instance 를 전달할 것이다.

결국 onChange() 에서 같은 시점, 같은 코드에서 활성화되어 여러번 실행되는 옵저버의 수가 늘어나는 결과를 초래한다.

해당 이슈는 본래 여기에 보고되었으며, 더 자세한 설명은 여기에서 찾을 수 있다.

권장 솔루션은 support library 28.0.0, AndroidX 1.0.0 에 추가된 getViewLifecycleOwner() 또는 getViewLifecycleOwnerLiveData() 를 통해 fragment 의 view lifecycle 을 사용하는 것이다.

그렇게 함으로 LiveData 는 fragment 의 view 가 파괴될 때마다 observer 를 제거할 것이다.

2. Reloading data after every rotation

우리는 Activity 의 onCreate() 혹은 Fragment 의 onCreateView() 메소드에 초기화 로직을 배치한다.

그렇기에 그 시점에 ViewModel 의 데이터를 불러와 연결하는것이 매력적으로 느껴질 수 있다.

하지만 당신의 코드에 따라, ViewModel 이 사용되고 있음에도 화면이 회전될 때마다 데이터가 다시 로드 될 가능성이 있다.

그것은 대부분이 무의미하고 의도하지 않은 작업일 것이다.

예제 :


class ProductViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val productDetails = MutableLiveData<Resource<ProductDetails>>()
    private val specialOffers = MutableLiveData<Resource<SpecialOffers>>()

    fun getProductsDetails(): LiveData<Resource<ProductDetails>> {
        // Loading ProductDetails from network/database
        repository.getProductDetails()  
        // Getting ProductDetails from repository and updating productDetails LiveData
        ...                             
        return productDetails
    }

    fun loadSpecialOffers() {
        // Loading SpecialOffers from network/database
        repository.getSpecialOffers()   
        // Getting SpecialOffers from repository and updating specialOffers LiveData
        ...                             
    }
}

class ProductActivity : AppCompatActivity() {

    lateinit var productViewModelFactory: ProductViewModelFactory

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val viewModel = ViewModelProviders.of(this, productViewModelFactory).get(ProductViewModel::class.java)

        // (probable) Reloading product details after every rotation
        viewModel.getProductsDetails().observe(this, Observer { /*...*/ })  
        // (probable) Reloading special offers after every rotation
        viewModel.loadSpecialOffers()                                       
    }
}

이 해결방안 역시 당신의 코드에 따라 다르다. 예제로 보면, repository 가 데이터를 캐싱하는 경우에 위 코드는 정상일 수 있다.

다른 해결방안은 아래와 같다.

LiveData 와 비슷한 AbsentLiveData 를 사용, 데이터가 세팅되지 않았을 경우에만 로딩을 시작
OnClickListener 에서 실제로 데이터가 필요한 경우에만 로딩을 시작
제일 간단한 방법으로, ViewModel 의 초기화 시점에 로딩을 하고 getter 로 LiveData 를 제공

class ProductViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val productDetails = MutableLiveData<Resource<ProductDetails>>()
    private val specialOffers = MutableLiveData<Resource<SpecialOffers>>()

    init {
        // ViewModel is created only once during Activity/Fragment lifetime
        loadProductsDetails()           
    }

    // private, just utility method to be invoked in constructor
    private fun loadProductsDetails() { 
        // Loading ProductDetails from network/database
        repository.getProductDetails()  
        // Getting ProductDetails from repository and updating productDetails LiveData
        ...                             
    }

    // public, intended to be invoked by other classes when needed
    fun loadSpecialOffers() {           
        // Loading SpecialOffers from network/database
        repository.getSpecialOffers()   
        // Getting SpecialOffers from repository and updating _specialOffers LiveData
        ...                             
    }

    // Simple getter
    fun getProductDetails(): LiveData<Resource<ProductDetails>> {   
        return productDetails
    }

    // Simple getter
    fun getSpecialOffers(): LiveData<Resource<SpecialOffers>> {     
        return specialOffers
    }
}

class ProductActivity : AppCompatActivity() {

    lateinit var productViewModelFactory: ProductViewModelFactory

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val viewModel = ViewModelProviders.of(this, productViewModelFactory).get(ProductViewModel::class.java)

        // Just setting observer
        viewModel.getProductDetails().observe(this, Observer { /*...*/ })    
        // Just setting observer
        viewModel.getSpecialOffers().observe(this, Observer { /*...*/ })     

        button_offers.setOnClickListener { viewModel.loadSpecialOffers() }
    }
}

3. Leaking ViewModels

ViewModel 에 view 참조를 전달하지 말라는것은 이미 강조되어 왔다.

주의 : ViewModel 은 activity context 를 가질 수 있는 view, lifecycle 또는 class 를 절대 참조해서는 안 된다.

하지만 우리는 다른 class 들에 ViewModel 의 참조를 전달하는 것 또한 조심해야한다.

activity 혹은 fragment 가 종료될 때, activity 보다 오래 살아남을 수 있는 어떤 객체에서도 ViewModel 이 참조되어서는 안되며, ViewModel 은 올바르게 가비지 콜렉팅 되어야 한다.

아래 예제는 싱글톤 스코프 내에서 repository 에 ViewModel listener 를 전달한고 삭제하지 않는다.

@Singleton
class LocationRepository() {

    private var listener: ((Location) -> Unit)? = null

    fun setOnLocationChangedListener(listener: (Location) -> Unit) {
        this.listener = listener
    }

    private fun onLocationUpdated(location: Location) {
        listener?.invoke(location)
    }
}


class MapViewModel: AutoClearViewModel() {

    private val liveData = MutableLiveData<LocationRepository.Location>()
    private val repository = LocationRepository()

    init {
        // Risky: Passing listener (which holds reference to the MapViewModel)
        repository.setOnLocationChangedListener {   
            // to singleton scoped LocationRepository
            liveData.value = it                     
        }
    }
}

해결방안으로 onCleared() 메소드를 이용하여 listener 를 제거하고 이를 repository 에 WeakReference 로 저장하며 LiveData 를 사용함으로 repository 와 ViewModel 간의 통신을 하는 것이다.

이를 통해 정학환 가비지 콜렉팅을 보장할 수 있다.


@Singleton
class LocationRepository() {

    private var listener: ((Location) -> Unit)? = null

    fun setOnLocationChangedListener(listener: (Location) -> Unit) {
        this.listener = listener
    }

    fun removeOnLocationChangedListener() {
        this.listener = null
    }

    private fun onLocationUpdated(location: Location) {
        listener?.invoke(location)
    }
}


class MapViewModel: AutoClearViewModel() {

    private val liveData = MutableLiveData<LocationRepository.Location>()
    private val repository = LocationRepository()

    init {
        // Risky: Passing listener (which holds reference to the MapViewModel)
        repository.setOnLocationChangedListener {   
            // to singleton scoped LocationRepository
            liveData.value = it                     
        }
    }
  
    // GOOD: Listener instance from above and MapViewModel
    override onCleared() {                            
        //       can now be garbage collected
        repository.removeOnLocationChangedListener()  
    }  
}

4. Exposing LiveData as mutable to views

이건 버그는 아니지만 관심사 분리에 어긋난다.

fragment, activity 의 view 는 LiveData 와 그에 따른 자신의 상태를 업데이트 할 수 없어야 한다.

그것은 오직 ViewModel 의 책임이기 때문이다. view 들은 LiveData 를 단지 observe 할 수 있어야 한다.

그러므로 우리는 MutableLiveData 를 getter 혹은 베이킹 필드로 캡슐화하여 접근하여야 한다.

class CatalogueViewModel : ViewModel() {

    // BAD: Exposing mutable LiveData
    val products = MutableLiveData<Products>()


    // GOOD: Encapsulate access to mutable LiveData through getter
    private val promotions = MutableLiveData<Promotions>()

    fun getPromotions(): LiveData<Promotions> = promotions


    // GOOD: Encapsulate access to mutable LiveData using backing property
    private val _offers = MutableLiveData<Offers>()
    val offers: LiveData<Offers> = _offers


    fun loadData(){
        // Other classes can also set products value
        products.value = loadProducts()     
        // Only CatalogueViewModel can set promotions value
        promotions.value = loadPromotions() 
        // Only CatalogueViewModel can set offers value
        _offers.value = loadOffers()        
    }
}

5. Creating ViewModel's dependencies after every configuration change

ViewModel 은 화면 회전과 같은 configuration change 가 발생할 때 살아남기 때문에

변경이 발생할 때마다 종속성을 생성하는 것은 중복되며, 특히 종속성 생성자에 로직이 있는 경우 의도하지 않은 결과를 야기한다.

매우 명확히 들릴 수 있지만, ViewModelFactory 를 사용할 때 간과하기 쉬운 부분이다.

ViewModel 은 대개 create() 과 동일한 종속성을 가진다.

ViewModelProvider 는 ViewModelFactory 의 instance 가 아닌 ViewModel 의 instance 를 보존한다.

아래의 코드를 보자.


class MoviesViewModel(
    private val repository: MoviesRepository,
    private val stringProvider: StringProvider,
    private val authorisationService: AuthorisationService
) : ViewModel() {
    
    ...
}


// We need to create instances of below dependencies to create instance of MoviesViewModelFactory
class MoviesViewModelFactory(   
    private val repository: MoviesRepository,
    private val stringProvider: StringProvider,
    private val authorisationService: AuthorisationService
) : ViewModelProvider.Factory {

    // but this method is called by ViewModelProvider only if ViewModel wasn't already created
    override fun <T : ViewModel> create(modelClass: Class<T>): T {  
        return MoviesViewModel(repository, stringProvider, authorisationService) as T
    }
}


class MoviesActivity : AppCompatActivity() {

    @Inject
    lateinit var viewModelFactory: MoviesViewModelFactory

    private lateinit var viewModel: MoviesViewModel

    // Called each time Activity is recreated
    override fun onCreate(savedInstanceState: Bundle?) {    
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_movies)

        // Creating new instance of MoviesViewModelFactory
        injectDependencies() 

        viewModel = ViewModelProviders.of(this, viewModelFactory).get(MoviesViewModel::class.java)
    }
    
    ...
}

매 번 configuration change 가 발생 시 우리는 새로운 ViewModelFactory instance 를 만들고 불필요한 새로운 종속성을 만들 것이다.


class MoviesViewModel(
    private val repository: MoviesRepository,
    private val stringProvider: StringProvider,
    private val authorisationService: AuthorisationService
) : ViewModel() {
    
    ...
}


class MoviesViewModelFactory(
    // Passing Providers here 
    private val repository: Provider<MoviesRepository>,             
    // instead of passing directly dependencies
    private val stringProvider: Provider<StringProvider>,           
    private val authorisationService: Provider<AuthorisationService>
) : ViewModelProvider.Factory {

    // This method is called by ViewModelProvider only if ViewModel wasn't already created
    override fun <T : ViewModel> create(modelClass: Class<T>): T {  
        return MoviesViewModel(repository.get(),                    
                               // Deferred creating dependencies only if new insance of ViewModel is needed
                               stringProvider.get(),                
                               authorisationService.get()
                              ) as T
    }
}


class MoviesActivity : AppCompatActivity() {

    @Inject
    lateinit var viewModelFactory: MoviesViewModelFactory

    private lateinit var viewModel: MoviesViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_movies)
      
        // Creating new instance of MoviesViewModelFactory
        injectDependencies() 

        viewModel = ViewModelProviders.of(this, viewModelFactory).get(MoviesViewModel::class.java)
    }
    
    ...
}

[Java] String.contains() with empty String, return true

DwEnn — Thu, 3 Oct 2019 17:29:13 +0900

String.contains() with empty String, return true

java 에서 String.contains() 를 사용할 때 내가 발생했던 이슈에 대해 다뤄보려한다.

아래의 코드를 보자.

String myString1="foo";
String myString2="";
if(myString1.contains(myString2)){
    System.out.println("Am here");
} else {
    System.out.println("Am not here");
}

foo 가 "" ( empty string ) 을 포함하냐는 것인데, 언뜻 보면 false 로 "Am not here" 가 실행될 것 같지만

컴파일 해보면 "Am here" 가 출력된다.

그 이유를 찾아보니 모든 문자열의 시작과 끝에는 공백 character 가 존재하기 때문이라고 한다.

이러한 이유로 String.contains(), String.indexOf() 를 빈 문자열과 같이 사용할 경우 원치 않는 결과를 발생 시킬 수 있다.

References

https://stackoverflow.com/questions/24007818/why-string-contains-with-empty-string-returns-true/24007827
https://jeeva-paramasamy.blogspot.com/2012/04/contains-and-indexof-in-java-will.html
https://stackoverflow.com/questions/18399189/why-does-contains-method-find-empty-string-in-non-empty-string-in-java

[Android] Message.obtain() vs Handler.obtainMessage()

DwEnn — Thu, 3 Oct 2019 17:28:15 +0900

Message.obtain() vs Handler.obtainMessage()

Handler 에 대해 찾다가 Message 객체를 얻어오는 두 메소드를 알게 되었다.

두 메소드의 차이를 보려고 Android Developers 문서를 보았는데 둘 다 Global Message Pool 의 인스턴스를 반환한다고 명시되어 있었다.

무언가 다른 점이 있을것 같아 찾아본 내용들에 대해서 정리하고자 한다.

Message.obtain()

Android Developers 에서 찾아보면 이렇게 정의되어있다.

obtain
static fun obtain(): Message!
Return a new Message instance from the global pool. Allows us to avoid allocating new objects in many cases.
Global Message Pool 에서 새 Message 인스턴스를 반환한다. 많은 경우 새로운 객체의 할당을 피할 수 있다.

Global Message Pool

나는 정의를 보면서 global message pool 이 무엇인지가 궁금했는데, Message.java 코드를 살펴보면 알 수 있다.

private static Message sPool;   // Message pool
private static final int MAX_POOL_SIZE = 50; // Message pool max size

public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            Message m = sPool;
            sPool = m.next;
            m.next = null;
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

코드를 보면 단순히 Message class 내의 재활용되는 정적 메시지 객체이다.

그런데 13번 라인을 보면 sPool == null 일 때, 새 Message 객체를 생성하여 리턴하는데 일반적으로 알고있는 싱글턴과 다르게 설계되어있다. 이는 Message.recycle() 을 보면 알 수 있다.

/**
    * Return a Message instance to the global pool.  You MUST NOT touch
    * the Message after calling this function -- it has effectively been
    * freed.
    */
public void recycle() {
    clearForRecycle();

    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) {
            next = sPool;
            sPool = this;
            sPoolSize++;
        }
    }
}

위 메소드를 통해 메시지 인스턴스를 global message pool 에 되돌린다.

recycle() 은 Handler.dispatchMessage(Message msg) 가 한 번 호출되고 난 뒤에 호출된다고 한다.

Handler.dispatchMessage(Message msg)
Looper.loop() 에서 MessageQueue 에서 Message 를 가져와 msg.target.dispatchMessage(msg) 를 호출하여 Message 를 처리한다. ( tartget = handler )
자세한 내용은 Handler, Looper 의 구조에 대해 추가 포스팅하려 한다.

그럼 Message.obtain() 에 대해서 간략히 보았고 다음은 Handler.obtainMessage() 에 대해 보면서 서로 간 차이점을 점층적으로 분석해 보자.

Handler.obtainMessage()

마찬가지로 Android Developers 문서를 보자.

obtainMessage
public final Message obtainMessage()
Returns a new Message from the global message pool. More efficient than creating and allocating new instances. The retrieved message has its handler set to this instance (Message.target == this). If you don't want that facility, just call Message.obtain() instead.
Global Message Pool 에서 새 Message 를 반환한다. 새 인스턴스를 생성하고 할당하는 것 보다 더 효율적이다. 검색된 Message 에는 Message 의 Hander 가 설정되어있다. (Message.target == this) 만약 그것을 원하지 않는다면 Message.obtain() 을 대신 사용하라.

이것 또한 global message pool 에서 새 message 객체를 반환한다고 설명하고 있다.

코드 상에서 다른 점을 살펴보자.

 public final Message obtainMessage()
{
    return Message.obtain(this);
}

Handler.obtainMessage() 에서 Message.obtain() 의 결과를 리턴하고 있는걸 볼 수 있다.

this 로 Handler 자신을 파라미터로 넘겨주고 있는데, 이번에는 Message.obtain(Handelr handler) 의 코드를 보자.

public static Message obtain(Handler h) {
    Message m = obtain();
    m.target = h;
    
    return m;
}

Message.obtain() 으로 가져온 Message 객체에 target handler 를 전달 받은 handler 로 지정하는 것을 볼 수 있다.

이 코드를 보고 나니 Android Developers 문서 설명이 이해가 된다.

검색된 Message 에는 Message 의 Handler 가 설정되어있다.

이제 알게된 내용을 정리해보자. Message.obtain(), Handler.obtainMessage() 모두 global Message Pool 에서 재활용 되는 새 Message 객체를 받아온다.

다른 점은 Handler.obtainMessage() 는 호출하는 Handler 로 target hander 가 지정된 Message 객체가 반환 된다는 것이다.

그런데 target handler 가 지정되면 무엇이 다른거지 ?

또 다시 구글링해보자.

obtain obtainMessage 를 키워드로 검색해 보았지만 좋은 글은 찾지 못하였다.

http://spatula.net/mt/blog/2015/02/androids-messageobtain-vs-handlerobtainmessage-from-safeasynctask.html

분석해 놓은 글을 하나 찾았지만 명확히 이해가 되지 않았고 참고를 위해 적어 두어야겠다.

검색결과 많은 의견이 Handler.obtainMessage() 를 쓰라는 것이 많았다.

이유에 대해서는 추후 더 조사해보도록 해야겠다.

References

http://androidxref.com/4.4.2_r1/xref/frameworks/base/core/java/android/os/Message.java#106
https://developer.android.com/reference/kotlin/android/os/Message?hl=en#obtain()
http://spatula.net/mt/blog/2015/02/androids-messageobtain-vs-handlerobtainmessage-from-safeasynctask.html
https://stackoverflow.com/questions/49940878/when-message-object-is-recycled-by-android-an-android-system/49941095

[Android] Handler ( sendMessage, post ) / runOnUiThread

DwEnn — Thu, 3 Oct 2019 17:26:53 +0900

Handler ( sendMessage, post ) / runOnUiThread

Handler ( sendMessage, post )
runOnUiThread
References

안드로이드에서 Thread 를 Main Thread 로 이관하는 작업 도중 문득 Handler ( sendMessage, post ) / runOnUiThread 의 차이점이 궁금해져서 찾아보았다.

각각의 사용법에 대해서는 잘 정리해놓은 글들이 많이 있고 내용이 길어질 수 있으니 사용법 관련해서는 적지 않았다.

Handler ( sendMessage, post )

sendMessage()

public final boolean sendMessage(Message msg)
{
    return sendMessageDelayed(msg, 0);
}

Handler.java 내에 정의된 sendMessage() 메소드이다.

[ 출처 : https://itmining.tistory.com/5 ]

sendMessage() 는 알다시피 위와 같이 처리된다.

잠깐 딴 소리 좀 하자면

Message msg = new Message(); // 내가 주로 사용하던 방식
Message msg = handler.obtainMessage(); // 예제에서 찾은 방식
Message 객체 생성 시 나는 주로 1번 라인 방식으로 사용하였었는데
찾다보니 2번 라인의 방식으로 예제가 많이 나와있었다. 무엇이 다른가 하여 Android Devleopers 사이트에서 설명을 찾아보니
obtainMessage() 는 Global Message Pool 에서 새 Message 객체를 반환하며, 새 인스턴스를 생성하고 할당하는 것보다 효율적이라고 한다.

Message.obtain() vs Handler.obtainMessage()
Handler.obtainMessage() 는 자동으로 traget handler 가 호출하는 handler 로 정해지고
Message.obtain() 은 target handler 를 지정해주어야 한다.
둘다 메시지 풀에서 객체를 가져온다는데 ?? 이 내용은 따로 포스팅 해야겠다.

그렇다면 post 메소드의 내부는 어떨까 ?

post()

 public final boolean post(Runnable r)
{
    return  sendMessageDelayed(getPostMessage(r), 0);
}

Handler.java 에 정의된 post() 이다.

sendMessage() 와 동일하게 sendMessageDelayed(Message, long) 를 호출하는 것을 볼 수 있다. Message 객체를 전달할 때 다른 것이 보이는데 getPostMessage() 를 살펴보자.

private static Message getPostMessage(Runnable r) 
{
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

Message.obtain() 으로 Message Pool 에서 메시지 객체를 가져오고

전달 받은 Runnable 객체를 콜백으로 등록한 뒤 해당 Message 객체를 리턴해준다.

그렇다면 sendMessage() 와 post() 는 어떤 Message 객체를 쓰느냐의 차이가 있을 뿐, 내부적으로 동일하게 sendMessageDelayed(Message, long) 를 호출한다는 것을 알 수 있다.

runOnUiThread

public final void runOnUiThread(Runnable action) 
{
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action);
    } else {
        action.run();
    }
}

Activity.java 내에 정의된 runOnUiThread() 메소드이다.

만약 현재 Thread 가 UI Thread 가 아니면, handler 의 post 를 실행하고

현재 Thread 가 UI Thread 라면, 전달받은 Runnable 작업을 실행, run() 시켜준다.

final Handler mHandler = new Handler();

Handler 는 위와 같이 전역 변수 final 로 관리되고 있고

mUiThread = Thread.currentThread(); // Thread mUiThread

mUiThread 는 Activity.attach() 에서 이처럼 초기화 된다.

결국 runOnUiThread 는 Handler.post() 로 동작한다는걸 알 수 있다.

References

https://sdw8001.tistory.com/119

DI : Dependency Injection ( 의존성 주입 )

DwEnn — Mon, 16 Sep 2019 22:53:29 +0900

DI : Dependency Injection ( 의존성 주입 )

What is DI ?
References

What is DI ?

의존성 주입을 이해하기 위해 의존성의 개념부터 짚고 가겠다.

Dependency ( 의존성 ) ?

SOLID 에서 Dependency Inversion Principle ( DIP, 의존 관계 역전 원칙 ) 을 이해하고 있다면 의존성을 이해하기 쉽다. DIP 에 대해서는 추후 포스팅 할 예정이다.

DIP 는 이렇게 정의하고 있다.

고차원의 모듈은 저차원의 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화 된 것에 의존해야 한다.
추상화 된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화 된 것에 의존해야 한다.
고수준 모듈 : 어떤 의미가 있는 단일 기능을 제공하는 모듈
저수준 모듈 : 고수준 모듈의 기능을 구현하기 위해 필요한 하위 기능을 실제로 구현한 것

말이 어려우니 예제 코드로 살펴보자. ( 출처 : http://wonwoo.ml/index.php/post/1717 )

아래 예제는 어떤 바이트 데이터를 읽어와 특정한 데이터로 결과를 반환 하는 예제이다.

여기서 고수준 모듈은 바이트 데이터를 읽어와 특정한 데이터로 결과를 반환하는 것이다.

그리고 저수준 모듈은 파일에서 바이트 데이터를 읽어오고, Json 데이터로 겨로가를 반환하는 것이다.

 /*
     고수준 모듈
  */
 class Response {
     private JsonConverter jsonConverter = new JsonConverter();
 
     public String response() {
         byte[] bytes = null;
         return jsonConverter.convert(bytes);
     }
 }
 
 /*
     저수준 모듈
  */
 class JsonConverter {
     public String convert(byte[] bytes) {
         // json converting ...
         return "json txt";
     }
 }

고수준 모듈인 Response 가 저수준 모듈인 JsonConverter 의 구현에 의존되고 있다. 즉, DIP 원칙을 어기고 있다.

이를 해결하기 위한 DI 는 계속해서 설명하기로 하고 먼저,

의존성 ( Dependency ) 가 위험한 이유에 대해서 알고 가자.

하나의 모듈이 바뀌면 의존한 다른 모듈까지 변경이 이루어지기 때문
테스트 가능한 어플을 만들 때 의존성이 있으면 유닛 테스트 작성이 어렵다
( 유닛 테스트의 목적 자체가 다른 모듈로부터 독립적으로 테스트하는 것을 요구하기 때문에 )

DI ?

이제 저런 의험성을 없애기 위해 DI 가 필요하다는 것 까지 이해가 되었다.

그렇다면 DI 의 정의는 무엇일까 ?

프로그래밍에서 구성요소간의 의존 관계가 소스코드 내부가 아닌 외부의 설정 파일 등을 통해 정의되게 하는 디자인 패턴 중 하나.
[ 출처 : https://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EC%84%B1_%EC%A3%BC%EC%9E%85 ]

위 링크를 타고 가보면 UML 로 간단히 정리가 되어있지만, 나는 UML 과 친숙하지 않아서 예제 코드로 이해했다.

위키에서 설명하는 DI 의 이점으로 모듈간의 결합도 저하, 코드의 재사용성, 단위 테스트의 편의성 향상 등이 있다.

또한, DI 의 적용 유형으로 생성자 주입, 세터를 통한 주입, 인터페이스를 통한 주입을 제시하였다. 이 내용은 위키에 잘 나와있으니 링크를 통해 참고하자.

그럼 아래의 예제 코드를 부며 DI 를 이해해 보자.

https://faith-developer.tistory.com/147

Dagger 에서도 사용하고 있는 Coffee Maker 예제라고 한다. 이 예제를 보면 알 수 있듯이, DI 의 핵심은 의존성 주입으로 인한 모듈간 결합도 저하 이다.

References

https://gmlwjd9405.github.io/2018/11/09/dependency-injection.html
https://faith-developer.tistory.com/147
https://tony-programming.tistory.com/entry/Dependency-%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%9D%B4%EB%9E%80
http://wonwoo.ml/index.php/post/1717
https://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EC%84%B1_%EC%A3%BC%EC%9E%85

[Java] JDK 6 이후, Timezone.setDefault()

DwEnn — Sun, 25 Aug 2019 12:12:01 +0900

JDK 6 이후, Timezone.setDefault()

Timezone.setDefault(Timzone timezone) 은 메소드 명에서 유추할 수 있듯이 기본 Timezone 값을 설정하는 메소드이다.

Timezone.getDefault() // 기본 Timezone 값 가져오기

먼저 핵심부터 이야기하면, JDK 6 이전에는 defaultTimzone 이 스레드 로컬 변수에 저장되었다.

하지만 JDK 6 이후로는 defaultTimezone 이 VM 전체를 변경한다고 한다.

내 경우에는 JDK 6 이전의 형태로만 알고 있었기 때문에,

Timezone 설정을 아래와 같이, 별도의 시간 관련 메소드 내에서 Timezone.setDefault(Timzone timezone) 을 사용하여 Timezone 설정을 간략화 해두었었다.

( Calendar 객체를 가져오거나 SimpleDateFormat 에 timezone 을 설정하지 않고 )

 public boolean checkDate() {
     TimeZone.setDefault(TimeZone.getTimeZone("GMT"));
   Calendar calendar = Calendar.getInstance();
   SimpleDateFormat dateFormat = new SimpleDateFormat("yyyyMMdd");
 }

하지만 문제가 발생한 것이, 다른 시간대를 가져와서 비교를 하는 로직이 있었는데

( 위의 메소드가 사용되는 곳과 전혀 다른 곳 - 다른 Activity, 다른 프로세스 )

 Calendar.getInstance("Asia/Seoul");

위 처럼 Asia/Seoul 의 Timezone 을 명시하여도 GMT 시간으로 가져오는 문제가 발생하였다.

이것 때문에 한참 골머리 썪었었는데, 다행히도 참고한 글을 발견하고 해결하였다.

References

https://codeday.me/ko/qa/20190508/489138.html