[android] 하나의 활동과 다른 모든 조각 [닫기]

나는 하나의 화면을 구현 생각하고 Activity그리고 다른 모든 sreens Fragmentsmanaging all the fragments thru the activity.

좋은 생각입니까? 내 대답은 아니요 이지만 여전히이 생각에 대해 더 명확하게 알고 싶습니다.

아이디어의 장단점은 무엇입니까?

노트 :

조각과 활동에 대한 링크를 제공하지 마십시오.

편집하다:

다음은 조각과 활동에 관한 것입니다.

장점 :

  1. 단편은 활동과 함께 하위 활동으로 사용됩니다.
  2. 조각은 활동을 대체하지 않습니다.
  3. 프래그먼트는 재사용 성을 의미합니다 (재사용 성을 달성 할 수있는 방법을 알아야합니다).
  4. 조각은 태블릿과 휴대폰을 모두 지원하는 코드를 작성하는 가장 좋은 방법입니다.

단점 :

  1. 조각에서 데이터를 가져 오려면 인터페이스를 구현해야합니다.
  2. 대화를 위해 우리는 그것을 보여주기 위해 먼 길을 가야합니다.

태블릿을 고려하지 않는 경우 왜 조각을 사용해야합니까? 활동과 조각의 시작 시간 차이는 무엇입니까?



답변

생성하는 앱에 따라 다릅니다. 두 가지 방법을 모두 사용하여 여러 앱을 만들었으며 한 가지 방법이 항상 다른 방법보다 낫다고 말할 수는 없습니다. 내가 만든 최신 앱은 단일 Activity접근 방식과 Facebook 스타일 탐색을 사용했습니다. 탐색 목록에서 항목을 선택할 때 단일 Fragment컨테이너를 업데이트하여 해당 섹션을 표시합니다.

즉, 싱글을 갖는 Activity것도 많은 복잡성을 초래합니다. 편집 양식이 있고 사용자가 선택하거나 작성해야하는 일부 항목의 경우 새 화면으로 이동해야한다고 가정 해 봅시다. 액티비티를 사용하면 새 화면을 호출 startActivityForResult하지만 Fragments그러한 것은 없으므로 값을 저장 Activity하고 주 편집 조각을 사용하여 Activity데이터가 선택되어 사용자에게 표시되는지 확인 하십시오.

Aravind가 단일 Activity유형 에 집착하는 것에 대해 말한 것은 사실이지만 실제로 그러한 제한은 아닙니다. 귀하의 활동은 FragmentActivity가 될 것이며 필요하지 않은 MapView한 실제 제한은 없습니다. 그래도 맵을 표시하려면 맵을 표시 할 수 있지만 공개적으로 사용 가능한 android-support-v4-googlemaps를FragmentActivity 확장 MapActivity하거나 사용 하도록 Android 호환성 라이브러리를 수정해야 합니다 .

궁극적으로 한 Activity경로로 갔다는 대부분의 개발자 는 코드를 단순화하기 위해 여러 활동으로 돌아갔습니다. UI를 현명하게 사용하면 태블릿에서 Activity디자이너가 생각해 낸 미친 상호 작용을 달성하기 위해 단일을 사용하는 경우 가 있습니다. 🙂

— 편집하다 —

Google은 마침내 MapFragment호환성 라이브러리에 출시 되었으므로 더 이상 android-support-v4-googlemaps 핵을 사용할 필요가 없습니다. 여기에서 업데이트에 대해 읽으십시오 : Google Maps Android API v2

-편집 2-

나는 현대 (2017) 조각에 대한이 위대한 게시물을 읽었 으며이 오래된 대답을 기억했습니다. 내가 공유 할 것이라고 생각했습니다 : 조각 : 모든 안드로이드 문제에 대한 해결책


답변

1 개의 활동과 17 개의 조각으로 구성된 전체 프로젝트를 가진 프로젝트 (개발 5 개월)를 마치려고합니다. 이것은 두 번째 조각 기반 프로젝트입니다 (이전 4 개월).

찬성

  • 주요 활동은 700 줄의 코드이며 조각 탐색 순서를 잘 관리합니다.
  • 각 조각은 자체 클래스로 멋지게 분리되어 있으며 상대적으로 작습니다 (~ 백 줄의 UI 항목 결합).
  • 경영진은 “이봐, 화면 순서를 바꾸는 방법”이라고 말할 수 있고, 그 조각들이 서로 의존하지 않기 때문에 그들은 모두 활동을 통해 의사 소통하기 때문에 아주 쉽게 할 수있다. 나는 그들이 서로 전화하는 곳을 찾기 위해 개별 활동을 파헤칠 필요가 없습니다.
  • 내 응용 프로그램은 그래픽이 매우 무거 우므로 1 화면 1 활동으로 작동하지 않습니다. 메모리의 모든 하위 활동은 앱에 항상 메모리가 부족하므로 finish()모든 보이지 않는 활동이 필요하며 조각과 마찬가지로 탐색을 위해 동일한 제어 논리를 만들어야합니다. 이 때문에 조각으로도 할 수 있습니다.
  • 태블릿 앱을 사용하는 경우 모든 것이 이미 잘 분리되어 있기 때문에 더 쉽게 리팩토링 할 수 있습니다.

단점

  • 조각을 사용하는 방법을 배워야합니다

답변

먼저, 무엇을 하든지 활동이나 조각에 크게 의존하지 않는 모델, 뷰, 발표자를 사용하여 모듈 식 디자인을 갖추어야합니다.

활동과 조각은 실제로 무엇을 제공합니까?

  1. 수명주기 이벤트 및 백 스택
  2. 상황과 자원

따라서이를 위해서만 사용하십시오 . 그들은 충분한 책임이 있으며, 너무 복잡하지 않습니다. Activity 또는 Fragment에서 TextView를 강화하는 것조차 나쁜 습관이라고 주장합니다. public View findViewById (int id) 와 같은 메소드 가 PUBLIC 인 이유가 있습니다 .

이제 질문이 더 간단 해집니다. 여러 개의 독립적 수명주기 이벤트와 백 스택이 필요합니까? 예라고 생각되면 조각을 사용하십시오. 결코 생각하지 않는다면 조각을 사용하지 마십시오.

결국, 당신은 자신의 백 스택과 수명주기를 만들 수 있습니다. 그러나 왜 바퀴를 다시 만드는가?

편집 : 왜 다운 투표? 단일 목적 클래스 사람들! 각 활동 또는 프래그먼트는 뷰를 인스턴스화하는 발표자를 인스턴스화 할 수 있어야합니다. 발표자와 뷰는 서로 교환 할 수있는 모듈입니다. 활동이나 단편이 발표자의 책임을 갖는 이유는 무엇입니까 ??


답변

찬성

모든 조각이 서로 독립적이기 때문에 단일 활동에서 조각을 제어 할 수 있습니다. 파편은 라이프 사이클 (이 onPause, onCreate, onStart자신의 …을). 수명주기를 가짐으로써 프래그먼트는 이벤트에 독립적으로 응답하고을 통해 상태를 저장 한 다음 onSaveInstanceState되돌릴 수 있습니다 (예 : 수신 통화 후 다시 시작하거나 사용자가 뒤로 단추를 클릭 할 때).

단점

  1. 활동 코드를 복잡하게 만듭니다.
  2. 조각의 순서를 관리해야합니다.

결코 적은 것은 아니지만 여러 뷰를 표시하려는 앱을 만들어야하는 것처럼 아주 좋습니다. 이 아이디어를 통해 여러 조각을 단일보기로 볼 수 있습니다.


답변

앱의 디자인 레이아웃에 따라 다릅니다. 디자인 레이아웃의 ActionBar에서 탭을 사용하고 앱의 단일 활동에서 탭을 클릭하면 조각이 변경 될 수 있다고 가정하십시오. 이제 활동이 있고 ActionBar에 세 개의 탭과 Fragments가 제공하는 탭에 대한 뷰가 있다고 가정하면 관리하기 쉽고 플러스도 가능합니다. 따라서 모든 것은 앱의 디자인 체계와 앱 구축 결정에 따라 다릅니다.


답변

장점 :

  • xml 레이아웃을 통해 여러 화면 크기와 방향으로 사용할 수있는 단일 인터페이스를 만드는 데 사용할 수 있습니다.

단점 :

  • 활동에 더 복잡한 코드가 필요합니다.

현재 화면 크기와 방향에 따라 다른 XML 레이아웃을 사용하면 앱을 더 유용하게 사용할 수 있으며 휴대 전화와 태블릿 모두에 앱을 출시하려는 경우 여러 버전의 앱을 출시 할 필요성을 줄일 수 있기 때문에 좋은 생각이라고 생각합니다. 태블릿과 휴대 전화에서 모두 앱을 사용하지 않는다면 문제가되지 않을 것입니다.


답변

더 나은 유연성을 제공하기 위해 모든 뷰 인플레이션을 단편으로 연기하는 것을지지합니다. 예를 들어 태블릿에 단일 랜딩 활동이있어 여러 조각을 집계하고 전화기에서 동일한 조각을 재사용하여 조각 당 하나의 화면을 표시합니다. 그러나 전화 구현에서는 각 화면마다 별도의 활동이 있습니다. 액티비티는 뷰 인플레이션을 위해 프래그먼트 대응을 즉시 연기하므로 코드가 너무 많지 않습니다.

탭 또는 메뉴 탐색으로 인해 완전히 새로운 화면이 만들어 지므로 탭 또는 슬라이드 아웃 메뉴가 도입되면 전화 구현이 단일 랜딩 활동으로 변경해야한다는 것은 나쁜 생각이라고 생각합니다.