딜레마 : 프래그먼트 vs 액티비티 사용시기 :

나는 알고 Activities있지만, 내 응용 프로그램의 하나의 화면을 표현하기 위해 설계된 Fragments이들의 논리 내장 된 내부와 재사용 가능한 UI 레이아웃으로 설계되었습니다.

얼마 전까지 만해도 개발해야한다고하는 응용 프로그램을 개발했습니다. 나는를 만들어 Activity내 응용 프로그램 및 위해 사용되는 조각의 화면 표현하기 위해 ViewPager또는 Google Maps. ListFragment여러 번 재사용 할 수있는 UI를 거의 만들지 않았습니다 .

최근에 나는 단지 2가 포함 된 프로젝트에 발견 Activities하나는이다 SettingsActivity다른 하나는입니다 MainActivity. 의 레이아웃은 MainActivity많은 숨겨진 전체 화면 UI 조각으로 채워지며 하나만 표시됩니다. 에서 Activity논리 많습니다 FragmentTransitions응용 프로그램의 다른 화면 사이.

이 접근법에 대해 내가 좋아 한 것은 응용 프로그램이을 사용하기 때문에 ActionBar그대로 유지하고 화면 전환 애니메이션과 함께 움직이지 않는다는 것입니다. 이는 Activity전환으로 발생합니다 . 이것은 화면 전환에보다 유창한 느낌을줍니다.

그래서 내가 요구하는 것은이 주제와 관련하여 현재 개발 방식을 공유하는 것입니다. 처음에는 의견 기반 질문처럼 보일 수 있지만 Android 디자인 및 아키텍처 질문으로 생각합니다 ... 실제로는 그렇지 않습니다. 의견 기반의 하나.

UPDATE (2014년 1월 5일) 에 의해이 프리젠 테이션에 이어 에릭 버크 에서 광장 (. 내가 말을 안드로이드 개발자를위한 유용한 도구의 많은 훌륭한 프리젠 테이션입니다 그리고이 광장에 어떤 식 으로든 관련이없는 오전)

http://www.infoq.com/presentations/Android-Design/

지난 몇 달 동안의 개인적인 경험을 바탕으로 응용 프로그램을 구성하는 가장 좋은 방법 은 응용 프로그램 의 흐름 을 나타내는 조각 그룹을 만들어 모든 조각을 하나로 표시하는 것 Activity입니다. 따라서 기본적으로 Activities응용 프로그램에서 흐름 수 와 동일한 수를 갖습니다 . 이렇게하면 작업 표시 줄이 모든 흐름 화면에 그대로 유지되지만 흐름을 변경하면 많은 의미가있는 재생성됩니다. 에릭 버크 (Eric Burke)가 말했듯이, 내가 아는 것처럼, Activities가능한 한 적은 수 를 사용하는 철학은 그가 "하나님"활동이라고 부르는 것을 혼란스럽게하기 때문에 모든 상황에 적용 할 수있는 것은 아닙니다.

전문가가 "UI를 볼 때 " Activity또는 Fragment"의 사용 여부를 알 수 있습니다 . 처음에는 이것이 의미가 없지만 시간이 지나면 실제로 필요한지 여부를 알 수 있습니다 Fragment.

저에게 매우 도움이되는 좋은 방법이 있습니다. 딸에게 무언가를 설명하려고 할 때 나에게 일어났다.

즉, 화면을 나타내는 상자를 상상해보십시오. 이 상자에 다른 화면을로드 할 수 있습니까? 새 상자를 사용하는 경우 첫 번째 상자에서 여러 항목을 복사해야합니까? 대답이 예인 경우, Fragments루트 Activity는 모든 복제 된 요소를 보유하여 작성 시간을 절약 할 수 있고 상자의 일부를 간단히 바꿀 수 있기 때문에 를 사용해야합니다 .

그러나 항상 상자 컨테이너 ( ) 가 필요 하거나 부품이 분산되어 있음을 잊지 마십시오Activity . 내부에 하나의 상자가 있습니다.

상자를 오용하지 않도록주의하십시오. Android UX 전문가는 명시 적으로 다른을로드 해야하는 경우 (YouTube에서 찾을 수 있음) Activity대신 Fragment(카테고리가있는 탐색 서랍을 처리 할 때와 같이) 사용하는 것이 좋습니다 . 에 익숙해지면 Fragments모든 동영상을 볼 수 있습니다. 훨씬 더 그들은 필수 자료입니다.

당신은 지금 당신의 UI를보고 당신이 Activity또는 여부를 알아낼 수 Fragment있습니까? 새로운 관점을 얻었습니까? 당신이 한 것 같아요

내 철학은 이것이다 :

절대적으로 필요한 경우에만 활동을 작성하십시오. 백 스택을 사용하여 조각 트랜잭션을 커밋 할 수있게되었으므로 앱에서 가능한 한 적은 활동을 만들려고합니다. 또한 여러 조각간에 통신하는 것이 활동간에 데이터를주고받는 것보다 훨씬 쉽습니다.

활동 전환이 비싸지 않습니까? 적어도 나는 그렇게 생각합니다-오래된 활동은 파괴 / 일시 중지 / 중지되고 스택에 푸시 된 다음 새로운 활동이 생성 / 시작 / 재개되어야하기 때문에.

프래그먼트가 소개 된 이래 그것은 단지 내 철학입니다.

글쎄요, 구글의 강의에 따르면 ( 여기서는 기억이 나지 않을 것입니다), 코드를보다 쉽게 ​​관리하고 제어 할 수 있도록 가능할 때마다 프래그먼트 사용을 고려해야합니다.

그러나 조각을 호스팅하는 활동이 조각을 탐색 / 통신해야하기 때문에 경우에 따라 너무 복잡해질 수 있다고 생각합니다.

본인에게 가장 적합한 것을 스스로 결정해야한다고 생각합니다. 일반적으로 활동을 조각으로 변환하거나 그 반대로 변환하는 것은 어렵지 않습니다.

나는이 dillema에 대한 게시물을 만든 여기 당신은 몇 가지 더 읽기하고자하는 경우.

모든 사례에서 활동보다 조각을 선호하는 이유는 무엇입니까?

• 활동은 비싸다. 프래그먼트에서는 뷰와 속성 상태가 분리되어 프래그먼트가에있을 때마다 backstack해당 뷰가 삭제됩니다. 따라서 액티비티보다 훨씬 많은 조각을 쌓을 수 있습니다.

• Backstack시장 조작. 을 사용하면 FragmentManager모든 조각을 쉽게 지우고 조각 등보다 더 많이 삽입 할 수 있습니다. 그러나 활동의 경우, 그러한 것들을 조작하는 것은 악몽 일 것입니다.

• 훨씬 예측 가능한 수명주기 . 호스트 활동이 재활용되지 않는 한. 백 스택의 조각은 재활용되지 않습니다. 따라서 FragmentManager::getFragments()특정 조각을 찾는 데 사용할 수 있습니다 (권장되지 않음).

이후 제트 팩 , 단일 활동 응용 프로그램은 선호하는 구조입니다. Navigation Architecture 구성 요소 와 함께 특히 유용합니다 .

출처

내 의견으로는 그것은 실제로 관련이 없습니다. 고려해야 할 핵심 요소는

1. UI의 일부 (예 : 메뉴)를 얼마나 자주 재사용합니까?
2. 태블릿 용 앱입니까?

프래그먼트의 주요 용도는 멀티 패널 활동을 빌드하는 것이므로 태블릿 / 전화 반응 형 앱에 적합합니다.

액티비티는 인 텐트를 통해 공유하고 시작할 수있는 애플리케이션의 블록 / 컴포넌트임을 잊지 마십시오! 따라서 응용 프로그램의 각 활동은 한 가지 종류의 작업 만 해결해야합니다. 응용 프로그램에 하나의 작업 만 있으면 필요한 경우 하나의 활동과 많은 조각 만 필요하다고 생각합니다. 물론 다른 작업을 해결하는 향후 활동에서 조각을 재사용 할 수 있습니다. 이 접근 방식은 작업을 명확하고 논리적으로 분리합니다. 또한 여러 조각 집합에 대해 다른 의도 필터 매개 변수를 사용하여 하나의 활동을 유지할 필요가 없습니다. 요구 사항에 따라 개발 프로세스의 디자인 단계에서 작업을 정의합니다.

당신이 알고있는 것보다 더 많은 것이 있습니다. 시작된 활동이 암묵적으로 호출 활동을 파괴하지 않는 것보다 기억해야합니다. 물론, 사용자가 버튼을 클릭하여 페이지로 이동하여 해당 페이지의 활동을 시작하고 현재 활동을 파기하도록 설정할 수 있습니다. 이로 인해 많은 오버 헤드가 발생합니다. 내가 줄 수있는 가장 좋은 가이드는 다음과 같습니다.

** 주 활동과이 활동을 동시에 열어야하는 경우에만 새 활동을 시작하십시오 (여러 창을 생각하십시오).

여러 활동을하는 것이 좋은 경우의 좋은 예는 Google 드라이브입니다. 주요 활동은 파일 탐색기를 제공합니다. 파일을 열면 해당 파일을보기 위해 새로운 활동이 시작됩니다. 최근 앱 단추를 누르면 열린 문서를 닫지 않고 브라우저로 돌아간 다음 첫 번째 문서와 동시에 다른 문서를 열 수도 있습니다.

내가 한 일 : 가능하면 조각을 적게 사용하십시오. 불행히도 거의 모든 경우에 가능합니다. 그래서 나는 많은 조각과 약간의 활동으로 끝납니다. 내가 깨달은 몇 가지 단점 :

• ActionBar& Menu : 2 개의 프래그먼트가 다른 타이틀, 메뉴를 가지면
  다루기가 어렵습니다. 예 : 새 조각을 추가 할 때 작업 표시 줄 제목을 변경할 수 있지만 팝업 backstack에서 이전 제목을 복원 할 방법이 없습니다. 이 경우 모든 조각에 툴바가 필요할 수 있지만 더 많은 시간을 소비하게 될 것입니다.
• 우리가 필요로 할 때 startForResult활동은 있지만 단편은 없습니다.
• 기본적으로 전환 애니메이션이 없습니다

이것에 대한 나의 해결책은 Activity를 사용하여 조각 을 감싸는 것입니다. 그래서 우리는 별도의 액션 바, 메뉴 startActivityForResult, 애니메이션을 가지고 있습니다 ...

fragment오버 액티비티 의 가장 큰 장점 중 하나 는 프래그먼트에 사용되는 코드가 다른 액티비티에 사용될 수 있으므로 응용 프로그램 개발에서 코드의 재사용 성을 제공한다는 것 입니다.

에 대한 기본을 제공하는 응용 프로그램 당 하나 개의 활동 사용 fragment 용도 fragment, 스크린이 fragments있는 라이트 중량 에 비해 activites 단편이다 재사용 단편되어 더욱 적합 전화 및 태블릿 모두 지원 앱

당신은 그 중 하나를 자유롭게 사용할 수 있습니다.
기본적으로 앱에 가장 적합한 것을 평가해야합니다. 비즈니스 흐름을 관리하는 방법과 데이터 기본 설정을 저장 / 관리하는 방법에 대해 생각하십시오.

프래그먼트가 가비지 데이터를 저장하는 방법에 대해 생각하십시오. 프래그먼트를 구현할 때 프래그먼트로 채울 활동 루트가 있습니다. 따라서 조각이 너무 많은 많은 활동을 구현하려는 경우 두 개의 컨텍스트 수명주기를 조작 (거친 말)하는 앱의 성능을 고려해야합니다. 복잡성을 기억하십시오.

기억하십시오 : 조각을 사용해야합니까? 왜 안돼?

문안 인사.

더 나은 사용자 경험을 위해 조각을 사용합니다. 예를 들어 버튼이 있고 클릭 할 때 웹 서비스를 실행한다고 가정하면 조각을 부모 활동에 첨부합니다.

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

이런 식으로 사용자는 다른 활동으로 이동할 필요가 없습니다.

둘째, 회전 중에 쉽게 처리 할 수 ​​있으므로 조각을 선호합니다.

실제로 만들고 싶은 것에 달려 있습니다. 예를 들어, navigation drawer조각을 사용합니다. 탭도 사용 fragments합니다. 또 다른 좋은 구현은 listview. 전화를 돌리고 행을 클릭하면 화면의 나머지 절반에 활동이 표시됩니다. 개인적으로, 나는 사용 fragments하고 fragment dialogs더 전문으로. 또한 회전이 더 쉬워졌습니다.