Kotlin

프로세스의 시작점 main 함수 main 함수는 모든 프로세스의 시작점이다. 보통 프로세스가 실행되면, 메인스레드에서 main 함수가 실행되며, main 함수의 실행이 끝나면 종료된다. 메인 스레드는 사용자 스레드 중 하나이며, 프로세스는 사용자 스레드가 모두 종료되면, 종료되는 특성을 가지기 때문에 메인스레드만을 사용해 실행되는 프로세스는 메인 스레드의 사용이 종료되는 지점(main 함수의 실행이 완료되는 시점)에 종료된다. 예를 들어 위와 같은 코드를 실행하면 다음과 같은 결과가 나온다. main 함수 입니다. Process finished with exit code 0 자 이제 그림2와 같은 코드를 실행해보자. 그림2에서는 Main Thread가 아닌 IO Thread에 코루틴을 실행 요청해 pri..

코틀린과 코루틴 코루틴은 코틀린 언어의 기본 기능으로 내장되어 있다. 따라서 별도 설정 없이도 코루틴을 위한 저수준 API를 사용할 수 있다. 하지만, 언어에 내장된 기능만으로는 launch나 async 같은 고수준 API는 사용할 수 없다. launch나 async 같은 고수준 API는 Jetbrains 사에서 배포한 kotlinx-coroutines 라이브러리의 기능으로, coroutine-core(org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.3) 라이브러리에 대한 의존성을 설정해줘야 사용할 수 있다. 이를 위해서는 다음과 같은 블록을 build.gradle 파일에 추가해야 한다. dependencies { implementation 'org.jetbrai..

예제파일 : https://github.com/seyoungcho2/GradleKotlinDSL Gradle with Kotlin DSL Groovy로 빌드 파일을 작성하는 것은 불편하다. 다른 곳에서 선언된 변수에 대해 자동완성이 지원되지 않고 문서 찾기가 어렵다. 실행시점 전까지 오류가 검출되지 않는다. IDE에서 제공하는 리펙터링 기능을 사용할 수 없다. (Intellij 기준 Shift+F6 을 눌러서 리펙토링 불가) 코드 작성이 제약이 약해 빌드 스크립트가 자유 분방해진다. Groovy는 같은 코드를 여러 방식으로 쓰는 것을 허용한다. 대표적 예로 문자열을 쓸 때 ' 를 쓰는 것과 "를 쓰는 것이 모두 허용되는 점이다. 왜 Kotlin DSL로 이전해야 하는가? 코드 자동완성과 참조 오류코드 강..

익숙하지 않은 Groovy언어로 BuildScript를 작성하는 것에 한계를 느껴 언젠가는 Kotlin DSL로 Migration해야 겠다고 생각했는데, 이번에 시간이 생겨 Migration을 진행하였다. Migration을 진행하면서 달라진 문법 구조로 인해 대형 프로젝트에서는 Migration을 진행하기 조금 어려울 수도 있겠다는 생각이 들어 정리를 할 필요성을 느끼게 되어 정리를 하게 되었다. 프로젝트 예제: https://github.com/seyoungcho2/GradleKotlinDSL seyoungcho2/GradleKotlinDSL Contribute to seyoungcho2/GradleKotlinDSL development by creating an account on GitHub. g..

Dagger2의 IOC Container 구성 앞의 글에서 Dagger2의 3가지 구성요소 Container, Module, Provider에 대해 배웠다. Component : 클래스의 인스턴스를 모아놓는 저장소(Container) 역할. 각 인스턴스들은 Module 단위로 제공된다. Module : Module 단위로 클래스의 인스턴스를 모아놓는 역할 Provider : 클래스의 인스턴스를 제공(Provide)해주는 역할 이제 각 부분이 어떤 역할을 하는지 알았으므로 더욱 상세히 정리해보고자 한다. Dagger2을 이용해 의존성 주입 구현하기 앞의 글에서 다음과 같은 그림을 본 적이 있다. 는 의존성을 약화시키기 위한 인터페이스의 역할에 대해 설명하면서 나온 그림이다. CPU Time을 구하기 위해 ..