_2nd.png&blockId=9df03bbd-ef30-4207-938b-bc84094584bc)
질문(예시)
1.
현재 navigation을 사용중인데, 하나의 navigation graph안에 많은 fragment가 들어있어 분리를 해야할 것 같은데, 어떻게 해야할 지 감이 안옵니다.
위 사진은 쇼핑몰 프로젝트를 예시로 든건데, 빨간 동그라미 친 3개의 프래그먼트만 bottom navigation tab에 해당하는 프래그먼트고, 나머지는 모두 하위 프래그먼트들입니다.
각 tab별로 navigation graph를 분리해야할 것 같은데, 이 방법이 맞는지 궁금합니다.
2.
아래 동영상처럼, 카테고리 탭의 상의 버튼을 클릭하면 새로운 창이 뜨고, 바텀네비게이션은 더이상 보이지 않도록 구현하고 싶습니다. 쇼핑몰 프로젝트 때 fragment전환 시 bottomnavigation을 숨기도록 구현했는데, 전환과 숨기는 동작의 속도가 안맞아 어색하더라구요.
계속 fragment를 사용하면서 이를 개선할 방법이 있을까요?
아니면 fragment말고 activity를 사용하는게 깔끔할까요?
화면캡쳐(예시)
위 질문에 해당하는 질문의 링크나 스크린샷을 여기에 추가해 멘토분들이 참고할 수 있도록 하세요.
프로젝트 주소
위 질문에 해당하는 질문의 링크나 스크린샷을 여기에 추가해 멘토분들이 참고할 수 있도록 하세요.
멘토 답변
•
코드 깔끔하게 작성이 되어있고, 미리 준비한 답변들이 이미 알고 있고 또는 적용한 상태라서 크게 말씀 드릴 것이 없었다.
현재 navigation을 사용중인데, 하나의 navigation graph안에 많은 fragment가 들어있어 분리를 해야할 것 같은데, 어떻게 해야할 지 감이 안옵니다.
기능 별로 nested Graph를 만드는 것이 좋다.
ex)
navigation/sign_up_graph.xml
navigation/login_graph.xml
아래 동영상처럼, 카테고리 탭의 상의 버튼을 클릭하면 새로운 창이 뜨고, 바텀네비게이션은 더이상 보이지 않도록 구현하고 싶습니다. 쇼핑몰 프로젝트 때 fragment전환 시 bottomnavigation을 숨기도록 구현했는데, 전환과 숨기는 동작의 속도가 안맞아 어색하더라구요.
NavController의 DestinationChangedListener를 통해 BottomNavigationBar를 show/ hide 하는 것이 가장 이상적인 방법인데 이미 적용되어 있었습니다
+ BottomNavigationBar가 사라지는 동작이 이상한 이유로 전환 시 아래에서 위로 올라오는 애니메이션을 사용하는 것과 관련이 있을까요?
누군가에게는 그런 이유도 있을 수 있겠지만
전환 애니메이션은 전환되는 화면에 영향이 클 수 있다.
아래에서 위로 올라옴: 기존 Context(문맥)과 달라지는 화면이 전환될 때
ex) 로그인 성공 후, 메인 화면
좌우로 슬라이드: 기존 Context를 유지하면서 화면이 전환될 때
ex) 로그인 화면에서 아이디 찾기로 넘어갈 때 → 로그인 Context를 유지
전환 애니메이션은 전환되는 화면에 영향이 클 수 있다.
아래에서 위로 올라옴: 기존 Context(문맥)과 달라지는 화면이 전환될 때
ex) 로그인 성공 후, 메인 화면
좌우로 슬라이드: 기존 Context를 유지하면서 화면이 전환될 때
ex) 로그인 화면에서 아이디 찾기로 넘어갈 때 → 로그인 Context를 유지+ 추가 답변) BottomNavigationBar가 hide 되어야 하는 Fragment 들의 위치가 이상한 것일 수 있다.
mainFragment Fragment Container에서 사용되는 fragment_nav_graph는 BottomNavigationBar를 통해 전환되는 Fragment만 존재하게 만들고
기존에 BottomNavigationBar가 사라져야 하는 Fragment 들은 nav_graph로 옮기는 것이 좋다.
현재 package 구조가 괜찮은지 모르겠어요.
package 구조에 정답은 없다고 생각하지만,
기능 또는 화면 별로 package를 나누고 그 안에 activity, fragment, view model, ui data 등을 정의하는 구조로 되어 있는데 문제없는 구조이고 최신 트렌트와 일치한 부분이 많다.
uiTread와 또 다른 Worker Thread가 필요한지 모르겠어요. 네트워크 요청 결과가 올 때까지 화면에서 별다르게 처리해줄 수 있는 것이 없는 것 같아요
UI Thread 에서 비동기 작업을 하게 되면 아예 쓰레드를 점유하게 되므로 다른 작업을 할 수 없다. 따라서 유저의 인터렉션 자체가 막히기 떄문에 올바른 Ux가 아니게 된다.
Android의 ANR를 참조하면 좋다!
매번 서버 혹은 Firebase에 데이터를 요청하는 것이 비효율적인 것 같은데 로컬에 저장해서 데이터를 보여주는 것은 어떤 경우인지 어떻게 하는 것인지 궁금하다.
JavaScript
복사
기본적인 동작 흐름은
1) UI에서 데이터 호출 -> local Data 확인 후 최신 데이터면 그대로 전달
2) UI에서 데이터 호출 → local Data 확인 결과 업데이트가 필요함 → 서버로 부터 데이터 갱신 → UI에게 전달
2의 경우. 서버로 부터 온 데이터를 그대로 전달하지 않고 로컬에 저장해서 observe 패턴으로 ui에게 전달하는 경우도 있다.
이런식으로 로컬에 데이터를 캐싱해서 사용자에게 보여주는 경우는
1) 사용자 UX 경험의 증진
네트워크가 불안정한 유저들이 많은 경우, 좋은 Ux를 제공해주기 위해서
2) 최신 데이터가 크게 중요하지 않는 경우
금융처럼 돈 관련 정보들은 항상 최신 데이터를 보여줘야 해서 로컬에 데이터를 한번 캐싱하는 것이 위험할 수 있다. 클라에서 고도의 동기화 로직을 보유하지 않는다면
그래서 보통 약간 오래된 데이터를 보여줘도 크게 문제가 없는 서비스에서 가져갈 수 있는 구조로 보인다.
홈 화면에 돌아오면 가끔 리스트가 버벅이는 현상이 많아요.
ListAdatper 라는 RecyclerView의 개선된 Adapter를 사용해보는 것도 좋다.
RecyclerVIew.Adapter는 새로운 리스트에서 변경된 범위를 따로 알려주지 않는 이상 매번 새로 그리기 때문에 성능이 좋지 않다.
cc. notifyDataSetChanged vs notifyItemRangeInserted
notifyItemRangeInserted를 이용해서 변경된 Item을 직접 Adapter에게 알려주는 것은 복잡하고 번거롭다.
ListAdapter는 위 문제를 해결해주는 Adapter로 개발자는 단순히 list만 sumitList 하면 내부적으로 비동기 Thread에서 이전 List와 비교해서 변경된 Item만 다시 그리게 되어 성능이 올라간다.
+ 만약 더욱 성능 개선을 하고 싶다면 ListAdapter with payload를 찾아봐도 좋다.
