오늘도 더 나은 코드를 작성하였습니까?

ViewModel이 없이 하나의 Activity에서 일반적으로 여러 개의 Fragment와의 데이터를 공유하고 전달하기 위해서는 Activity가 인터페이스를 구현하고 그 인터페이스의 참조(context)를 각 Fragment에 넘겨준 후 호출시키는 방법으로 통신을 하는 것이 기본적이다. 하지만 두 fragment가 모두 인터페이스 설명을 정의해야 하고 소유자 Activity가 두 fragment를 함께 결합해야 하므로 이 사례는 간단히 처리할 수 있는 작업이 아닙니다. 또한 두 fragment는 모두 다른 fragment가 아직 생성되지 않았거나 표시되지 않은 시나리오도 처리해야 합니다. ViewModel을 사용하면 이러한 Activity 및 Fragment 간 데이터의 공유 및 통신이 쉬어지고 코드가..

생명주기를 인식하는 ViewModel 인스턴스를 얻으려면 Lifecycle을 ViewModel Provider에 넘겨준다. 따로 new나 코틀린 객체를 생성하지 않는다. ViewModel은 범위가 지정된 Lifecycle이 영구적으로 경과될 때까지, Activity가 소멸될 때, Fragment가 Activity에서 떼어질 때까지 메모리에 존재한다. 아래 그림은 Activity가 화면구성의 변경될 때 생명주기가 변하는 동안 ViewModel의 전체 기간도 보여준다. 일반적으로 시스템에서 활동 객체의 onCreate() 메서드를 처음 호출할 때 ViewModel을 요청합니다. 시스템은 활동 기간 내내(예: 기기 화면이 회전될 때) onCreate() 메서드를 여러 번 호출할 수 있습니다. ViewModel..

코틀린은 원시 타입과 래퍼 타입을 구분하지 않는다 원시 타입은 변수에 할당한 그 값이 직접 메모리에 들어간다. 참조 타입은 그 객체에 대한 주소 값이 메모리에 들어간다. 자바의 경우 참조 타입이 필요한 경우 원시 타입을 래퍼 클래스로 감싸서 사용한다. 예를 들면 Collection 가 아닌 Collection 처럼 말이다. 하지만 코틀린은 그렇지 않다 래퍼타입과 원시 타입을 구분하지 않으면 편리하다. 또한 원시타입에 대한 메서드 호출이 가능하다. *coerceIn은 값을 특정 범위로 한정한다. fun showProgress(progress: Int){ val percent = progress.coerceIn(0,100) println("$percent done! ") } fun main() { showP..

코틀린을 비롯한 최신 언어에서는 null에 대한 접근방법은 가능한 이문제를 runtTime 시점이 아닌 compile 시점으로 옮기는 것이다. null 이 될 수 있는지 여부를 타입 시스템에 추가함으로써 컴파일러가 여러 가지 오류를 컴파일 시 미리 감지해서 실행 시점에 발생하는 예외를 줄이는 것이다. Null 이 될 수 있는 타입 - 코틀린은 null 이 될 수 있는 타입을 명시적 지원한다 - TYPE? = TYPE or null - null이 될 가능성이 있는 타입의 변수는 메서드의 직접 호출을 할 수 없다. - null이 될 가능성이 있는 타입의 변수를 null 이 될 수 없는 타입의 변수에 대입할 수 없다. - null이 될 가능성이 있는 타입을 null 될 수 없는 타입을 파라미터로 받는 함수에 ..