Model-View-Presenter và Thiết kế ứng dụng Android

Question

Vấn đề: Các lớp Hoạt động thực sự lớn và phức tạp. Khó đọc/hiểu và sửa đổi. Khó kiểm tra.

Giải pháp có thể có: Model-View-Presenter (có lẽ với tiêm phụ thuộc). Và đối tượng thử nghiệm Mock!

Tôi đang lập kế hoạch triển khai Model-View-Presenter trong ứng dụng Android của mình. Về cơ bản, đây là một biến thể của Model-View-Controller. Về bản chất, hãy làm cho Hoạt động một trình quản lý bố cục được tôn vinh và trì hoãn bất kỳ logic nghiệp vụ nào cho Người trình bày. Một cách khác để xem Presenter là nó giống như một lớp Helper được khởi tạo trong một Activity để thực hiện việc nâng hạng nặng với hoạt động cung cấp một giao diện/gọi lại mà Presenter có thể sử dụng.

Tôi muốn nhận được một số suy nghĩ của cộng đồng về vấn đề này. Ví dụ: Giao diện nào được ngụ ý bởi điều này?
Mô hình và Chế độ xem có trách nhiệm gì so với Người trình bày.

Đối với người trình bày Tôi cho rằng Hoạt động sẽ triển khai các giao diện cần thiết bởi Người trình bày?
Những thứ gì sẽ được đưa vào Trình bày so với Hoạt động?

Người trình bày có thể là một đối một với Hoạt động không? Điều gì về một hoạt động với nhiều mảnh hiển thị các vật dụng khác nhau mỗi với bộ chuyển đổi riêng của mình? Bây giờ chúng ta có cần nhiều người thuyết trình hay vẫn chỉ là một diễn giả không?

Điều gì về Người trình bày so với bộ điều hợp?

Người trình bày nên liên hệ như thế nào để nói Hoạt động với ListView và ListViewAdapter? Điều gì xảy ra với Presenter vs. Adapter?
Người thuyết trình có nên chọn Bộ điều hợp để sử dụng không? Hoặc nên Hoạt động đưa ra quyết định này? Nếu Trình mô hình xử lý Dữ liệu Mô hình hoặc Bộ điều hợp? Có xung đột giữa các bộ điều hợp và người thuyết trình không? Người thuyết trình có thích ứng không? hoặc một cái gì đó ít hơn/nhiều hơn. Thông thường Bộ điều hợp chỉ dành cho các tiện ích như ListViews trong một Hoạt động. Họ không thực hiện các cuộc gọi tự lấy dữ liệu mà tôi nghĩ. Vì vậy, trong mô hình xem-presenter điều quan trọng là thực sự để quyết định những gì đi trong người trình bày so với các lớp khác và những gì giao tiếp nên được giữa người trình bày và các hoạt động, bộ điều hợp và quan điểm/bao gồm cả các mảnh vỡ. Các tính năng chính của chúng tôi là gì?

Model-View-Presenter có thực sự là một ý tưởng tồi cho Android không? Hay nó có phù hợp với Khung làm việc Android không?

Hãy nhớ rằng có rất nhiều ví dụ bên ngoài Android của SDK rất trưởng thành vẫn cần một kiến ​​trúc vi mô như MVP. Trong thực tế ví dụ rất nhiều: ví dụ. Flex đã rất trưởng thành SDK cho Flash và nó vẫn cần MVP và MVC framework cho hầu hết các ứng dụng chính.

EJB cần Spring để đơn giản hóa và sắp xếp nó. MFC/Struts vv và danh sách đi và về. Tại sao Android nên khác biệt? Tại sao chúng ta nên giả sử SDK có mọi thứ cần thiết trong trường hợp của Android mà không có một mẫu thiết kế như MVP?

Điều cần biết trước khi tôi dành hàng trăm giờ cho việc này, vui lòng nhận xét/trả lời bất kỳ phần nào của câu hỏi này.

Answer 1

Android trừng phạt kém MV (P | C) thiết kế nhiều hơn bất kỳ nền tảng nào mà tôi từng gặp phải. Hãy quên đi các phương pháp vụng về mà nó cung cấp để chuyển trạng thái lên và xuống ngăn xếp hoạt động.Nhận được càng nhiều trạng thái và logic ra khỏi các hoạt động của bạn càng tốt. Di chuyển nó vào Dịch vụ, Trình cung cấp nội dung và SharedPreferences khi thích hợp. Cố gắng làm cho hoạt động của bạn trở nên thuần khiết. IMO, Dịch vụ chưa bao giờ được chú ý đầy đủ trong hướng dẫn Android. Ngay cả cuốn sách O'Reilly Lập trình Android chỉ cung cấp cho họ một trang quý!

Hãy cảnh giác với việc mở rộng Ứng dụng. Nếu bạn đã từng bắt đầu một Dịch vụ theo quy trình riêng của mình (ví dụ: để cho phép Dịch vụ được tắt một cách duyên dáng khi Hoạt động bị treo) thì Dịch vụ sẽ có bản sao Ứng dụng của riêng bạn.

Answer 2

Chỉ để cung cấp tài liệu tham khảo cho những người khác có thể quan tâm. Tôi đã suy nghĩ điều tương tự một vài năm trước đây. Khi chúng tôi áp dụng MVC/MVVM/Presentation Model cho ứng dụng android, điều chúng tôi thực sự muốn là có một dự án có cấu trúc rõ ràng và quan trọng hơn đối với các bài kiểm tra đơn vị. Hiện tại, không có khung bên thứ ba, bạn thường có nhiều mã (như addXXListener(), findViewById() ...), không thêm bất kỳ giá trị kinh doanh nào. Hơn nữa, bạn phải chạy thử nghiệm đơn vị android thay vì kiểm tra JUnit bình thường, mà mất nhiều thời gian để chạy và làm cho các bài kiểm tra đơn vị hơi không thực tế. Vì những lý do này, một vài năm trước, chúng tôi đã bắt đầu một dự án mã nguồn mở RoboBinding - Khung mô hình trình bày ràng buộc dữ liệu cho nền tảng Android. RoboBinding giúp bạn viết mã UI dễ đọc, kiểm tra và bảo trì hơn. RoboBinding loại bỏ sự cần thiết của mã không cần thiết như addXXListener hoặc như vậy và thay đổi logic giao diện người dùng thành Mô hình trình bày, là một bài thơ và có thể được kiểm tra qua các kiểm tra JUnit bình thường. RoboBinding chính nó đi kèm với hơn 300 bài kiểm tra JUnit để đảm bảo chất lượng của nó. Các lựa chọn thay thế khác: Android-Binding, Bindroid và MvvmCross.