Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- VisualStudio
- gradle
- 데이터바인딩
- 안드로이드
- 인증문제해결
- 설정
- Invalid credentials
- react-native
- sourcetree
- not working
- react
- git인증
- EC2
- 뒤로가기 안됨
- 안됨
- WPF
- Kotlin
- AWS
- 빌드 오류
- 리액트 네이티브
- flutter
- bitbucket
- 개발환경설정
- 안드로이드 스튜디오
- Git
- 디버깅
- Android
- 리액트
- 예제
- aPK
Archives
- Today
- Total
물에 살고싶은 개발자
NavController 사용 시 뒤로가기가 안되는 문제 본문
언제나 그랫듯, 선결론
옵저빙으로 화면을 넘긴 경우 되돌아오면서 다시 같은화면으로 이동시켜서 생긴 문제다.
옵저빙으로 화면을 넘길때 항상 해당 라이브데이터를 바꿔주든 해서 관리해야한다.
즉 !
뷰모델에 있는 라이브데이터를 이용해 navigate 시킬 경우 아래 예제를 보자.
ViewModel.kt
...
var onBoardingNav: MutableLiveData<Boolean> = MutableLiveData<Boolean>(false)
...
OnBoardingFragment.kt
onBoardingNav.observe(viewLifecycleOwner) {
navController.navigate(R.id.action_onBoardingFragment_to_loginMainFragment)
}
Fragment에서 이런식으로 화면을 넘길 경우
onBoardingNav.observe(viewLifecycleOwner) {
onBoardingNav.value?.let {
if(it) navController.navigate(R.id.action_onBoardingFragment_to_loginMainFragment)
}
onBoardingNav.value = false
}
이런식으로 라이브데이터의 값을 변경 해 줘야 한다.
평소엔 이렇게 선결론 후 아래에 주절주절 왜그랬는지 등등을 써왔었으나, 이번 글에서는 개발노트에 적어둔걸 토대로 정리하는것으로 마무리하겠다 !
아래는 문제를 인지 하고나서부터 해결까지의 과정을 순서대로 나열해본것이다.
- 왜인지 뒤로가기가 안되는 문제 발생
- 코드부터 싹 점검 -> 별다른게 없는데 문제는 발생한걸 확인
- not working으로 검색해봣으나 딱히 답은 없음
- 팝백으로 넘기기도 해봣으나 답이 안나옴 -> 브레이크포인트를 이용해봣는데, 백버튼도 팝백도 정상적으로 동작하는걸 확인 -> 근데도 화면이 안넘어감
- 그래서 아예 네비게이트로 넘겨봣는데, 이전에 살아있던 뷰가 아니다보니 데이터 유지가 안됨. -> 즉 데이터를 가져와야하고, 백스택이 쌓이는 문제도 발생
- 뭔가싶어 다른 프로젝트랑 비교하다보니, 비슷한 역할을 화면으로 넘어갈때 애니메이션을 태우는걸 발견
- 여기까지 확인한 타이밍에서 다른 프로젝트에는 옵저빙으로 네비를 태우지 않는걸 확인
- 옵저빙으로 해서 문제가 발생한걸까 막연한 생각도 들었지만 일단 액션 애니메이션부터 적용해봄
- 그랬더니 왠걸, 팝백을 했더니 뒤로갔다가 다시 생기는걸 확인 -> 천천히 뒤로가기를 하면 계속 같은화면이 나오고, 연속으로 빠르게 두번을 해야만 넘어가는걸 확인
- 그제서야 이전화면에서 호출코드쪽에 브레이크포인트를 찍어보니, 라이브데이터로 인해 돌아올때마다 옵저빙이 계속 호출되는걸 확인 -> 옵저빙을 이용하려면 네비를 태우기 전 플래그값을 제대로 바꿔주는 작업이 필요한걸 깨닳음.
- 어찌됏든 지금구조에선 크게 세가지방법이 있는데, 나열해보자면
- 아무튼 당장은 프래그먼트에서 변수조정을 해주는 방향으로 가기로 결정 -> 이유는 작업 시 레이아웃작업 -> xml에서 데이터바인딩 작업 + 뷰모델에 필요 변수와 메서드 생성 -> 뷰모델에서 필요한 로직 작성 -> 프래그먼트에서 해야할 일들 작성 순서로 작성중인게 퍼포먼스에 도움이 되는 프로세스라고 생각하기 때문, 역할군이 나뉘어있기때문에 레이아웃작업,데이터바인딩,로직,context가 필요한 작업 순서로 작업할때 내 머리도 역할에 따라 돌수있게 되어있어서 매끄럽게 진행되는게 체감되기때문.
- 다른 프로젝트의 코드를 참고하다보니 koin의 sharedViewModel() 도 있는걸 알게 됨. 이걸 이용하면 ViewModel이 공유되기때문에 괜찮을거같긴한데, 일단은 위 코드 예제처럼 변경하는것으로 해결
끝!
Ps. 필자가 이해도가 떨어지거나 잘못판단한게 있을수있다고 생각한다. 혹 보다 구조적인게 불편하다거나 그걸 왜 그렇게...하는 생각이 든다면 부담없이 댓글로 비판해주시길 ! (필자는 비난이 아닌 맹비판,맹지적을 좋아한다.)
Comments