Tại sao nên sử dụng Android Fragment?


15

Tôi đã đọc tài liệu và một số chủ đề của câu hỏi khác về chủ đề này và tôi không thực sự cảm thấy bị thuyết phục; Tôi không thấy rõ giới hạn sử dụng của kỹ thuật này.

Các mảnh vỡ hiện được xem là một thực tiễn tốt nhất ; mọi Hoạt động về cơ bản phải là sự hỗ trợ cho một hoặc nhiều Mảnh vỡ và không gọi trực tiếp bố cục.

Các mảnh được tạo ra để:

  1. cho phép Activitysử dụng nhiều phân đoạn, thay đổi giữa chúng, sử dụng lại các đơn vị này ... ==> Fragmenthoàn toàn phụ thuộc vào Contexthoạt động, vì vậy nếu tôi cần một cái gì đó chung chung mà tôi có thể sử dụng lại và xử lý trong nhiều Hoạt động, tôi có thể tạo bố cục hoặc Chế độ xem tùy chỉnh của riêng tôi ... Tôi sẽ không quan tâm đến Lớp phát triển phức tạp bổ sung này mà các mảnh sẽ thêm vào.

  2. xử lý tốt hơn với độ phân giải khác nhau ==> OK cho máy tính bảng / điện thoại trong trường hợp quá trình dài mà chúng ta có thể hiển thị hai (hoặc nhiều) đoạn trong cùng một Hoạt động trong Máy tính bảng và từng cái một trong điện thoại. Nhưng tại sao tôi luôn sử dụng các mảnh vỡ ?

  3. xử lý các cuộc gọi lại để điều hướng giữa các Đoạn (nghĩa là: nếu người dùng đã Đăng nhập, tôi hiển thị một đoạn khác, tôi hiển thị một đoạn khác). ===> Hãy thử xem có bao nhiêu lỗi đăng nhập SDK SDK vì điều này, để hiểu rằng đó thực sự là (?) ...

  4. xem xét rằng Ứng dụng Android dựa trên Hoạt động ... Thêm một vòng đời khác trong Hoạt động sẽ tốt hơn để thiết kế Ứng dụng ... Ý tôi là các mô-đun, kịch bản, quản lý dữ liệu và kết nối sẽ được thiết kế tốt hơn, theo đó đường. ===> Đây là câu trả lời của ai đó đã từng xem SDK Android và Android Framework với tầm nhìn Fragment. Tôi không nghĩ nó sai, nhưng tôi không chắc nó sẽ cho kết quả tốt ... Và nó thực sự trừu tượng ...

====> Tại sao tôi lại làm phức tạp cuộc sống của mình, mã hóa nhiều hơn, trong việc sử dụng chúng luôn? khác, tại sao nó là một thực tiễn tốt nhất nếu nó chỉ là một công cụ cho một số trường hợp? những trường hợp này là gì?


1
Không rõ những gì bạn đang hỏi, bạn có thể vui lòng tóm tắt câu hỏi, có thể dưới mức liệt kê các lợi thế được cho là và sự chỉ trích của bạn về mỗi?
đăng nhập

Tôi đã thêm một câu hỏi chi tiết.
ahmed_khan_89

Tôi bị mất như @logc. Làm thế nào bạn sẽ xử lý những trường hợp mà không có mảnh vỡ?
neontapir

Tôi đã đưa ra những gì tôi sẽ làm mà không có Fragment: (1) tạo các điều khiển chung tùy chỉnh và sử dụng lại chúng ở nơi tôi muốn (2) bằng cách sử dụng 2 Hoạt động và điều hướng bằng startActivityForResult hoặc đơn giản là thay đổi giữa các chế độ xem (hiển thị / ẩn, thổi phồng / xóa ...) không cần mã hóa quá nhiều ... (3) bạn có thể sử dụng một cuộc gọi lại ngay cả trong Hoạt động có lượt xem (4) Đó là một câu trả lời trừu tượng mà tôi luôn nhận được khi thảo luận về chủ đề này ... cần được giải thích nhiều hơn ...
ahmed_khan_89

1
Hừm. Câu hỏi và trả lời này cho thấy giới hạn của thiết kế của stackexchange trong đó người đăng ban đầu chọn câu trả lời "tốt nhất". (Trái ngược với slant.co, nơi mọi người bỏ phiếu.) Không lý tưởng cho một câu hỏi rộng như thế này. Ở đây, một câu hỏi mơ hồ nhận được một câu trả lời được chấp nhận rõ ràng đồng ý với những gì người hỏi muốn nghe. Nếu bạn thấy không có lý do để sử dụng đoạn trong tình huống của mình, thì đừng. Một câu hỏi tốt hơn sẽ là hỏi về ưu / nhược điểm của phân đoạn so với hoạt động . Và có nhiều chủ đề về chủ đề chính xác đó.
ToolmakerSteve

Câu trả lời:


5

Đoạn là một phần mô-đun của Hoạt động có vòng đời riêng, nhận các sự kiện đầu vào của chính nó, bạn có thể thêm hoặc xóa trong khi hoạt động đang chạy (giống như một "hoạt động phụ" mà bạn có thể sử dụng lại trong các hoạt động khác nhau)

Ngoài lợi thế rõ ràng là sử dụng các đoạn, tối ưu hóa giao diện người dùng trên các màn hình khác nhau, nó cho phép bạn quản lý xử lý nền của hoạt động mà không cần thành phần giao diện người dùng hiển thị.

Hiện nay...

====> Tại sao tôi lại làm phức tạp cuộc sống của mình, mã hóa nhiều hơn ... ??

Mặc dù được khuyến nghị, bạn không cần trừ khi bạn có kế hoạch kiểm soát vòng đời của các yếu tố riêng lẻ và / hoặc sử dụng lại trạng thái ngăn xếp hoặc lịch sử của các chế độ xem trước đó.


5

Nếu có trường hợp sử dụng "cổng" cho những người hoài nghi phân đoạn, thì đó có thể là hộp thoại. Các phương pháp dài bị phản đối showDialog(...), onCreateDialog(...)vv, đã được tốt đẹp trong đó khuôn khổ sẽ gọi cho họ để tự động phá hủy và tái tạo các hộp thoại của bạn khi hoạt động lưu trữ đã bị phá hủy và tái tạo. Nếu bạn tạo các hộp thoại của riêng bạn trực tiếp, bạn phải tự mình quản lý tất cả những thứ đó. Nhưng nếu bạn sử dụng a DialogFragment, bạn có thể một lần nữa để khung quản lý chúng cho bạn. Trong trường hợp này, các đoạn có thể đơn giản hóa rất nhiều mã hóa của bạn.


1

Tôi đã hỏi câu hỏi này hơn một năm trước.

Tôi đang sử dụng các mảnh vỡ hàng ngày và tôi muốn giới thiệu nó.

Trước hết, tôi muốn nói rằng việc sử dụng các đoạn chỉ là một tùy chọn và sẽ là một phản xạ để xem xét nó một khi bạn bắt đầu sử dụng chúng.

Ưu điểm:

1 / nó giúp mô đun hóa mã nơi bạn có thể có một luồng đầy đủ trong một Hoạt động, trong các đoạn riêng biệt. Ví dụ: + danh sách / lưới & chi tiết, + đăng nhập & đăng ký và quên mật khẩu, + v.v ... Thật tuyệt vời khi nhận được mã có thể sử dụng lại, mà bạn luôn có thể sao chép và qua trong các dự án khác nhau.

2 / bạn có một vòng đời mới, đầy rẫy những rắc rối đó là sự thật, nhưng cũng có những lợi thế. Ví dụ: đoạn đối tượng được giữ lại là tuyệt vời vì nó giải quyết vấn đề định hướng.

3 / bạn có thể quản lý dòng phân đoạn của mình bằng các sự kiện và người nghe từ Hoạt động.

4 / một đống các mảnh vỡ của bạn trong Hoạt động của bạn.

5 / sử dụng cùng một thanh Action trong nhiều màn hình.

Và nhiều người khác ...

Thỉnh thoảng tôi vẫn sử dụng Activity như một thùng chứa, đặc biệt là cho vỏ Camera. Một số API Android và một số thư viện bên thứ ba không dễ thực hiện theo từng mảnh.

Chà, nó giống như bất kỳ công cụ nào, bạn phải xem xét nó và tự đánh giá xem liệu sử dụng nó trong trường hợp này hay trường hợp khác tốt hơn.

Tôi hy vọng điều này có thể giúp !!!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.