이번 편은 조금 쉬어가고자(?) 조금 익숙한 주제를 골라봤습니다. 바로 SOLID입니다! 엥, 갑자기 무슨 SOLID냐? 너무 기본 아니냐? 라고 하실 수 있습니다.아무래도 이전 글들에 비하면 주제가 몇 년 전으로 돌아간 느낌입니다.그래도 막 들어온 따끈따끈한 우테코 7기 친구들도 있고, 학교에서 이제 객체지향을 배우는 친구들도 어딘가에 있을 테니까요? 이전에 SOPT에서 SOLID를 주제로 세미나를 하기도 해서 금방 적을 수 있을 거로 생각했습니다. 그런데 알고 있는 것과 별개로 간만에 이야기 하려니 생각보다 오래 걸리네요.예시도 바로 안 떠오르고.. 어쩌면 잊고 살았는지도 모르겠습니다. SOLID라는 단어를 들으면 각자의 세대에 따라 다른 단어를 떠올릴 것입니다.누군가는 가수를, 누군가는 카트라이더를..
전체 글
mutableStateOf우리는 지난번 글에서 State와 MutableState를 살펴보았고, 그 과정에서 RecomposeScope와 리컴포지션 과정에 대해 알아보았다.글이 길어져서 다루지 못했지만, 나는 사실 한 가지가 더 궁금했다. State(MutableState) 인스턴스를 생성할 때 우리는 mutableStateOf 함수를 사용한다. mutableState는 무엇을 어떻게 생성해서 뱉어내는가? 이제부터 그것을 알아보려고 한다. mutableStateOf 함수는 다음과 같이 생겼다.@StateFactoryMarkerfun mutableStateOf( value: T, policy: SnapshotMutationPolicy = structuralEqualityPolicy()): Mu..
서론(서론은 공식문서에서 발췌한 내용이 대부분이다. 이미 알고 있다면 패스해도 좋다)이번 주제는 Jetpack Compose의 State와 MutableState이다. 지난 번에 작성했던 RecyclerView 글에 대한 후속편도 적어야 하는데, 시간이 부족하다..얼른 시간 내서 작성해보도록 하겠다. 이제는 역사가 유구한 프로젝트가 아니라면 대부분 컴포즈를 사용할 것이다. 그럼 다들 좋다고 사용하는 컴포즈는 어떻게 다를까?컴포즈 이전에 우리는 명령형 UI 형태로 뷰 객체의 프로퍼티를 수정하거나, 메서드를 호출해서 화면을 업데이트 했다.binding.tv.text = "안녕하세요"binding.tv.textSize = dpToPx(context, 14)binding.tv.updatePadding(top =..
서론저번 회고 글에서 말했듯 블로그 챌린지를 시작했다. 이번 회차엔 모두 같은 주제로 글을 쓴다.그 주제는 바로 리사이클러뷰다.컴포즈가 만연해진 시대에 (컴포즈를 사용하지 않는 역사가 긴 앱을 제외하면) 리사이클러뷰는 이제 잘 사용되지 않는다.컴포즈로 안드로이드 개발을 처음 시작하는 사람이 늘어나면서 리사이클러뷰를 모르는 경우도 더러 있다고 들었다. 사실 컴포즈만 사용한다면 굳이 알 필요는 없다.그러나 만약 당신이 들어간 회사가 여전히 xml을 사용하고 있다면, 리사이클러뷰 사용을 피할 수 없을 것이다. 그만큼 리사이클러뷰는 앱을 만들 때 많이 사용되는 컴포넌트이다. (컴포즈 사용자라면 생각해 보자, LazyRow, Column, Grid 없이 앱을 만들 수 있겠는가?)리사이클러뷰는 역사가 긴 만큼 자료..
최근 동력을 잃어 아무것도 하지 않고 어영부영 시간을 보내고 있었다. 그러던 와중 블로그 챌린지 모집 글을 보고 동력을 되찾기 위해 신청했다. 원래 주제는 2024년 회고지만, 창업 회고가 곁들여지면서 2023 하반기까지 포함되게 되었다. 창업 그리고 퇴사올해 나에게 가장 큰 사건이지 않을까 싶다. 작년(2023년) 9월부터 쭉이라는 팀으로 창업을 시작했다. (이제는 회사가 되었지만)종종 친구들이 왜 취업하지 않고 창업을 하냐고 물었다. (물론 취업이 하고 싶다고 되는 건 아니지만...) 원래 내 인생 계획은 2024년에 취업을 하고 30대 중반까지 돈과 경험을 쌓아 창업하는 것이었다. 그런데 효재(쭉의 대표)를 만나면서 내가 10년 뒤로 계획했던 창업의 기회가 운 좋게 일찍 찾아왔다고 생각했다. 성공..
지금까지 여러 사이드 프로젝트를 하면서 에러를 겪은 적은 많았다. 그러나 대부분의 사이드 프로젝트가 그렇듯 유저가 없었기에 나와 팀원들이 (혹은 지인들이) 발견해서 고쳤다. 또 대부분의 에러가 심각한 문제는 아니었다. 주요 기능을 사용할 수 있는 선에서 조금 불편해지는 정도였다. 그러나 이번엔 메인 기능을 사용할 수 없을 정도의 큰 에러를 제보받게 되었다. 반려동물의 이름 입력이 안된다는 제보였다. 나는 쭉(ZOOC)이라는 팀에서 핏어팻(fitapat)이라는 서비스를 운영하는 안드로이드 개발자다. 핏어팻은 유저 반려동물의 이름, 종, 사진을 입력 받고 AI를 통해 반려동물 커스텀 굿즈를 만들어 판매하는 서비스다. 반려동물을 등록해야 제품을 구매할 수 있는데, 반려동물 이름 입력이 안된다는 것이었다. 즉,..
코틀린과 자바는 한글 네이밍이 가능하다. (변수명, 클래스명 등) 하지만 우리는 주석을 제외하고는 코드에서 한글을 마주치는 경우가 거의 없다. 또 영문으로 코드를 작성하는 것에 익숙하기에, 의미가 잘 전달되더라도 한글 네이밍을 보면 눈살이 찌뿌려질 수 있다. 그렇다면 한글 변수는 나쁜가? 사람들이 한글 변수를 사용하지 않는 이유를 개인적으로 추측해보았다. 코드를 영어로 작성하는데 중간에 한글을 섞으려면 한/영 키를 눌러야한다. (즉 키보드를 한 번 더 눌러야한다.) 영어로 전부 작성되어있는 코드 사이에 한글이 박혀있으면 굉장히 생소하다. 카멜케이스 같은 네이밍 컨벤션을 적용하기 어렵다. 한번쯤 생각해 보았더라도 동료들을 설득할 수 있을지 모르겠다. ... 읽어보면 카멜케이스를 적용하기 어렵다 를 제외하면..
현재 진행중인 반려동물 기록 서비스 'ZOOC'을 개발핟면서 생긴 이슈다. 아래는 우리 앱의 메인 화면이다. 호스팅 액티비티에 바텀 네비게이션이 있고 홈, 마이페이지 두 개의 프레그먼트가 전환되는 형태이다. 가운데 + 버튼을 누르면 기록을 위한 새로운 액티비티가 생성되는데, 해당 액티비티를 갔다오면 홈 프레그먼트의 데이터를 리프레시해야했다. 그래서 Activity Result API를 이용해 기록 액티비티에서 돌아오는 시점을 알고 데이터를 리프레시 하려고했다. 그런데 여기서 문제가 발생했다. 바텀 네비게이션은 호스팅 액티비티에, 리프레시할 데이터는 홈 프레그먼트에 있었기 때문이다. 즉, 바텀 네비게이션이 액티비티에 있으므로 기록 액티비티에서 돌아오는 시점을 프레그먼트가 아닌 액티비티가 아는 것이 문제였다..