최데브는 오늘도 프로그래밍을 한다.

우리는 함수를 작성하다보면 결과를 만들어 낼 수 없을 때가(예외) 있다. 대표적으로 아래와 같은 상황이 생길 수 있다. 서버로부터 데이터를 받을때 인터넷 문제로 받아오지 못한 경우 조건에 맞는 요소들중 첫번쨰 요소를 가져오려고 했는데 조건에 맞는 요소가 하나도 없는 경우 ex) index 에러 json 파싱을 하려고 했는데 형식이 맞지 않아서 발생하는 오류 이런 상황을 처리할때 두 가지 매커니즘을 활용 할 수 있다. 제목처럼 null이나 Failure(라는 이름의 sealed 클래스)를 사용해서 처리 예외를 throw 두가지에는 중요한 차이가 있다. 예외를 throw 하는거부터 보자. 일단 예외는 정보를 전달하는 방법으로 사용해서는 안된다. 예외는 잘못된 특별한 상황을 나타낼때 사용해야한다. 그 이유는 ..

프로젝트를 하다가 간만에 Viewpager 를 쓸일이 생겼다. 뷰페이저 자체가 예전부터 있었다보니 여러가지 방법으로 구현하는 방식이 있는데 이번에 나는 ViewPager2 와 FragmentStateAdapter 를 이용해서 만들어 보기로 했다. 먼저 ViewPager 가 지원중단되고 ViewPager2 로 몇년전에 넘어가게 됐는데 알아보는김에 왜 바뀌게 됐는지도 한번 알아보자. 대표적인 ViewPager 의 문제는 1. 리사이클러뷰에 뷰페이저를 집어 넣을때 발생한다. 뷰페이저는 PagerAdapter 기반으로 구성됐는데 스크롤을 할때마다 instantiateltem() 과 destroyItem() 메소드가 호출되면서 스크롤이 버벅거리는 문제가 있었다. * instantiateltem() : 화면에 표시..

확실히 어떻게 동작해야하는 코드가 있으면 예외를 활용해서 제약을 걸어주는게 좋을때가 있다. 코틀린에는 대표적으로 1. require : 아규먼트와 관련된 예측을 정의할때 상용하는 방법 숫자를 아규먼트로 받아서 팩토리얼을 계산하면 양의 정수만 받아야할때 좌표를 아규먼트로 받아서 클러스터를 찾을 때 비엉 있지 않은 좌표 목록을 사용할때 사용자로부터 이메일 주소를 입력받을 때 값이 입력됐는지, 이메일 형식이 바른지 확인할때 2. check : 상태와 관련된 예측을 정의할때 사용하는 방법 어떤 객체가 미리 초기화되어 있으어만 처리가 되게 하고 싶은 함수에 사용 사용자가 로그인 했을 때만 처리를 하게 하고 싶은 함수에 사용 객체를 사용할 수 있는 시점에 사용하고 싶은 함수인지 체크할때 사용 일반적으로 requir..

코틀린은 타입추론(type inference) 를 제공한다. 자바 10부터는 코틀린처럼 타입추론을 제공하지만 코틀린에 비해서는 제약이 많다. 아무튼 타입 추론을 사용할때 주의할 점들이 있는데 할당 할때 inferred 타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다는 것을 기억해야 한다. 일반적으로는 아래와 같이 open class Drink class Water: Drink() fun main() { var drink = Water() drink = Drink() // 타입에러 } 하지만 이건 open class Drink class Water: Drink() fun main() { var drink : Drink = Water() // 타입 명시 drink = Drink() } 타입 명시를 해..

최근 Dev6 프로젝트를 새로 개발하면 스플래시 스크린을 만들일이 생겼다. 이번에 스플래시 스크린을 만들면서 안드로이드 12 부터 바뀐 스플래시 스크린을 적용해보며 정리하는 글이다. 먼저 라이브러리를 추가하자. dependencies { implementation 'androidx.core:core-splashscreen:1.0.0-beta01' } 위 처럼 스플래시 스크린 라이브러리를 import 해준다. 이 라이브러리를 사용하려면 minSdk 는 21이상 , targetSdk 는 31 이니 참고하자. themes.xml 에 스플래시 스크린 테마를 추가하자. 이렇게만 보여주면 뭐가 무슨 옵션인지 찾아보기 귀찮으니 몇개 적어보자. windowSplashScreenBackground: splashscree..

플랫폼 타입? 다른 프로그래밍 언어에서 와서 null 가능 여부를 알 수 없는 타입을 플랫폼 타입이라고 한다. 플랫폼 타입을 사용하면 해당 부분도 null 에러가 발생할 위험이 있으며 해당 코드를 사용하는 곳까지 영향을 줄 수 있다. 예를 들면 아래와 같은 상황이 있다. 안드로이드 개발자가 자바 코드로 코드를 작성하다가 코틀린으로 변경해서 코드를 이어서 작성한다고 가정해보자. // 자바 public String getValue() { return null; } // 코틀린 fun statedType() { val value: String = JavaClass().value // NPE // ... println(value.length) } fun platformType() { val value = Jav..

늦은감이 있지만 2023년을 맞아서 2022년을 돌아보려한다. https://choi-dev.tistory.com/148 2021년을 돌아보며 2022년을 고민해보기. 2021년이 지나서 2022년이 됐습니다. 2021년에 이루고 싶었던것들을 다 이루진 못했지만 나름 만족스러운 한 해였습니다. 회사에서 많은 프로젝트를 하고 그 프로젝트를 통해 고객들이 신기해하는 choi-dev.tistory.com 작년에 내가 적었던 글이다. 배움의 깊이를 더해보려고 했었고 5가지의 여러 목표를 세웠다. 사실 모두 이뤘는지는 모르겠다. 노력은 했지만 아직 부족한 부분이 많은 거 같다. 작년에 얻은 것들 1. 코틀린 언어에 대한 학습은 작년이나 올해나 꾸준히 되어야한다고 생각하고 있기에 올해도 꾸준히 공부할 예정이다. 사..

끝? 시작? 리드펫이 끝나고 나서 배포는 했지만 운영은 실질적으로 힘들다는 결론을 팀 내부에서 내리고 프로젝트가 마무리 됐다. 아쉬움과 후련함이 교차했지만 아무래도 살아있는 서비스를 계속 만들지 못했다는 아쉬움이 가장 컸던 것 같다. 그래도 이렇게 끝내려고 시작한건 아니니까 라고 생각하곤 새로운 서비스를 만들 준비를 했다. 뉴 페이스 같이 개발하던 안드로이드 개발자분은 다른 IT 개발 동아리에 참가하게 되셔서 잠시 Dev6 개발에서 빠지셨고 디자이너분도 다른 프로젝트에 참가 하셔서 함께하지 못하게 됐다. 기존 팀원의 결원으로 인해 새로운 팀원이 필요했고 수소문 끝에 현재는 실력있는 기획자, IOS 개발자, 디자이너분이 합류하셨다. 특히 우리팀에는 기획자라는 포지션이 없고 내가 리딩을 하다보니 팀내 기획력..

상태를 정의할 때는 변수와 프로퍼티 스코프를 최소화 하는것이 좋음 최소화하지 않으면 아래와 같은 단점이 있다. - 프로그램을 추적하고 관리하기 쉬워짐. - 스코프 범위가 너무 넓으면 다른 개발자에 의해서 변수가 잘못 사용될 수 있음. - 프로그램을 읽고 이해하기에 어려워짐 변수는 읽기 전용 또는 읽고 쓰기 전용 여부와 상관없이 변수를 정의할때 초기화되는 것이 좋다. 여러 프로퍼티를 한번에 설정할 경우에는 구조분해 선언을 활용하자 프로퍼티보다는 지역 변수를 사용하는 것이 좋다 캡처링에 유의하자. val primes : Sequence = sequence { var numbers = generateSequence(2) { it + 1 } while(true){ val prime = numbers.first(..

코틀린의 요소 중 일부는 상태를 가진다. 상태라는건 상황에 따라 값이 변화할 수 있는 것을 의미한다. 대표적으로 var 프로퍼티와 mutable 객체가 있다. 시간 변화에 따라 변하는 요소를 표현할 수 있는것은 유용하지만 여러가지 고려할 점이 생긴다. 1. 프로그램을 이해하고 상태 추척하는것이 어려워진다. 2. 가변성을 가지고 있으면 코드의 진행을 추론하기 어려워진다. 3. 멀티스레드 일때 동기화의 문제를 만날 수 있다. 4. 테스트하기가 어려워진다. 변경되는 값이 많을수록 여러 케이스를 테스트 해야한다. 5. 상태 변경이 일어나면 이 상태를 사용하고 있는 곳에 지속적으로 알려주는 번거로움이 생긴다. 예를 들면 이런 상황이다. suspend fun main() { val lock = Any() var n..