마스터Q&A 안드로이드는 안드로이드 개발자들의 질문과 답변을 위한 지식 커뮤니티 사이트입니다. 안드로이드펍에서 운영하고 있습니다. [사용법, 운영진]

BottomNavigation 구현 방식?에 관한 질문

0 추천

기존 계획에 없었던 바텀내비게이션을 추가하는게 좋을것같아

안드로이드에서 제공하는 BottomNavigation 템플릿을 사용할지 아니면 직접 만들지 고민하고있습니다.

 

먼저 템플릿 코드부터 봐야겠다는 생각으로 보니 NavigationDrawer랑 거의 차이가 없더군요.

그리고 직접만드는 사람들은 어떻게 만드는지 궁금해서 간편하게 먼저 국내 샘플 코드를 보는데

좀 다르더군요.

 

예를들면 메뉴 구성을 템플릿의 경우 AppBarConfiguration을 이용하거나 또는 이것의 동작?은 

NavController를 사용한다거나 또 xml의경우 navgraph를 사용하거나 등.. 안드로이드에서 만든거라

체계적이라고나할까요 라이브러리?를 사용한다고할까요 그런데

 

사람들이 직접만든다는 코드는 대부분 화면에 관한 프래그먼트를 만들고

코드에서 setOnNavigationItemSelectedListener를 이용해서 프래그먼트를 초기화하고  프래그먼트매니저를 이용해서 프래그먼트를 전환하는 이런 코드만 다 사용하더라구요.

 

AppbarConfiguration이나 NavController등 이런것 전혀없이 딱 저것만이용해서 사용하던데

이 둘의 차이점은 무엇이고 목적같은게 따로있나요?

 

제가 생각하기로는 NavCotroller,NavUI, AppbarConfiguration 처럼 템플릿에서 구현했던것처럼하면 좀 더 체계적이고 프래그먼트매니저를 불러오고 화면전환하는 코드를 제가 굳이 신경쓸 필요가 없기때문에

더 효율적인것같은데.. 어떻게 차이점이 있을까요 

codeslave (2,130 포인트) 님이 3월 29일 질문
codeslave님이 3월 29일 수정

2개의 답변

0 추천
NavController는 JetPack naviation componen라이브러리입니다. 제가 1년 넘게 프로젝트에 사용해고 있는데, 간단한 화면 전환에는 사용하기가 정말 좋은데, 앱이 복잡해질 수록 이 라이브러로 해결리 안되는 경우가 상당히 많고, 기본적으로는 버그가 생각보다 많고, 내부가 엄청나게 복잡한 라이브러리입니다. 제일 신경이 거슬리는 부분은 이 라이브러리를 사용하면  Single Activity 아키텍쳐를 사용해야 하는데, 최근에 구글이 프레그먼트를 이상하게 만져놓아서 라이프사이클이 무지하게 복잡합니다. 원래대로라면 SingleActivity일 때 퍼포먼스가 더 좋을 것으로 기대했는데, 딱히 그것도 아닌것 같고, 다른 화면을 갔다올 때 뷰상태를 복구해주는 처리는 본인이 직접해야 합니다. 이를 편의상 Jetpack의  savedStatedHandle라이브러리를 사용하는 경우가 많은 것 같더라구요.. 참고로 프레그먼트는 다른 프레그먼트로 갔다가 돌아올 때는 onStop/onStart가 호출이 되지 않습니다. 물론 Fragement의 onCreateView부터 다시 호출이 됩니다. 커스텀 컴포넌트를 많이 사용한다면 뷰상태 복구를 직접해주셔야할 확률이 더 높습니다. 물론, process death나 configuraition changes를 처리하려면 당연히 그래야겠지만요.  이유는 NavController경우FragmentManger가 show/hide가 아닌 replace를 사용하기 때문입니다.

이미 많은 안드로이드 전문 교육자들인 Navgation Component의 문제점에 많이 지적하고 있고, 잘 사용하지 않습니다. 대신 FragmentManager를 사용해서 show/hide를 해주는 방식이 퍼포먼스에도 차이가 없고 훨씬 더 다루기가 쉽다는 것이 네이게이션 컴포넌트 아주 오래전 부터 개발해온 안드로이드 라이브러리 개발자의 충고입니다. (Simple Stack)

암튼 NavController를 사용하면서 Sing Activity를 사용하면서 이전보다 개발이 훨~씬 힘들어 진 것을 통감하고 있습니다. 다음에 새로운 프로젝트를 하게 된다면 개인적으로는 절대로 사용하지 않을 것 같습니다.

다만, 프로젝트가 별로 복잡하지 않다면, 크게 상관은 없을 겁니다.
spark (42,080 포인트) 님이 3월 29일 답변
1.Single activity를 사용해야한다고 하셨는데 이 말은 액티비티는 단 하나이고.. 나머지 모든화면은 프래그먼트로 구성한다는 말인것같은데요.
요즘 보니 구성을 싱글 액티비티 많이하던데 별신경 안쓰고 지나텼던부분인데 싱글액티비티를 사용하면 좋은점이 뭔가요? jetpack navigation을 사용하면 이게 강제되는 부분인가요? 액티비티를 둘 이상사용하면 안좋나요?

2.NavController가 프래그먼트매니저가 show/hide가 아니라 replace를 사용한다하셨는데
이미 많은 프래그먼트 화면전환 기초 샘플코드?를보면 모두 replace 사용하던데 이것들은 좀 다른경우인가요 show,hide는 처음 들어봐요..


질문과 별개로 제 수준에서는 프로젝트가 복잡하지는 않기때문에 라이브러리를 사용해도 상관없을것같지만 라이브러리가 별로 좋지않다고 것같다고하시니 습관을 들일겸 리스너로 화면전환하는 방식을 선택해여겠네요

감사합니다
0 추천

1.Single activity를 사용해야한다고 하셨는데 이 말은 액티비티는 단 하나이고.. 나머지 모든화면은 프래그먼트로 구성한다는 말인것같은데요. 맞습니다.
요즘 보니 구성을 싱글 액티비티 많이하던데 별신경 안쓰고 지나텼던부분인데 싱글액티비티를 사용하면 좋은점이 뭔가요? jetpack navigation을 사용하면 이게 강제되는 부분인가요? 액티비티를 둘 이상사용하면 안좋나요?

액티비티는 프레그먼트 무겁습니다. 그로 인해 싱글액티비티를 사용할 때 퍼포먼스의 이득을 기대할 수 있습니다. 그리고 액티비티를 AndroidManifest.xml에 선언하지 않아서 나는 에러를 걱정할 필요가 없겠죠. 또한 백스택 관리에 액티비티보다는 이점이 있습니다.
디바이스 스크린 사이즈에 따라 화면을 서포트 할 때 프레그먼트를 쓰면 좀 더 구조가 잘 잡힐 수 있을 겁니다. 예를 들면, 뉴스 앱의 경우, portrait일 때는 뉴스 목록만 나오게 하고, landscape일 때는 왼쪽에 목록, 오른쪽에 디테일과 같이 구성할 때 프레그먼트를 사용함으로써 좀 더 모듈화된 코드가 가능해 집니다.

Navigation Component는 싱글 액티비티를 염두에 두고 만든 라이브러리입니다. 따라서 기본적으로 액티비티 하나에 나머지는 프레그먼트를 사용하게 됩니다. 물론 액티비티를 여러개 사용할 수도 있죠. 이렇게 하려면 여러 액티비티를 처리할 수 있는 추가적인 코드를 작성하셔야 할 겁니다. 물론 단순히 액티비티를 보여주기만 하는 거라면 프레그먼트를 호출할 때와 같이 하시면 되며, 전혀 문제가 될 게 없어요.

2.NavController가 프래그먼트매니저가 show/hide가 아니라 replace를 사용한다하셨는데
이미 많은 프래그먼트 화면전환 기초 샘플코드?를보면 모두 replace 사용하던데 이것들은 좀 다른경우인가요 show,hide는 처음 들어봐요..
구글 샘플에는 거의 replace를 사용할 겁니다. FragmentManager의  transaction을 보면 show/hide도 존재합니다.  말그대로 생성된 프레그먼트를 보여줬다 감췄다 합니다. replace를 사용해서 뷰를 전부 다시 구성하는 것보다는 show/hide하는 편이 뷰상태 복구같은 걸 신경쓰지 않아도 되기 때문에 머리가 덜 아프죠.

안드로이드의 프래그먼트는 소스코드가 2000라인이 넘는 엄청나게 복잡한 클래스입니다.  이렇게 복잡한 클래스를 주로 사용해야 한다는 것 부터가 처리의 복잡함을 가져올 수 밖에는 없을 겁니다.
 

spark (42,080 포인트) 님이 3월 29일 답변
감사합니다 Navigation Component는 사용하지 않고 바텀 내비를 구성해서 show,hide를 이용하는 방식으로 방향을 정했습니다.
게다가 싱글액티비티로 전환하기로 했습니다.
다만 지금 화면들을 액티비티로 만든 상태라 코드들을 프래그먼트로 맞춰 바꿔서 만들려고합니다. 이건 좀 시간이 걸리겠네요

답변 감사합니다
...