Tại sao Apple không cho phép phân lớp UINavigationController? Và các lựa chọn thay thế của tôi cho phân lớp là gì?

Question

Tôi hiện đang xây dựng một ứng dụng iPhone theo thẻ trong đó mỗi bộ điều khiển xem của tab là một phiên bản UINavigationController và mỗi bộ điều khiển của mỗi một phiên bản UINavigationController là một phiên bản UITableViewController. Lý tưởng nhất, tôi muốn phân lớp UINavigationController để bộ điều khiển cho mỗi tab là một phân lớp của UINavigationController (ngoài việc có tất cả chức năng chuẩn UINavigationController, rõ ràng) đóng vai trò là nguồn dữ liệu và ủy nhiệm cho mỗi lần xem bảng được liên kết với các công ty con của nó. Cố gắng để làm điều này dường như phá vỡ các chức năng cơ bản UINavigationController trong phân lớp.

Xem như Apple nói trong tài liệu iPhone của họ rằng không nên phân loại UINavigationController và mọi thứ dường như bị hỏng khi thực hiện, tôi tự hỏi làm cách nào để mở rộng chức năng UINavigationController's mà không phân lớp và nói chung nên làm việc xung quanh các hạn chế phân lớp khi thực hiện phát triển Cocoa.

Cảm ơn!

Answer 1

Để tham khảo, lưu ý rằng kể từ iOS 6, UINavigationController có thể được phân loại là hợp pháp.

Lớp này thường được sử dụng nhưng có thể được phân lớp trong iOS 6 trở lên. UINavigationController Class Reference

Tất nhiên, điều đó không có nghĩa là bạn luôn nên làm như vậy. Nhưng bạn có thể.

Answer 2

Bởi vì họ muốn tránh sự không thống nhất của giao diện người dùng gây ra mọi nền tảng khác.

Answer 3

Tại sao bạn muốn UINavigationController hoạt động như một nguồn dữ liệu cho bảng? Toàn bộ điểm của UITableViewController là bạn phân lớp nó và nó hoạt động như nguồn dữ liệu cho số UITableView mà nó cũng đặt vào và điền vào, chế độ xem gốc.

Answer 4

Như tôi đã hiểu, lớp con không được khuyến khích vì Objective C cho phép một lớp con truy cập quá nhiều vào các hoạt động bên trong của lớp cha của nó.

Cách thay thế được đề xuất để viết một lớp con là viết một đại biểu, trong trường hợp này là UINavigationControllerDelegate. Sau đó bạn có thể gói gọn hành vi cụ thể mà bạn muốn mở rộng vào lớp đại biểu này và liên kết nó với UINavigationController bất cứ khi nào bạn cần.

Answer 5

Nếu chế độ điều khiển sẵn có không đáp ứng nhu cầu của bạn về xử lý dữ liệu (giả định của chúng tôi, vì chúng tôi không biết tại sao bạn muốn một đối tượng là nguồn dữ liệu cho nhiều chế độ xem), bạn luôn có thể tạo dữ liệu bổ sung và/hoặc các lớp điều khiển (các lớp con của NSObject ít nhất).

Bạn có thể tồn tại dữ liệu hoặc đối tượng khác trong khi thay đổi chế độ xem theo nhiều cách khác nhau. (1) một tài sản của lớp ứng dụng ủy nhiệm của bạn. Bất kỳ đối tượng nào trong ứng dụng của bạn đều có thể lấy mẫu ứng dụng ủy nhiệm ứng dụng của bạn với

[[UIApplication sharedApplication] delegate] 

Sử dụng điều này một cách tiết kiệm vì nó thực chất tạo ra hình cầu.

(2) Bạn có thể truyền dữ liệu hoặc các đối tượng khác từ bộ điều khiển đến bộ điều khiển khi bạn đẩy các lớp con của bộ điều khiển xem hoặc đưa chúng lên trong các tab.

(3) Dữ liệu cốt lõi là một cách khác nhưng đòi hỏi nhiều Ca cao trong vành đai của bạn và bạn vẫn phải quản lý (các) bối cảnh ngữ cảnh.

Answer 6

Tôi sẽ tiếp tục và nói ý tưởng của bạn có một số công đức, nếu ở mọi cấp độ bạn thực sự sử dụng cùng một loại dữ liệu và mỗi cấp có lẽ có một đại biểu khác nhau để xử lý việc tạo tế bào.Về cơ bản không có lý do gì bạn không thể phân lớp bộ điều khiển UINavigation để thêm một lớp dữ liệu hoàn toàn trực giao, vì nó không liên quan gì đến giao diện người dùng hoặc hành vi mà UINavigationController đang quản lý (đó là những gì Apple quan tâm với). Đối với những người phản đối ý tưởng, hãy nghĩ về nó như một kho lưu trữ dữ liệu trên mỗi tab mà tất cả các trang trong một tab có thể truy cập thay vì mỗi trang trong hệ thống phải đi đến AppDelegate, hoặc có một nhóm người độc thân. Về cơ bản thì đó là một singleton, nhưng ít nhất một cái đã có và nhận được tham chiếu được truyền đi tự động. Tất cả những gì đã nói, tôi sẽ kết thúc bằng một đề xuất thiết kế thay thế - Tôi nghĩ rằng những gì bạn có thể muốn làm là xem chi tiết nhiều lớp sử dụng lại cùng một mã để tạo ra các ô và vì bạn có cùng một loại dữ liệu ở mỗi lớp. Một cách tiếp cận tốt hơn để xử lý đó là có một bộ điều khiển chế độ xem bạn cho phép tập con dữ liệu hiển thị và khi người dùng đọc xuống, nó chỉ tạo một thể hiện khác của cùng một bộ điều khiển chế độ xem với tập con dữ liệu mới. Cách tiếp cận đó tốt hơn nhiều so với ý tưởng của việc điều khiển chuyển hướng hoạt động như một bảng ủy nhiệm cho mỗi cấp độ, bởi vì bạn phải thực hiện một tấn tua đi qua lại và nó sẽ đòi hỏi nhiều công việc hơn để nhớ vị trí cuộn ở mỗi mức để khởi động. Đó là lý do tại sao bạn muốn giữ các bản tóm tắt bằng cách sử dụng nhiều phiên bản của bộ điều khiển chế độ xem, nhưng nhiều phiên bản không có nghĩa là nhiều lớp.