나나공('나보다 나무늘보가 공부 열심히 한다') 트러블 슈팅

1차 리팩토링

2차 리팩토링

viewModel databinding (onClickListener -> onClick="{()->vm.navigateTo()} → intent 와 같이 context 가 필요한 click method 의 경우는 어떻게 대처할 것인지 공부 → 방법은 알았는데 고치려면 대대적인 공수가.. 하면 되지 → recyclerView Adatper 부분 제외 완료
강의 추가 화면 Jetpack Navigation 적용 → 구현 하려면 navigation show & hide → custom navigation 을 구현해야함 최신버전 대응이 안되는 이슈 → SharedViewModel + StateHandle을 통한 데이터 공유의 방법으로 해결~~
Update Validation 예외처리 해야함..
→ 이미 들은 강의수보다 수정한 강의수가 적으면 안된다 라던가 → 0개일때 다른 것을 바꾸면 버튼이 활성화 되어서 그거 토스트메세지 띄우는 형식으로 막아줘야 한다던가, 이부분 예외처리가 미흡했다.
inputForm 들 관련해서 liveData로 처리하는 방법 → button의 활성화/비활성화를를 liveData로 MediatorLiveData <-- keyword
투데이, 강의목록 화면도 databinding, livedata (recyclerview와의 연동)

문제) -> 해결

강의 등록 파트 네비게이션으로 변경하려고 함 → 네비로 변경하면 acitivty에서 api불르면 안됨 (타이밍이슈. 네비게이션을 사용하면 activity는 entry point의 목적으로만 사용가능) 첫번째 프래그먼트에서 api 불러서 activity에 변수에 저장시킴 (이럴 경우 첫번째 프래그먼트로 돌아올경우 다시 api를 호출해서 새로고침됨 그리고 강의 등록 api를 호출할때 cast 오류나서 앱이 죽음 → viewModel에서 데이터를 관리하는 형태로 바꾸지 않으면 네비게이션으로 전 처럼 정상적인 진행 불가능? -> ㅇㅇ navigation은 기본적으로 fragment 를 replace 하는 구조 → viewModel과 liveData 를 통해 변수들 상태관리 선행 작업 마무리 후 진행 그런데 상태에 따른 ui와 관련된 코드들은 어쩌지 상태를 통한관리? → 이게 LiveData를 쓰는 이유

리팩토링 말고 해야할 작업 - 기능 추가

강의 초과 수강 기능 추가 (하루 할당량 보다 더 많이 들을 수 있게 해서 조기 종료 할 수 있도록, 나공이와의 대결 승리)
매일 특정 시각마다 알림을 받을 수 있는 기능 추가

보안 부분) kakao API key, google api key firebase 등등

gradle properties → local properties 로 이동, 둘의 차이 확인

이슈)

Authenticator 가 적용되지 않음
- 임의의 값을 accessToken 에 대입할 경우 404 forbidden
- 빈값을 넣을 경우 “” → 401 Unauthorized → 과거버전 동작 확인 → 과거버전엔 authenticator 정상 동작 → retryLimitcount 변수 제거하여 해결
Success 일때에 대한 함수들 호출이 로그에 출력이안됨 - 실행이 안되는거같음; → emit을 안해준거였음 → 해결
인터넷 연결 끊겼을 경우에 대한 핸들링 → 인터넷 끊겼을때에 대한 화면 추가
appcompat → Material → 불필요한 확장 함수 제거 → ~ing
ssaid Datasoure에서 핸들링 → 일단은 그대로 → respositoryImpl 에 applicationContext 주입 받아서 ssaid 추출하는 방식으로 해결
style 속성 적용으로 불필요한 background drawable 파일 제거 → ~ing
툴바가 필요한 화면에 툴바 만들기
Gradle to KTS
→toml 파일을 이용한 version catalog 적용
fcm 토큰 저장 로직 정리 (로컬에 fcm 토큰을 저장하지 않는 경우)
- 처음 앱을 설치한 경우
  - 서버에 해당 아이디로 fcmToken이 저장되어잇는지를 조회 → 없음
  - 생성 후 서버에 저장 → fcm 정상 작동
  - 다시 앱을 실행 한 경우 서버에 fcm토큰이 있는지 조회 → 있음 → fcm 토큰 발급 api 및 서버에 저장하는 api를 실행하지 않음 → fcm 정상 작동
- 앱을 삭제하고 다시 설치한 경우 (새로운 fcm 토큰이 발급되는 케이스)
  - 서버에 해당 아이디로 fcmToken이 저장되어있는지를 조회 → 있음 (하지만 해당 토큰은 이제 쓸모 없는 토큰) → fcm 토큰 발급 api 및 서버에 저장하는 api를 실행하지 않음→ fcm 작동 X → 새로운 토큰을 발급받아서 이를 서버에 저장하는 로직이 필요 (대체)
fcm 토큰 저장 로직 정리 (로컬에 fcm 토큰을 저장하는 경우)
- 처음 앱을 설치한 경우
  - 서버에 해당 아이디로 fcmToken이 저장되어잇는지를 조회 → 없음
  - 생성 후 서버와 로컬에 저장 → fcm 정상 작동
  - 다시 앱을 실행 한 경우우 로컬에 저장된 fcm 토큰이 있는지 조회 → 있는 경우 서버에 fcm이 있는지를 조회하는 Api를 호출하지 않음 → 무분별한 api 호출 방지
  - 로그아웃 한 경우 auth 토큰과 함께 fcm 토큰 또한 preference에서 제거
  - 다시 앱을 실행한 경우 로그인 → 로컬 fcm 토큰 조회 없음 → 서버에 조회 → 있음 → 있는 경우 다시 로컬에 저장하는 로직이 필요)
- 앱을 삭제하고 다시 설치한 경우 (새로운 fcm 토큰이 발급되는 케이스)
  - 로컬에 조회 없음 → 서버에 fcm 토큰이 있는지 조회 → 있음 (하지만 해당 토큰은 이제 쓸모 없는 토큰) → fcm 토큰 발급 api 및 서버에 저장하는 api를 실행하지 않음→ fcm 작동 X → 새로운 토큰을 발급받아서 이를 서버에 저장하는 로직이 필요 (대체)
~~문제(결론) → 해결~~
- 앱 진입시 마다 토큰을 발급받아 서버에 전달하는 방식 채택
~~로그인 화면을 nav_home 에 포함시키기~~
- 로그인 화면의 구성
  
  로그인 액티비티, 로그인 바텀 시트 프래그먼트, 개인정보 처리 확인 바텀 시트 프래그먼트, 개인정보처리 웹뷰 액티비티
개인정보 처리 액티비티는 이미 프래그먼트로 만들어둔게 있음

문제 1) 해당 프래그먼트의 뒤로가기는 manage 화면으로 넘어가는 것으로 구현되어있는데 어떻게 개인정보 처리 바텀시트로 넘길까

앞에서 이동해왔을때 argument가 존재하냐 하지 않냐 등으로 따져서 이동을 분기해볼 순 있을 것 같다.

문제 2) 어느 화면을 start_Destination으로 해야할 것인가

~~로그인 화면으로 해서 auto login 시 빠르게 today 화면으로 넘기는 방향으로 하는게~~

~~ㅇㅇ 이 방법으로 하면 기존의 로직을 크게 바꾸지 않을 수 있음~~

문제 3) 바텀시트가 safenavigate로 기존의 애니메이션의 느낌으로 잘 넘거갈까? - 해봐야알것같음~~

기존엔 show close 의 형식이었는데 close는 어떻게 구현해야하지? 원래 show close 둘다 login activity가 담당했었는데 전부 프래그먼트가 되면..음~~

home activity에 해당 작업을 이전해줄수있을까?~~

바텀시트, 네비게이션 연동에 관한 학습이 필요하다.

스플래시 액티비티는 이제 아예 버려도되나?

내가 너무 한번에 바꾸려는것 같기도하다
- 우선 로그인 액티비티쪽 파트를 네비게이션으로 마이그레이션을 먼저 한 뒤에 그 후에 네비게이션을 합치는 방향으로 해보자
그럴려면 이제 근데 로그인 액티비티는 entrypoint의 역할을 해야됨 비즈니스 로직이 들어가선 안됨 그렇게 짤 수 있는가가 문제

어쨌든 간에 loginFragment로 모든 비즈니스로직을 이관해야함 둘이 상반된 방향이 아니기 때문에 먼저 이렇게 하기로하자
- 이제 registerBottomSheet 에 붙은 webviewfragment 만 제외하고 nestedGraph 로 넣어보자
BottomNavigationView + Navigation 관련 이슈
- 메뉴를 통해 이동하고 나서 시스템 백버튼을 누르면 startdestination으로 바로 이동되지 않고 백스택이 하나씩 빠지다가 마지막에 startdestination에 도착되고 종료된다
- startdestination을 로그인 화면에서 투데이 화면으로 변경해줄 경우 시스템 백버튼을 통해 바로 백스택을 거치지 않고 투데이 화면으로 이동할 수 있지만, 로그아웃을 한번 더 해주고 다시 홈화면에 진입할 경우 initNavigatio이 호출이 되지 않아서 startdestination이 초기화된다 ? → 그 전과 같이 바로 투데외화면으로 이동 → 앱 종료 로직이 깨진다
- 커스텀하게 setUpWithController 함수를 만들어보았는데 메뉴아이템과의 연동이 되지 않는다(시스템 백버튼을 누르면 메뉴 아이템의 변화가 이뤄지지 않음(클릭 상태))
- popUpTo, popUpToInclusive의 개념이 잘 잡히지 않아서 그런걸지도 현재 화면에 보여지고있는 화면은 백스택에 포함되지 않는다 로그아웃 액션의 popUpTo와 popUpInclusive 설정에 문제가 있는 듯 하다. → 로그아웃 한다음에 시스템 백버튼을 누르면 manage 화면으로 돌아가는 이슈
  
  → 로그인 화면으로 돌아가는게 다른 popUpTo 작업과 다르게 동작하는 이유 → 애초에 백스택에서 로그인 화면이 빠져있기때문에 popUpTo = @id/login ← 이게 무의미한 설정이 되버리는 것 것 같다.
  
  → logout 함수가 비동기라 today_lesson까지 전부 popup 처리해서 loginFragment 로 돌아갈 경우 토큰이 삭제 제거되지 않아서 바로 자동로그인 되어 today_lesson 프래그먼트가 열린다 → 그런데 그러면 쨌든 화면이 켜지고 나서 토큰이 지워져야되는거 아닌가?
  
  안지워지는것 같은데 → 토큰 삭제함수가 실행이 안됨 → 메소드가 실행되기이전에 프래그먼트가 없어져서 실행 자체가 취소된건가
  
  이러면 jwt토큰 만료시에도 똑같은 상황이 발생할텐데..? 매우 위험한 버그
- 또한 homeActivity는 앱이 시작할때 create 되면서 initNavigation 함수를 호출하는데 로그인 후에 startDestinaion를 코드로 바꿔줄수가 있는 걸까 ? → 이건 구독 개념이 들어가야할것같은데
  
  → 홈액티비티에 이벤트를 수집해줘야할듯
  
  → 아니다 액티비티는 그저 EntryPoint의 역할을 해줘야한다.
  
  → 기본적으로 startDestination을 login 이 아닌 today_lesson으로 해주고 → todaylesson 에서 로그인 상태를 체크해서 로그인이 되어있지 않으면 login으로 보내주면 될 것같다.
  
  → 두 화면이 다른 뷰모델을 사용하는데 어떻게 check를 바꿔주지
  
  → 두 뷰모델을 공유해야하나, BaseViewModel에 LoginState를 관리하는 건 소용이 없음
  
  → autoLogin 체킹을 today_lesson에서 해주면 되잖아 → 이거 false 나면 login으로 가고 이러면 화면 버벅임도 없을거고 베스트네 → 해결
  
  → 또한 startDestination을 today_lesson으로 변경해주었기 때문에 자동적으로 백스택에는 startDestinaion만 남겨지게 됨, 따로 백스택에 startDestinaion만 남도록 설정해주지 않아도 된다.
내가 알던 popUpTo / popUpToInclusive 와 프로젝트에 실 적용된 popUpTo / popUpToInclusive 가 이질적이라 느꼈던 이유

→ actionAtoB 를 통해 이동하면 새로운 스택이 하나 생성되어서 위로 쌓이는 형태이기때문이다

→ 따라서 B를 미포함 하고 pop 설정을 하고 이동하면 A → B (이동하면서 B)삭제 → A → 결국 A → A 의 형태 따라서 시스템 백버튼을 통해 한번 뒤로가기를 수행하면 바로 밑에 한번더 똑같은 화면이 들어가 있던 것이다!.

→ 결론은 순환형 이동시 A → B , B→A를 따로 따로 만들지 말고 그냥 B→A 는 뒤로가기와 동일하게 구현하는게 낫다!
로그인 부분 이슈

기존의 로직: 신규가입의 경우 첫 로그인 성공시 isNewMember: true가 떨어지면 → 개인정보동의 화면이 뜬다 → 동의하고 시작하기를 누르면 메인 화면으로 이동하게 된다. → 취소를 선택하면 첫 로그인 화면으로 다시 이동된다.

개인정보동의 화면)

문제 발생)

→ 이때 다시 로그인을 하게 되면 이미 어쨌든 기존의 로그인을 한 유저이기 때문에 isNewMember:False가 response로 넘어오고 개인정보 동의 화면이 뜨지않고 바로 메인화면으로 이동된다.

문제를 해결하려면)

→ 취소를 눌렀을 경우 유저 로그인 기록 초기화? api를 호출하여 다음 로그인 api 호출의 결과의 response의 isNewMember가 다시 True로 넘어오도록 해줄 필요가 있을 것 같다.
- accessToken 을 검사하는 api 추가하여 해결
유스케이스 네이밍 컨벤션 통일 → get/fetch delete/remove
updateMemberDialog IllegalStateException 해결 (두번째 dialog open 했을 경우 앱이 꺼지는 문제) [The specified child already has a parent. You must call removeView() on the child's parent first (Android)](https://stackoverflow.com/questions/28071349/the-specified-child-already-has-a-parent-you-must-call-removeview-on-the-chil)

→ DialogFragment 로 migration 하여 해당 문제를 해결하고 Navigation으로 연결 및 databinding 하려고 했던 TODO 도 해결 → 버튼 관련 확장함수 제거, drawable resource 제거 까지 → 처음에 다이얼로그를 열었을 때, hint 가 화면에 출력되지 않는 이슈 해결
SlothDialog 도 SlothDialogFragment 로 전환 → onClickListner interface 를 어떤 방식으로 대체 할 수 있을 시 학습 → 각각의 독립적인 뷰모델을 가지는 dialogFragment 로 쪼개면 됨 → 강의 삭제 다이얼로그 관련 백스택 이슈 → dialogFragment 짜부 이슈 -> BaseDialogFragment 에서 size 설정
강의를 삭제할때 한번 눌러도 다이얼로그가 꺼지지 않고 화면은 투데이화면으로 돌아오는 이슈 navigation action 관련 이슈같다. → 다이얼로그 관련 비동기 이슈? → 강의 목록 화면으로 돌아오지 않고 투데이화면으로 돌아오는 이슈 → 백스택 관련 → 에러 재현 강의를 수정하고 상세화면으로 돌아와서 삭제하는 경우 발생 → 삭제되었습니다 토스트메세지도 두번 출력됨 → 토스트가 두번 뜨는거는 뷰모델의 상태를 공유해서 그런것같다? → 독립적인 뷰모델을 가지는 화면으로 만들어야 할것같기도 → Dialog 를 DialogFragment 로 각각 하나씩 쪼개서 해결
투데이 화면 클릭 이벤트 관련 리팩토링 → 뷰에서 뷰의 갱신을 위해 updateLessonCount 함수를 실행하는데 이 내부에서 viewModel의 함수와 어떤 버튼을 눌렀는지에 대한 enum class의 타입을 파라미터로 받는다 → 뷰모델 함수 호출의 결과로 (api호출) 받은 데이터와 기존에 함수의 파라미터로 받은 enum class의 타입 변수를 통해 다음 행동에 대한 조건문이 세워진다 → 따라서 뷰 내에서 viemodel의 함수를 호출하며 바로 결과를 받는 구조이다. withContext ~

→ 기존의 구조처럼 상태를 나타내는 상태변수의 갱신된 값을 통해 (successEvent) 뷰에서 수집하는 형태로 로직을 수정해보려고 했지만 같이 받아줘야하는 enum class의 타입 변수들이 recycler view 의 adapter 내부의 enum class 들이기 때문에 뷰에서 바로 접근을 할 수가 없다 그래서 어댑터의 onClick 익명함수를 구현하는 블럭 내에서 함수를 호출 해주고 있는 형식이다. → 현재 방식이 마음에 안들지만 더 나은 방법으로 고치는 방법을 아직까지는 모르겠다
hiltNavGraphViewModel 을 사용할때 이슈

강의 목록 화면에서 처음으로 클릭한 강의의 id가 savedStatehandle 에 저장되어 다른 강의를 클릭하여도 이전 강의의 상세화면만 보여지는 이슈 lessondetailviewmodel을 viewmodels 로 초기화하면 deleteLesson뷰의 뷰모델을 hiltGraphViewModel 로 할 경우 앱이 죽음 두 뷰가 뷰모델의 상태를 공유하고 있지 않기 때문에 왜 처음 진입한 lessonDetial의 id만 저장되고 그 이후로는 갱신이 되지 않을까?
databinding 관련

업데이트 맴버 화면에 edittext:hint는 절때 databinding이 적용이안되고(화면에 출력이 안되고) edittext:text는 잘만된다.. 이상하다 증말 → 정상이다. 초기값이 “” 이라 “” 로 바인딩이 되고 그 뒤로는 변하지 않는다. EditText 의 hint 의 기본 속성이 그럼
또 다시 발생한 강의 등록에서의 문제

first에서 second 로 갔다가 다시 first 로 돌아오면 카테고리가 빈칸으로 출력된다. 앱이 죽지는 않는데 아마도 뷰모델 내부에 init 블럭으로 api를 호출해서? 그런거같다. 맞음, startDate만 init에서 초기화해주는게 맞는 방법이다. 나머지는 FirstFragment 의 onStart 콜백에서 호
updateLesson 이슈 강의 개수를 수정할 때 뒤에 ‘개’가 정상적으로 붙지않음 개수, 원 수정시 발생 해결
flow 중간 연산자를 통해 lesson site, category response data를 변환하여 최종 형태로 바로 뷰에 emit 할 수 있게 변경 → map(), transform() 과 같은 연산자를 이용 → 모듈을 나누면서 mappter 를 통해 하는게 나을수도

온보딩 튜토리얼

 1. 처음 로그인했을 경우 온보딩 튜토리얼 진행 (isNewMember = True)
 2. [메인화면, 1번째 화면] 으로 진입하고 플러스 버튼을 한번 누르면 [완료한게 없는 경우, 2번째 화면] 으로 이동
 3. 3번 클릭을 완료한 경우 [완료한게 없는 경우→ 완료한 경우, 3번째 화면]으로 이동
 → 여기서 다른 버튼들을 눌를 수 있는데 다른 버튼들을 누르는 경우의 대한 핸들링 
 → 막아놔야하는지, 아니면 그대로 둬도되는지 (강의를 등록해버릴 경우) -> 바텀 네비게이션 뷰를 hide

 4. 완강하기를 누름 → [진행할게 없는 경우 화면, 4번째 화면]으로 이동
 5. [진행할게 없는 경우] 화면에서 강의 등록하기를 누르면 강의 등록화면 이동(진짜 강의 등록 진행)
 6. 진짜 강의 등록완료 → [강의 목록, 5번째 화면] 으로 이동
 7. [강의 목록화면]에서 방금 진짜로 등록한 강의를 클릭하여 강의 상세 화면으로 이동 → 온보딩 튜토리얼 종료 (isNewMember = False)

위로 보이는 나공이는 나중에 구현하고 아래 화면부터 먼저 구성을 해보도록 하자 → 화면 비율 때문에 모든 화면에서 대응이 불가능
온보딩 관련) onBoardingAdapter 와 TodayLessonAdapter 분리의 필요성 ← 차이가 존재 상태관리를 더 세세하게 해야할 것 같다. 투데이화면 온보딩이 종료되었는가? + 강의 목록화면에서의 온보딩이 종료되었는가? 강의를 등록하고 왔는가? ~~checkOnBoarding 해서 false 이면 투데이 화면으로 빠꾸, 이게 확실한 방법~~

근데 그러면 true 떴을때 강의 목록에서의 checkDetail 화면을 계속 띄워주게 될 텐데 투데이 화면에서 온보딩 안끝났으면 아예 일로 넘어오지 못하게해야지 않나 check 해서 다시 돌아가게 빠꾸먹일까 그게 쉬울 것 같은데 근데 그러면 checkDetail OnBoarding 화면을 띄울 수 없음 onBoarding 이 Complete 되었을 때 띄운다면 매번 강의목록 화면에 진입할때마다 checkDetail 온보딩이 수행됨

→ 시스템 백 버튼을 막아버리는 것으로 해결

fetchMemberInfo내에서 onBoarding이 종료되었는지 먼저 검사하고(fetchLessonList 도 마찬가지 종료가 되지 않았다면 빠꾸 종료되었다면 UseCase를 호출하는 식으로 구현해야 UDF를 위반하지 않는다

강의를 등록하는 절차를 밟지 않아도 바텀 네비를 통해 강의 목록화면으로 이동하면 강의 목록화면 온보딩이 띄워진다 -> 온보딩 진행시 바텀 네비게이션 뷰 hide 그 상태로 투데이화면 가면 또 다시.. 마이페이지 갔다와도 초기화되고 전부 뜯어고쳐서 상태관리를 용이하게 만드는게 더 쉬울수도..?

→ 온보딩의 상태를 하나로 관리하지말고 따로 분리하도록 하자
- 강의 목록 화면에 도달하였고, 상세화면에 진입했다가 뒤로 돌아왔는데 강의 목록 화면 온보딩 다이얼로그가 뜨는 이슈
- 강의 목록 화면 온보딩이 띄워진 상태에서 온보딩 을 닫고 투데이화면 탭을 눌러도 눌러지지 않는 백스택 관련 이슈
지금 보이는 맘에 안드는 것들
- 전체적인 부분 stock market app 참고→ 네트워크 통신(repository, viewmodel) 에러 처리 코드 개선 가능성 다분히 존재해보임.
  
  scope 함수) with vs apply → binding.apply vs with(binding) → viewModel.apply vs with(viewModel) → 각각의 용도를 학습하여 적용
- todaylesson
  - auto login → fetchTodaylesson ← UDF 위반
  - when(boolean) { true → else(?) → } 직관적이게 false
    
    → 아니면 굳이 true else 인데 when 으로 할필요가 있나 싶기도 함 -> 조건 분기가 2개인 경우 그냥 if else 로 해결
  - 조건식이 복잡한 경우 조건식을 변수화 해볼 것(isNotStarted, isFinished)
  - dialogFragment 코드내에 deprecated된 code 수정
  - SharedFlow event 상권님 블로그 참고해서 뷰에 코드 간략화 → 구글 공식 아키텍처 패턴을 고려 (UiState + StateFlow
  - LessonDetail 화면 chip button 이 내려와있다 → onBoading develop 에 merge 하고 바로 수정해야 → ~~운영서버 배포할때 이것도 할걸…~~
  - 운영서버 BASE_URL 이 다를때 화면에 인터넷 연결 불가 화면이 뜨는 이슈 (그냥 error 가 아니라 internet error 로 잡히는 이유
  - mapper 를 통해 data , domain, ui 에서 사용하는 모델을 분리 → 투데이, 강의 목록 화면에서 사용하는 모델의 사잇 변환과정을 간략화
  - 변수명의 list → Clean Code 위배 변수의 복수형으로 바꿔볼 것
  - navigation graph 가 너무 복잡한거같은.. nested nav graph 로 좀 분리를 할 수 없나도 고민해보자
  - 웹뷰 화면에도 인터넷 연결이 안되었을 경우 onReceivedError() 콜백을 통해 에러페이지 보여주기
  - splash screen 첫페이지 로드가 성공되고 나서 종료시키기 적용해보기(diary app 참고)
  - 뷰 내에서 .value 로 접근하는 경우 지양 -> 최대한 관련 코드 수정 중
  - .apply 는 값을 변경할 때 사용한다 적절하지 않은 사용 수정
  - string resource 분리, 및 이름들 수정
  - 리스트 깜박이던 문제 해결
  - Coroutine job 을 통한 생명주기에 호출되는 api 동시 실행 제어 → 빠르게 화면을 반복해서 진입할 경우 이전 api 호출이 종료되기 이전에 다음 api 가 호출될 경우에 대한 무한 로딩 이슈 해결
  - 화면 좌우 비율 관련…
  - retry 구현 관련 (abstract fun 이라고 선언해야지만 바디 없는 형태로 선언해둘 수 있다)
  - 2항 연산이면 when 제거
  - drawable 을 비롯한 다른 resources 도 stringProvider 처럼 resourceProvider 를 통해 뷰모델에서 다룰 수 있긴 하다
  - todayLesson 화면 app바 처럼 lessonList 화면도 수정 -> appBar elevation은 android:elevation 이 아니라 app:elevation으로 0dp 를 적용해주어야 그림자가 사라진다
  - DiffUtil 비교값 관련 이해안되는 부분 이해
  - 항상 update 를 통해 stateFlow 를 업데이트해도 되는건지 → 아니다 적절하게 취사 선택해야한다. 동시에 호출될 수 있는 가능성이 있는 경우만 update를 사용하는것으로

2023/2/6 회의에서 언급해야할 것들

온보딩 관련
- 온보딩이 튜토리얼 형식일 경우
  - 로컬 디비를 통해 온보딩 완료 여부를 저장하고 있었는데, api의 형태로 바꿀지 고민
    
    앱을 삭제하고 다시 시작할 경우 다시 온보딩 튜토리얼이 진행되는 이슈
  - 온보딩 진행 중에 다른 버튼들을 누를때의 대한 핸들링을 해줘야 한다.
    
    강의 채워보기 튜토리얼을 하고 있는데 강의 목록 화면으로 가서 강의를 등록해버릴 경우, 온보딩이 끝나지 않았기 때문에 투데이 화면에서 등록한 강의를 볼 수 없다.
  - 화면 대응 불가능, 위에 올라와있는 이미지와 밑에 있는 화면의 버튼, 아이템 등의 크기 비율을 모든 기기에 대해서 대응을 할 수 없다.
recyclerview 를 사용하는 화면 관련 변경 가능한 사항(pagination이 지원되지 않아 api 호출시 모든 데이터를 내려주는 경우에)
- 기존의 방법
  
  API 호출 → 데이터를 성공적으로 가져왔는지를 뷰에서 구독(Result.Success) → success 이면 뷰에서 list를 세팅 (각 타입의 리스트를 따로따로 뷰에서 선언하여 조건에 맞춰 데이터를 각각 담음)
  
  → 각각의 리스트를 각각의 어댑터에 부착하여 → concatAdapter로 합침 → adapter를 리사이클러뷰에 부착
  
  클릭이벤트 전달 방식) adapter 내에 enum class를 선언하여 각각의 adapter마다 상수를 파라미터로 넣어서 해당 파라미터(ex)Adapter.BodyType, Adapter.ClickType) 와, ‘뷰’에서 구현한 클릭이벤트(비즈니스 로직)를 adapter에 생성자에 담아서 전달하여 처리
- 개선
  1. 각각의 리스트를 뷰가 아닌 뷰모델에서 관리하자
    
    변경사항이 존재하면 stateFlow.update 확장함수를 통해 변경
  2. 클릭이벤트(비즈니스로직)을 뷰모델내에서 구현한뒤에 해당 뷰모델 함수를 adapter의 파라미터(람다)로 전달 (viewModel 을 adapter에 직접 전달하지 말고, 해당 뷰모델 함수만을 전달). 뷰홀더에 존재하는 클릭리스너 제거
  3. Adapter들을 lazy 하게 초기화해주자
  4. Adapter 에 파라미터로 들어간 enum class 상수를 제거하고 adapter 내의 viewtype 으로 분리 (adapter 내부의 companion object 를 사용하여 adapter의 파라미터를 제거)
  5. TODO → 온보딩을 위에 얹기 (UDF 를 위반하지 않는 로직으로 → api 호출→ 뷰에서 api 를 결과를 성공적으로 받았는지 뷰에서 구독 → 다시 뷰모델내의 api 함수 호출 (x))
  6. TODO → 하나의 뷰에서 너무나도 많은 이벤트를 구독 (상권님 글 5번째 방법을 참고하여 sealed class로 이벤트를 관리하는 방법을 적용하여 initObserver함수 개선) -> 리스트를 뷰모델 내에서 관리
remote 를 통해 받아온 list<데이터>를 뷰모델내에 변수(리스트)로 관리하자
update 가 이뤄질 경우 api를 호출하고 변경된 list 변수에 접근하여 업데이트해주자.
해당 list를 화면에서 구독하는 형태이므로 업데이트된 것이 바로 반영될 것이다.

→ adapter.submitList 의 형식으로
이러면 매번 각각의 list 를 새로 생성해서 데이터를 조건에 따라 넣고 어댑터에 다시 리스트들을 장착해줄 필요가 없다.
또한 로직이 간편해져서 updateLessonCount 함수를 간소화 할 수 있다.
다만 새롭게 강의가 추가될 경우에 대해 이를 반영해주기 위해선 다른화면에서 있다가 다시 돌아왔을때는 fetchLessonList api를 호출해야한다.
하나의 리스트내에서 특정 값을 검사하여(투데이 화면일 경우에 untilTodayFInished) 이를 통해 뷰타입을 나누고 뷰타입을 통해 하나의 어댑터로 모든 리스트를 관리할 수 있어 concatAdapter 를 사용하지 않아도 된다. ← 추가적인 학습이 필요
강의 목록 내에서는 3가지의 뷰타입으로 뷰홀더를 나눠서 하나의 어댑터로
이제 문제는 아이템 내부의 클릭이벤트는 어떤식으로 개선할 수 있느냐 인데
각 상태의 대한 header viewType 으로 하여금 concatAdapter 를 제거하는 방향으로..? 어렵다

concatAdapter 를 계속 써야되는건지, 쓰지 않는 방향(emptyLessonAdapter 와 TodayLessonAdapter 로만 분리)으로 완전 변경해야하는건지

이럴거면 list 도 분리하면 안된다 하나의 리스트로 관리하고 diffUtil 을 통해서 뷰홀더를 구분해줘야한다. → 가능한 건가?
근데 지금 짠대로 만약에 run 하면 뷰들이 뒤죽박죽 섞여있을 것 같다. 정렬이 수반되어야할 것 같은데.. 그게 가능한건가 (채팅과의 차이점)

각 뷰타입들이 모여있어야 하는데…

2023/2/20 회의에서 언급해야할 것들

백엔드 투데이화면 오늘 아직 끝내지 않은 강의 (untilTodayLessonFinished 가 false)인 것을 우선으로 정렬해주세요.

lessonId 는 이제 후 순위
투데이 화면에서 강의 등록시, 온보딩에서 강의 등록시 등록완료 후 투데이 화면 바텀 탭이 눌리지 않는 이슈

→ 강의 등록 네비게이션이 강의 등록 완료시 기존의 강의 목록 화면까지의 백스택을 제거해주면서(popUpTo) 종료되는데, 이 경우엔 백스택에 강의 목록 화면이 없음

→ 따라서 해당 화면이 백스택에 없으므로 백스택 자체가 제거되지 않았기 때문에 발생

→ 시스템 백버튼을 누르면 강의 등록 화면으로 다시 이동됨

→ 근데 왜 투데이 화면 바텀 탭 자체가 눌리지 않는지 그 이유는 모르겠음..(singleTop 설정을 해줘야하는건지)

→ 조건부 탐색 을 활용해서 popUpTo 설정에 들어갈 화면을 ‘동적’으로 설정해줘야 해결 가능할듯

조건부 탐색 | Android 개발자 | Android Developers

→ 아님, safeargs 를 사용해서 각각의 화면에서 강의 목록화면으로 이동할때 인자를 전달해서 그 인자를 통해 어떤 화면에서 왔는지 판별→ 상황에 맞게 강의 완료 후 이동하는 화면을 분기처리해주면 된다

시행착오

viewmodel 에서 SSOT 를 만족시키기 위해 uiModelList 내의 데이터를 직접 수정하는 형식으로 짜봤는데 화면이 불필요하게 깜빡거리고 프로그래스바의 애니메이션도 부드럽지않고 끊겨서 데이터를 이원화 시키는 방향으로 다시 돌림..

fun updateOnBoardingItemCount(count: Int) {
        if (count == 1) {
            increaseOnBoardingUiItemCount()
        } else {
            decreaseOnBoardingUiItemCount()
        }
    }

private fun increaseOnBoardingUiItemCount() {
        lateinit var newItem: TodayLessonResponse
        lateinit var currentItem: TodayLessonResponse
        val currentList = _onBoardingUiModelList.value.toMutableList()
        var flag = false

        for (i in currentList.indices) {
            if (currentList[i] is OnBoardingUiModel.OnBoardingDoingItem) {
                currentItem = (currentList[i] as OnBoardingUiModel.OnBoardingDoingItem).todayLesson
                break
            }
        }
        Timber.d("$currentItem")
        Timber.d("$flag")

        val isOutOfRange = currentItem.presentNumber >= currentItem.untilTodayNumber
        if (isOutOfRange) return

        val isFinished = currentItem.presentNumber + 1 == currentItem.untilTodayNumber

        if (isFinished) {
            newItem = currentItem.copy(presentNumber = currentItem.presentNumber + 1, untilTodayFinished = true)
            flag = true
        } else {
            newItem = currentItem.copy(presentNumber = currentItem.presentNumber + 1)
        }

        currentList.replaceAll {
            if (it is OnBoardingUiModel.OnBoardingDoingItem) {
                OnBoardingUiModel.OnBoardingDoingItem(newItem)
            } else {
                it
            }
        }

        // _onBoardingUiModelList.value = currentList
        _onBoardingUiModelList.update { currentList }
        Timber.d("${_onBoardingUiModelList.value}")
        if (flag) setOnBoardingItem()
    }

private fun decreaseOnBoardingUiItemCount() {
        lateinit var newItem: TodayLessonResponse
        lateinit var currentItem: TodayLessonResponse
        val currentList = _onBoardingUiModelList.value.toMutableList()
        var flag = false

        for (i in currentList.indices) {
            if (currentList[i] is OnBoardingUiModel.OnBoardingDoingItem) {
                currentItem = (currentList[i] as OnBoardingUiModel.OnBoardingDoingItem).todayLesson
                break
            }
        }
        val isOutOfRange = currentItem.presentNumber == 0
        if (isOutOfRange) return
        val isNotFinished = currentItem.presentNumber == currentItem.untilTodayNumber

        if (isNotFinished) {
            newItem = currentItem.copy(presentNumber = currentItem.presentNumber - 1, untilTodayFinished = false)
            flag = true
        } else {
            newItem = currentItem.copy(presentNumber = currentItem.presentNumber - 1)
        }

        currentList.replaceAll {
            if (it is OnBoardingUiModel.OnBoardingDoingItem) {
                OnBoardingUiModel.OnBoardingDoingItem(newItem)
            } else {
                it
            }
        }
        // _onBoardingUiModelList.value = currentList
        _onBoardingUiModelList.update { currentList }
        Timber.d("$flag")
        if (flag) setOnBoardingItem()
    }

private fun setOnBoardingUiItem() {
        Timber.d("setOnBoardingItem() 호출")
        _onBoardingUiModelList.update {
            if (_onBoardingList.value.isEmpty()) {
                listOf(
                    OnBoardingUiModel.OnBoardingHeaderItem(OnBoardingType.EMPTY),
                    OnBoardingUiModel.OnBoardingTitleItem(OnBoardingType.EMPTY),
                    OnBoardingUiModel.OnBoardingEmptyItem
                )
            } else {
                onBoardingList.value.groupBy {
                    it.untilTodayFinished
                }.values.map { todayLessonList ->
                    todayLessonList.map { lesson ->
                        if (lesson.untilTodayFinished) {
                            OnBoardingUiModel.OnBoardingFinishedItem(lesson)
                        } else {
                            OnBoardingUiModel.OnBoardingDoingItem(lesson)
                        }
                    }
                }.flatMap { todayLessons ->
                    when (todayLessons.first()) {
                        is OnBoardingUiModel.OnBoardingDoingItem -> {
                            todayLessons.toMutableList().apply {
                                add(0, OnBoardingUiModel.OnBoardingTitleItem(OnBoardingType.DOING))
                            }
                        }
                        is OnBoardingUiModel.OnBoardingFinishedItem -> {
                            todayLessons.toMutableList().apply {
                                add(0, OnBoardingUiModel.OnBoardingTitleItem(OnBoardingType.FINISHED))
                            }
                        }
                        else -> return
                    }
                }.let { lessons ->
                    val isFinished = lessons.find { it is OnBoardingUiModel.OnBoardingDoingItem } == null
                    when {
                        isFinished -> {
                            lessons.toMutableList().apply {
                                add(0, OnBoardingUiModel.OnBoardingHeaderItem(OnBoardingType.FINISHED))
                            }
                        }
                        else -> {
                            lessons.toMutableList().apply {
                                add(0, OnBoardingUiModel.OnBoardingHeaderItem(OnBoardingType.DOING))
                            }
                        }
                    }
                }
            }
        }
    }

조기 완료한 강의 lessonStatus 를 PAST 로 변경해달라고 요청드려야 함
투데이 화면 이슈 login → onBoarding 완료 → fetchTodayLesosnList 호출 플로우에 collect 함수에 로그를 찍어본 결과 다른 화면 (바텀네비와 연결된 강의목록, 관리화면)에 이동했다가 다시 돌아오면 로그가 n 배씩 호출되는 이슈 (api 자체는 1번만 호출되도록 막아놔서 1번만 호출) → 근본적인 원인은 순환형 함수 호출 (funA() 함수 내에서 funB() 호출, funB() 함수 내에서 funC() 함수 호출) → 설계적 측면에서 A 함수가 B,C 함수에 대한 행위의 책임까지 전부 지게 됨 → 단일 책임 원칙 위배 → 테스트 측면에서 A 함수를 테스트하기 위해서는 B,C 까지 처리해야하는 문제가 생김 → 개발 측면에서 A -> B -> C 로 이어지는 Call stack 이 단일 stack 이라면 상관없지만 어딘가에서 B를 호출하는 순간 순환 호출 구조가 성립될 가능성이 있음
온보딩 강의 업데이트와 투데이화면 강의 업데이트의 로직이 동일한 것 같은데 투데이화면에서 uiModel.todayLesosn.presentNumber ++ — 는 viewModel 내에 관리되는 리스트의 원소를 직접 업데이트하는 반면에 온보딩화면에서의 uiModel.todayLesson.presentNumber ++ — 는 viewModel 내에 관리되는 리스트의 원소를 직접 업데이트하지 않는 이슈 두 코드의 차이를 확인 후 어느쪽이 잘못된 것인지 확인하고, 잘못된 쪽을 확인하여 주말내에 머지 후 배포를 수행해야 함

→ 투데이 화면의 updateLessonCount 가 비동기 (네트워크 호출) 함수 이기 때문에 발생했던 이슈(타이밍 이슈) → viewModel 의 updateLessonCountItem 함수를 Result.Success 일 때 호출하는 것이 아닌, 메소드 호출시 바로 호출되는 식으로 변경하여 (동기적으로 호출) 해결

update 적용사항)

온보딩 추가
통계 기능 추가
투데이화면에서 강의를 등록하고 나서 투데이 화면으로 돌아갈 수 없는 문제를 해결(하단 탭의 버튼을 눌러도 반응이 없던 문제)
알림 목록 화면 추가 (Paging 라이브러리 적용은, api response 수정 후에 적용)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

나나공('나보다 나무늘보가 공부 열심히 한다') 트러블 슈팅

Clone this wiki locally