왓챠 앱의 메인화면과 상세화면이 뭘로 구성되어 있을지 궁금합니다..

Question

안녕하세요!

왓챠 앱에서 메인화면과 상세화면이 어떤 구조로 되어있는지 궁금합니다.ㅠㅠ

메인화면 상세화면 둘다 프래그먼트로 구성되어 있는건지

아니면 메인화면(액티비티) - 상세화면(액티비티) 이렇게 구성이 되어 있는건지 궁금합니다..

스크린샷 첨부합니다.

순서대로 메인에서 ->상세화면 -> 빽키눌러서 다시 메인화면

이렇게 돌아오는 순서입니다.

만약 프래그먼트 replace로 구현했다면 상세로 갔다가 되돌아왓을때 전체 뷰가 다시 그려져야될것 같은데

그렇지 않고 뷰가 그대로 유지되는데 어떤 구조로 구성이 되어 있을까요?

 

Comments

아마 여러가지 경우를 고려한 앱이라면, 액티비티이든 프레그먼트이든 상관없이 process detah에 대응하기 위해 캐쉬를 쓰거나 상태를 복구할 수 있는 구조를 가지고 있을 겁니다. 화면만 가지고는 이게 액티비티이다 프레그먼트이다를 말씀드리기는 그렇구요, 프레그먼트가 액티비티보다 경량인 것은 맞습니다. 싱글액티비티 구조가 다른 구조보다 퍼포먼스가 기본적으로 우수합니다. 하지만 상태의 보관과 복구는 process death에 대처하기 위해 결국은 같은 메카니즘을 사용해야 합니다.

---

답글 감사드립니다.
만약 Fragment를 사용했다고 가정한다면 replace하는 방식으로는 위와 같은 구조를 만들 수 없겠죠..? add로 Fragment를 붙이는 구조로 해야지 메인 화면 뷰가 다시 안그려져서 add밖에 방법이 없겠죠? replace로 프래그먼트를 교체하면 detach가 되서 addbackstack을 했어도 되돌아갔을때 뷰가 다시 그려지더라구요..

---

백스택 관리에 자신이 있다면 show/hide를 할 수도 있겠죠.

Answer 1

횡스크롤뷰를 리사이클러 뷰로 처리 했기 때문에
다시 서버에서 조회해도 큰 차이가 없으면 변화가 없는 것처럼 보이는 것 같네요.

Fragment --> 리사이클러뷰 어댑터 --> Activity 호출입니다.

제가 만든 거랑 비슷해서 제것도 변화가 없는 것 같아서
브레이크포인트 잡아서 보니 다시 통신 하네요.

Comments

다시 통신할 필요가 없지 않나여? 다시 통신하면 취향리스트가 변했을텐데 아무런 변화 없는거보니 의미 없는 통신 다시 안하는거 같운뎅

---

통신을 하는 모듈을 호출할지 안할지는 판단을 하면 됩니다.

그러나
Fragment에서 하위 Activity로 계속 왔다갔다 하면
계속 통신을 안하기는 좀 그렇죠?

유투브의 케이스를 생각해 보면 컨텐츠 하나 보면 목록이 변해있습니다.

대안적으로
어떤 시간 기준을 두고, 마지막 조회 시간을 저장하고 있다가,
특정 시간이 지나면 호출하거나 하면 되죠.

앱에 따라 상황에 따라 다를 겁니다.
그것에 맞추어 비지니스로직을 설계하면 됩니다.

---

조언 정말 감사드립니다^^
음.. 제가 고민하는건 A->B로 갔다가 다시 A로 왔을때 해당 뷰가 새로 그려지지않고 그대로 유지가 되었으면 하는건데.. 메인화면과 상세화면 둘다 Fragment라고 가정할때 replace 방식으로 Fragment를 교체하는 방법으로는 위의 왓챠처럼 메인화면의 뷰가 그대로 유지되게 할수는 없겟죠?

---

생각보다 시간이 좀 걸렸지만, 라이프싸이클 공부도 할 겸 해보았습니다.
아래와 같이 Replace를 하고  프레그먼트를 실행했을 때는 백키를 눌러도
원래 호출한 프레그먼트는 onResume()도 수행이 되지 않습니다.

FragmentTransaction tr = getActivity().getSupportFragmentManager().beginTransaction();
                tr.addToBackStack(null);
                tr.replace(R.id.navHostFragment, new EventFragment());
                tr.commit();

서랍메뉴에서 호출해서 백키를 누르면
onResume()은 수행되지만,
onCreate() 는 수행되지 않기 때문에,
onResume()에서 서버 조회를 하지 않게 만들면 됩니다.

리플레이스 말고 Add를 하는 경우도 있는데, 이 것은 아마도 같은 프레그먼트가 여러개 동시에 수행되게 만드는 경우인 것 같네요.
아래 커맨드도 백키를 수행해서 돌아오면 이전 프레그먼트에서 모릅니다.

FragmentTransaction tr = getActivity().getSupportFragmentManager().beginTransaction();
                tr.addToBackStack(null);
                tr.add(R.id.navHostFragment, new RecommendFragment());
                tr.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OPEN);
                tr.commit();

알 수 있는 override 함수가 있을 것 같기도 한데요.
일단은 Fragment를 가진
부모 Activity의 onBackPressed에서 백키를 잡긴 합니다만,

fragment 정보를 가지고 오는 것은 스택에 두개이상 쌓였을 때만 보이는 듯..
즉,  A 프레그먼트에서 B 프레그먼트를 수행하고 백키를 눌렀을 때는
getSupportFragmentManager().getBackStackEntryCount()  는 0이라서 관리 안하는 것 같고요.
여러 프레그먼트가 메뉴에 의해서 수행되고 있는 경우에만 보이는 것 같네요.

일단, 시간이 부족한 관계로 더 Follow Up은 못하겠지만,
결론은 상기 코드로 수행하면,
원래 Fragment로 돌아왔을 때, 아무 것도 수행되지 않는다.
입니다.

다만, 서랍메뉴에서 수행될 때는 Backkey를 눌렀을 때 onResume()이 수행됩니다.

Good luck 2 U~!