조각을 사용하는 이유는 무엇입니까?

조각을 사용하는 이유는 무엇입니까?

---

이 질문에 이미 답변이 있습니다.

• 뷰가 아닌 Android에서 프래그먼트를 사용하면 어떤 이점이 있습니까? 6 답변

다른 레이아웃에서 재사용되는 Fragment사용자 지정 을 사용하는 것보다 s 를 사용하는 이점은 무엇입니까 View?

단편을 소개 하는 원래 블로그 게시물 에서 Dianne Hackborn은 다음과 같이 말합니다.

[Fragments]는 개발자가 플랫폼에서 이미 사용 가능한 기능을 넘어서 다양한 화면 크기로 확장 할 수있는 애플리케이션을 더 쉽게 작성할 수 있도록합니다.

그녀는 동일한 앱의 휴대폰 버전에서 가져온 두 가지 활동의 UI를 결합하는 앱의 태블릿 레이아웃을 만드는 맥락에서 Fragments를 설명합니다.

그러나 사용자 지정 뷰를 사용하여 동일한 재사용을 달성 할 수있는 것 같습니다. 프래그먼트와 뷰의 주요 차이점은 수명주기가 다르다는 것입니다.

Fragment라이프 사이클은 다음과 같습니다

onAttach(), onCreate(), onCreateView(), onActivityCreated(), onStart(), onResume(), onPause(), onStop(), onDestroyView(), onDestroy(), onDetatch().

View라이프 사이클은 다음과 같습니다

ctor, onFinishInflate(), onAttachedToWindow(), onMeasure(), onLayout(),onDetatchedFromWindow()

대형 앱을 작성한 경험이있는 개발자로부터 Fragments와 Custom View를 사용하여 UI를 재사용 가능한 조각으로 나눌 때 어떤 이점 (있는 경우)을 본 적이 있는지 듣고 싶습니다.

---

주된 이유는 프래그먼트가 사용자 정의보기보다 재사용 가능하기 때문입니다.

때로는 뷰에만 의존하는 완전히 캡슐화 된 UI 구성 요소를 만들 수 없습니다. 이는 뷰에 넣고 싶은 것이 있지만 액티비티 만 처리 할 수 ​​있기 때문에 할 수 없기 때문입니다. 따라서 액티비티와 뷰가 긴밀하게 연결됩니다.

여기에 그러한 예가 있습니다. 여러 가지 중에서도 사진을 캡처하여 작업을 수행하려는 재사용 가능한 UI 구성 요소를 만들고 싶다고 가정 해 보겠습니다. 일반적으로 카메라를 시작하고 캡처 된 이미지와 함께 반환하는 인 텐트를 실행했습니다.

뷰가 활동 결과를 허용하지 않기 때문에 (컨텍스트를 통해 간접적으로 인 텐트를 실행할 수 있기 때문에) 액티비티의 startActivityForResult 호스팅에 의존해야하기 때문에 사용자 정의 UI 구성 요소가이 기능을 완전히 캡슐화 할 수 없습니다 .

이제 다른 활동에서 사용자 정의 UI 구성 요소를 재사용하려면 Activity.startActivityForResult에 대한 코드를 반복합니다.

반면에 조각은이 문제를 깔끔하게 해결합니다.

마찬가지로 프래그먼트는 옵션 메뉴에 항목을 제공 할 수 있습니다. 전통적으로 활동 만 할 수있는 작업입니다. 사용자 정의보기의 상태가 메뉴의 내용을 지시하는 경우에도 이것은 중요 할 수 있습니다.

---

조각은 단순한보기 그 이상입니다. 사실 그것은 전혀보기가 없을 수도 있습니다. AsyncTasks, 다양한 리스너, 파일 및 데이터베이스 액세스 등 모든 종류의 항목을 포함 할 수 있습니다.

작은 활동으로 생각하되, 화면에 여러 개를 표시하고 표시되는 동안 서로 통신하는 것을 포함하여 모두 작업 할 수 있습니다.

예를 들어 한 조각에는 장바구니 목록이 표시되고 다른 조각에는 현재 선택된 카트가 자세히 표시 될 수 있습니다. 그런 다음 예를 들어 상세보기에서 항목의 수량을 변경하면 목록보기에 이에 대한 알림이 표시되고 목록보기에서 총 가격을 업데이트 할 수 있습니다. 예를 들어 더 작은 화면 장치에서 여전히 그 중 하나만 볼 수있게하면서 이와 같은 상호 작용을 완전히 오케스트레이션 할 수 있습니다.

좋은 태블릿 지원을 받기 위해 대규모 비즈니스 앱 (> 15 개 활동)을 활동에서 조각으로 리팩터링했으며 조각 없이는 새 앱을 시작하지 않을 것입니다.

2016 년 2 월 업데이트 : 위의 내용은 여전히 ​​유효하지만 많은 사람들이 사용을 완전히 피하게 만드는 단편의 복잡성이 있습니다. MVC 접근 방식의 사용과 더 강력한보기와 같은 새로운 패턴은 대안을 제공합니다. 그들이 말했듯이 .. YMMV.

---

설명 :

활동을 하나의 큰 케이크를 담는 접시로 상상해보십시오. 조각은 같은 케이크를 조각으로 자르는 용기입니다. 각 슬라이스에는 자체 로직 (리스너 등)이 포함됩니다. 그리고 전체적으로 그들은 하나의 큰 케이크와 거의 다르지 않습니다.

이점 :

1. 접시에 큰 케이크를 담을 수 없을 때. (화면이 작음) 로직을 새 활동으로 이동할 필요없이 몇 개의 플레이트 (Activity)를 사용하여 각 플레이트를 쉽게 유지할 수 있습니다.

2. 더 나은 재사용 성. 다른 앱에서 조각을 완전히 재사용 할 수있는 경우가 있습니다. 커스텀 뷰도 그렇게 할 수 있다고 주장 할 수 있습니다. 그러나 포인트 1을 참조하면 몇 줄의 레이아웃 변경만으로 재사용 할 수 있지만 사용자 지정보기의 경우 레이아웃과 코드 모두에 연결하는 방법을 찾아야합니다.

3. 어떤 의미에서는 Android 프로그래밍에서 UI 로직을 구성하는 더 많은 OO 방법입니다. 기능 (예 : 화면의 새 파티션)이있는 경우 기존 활동 클래스를 약간 수정하여 새 Fragment 클래스를 만듭니다. 그러나 액티비티로만 프로그래밍하는 경우 로직을 추가하고 테스트 된 클래스를 크게 수정해야합니다.

내 2 센트. :)

---

수명주기 방법은 아마도 가장 큰 힌트 일 것입니다. 생각해 보면 활동 라이프 사이클과 밀접하게 관련됩니다 (활동 및보기에 대한 일부 후크 포함). 실제로 링크 한 기사에서 Hackborn은 다음과 같이 말합니다.

어떤면에서는 조각을 미니 활동으로 생각할 수 있습니다.

소프트웨어 설계 / 개발의 많은 일과 마찬가지로 일을 수행하는 방법에는 여러 가지가 있습니다. 코드를 넣을 수있는 장소는 다양합니다. 예, 아마도 뷰에 많은 것을 넣을 수 있지만 다른 클래스에서 다른 관심사를 분리하는 것은 좋은 일입니다. 이것의 고전적인 패턴은 MVC이며이 시나리오에 적용됩니다. 뷰에 너무 많은 컨트롤러 로직을 적용하고 싶지는 않습니다. 활동이고 이제는 조각 인 컨트롤러와 같은 클래스에 유지하는 것이 좋습니다. 이것이 바로 프래그먼트의 라이프 사이클이 뷰보다 활동에 더 가까운 이유입니다. 이러한 종류의 조직을 용이하게하기 위해 만들어졌습니다.

---

Custom views are much more work than just using fragments in place of your activities. if you decide to use Activities and custom Views, you have to create your custom view, and then you have to implement the same activity lifecycle methods in your activity (a very similar lifecycle is used for fragments).

Using Fragments also allows you to separate components into their own classes (Fragments), rather than having too much logic in a single Activity. Let me ground that with an example:

Say you're implementing a magazine reader application. using fragments, you could create a fragment: ArticleList, which displays a list of articles, and another fragment: ArticleDisplay, which handles the logic for displaying content. you can then specify how these fragments should interact using the fragments tools, so that on a handset, you can use the full screen real-estate for ArticleDisplay, while on a tablet, you can display the fragments side by side.

If you were to attempt this with an Activity/custom view, you'd have the logic for both Fragments in your monolithic Activity, you'd have to write a custom view, and you'd have to debug this unwieldy monster.

Fragments are, in general, a more sophisticated and powerful way to write your applications. They can do everything an Activity can do, and more. If you don't need the extra functionality, the defaults will probably get you where you need to go, and with less work.

---

I touched Fragments once and found them not very useful (see this post). From what I have read, A Fragment is really a fancy word for an Object with access to Activity Context. I like to ignore Fragments in my work, and just create these Objects myself. I have created very large, very demanding apps by passing an Activity to constructors, instead of Context. One major benefit, however, for using Fragments is that they are supported by the View layout system - so you can easily add them to Android xml (if you use it for your layouts).

참고URL : https://stackoverflow.com/questions/9827072/why-use-fragments