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

StateFlow를 MVVM 패턴에서 UI 상태를 관리하고 반영하는데 사용하곤 했다. flow를 반복적을 관찰하며 최신 UI 상태를 얻어서 view에 보여줄 수 있는데 class MainViewModel: ViewModel(){ _viewState.value = _viewState.value.copy(checked = true) } 위 코드처럼 copy 함수를 사용해서 다른 값을 유지하면서 하나 이상의 속성을 변경하는것도 가능하다. 갑자기 copy 이야기를 뜬금없이 왜 했냐? 이런식으로 값의 수정이 일어나면 copy가 완료된 시점과 stateflow에 새로운 값이 내보내지는 시간 그 사이에 우연히 다른 코루틴이 다른 속성의 값을 업데이트 했다면? 의도치 않은 data class 값이 만들어질수도 있을 것..

팀 프로젝트를 하다가 기존에 로그인이 됐던 유저인지 처음 로그인 하는 유저인지 체크해서 로그인 화면으로 이동시킬지 자동으로 메인화면으로 이동하게 할지 체크하고 이동시켜주는 기능이 필요했다. 해당 프로젝트에서는 Jetpack navigation 을 사용하고 있었는데 위 동작을 정상적으로 보여주려면 startDestination 을 상황에 맞게 새로 설정해주는게 필요했다. 일단 해당 기능이 필요한 액티비티에서 lateinit var navController : NavController 네비게이션 동작을 컨트롤 해줄 NavController 을 선언해주자. 그리고 onCreate 에 val navHostFragment = supportFragmentManager.findFragmentById(R.id.join..

xml 에 다른 xml 파일을 include 하여 해당 xml에 포함되게 사용할수가 있는데 이때 그냥 해당 액티비티의 id로 view binding 을 하면 참조가 되지 않는다. 이때는 private lateinit var exampleBinding: InclueTopBinding exampleBinding = InclueTopBinding.inflate(layoutInflater) exampleBinding.tvLeft.setOnClickListener { findNavController().popBackStack() } include_top.xml 을 binding 했다. InclueTopBinding 은 해당 include xml 을 바인딩 한 것 tvLeft 는 include_top.xml 에 있..

페이징이라는 개념은 예전부터 있었다. 페이징을 내 멋대로 설명 해보자면 대량의 데이터를 불러올때 한번에 다 불러오면 리소스 낭비가 심하다. 이를 처리하는 전략이 페이징이였는데 100개의 데이터가 있으면 이걸 다 불러오지말고 한 페이지당 10개씩 다음 페이지가 보고 싶다고 하면 다음 페이지의 10개의 데이터를 보여줘라. 라는 개념이다. 그리고 안드로이드에서도 비슷한 니즈가 있었는데 스크롤을 내려서 데이터를 볼때 한번에 다 보여줄 필요없이 스크롤이 어느정도 내려왔을때 다음 데이터를 불러오면 좋지 않을까? 하는 점이다. 그리고 그걸 관리하기 쉽게 구현을 도와주는 라이브러리가 Paging3 다. 이게 최선인가에 대해서는 확실히 말하기 어렵지만 일단 내가 구현한 방법대로 설명을 해보려고 한다. 해당 예시는 MVV..

데브식스 프로젝트를 진행하다가 동료 안드로이드 개발자분께서 view 에서만 에러처리를 하지말고 네트워크쪽 로직에서도 에러처리를 하자고 말씀하셨다. 이게 맞는 접근법인지는 모르겠지만 그말을 듣고 가만 생각해보니 view에서 발생하는 에러가 아니라 통신에서부터 에러가 생겨서 발생하는 문제를 view에서만 처리하는건 예상치 못한 상황이 발생할 수 있기도 했고 view까지 오지 않아도 사전에 에러로 인한 예기치 못한 상황을 방지 할 수 있기도 했다. 그러면서 정말 괜찮다고 느낀 방법을 소개해주셨는데 그 부분에 대해서 정리를 해보려한다. 전체적인 프로젝트 코드를 다 소개하지는 못하고 일부분만 가져와서 아이디어를 공유하는 정도로 이 글은 작성될 예정이다. 먼저 우리는 RemoteSource 라는 개념을 가져와서 쓰..

공부를 하던중 typealiases 라는 키워드를 알게됐다. 코틀린에서 typealiases 는 긴 제너릭 타입을 사용하는 변수들에 대한 새로운 별명을 지어주는 키워드다.크게 엄청난 역할을 하는것은 아니고 짧게 별칭으로 쓸 수 있게 바꿔주는 용도 정도로 생각하면 좋을 거 같다. typealias DataBaseUseCase = BaseUseCase 이렇게 적어주면 class DatatUseCase @Inject constructor(private val repo: DataRepository) : BaseUseCase 이렇게 됐어야하는게 class DatatUseCase @Inject constructor(private val repo: DataRepository) : DataBaseUseCase 이런식으..

한달이 넘는 시간전 글을 마지막으로 블로그를 쉬었었다. 그때 글에도 남겨져 있지만 마음이 지쳐서 일이 끝나면 집에서 쉬기만하고 데브식스 프로젝트만 조금씩 하는 수준으로 쉬는 시간을 가졌다. 최근에 글이 많이 올라오지 않은 다른 이유도 사실은 요즘 회사에서 안드로이드 개발과 플러터 개발을 동시에 하게 됐는데 아무래도 잘해보지 않았던 플러터를 하다보니 상대적으로 안드로이드쪽 지식보단 플러터쪽 지식을 많이 얻게 됐고 이것에 대해서 나 스스로도 깔끔하게 정리가 되지 않은 상황이라 글을 작성하기가 꺼려졌다. 안드로이드에 좀 더 집중하고 싶은 마음이 크지만 회사 일이라는게 내가 원하는것만 하게 되지는 않으니까 그냥 안드로이드 컴포즈와 비슷한 선언형 UI 에 익숙해지는 시간을 가진다 정도로 생각하고 있다. 실제로도 ..

간만에 쓰는 블로그의 글이 잡담인게 스스로 유감이다. 이것저것 정리하고 쓸것도 많은데 손에 잡히지 않는다. 그렇다고 공부하는걸 그만둔것도 일에 권태를 느낀것도 아니다. 그냥 내 마음의 문제다. 열정과 의지의 문제도 아니고 그냥 마음이 많이 지쳐서 조금 속도를 늦추고 날 보살피고 싶은거 같다. 가슴이 머리를 앞서가면 항상 이런일이 생긴다. 내가 간절하게 바란것과 현실의 괴리를 알았을때 그 간격의 크기만큼 나를 보살필 시간이 필요하다. 그리고 그 간격이 도저히 나만의 의지로는 좁혀지지 못하겠다고 생각이 들었을때는 더욱 더 그렇다. 노력으로만 되지 않는 일도 얼마든지 많으니까 그리고 그런 일의 대부분은 시간이 지나며 덤덤해지는게 대부분이니까. 괜찮아지겠지 이런건 계속 겪어왔고 앞으로도 겪게 되겠지 그러니까 그..

이전 포스팅에서는 BindingAdapter에 대해서 알아봤다. InverseBindingAdapter 에 대해 언급을 했었는데 이번엔 InverseBindingAdapter 에 대해 집중해서 포스팅한다. InverseBindingAdapter 은 양방향 데이터 결합을 지원한다. 갑자기 이게 뭔소린가 싶다면 기존의 BindingAdapter 와 차이가 뭔지를 봐보자. 기존의 Binding 은 Model To View InverseBinding 은 View To Model 이다. 그러나 InverseBinding 은 Binding의 역할도 포함하고 있기에 양방향이라고 볼 수 있다. 쉽게 말하면 Binding 은 Model 있는 값을 View 로 보내주기만 한다면 InverseBinding 은 view에서 ..

Databinding 관련 작업을 하다보면 BindingAdapter에 대해서 자주 보게 된다. 오늘은 BindingAdapter를 작업 할 일이 있었는데 생각이 난김에 정리를 해보려고 한다. 먼저 BindingAdapter는 뭐고 왜 쓰는걸까? BindingAdapter 는 view 의 속성을 커스텀하게 추가시킬 수 있는 것이다. 일단 잡다하게 BindingAdapter 을 적용하기 위해서 필요한 선작업들은 알고 있다는 상황으로 가정하고 적겠다. 먼저 viewmodel 부터 보자. @HiltViewModel class FeedViewModel @Inject constructor (private val feedUsecase: FeedReposUseCase): ViewModel() { private val..