이번 글은 저번 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형으로 계산할 때 오버플로우가 날만한 범위까지도 계산이 가능한 클래스이..
미루고 미뤄왔던 SDC Korea 2023 후기를 드디어 쓰게 되었다. 먼저 이번 달에 상당히 나태해진 나에게 따끔한 한마디를 다시금 전하며 9월부터는 다시 열심히 공부했으면 좋겠다. 참석 계기줄곧 개발자 행사(컨퍼런스, 밋업 등)를 직접 참가해보고 싶은 생각이 있었다. 타이밍이 매우 좋게 삼성전자에서 컨퍼런스를 하게 된다는 사실을 접했고 그대로 부장님께 외근 처리를 부탁드렸다. 생각보다 매우 흔쾌히 다녀오라고 하시며 동기와 선임도 데려가라고 하셨다. 그렇게 3명이 컨퍼런스를 가게 되었다.(동기는 iOS라 사실 매우 연관성이 있지는 않았다.) 일단 서초 사옥으로오전에 도착해 컨퍼런스가 열릴 위층으로 올라가는데역시나 동종 업계 사람들이 입구를 못 찾는 모습과 그걸 안내해주는 프론트 직원들의 모습이 눈에 띄..
이번 글에서는 저번 Coroutine retry 로직을 구현했던 것을 고차함수로 추출해내는 작업을 해볼 예정이다. Step1. 초안 작성하기fun retry(numberOfRetries: Int, block: () -> Unit) { repeat(numberOfRetries) { try { block() } catch (e: Exception) { e.printStackTrace() } } block()}초안을 작성해보면 위와 같은 코드가 된다. 얼핏 보기엔 문제가 없을 것 같지만, 파라미터 전달될 함수 리턴 타입을 알 수 없기에 Unit 하나로 제한해버리면 안된다. 이럴 때 생각나는 녀석이 하나 있는데 바로 제네릭(Generic)이..
글 작성 배경이 글을 적게 된 배경은 뭘까? 나는 시간이 어느 정도 지난 개인 프로젝트를 오랜만에 다시 만지고 있었다. 이 때, Material 라이브러리 버전과 targetSdk 버전을 동시에 올리면서BottomNavigationView 배경 색상이 내가 사용하지 않는 기본 색상으로 적용이 되었다. 샘플 앱을 대충 만들면 나오는 그 보라색 말이다. 나는 Material 라이브러리의 Color system을 사용하고 있었는데도 이런 현상이 발생했다. 문제 지점 찾기분명 라이브러리에서 BottomNavigationView의 background color를 정의하는 부분이 있을 것이라 생각했다. 그럼 라이브러리에서 어떤 color를 사용할까? 바로 Material 공식 사이트에서 확인할 수 있었다. 스크린샷..
필요해진 배경이번 기능은 왜 필요했을까? QR코드 스캐너 라이브러리를 사용하는데 알고보니 화면 방향이 가로 고정이었다. 하지만, 내가 필요로 하는 화면 방향은 세로 고정이었다. 해결 방법내가 사용했던 라이브러리를 예시로 보여주겠다. https://github.com/journeyapps/zxing-android-embedded GitHub - journeyapps/zxing-android-embedded: Barcode scanner library for Android, based on the ZXing decoderBarcode scanner library for Android, based on the ZXing decoder - journeyapps/zxing-android-embeddedgithub..
이번 기능은 상당히 어이없는 해결책을 가져왔다.(그런걸 왜 가져왔냐..?고 하면 할 말은 없다 ㅋㅋㅋ😂) 문제의 시작요구사항은 이렇다. RecyclerView 각 아이템에 포커스를 주면 해당 아이템이 총 몇 개 중 몇번 째인지 읽어주는 것이었다. 정말 간단한 기능이다. 나는 onBindViewHolder에서 setContentDescription을 통해 해당 문자열을 설정해주었다. 그런데 스크린리더가 읽는 텍스트는 약간 달랐다.예를 들면, 총 10개 중 일번 째라고 읽는 것이 아니겠는가? 이상한 점을 찾았을 지 모르겠다. 첫번째, 두번째, 세번째가 아닌 일번 째, 이번 째, 삼번 째와 같은 형식으로 읽어버리는 것이었다. 문제 발생 지점나는 나름 수동으로 문자열 리터럴을 만들어 설정해주었는데 여기서 정말..
먼저 이번 글에서는 코드가 등장하지 않는다. 이번 오적용기가 나에겐 나름 Room을 제대로 사용해본 경험이라 작성해둔 코드가 아쉽기도 하다. 하지만, 언젠가는 갈아엎어야 될 코드가 되어버렸다. 왜 그렇게 됐을까? 현재 상황 파악의 중요성내가 연동해야할 백엔드는 어떤 상황인가?를 너무 간과했다. 대부분 앱 서비스는 회사에서 서버를 두고 앱이 해당 서버와 통신하게 된다. 그리고 해당 백엔드에서 가져온 데이터로 로컬 DB를 구성해 앱에서 사용한다. 하지만, 나의 경우는 각각 지역의 로컬 서버가 존재하고해당 서버에서 DB 파일을 다운로드받아 Room으로 사용하는 것이었다. 더욱 심화되는 문제와 해결 불가능한 상황까지각 로컬 서버는 모두 같은 Table 버전을 갖고 있을 것이라 생각했었다. 하지만 로컬 서버들은 ..
사실 이 문제는 회사에 들어와 가장 먼저 고민했던 문제였다. 로그인 시, 아이디와 패스워드를 암호화해 전송해야 했기 때문이다. 전에 Google Play Console 여기저기를 누르다보니 SHA 방식의 암호화를 지나치듯 본 기억이 있었다. 짧은 AES 방식 소개하지만 SHA는 복호화할 수 없는 방식이기에 AES 방식을 사용하기로 했다. AES 암호화 방식은 key 값의 길이에 따라 바뀌는데 16바이트이면 AES-128, 32바이트이면 AES-256이 된다. 대신 IV(Initialization Vector)의 길이는 AES-128, AES-256 둘 모두 16바이트로 동일하다. Random IV를 적용해보기여기서 재밌는 기능을 하나 추가해보자. 바로 IV를 매번 random하게 생성하는 것이다. 그리고..
