Một hoạt động và tất cả các mảnh khác [đã đóng]

Tôi đang nghĩ đến việc thực hiện một màn hình với Activityvà tất cả các màn hình khác với Fragmentsvà managing all the fragments thru the activity.

Nó là một ý tưởng tốt? và câu trả lời của tôi là KHÔNG nhưng tôi vẫn muốn biết rõ hơn về suy nghĩ này.

Những ưu và nhược điểm của ý tưởng là gì?

Ghi chú:

Xin đừng cho tôi liên kết cho mảnh và hoạt động.

BIÊN TẬP:

Đây là một cái gì đó trên Mảnh vỡ và hoạt động:

Ưu điểm:

1. Các mảnh có nghĩa là được sử dụng với các hoạt động như một hoạt động phụ.
2. Những mảnh vỡ không phải là sự thay thế cho các hoạt động.
3. Các mảnh vỡ có nghĩa là để tái sử dụng (Cần biết theo cách nào có thể đạt được khả năng tái sử dụng.).
4. Các mảnh vỡ là cách tốt nhất để viết mã để hỗ trợ cả máy tính bảng và điện thoại.

Nhược điểm:

1. Chúng ta cần thực hiện giao diện để lấy dữ liệu từ các đoạn.
2. Đối với hộp thoại, chúng ta phải đi một chặng đường dài để hiển thị nó.

Tại sao chúng ta nên sử dụng các mảnh vỡ nếu chúng ta không xem xét máy tính bảng? Sự khác biệt thời gian bắt đầu giữa hoạt động và mảnh là gì?

Nó phụ thuộc vào ứng dụng bạn đang tạo. Tôi đã tạo một số ứng dụng bằng cả hai cách tiếp cận và không thể nói một cách luôn tốt hơn cách khác. Ứng dụng mới nhất tôi tạo ra tôi đã sử dụng Activitycách tiếp cận duy nhất và điều hướng theo phong cách Facebook. Khi chọn các mục từ danh sách điều hướng, tôi cập nhật một vùng Fragmentchứa để hiển thị phần đó.

Điều đó nói rằng, có một đơn Activitycũng giới thiệu rất nhiều phức tạp. Giả sử bạn có một biểu mẫu chỉnh sửa và đối với một số mục người dùng cần chọn hoặc tạo, yêu cầu họ chuyển sang màn hình mới. Với các hoạt động, chúng tôi chỉ gọi màn hình mới startActivityForResultnhưng Fragmentskhông có điều đó nên cuối cùng bạn lưu trữ giá trị trên Activityvà có đoạn chỉnh sửa chính kiểm tra Activityxem liệu dữ liệu đã được chọn và có được hiển thị cho người dùng không.

Những gì Aravind nói về việc bị mắc kẹt trong một Activityloại duy nhất cũng đúng nhưng không thực sự hạn chế. Hoạt động của bạn sẽ là một FragmentActivity và miễn là bạn không cần MapViewthì không có giới hạn thực sự. Nếu bạn muốn hiển thị bản đồ, điều đó có thể được thực hiện, nhưng bạn sẽ cần phải sửa đổi Thư viện tương thích Android để FragmentActivitymở rộng MapActivityhoặc sử dụng các hỗ trợ android-v4-googlemaps có sẵn công khai .

Cuối cùng, hầu hết các nhà phát triển mà tôi biết đã đi theo một Activitylộ trình đã quay lại nhiều Hoạt động để đơn giản hóa mã của họ. UI khôn ngoan, trên một chiếc máy tính bảng, đôi khi bạn bị mắc kẹt khi sử dụng một chiếc duy nhất Activityđể đạt được những gì tương tác điên rồ mà các nhà thiết kế của bạn nghĩ ra :)

-- BIÊN TẬP --

Google cuối cùng đã phát hành MapFragmentvào thư viện tương thích để bạn không còn phải sử dụng hack android-support-v4-googlemaps. Đọc về bản cập nhật tại đây: Google Maps Android API v2

- CHỈNH SỬA 2 -

Tôi vừa đọc bài đăng tuyệt vời này về tình trạng của những mảnh vỡ hiện đại (2017) và ghi nhớ câu trả lời cũ này. Tôi nghĩ tôi sẽ chia sẻ: Những mảnh vỡ: Giải pháp cho tất cả các vấn đề của Android

Tôi sắp hoàn thành một dự án (5 tháng trong quá trình phát triển), có 1 hoạt động và 17 phân đoạn, toàn màn hình. Đây là dự án dựa trên mảnh thứ hai của tôi (trước đó là 4 tháng).

Ưu

• Hoạt động chính là 700 dòng mã, chỉ cần quản lý độc đáo thứ tự của các đoạn điều hướng.
• Mỗi mảnh được phân tách độc đáo thành lớp riêng của nó và tương đối nhỏ (~ vài trăm dòng ui).
• Quản lý có thể nói, "này, chúng ta sẽ thay đổi thứ tự của những màn hình đó như thế nào" và tôi có thể làm điều đó rất dễ dàng, vì những mảnh vỡ đó không phụ thuộc vào nhau, tất cả đều giao tiếp thông qua hoạt động. Tôi không phải đào bới các hoạt động cá nhân, để tìm nơi họ gọi nhau.
• Ứng dụng của tôi rất nặng về đồ họa và sẽ không bao giờ hoạt động như 1 hoạt động 1 màn hình. Tất cả các hoạt động phụ đó trong bộ nhớ, sẽ khiến ứng dụng hết bộ nhớ mọi lúc, vì vậy tôi sẽ phải thực hiện finish()tất cả các hoạt động không nhìn thấy được và tạo logic điều khiển giống nhau để điều hướng, như tôi đã làm với các đoạn. Cũng có thể làm điều đó với những mảnh vỡ chỉ vì điều này.
• nếu chúng ta từng làm một ứng dụng máy tính bảng, chúng ta sẽ có một công cụ bao thanh toán lại thời gian dễ dàng hơn, bởi vì mọi thứ đã được tách biệt độc đáo.

Nhược điểm

• bạn phải học, làm thế nào để sử dụng các mảnh

Trước tiên, bất cứ điều gì bạn làm, hãy đảm bảo bạn có một thiết kế mô-đun bằng cách sử dụng mô hình, chế độ xem, người trình bày không phụ thuộc nhiều vào Hoạt động hoặc Đoạn.

Hoạt động và mảnh vỡ thực sự cung cấp những gì?

1. Sự kiện vòng đời và backstack
2. Bối cảnh và tài nguyên

Do đó, sử dụng chúng cho điều đó, CHỈ . Họ có đủ trách nhiệm, đừng quá phức tạp. Tôi sẽ lập luận rằng ngay cả việc tích hợp một TextView trong một Activity hoặc Fragment là một thực tiễn tồi. Có một phương thức lý do như công khai View findById (int id) là PUBLIC .

Bây giờ câu hỏi trở nên đơn giản hơn: Tôi có cần nhiều sự kiện độc lập và vòng đời độc lập không? Nếu bạn nghĩ có thể, hãy sử dụng các mảnh vỡ. Nếu bạn nghĩ không bao giờ, đừng sử dụng các mảnh vỡ.

Cuối cùng, bạn có thể thực hiện backstack và vòng đời của riêng bạn. Nhưng, tại sao lại tái tạo bánh xe?

EDIT: Tại sao xuống bỏ phiếu này? Lớp người độc thân! Mỗi hoạt động hoặc đoạn sẽ có thể khởi tạo một người thuyết trình khởi tạo một khung nhìn. Người trình bày và chế độ xem là một mô-đun có thể thay thế cho nhau. Tại sao một hoạt động hoặc đoạn có trách nhiệm của người trình bày ??

Ưu

Bạn có thể kiểm soát các mảnh vỡ của mình từ một hoạt động duy nhất, vì tất cả các mảnh đều độc lập với nhau. Các mảnh vỡ có một vòng đời ( onPause, onCreate, onStart...) của riêng mình. Bằng cách có vòng đời, các mảnh có thể phản ứng độc lập với các sự kiện, lưu trạng thái của chúng onSaveInstanceStatevà được đưa trở lại (ví dụ như khi tiếp tục sau cuộc gọi đến hoặc khi người dùng nhấp vào nút quay lại).

Nhược điểm

1. Tạo sự phức tạp trong mã hoạt động của bạn.
2. Bạn phải quản lý thứ tự của các mảnh.

Không bao giờ là ít hơn, đó là một ý tưởng tốt, vì nếu bạn cần tạo một ứng dụng, nơi bạn muốn hiển thị một số lượt xem. Theo ý tưởng này, bạn sẽ có thể xem một số đoạn trong một chế độ xem ..

Nó phụ thuộc vào bố trí thiết kế của ứng dụng của bạn. Giả sử nếu bạn sử dụng Tab trong ActionBar trong bố cục thiết kế thì trong Hoạt động đơn của ứng dụng, người ta có thể có các đoạn được thay đổi khi nhấp vào Tab. Vì vậy, bây giờ bạn có một Hoạt động và giả sử ba Tab trong ActionBar và chế độ xem cho các tab được cung cấp bởi các Mảnh vỡ, điều này giúp dễ dàng quản lý cộng cũng khả thi. Vì vậy, tất cả phụ thuộc vào sơ đồ thiết kế của ứng dụng của bạn và cách bạn đưa ra quyết định xây dựng cho nó.

Ưu điểm:

• Có thể được sử dụng để tạo một giao diện duy nhất có thể sử dụng được bằng nhiều kích thước và hướng màn hình thông qua bố cục xml.

Nhược điểm:

• Yêu cầu mã phức tạp hơn trong hoạt động của bạn.

Tôi tin rằng đó là một ý tưởng tốt, bởi vì sử dụng các bố cục xml khác nhau dựa trên kích thước và hướng màn hình hiện tại có thể giúp ứng dụng trở nên hữu dụng hơn và giảm nhu cầu phát hành nhiều phiên bản ứng dụng của bạn nếu bạn dự định phát hành ứng dụng cho cả điện thoại và máy tính bảng. Nếu ứng dụng của bạn sẽ không bao giờ được sử dụng bởi cả máy tính bảng và điện thoại, thì có lẽ nó không đáng để gặp rắc rối.

Tôi là người đề xuất trì hoãn tất cả xem lạm phát thành các mảnh để cung cấp sự linh hoạt tốt hơn. Ví dụ: có một hoạt động hạ cánh duy nhất cho một máy tính bảng tổng hợp nhiều phân đoạn và sử dụng lại các phân đoạn giống nhau trên điện thoại để hiển thị một màn hình cho mỗi phân đoạn. Tuy nhiên, trong triển khai điện thoại, tôi có một hoạt động riêng cho từng màn hình. Các hoạt động sẽ không có quá nhiều mã vì họ sẽ ngay lập tức trì hoãn đối tác phân mảnh của mình để xem lạm phát.

Tôi nghĩ rằng việc triển khai điện thoại phải thay đổi thành một hoạt động hạ cánh duy nhất khi các tab hoặc menu trượt được giới thiệu do điều hướng tab hoặc menu chỉ dẫn đến một màn hình hoàn toàn mới.

Lý do quan trọng nhất tôi sẽ đưa ra cho việc không sử dụng phương pháp hoạt động đơn lẻ là để vòng đời hoạt động có thể bị lợi dụng. Các hoạt động chứa hành vi theo ngữ cảnh của một phần nhất định của ứng dụng và các đoạn bổ sung cho hành vi đó. Có khả năng tận dụng các bước có thể vượt quá trong vòng đời hoạt động giúp phân tách hành vi của một hoạt động với hoạt động khác với các phương thức như onPausevà onResume. Vòng đời này cũng cho phép bạn quay lại bối cảnh trước đó. Với cách tiếp cận hoạt động đơn lẻ, một khi bạn để lại một đoạn, bạn phải tạo một cơ chế để quay lại nó.