오늘은 AI가 추천해준 문제를 풀어봤다.이리저리 생각하다보니 문제의 요구사항을 파악하는 것이 가장 오래 걸렸다.문제문제의 답을 한 줄로 요약해보면 파일이 있는 가장 작은 x, y값과 가장 큰 x, y값을 구하는 것이다.그렇게 숫자 네 개를 가진 정수형 배열을 리턴하면 끝이다.풀이가장 간단한 방법으로 생각한 것은 최솟값과 최댓값을 구하는 것이었다.내가 가진 값보다 더 작은 값이 있다면 내 값을 갱신하고내가 가진 값보다 더 큰 값이 있다면 내 값을 갱신하는 것이다.나는 if문을 통해 일일이 직접 비교해서 풀어보았다. 실행 결과다음에도 재밌는 문제를 풀어보기를 기대해야겠다.
Material theme을 사용하면서 왜 Elevation 설정을 해제하려고 할까앱에서 원하는 색상을 적용하기 어렵다. Material theme만 적용하게 되면 상관이 없겠지만,iOS나 다른 플랫폼과 색상을 맞추기 위해서는 Material theme만을 사용할 수가 없다. 왜 하필 elevation이냐... 그건 바로 elevation을 통해 shadow를 적용했는데Material theme 설정 때문에 내가 지정한 View의 backgroundTint를 적용할 수 없었다. 예를 들면?MaterialCardView가 있다. Appcompat의 CardView를 상속받아 만들어졌는데cardElevation을 0 초과로 설정하는 순간 내 기본 테마 색상에서더 진한 채도를 가진 색상으로 background..
CoroutineScope(이하 Scope)는 CoroutineContext(이하 Context)라는 하나의 프로퍼티를 가지고 있다. 더불어 모든 Coroutine은 특정 Scope에서 실행된다. 그리고 여러 개의 Coroutine은 같은 Scope에서 실행될 수 있다. 특정 Coroutine과 그 자식 Coroutine을같은 Scope에서 실행하게 되면 Job 객체들이 부모-자식 계층을 구성하게 된다. 이렇게 형성된 부모-자식 계층은 구조적 동시성에서 중요한 부분이다. 같은 Scope에서 실행된 Coroutine은기본적으로 해당 Scope의 Context를 상속받는다. 하지만 각 Coroutine은 다른 Context로 실행될 수 있고,이것도 계층 구조를 따라 특정 Coroutine이 A라는 Conte..
저번 글에서 예고했던 대로 메인 스레드에서 했던 무거운 작업을 이제 다른 스레드에서 작업시켜보자.(이전 글 확인하기) 이전 동작 이해하기아까 첨부한 링크에서의 이전 글을 보면우리는 viewModelScope를 사용해 CPU 연산이 무거운 작업을 메인 스레드에서 실행했다. 그렇게 수초간 메인 스레드가 blocking되었고, 다른 UI는 반응할 수 없었다. 그리고 우리가 실행했던 viewModelScope의 Context를 확인하는 방법이 하나 있다.fun performCalculationOnMain(factorial: Int) { viewModelScope.launch { println("Coroutine Context: $coroutineContext") var result = BigInt..
이번 글은 저번 CoroutineContext와 CoroutineScope를 소개한 것에 이어서 Dispatcher에 대해 알아보겠다. Dispatcher의 역할Dispatcher는 해당 코루틴이 어느 스레드나 스레드 풀에서 실행될지 결정한다. Dispatcher의 종류Dispatcher는 이미 정의된 몇가지가 있는데 이에 대해 짧막하게 알아보자. Dispatchers.MainMain Dispatcher는 오직 UI가 있는 애플리케이션에서만 사용할 수 있다. 안드로이드의 경우, UI 작업을 오직 메인 스레드에서만 허용하므로Main Dispatcher를 사용해 메인 스레드에서 실행할 수 있다. 해당 Dispatcher가 Main Looper와 연결된 Handler를 사용하기 때문이다. 우리가 Main Di..
이번에는 CoroutineContext는 대체 무엇인지 알아보자. 그리고 간단히 CoroutineScope 구조까지 살펴보도록 하겠다. viewModelScope로 찾아보기viewModelScope는 CoroutineScope라는 인터페이스를 상속받아 만들어진 녀석이다. 그리고 CoroutineScope 인터페이스를 확인해보자.보다시피 CoroutineContext를 가지고 있는 걸 볼 수 있다. 그리고 다시 한 번 CoroutineContext가 무엇인지 들어가보자.문서 최상단을 읽어보면 CoroutineContext는 여러 Context Element를 포함하고 있다는 사실을 알 수 있다. 여기서 가장 중요한 Element에는 바로 Dispatcher, Job, ExceptionHandler, Nam..
오늘은 코루틴을 메인 스레드에서 실행해보고 그 결과에 대해 생각해보는 시간을 가져보았다. 어떤 작업을 시킬까이번에는 단순한 연산을 시킬 예정이다. 아주 많이 팩토리얼(Factorial) 계산을 시켜보겠다. 코드를 보자.fun calculateFactorial(number: Int): BigInteger { var factorial = BigInteger.ONE for (i in 1 .. number) { factorial = factorial.multiply(BigInteger.valueOf(i.toLong())) } return factorial}여기서 BigInteger를 사용했는데 간단히 말하면Integer형으로 계산할 때 오버플로우가 날만한 범위까지도 계산이 가능한 클래스이..
이번 글에서는 저번 Coroutine retry 로직을 구현했던 것을 고차함수로 추출해내는 작업을 해볼 예정이다. Step1. 초안 작성하기fun retry(numberOfRetries: Int, block: () -> Unit) { repeat(numberOfRetries) { try { block() } catch (e: Exception) { e.printStackTrace() } } block()}초안을 작성해보면 위와 같은 코드가 된다. 얼핏 보기엔 문제가 없을 것 같지만, 파라미터 전달될 함수 리턴 타입을 알 수 없기에 Unit 하나로 제한해버리면 안된다. 이럴 때 생각나는 녀석이 하나 있는데 바로 제네릭(Generic)이..
이번 문제는 최근 포스팅한 AES 암호화 관련 글이 떠올라 풀어보았다. 문제문제의 요구사항은 영어 대소문자의 index를 가진 배열에문자열 안의 각 문자가 몇 번 포함되었는지 저장하는 것이다. 이 때, C언어를 배웠던 사람이라면 아스키 코드(ASCII Code)를 생각하지 않을까 싶다. 그리고 아스키 코드를 생각해낸 사람이라면 영소문자끼리 영대문자끼리 붙어있단 사실도 기억하고 있을 것이다. 그럼 이제 문제를 해결해보자. 풀이먼저 영대소문자를 모두 포함할 배열을 만들어준다. repeat 함수를 사용해 반복문을 대체했고문자열에서 각 index에 해당하는 문자를 숫자로 변환 후해당 정수 값으로 대소문자를 판별하고 배열 값을 1씩 증가시켜주었다. 그렇게 완성된 배열을 리턴해주면 된다. 실행 결과
오늘 이 문제는 기존에 사용해보지 않은 메소드를 사용해보는 겸 풀어보았다. 이번에 사용한 함수는 코틀린 표준 라이브러리에 있는 함수이다. 문제문제의 요구사항은 간단하다. 문자열 왼쪽의 0을 없애주면 된다. 여기서 문자열 왼쪽을 삭제하면서 자바엔 없는 함수를 사용해봤다. 풀이먼저 0이 몇개나 존재할지 모르기 때문에while문에서 startsWith로 문자열이 0으로 시작하면 문자열 앞의 0을 지워주었다. 그리고 removePrefix의 리턴을 다시 지역 변수로 넣어주었다. 지역 변수로 리턴된 문자열을 다시 넣어주지 않으면answer에 넣어둔 파라미터 값이 변하지 않기 때문에 while문에서 무한루프에 빠질 수 있다. 실행 결과
