2010-06-24 30 views
5

Tôi tiếp tục chạy vào các tình huống với UIViewControllers chứa một số lượng lớn các IBOutlets kết nối bộ điều khiển với các xem phụ của khung nhìn (thường là UILabels).Thực tiễn tốt nhất để giữ lại các yếu tố chế độ xem IBOutlet?

Tiếp theo "thực hành tốt nhất", ví dụ: sử dụng giữ lại trên tất cả các yếu tố giao diện người dùng: @property (retain, nonatomic) UILabel *theElement1, @property (retain, nonatomic) UILabel *theElement2 ... mang lại cho tôi số tiền điên mã tấm nồi hơi trong deallocviewDidUnload cho bộ điều khiển xem.

Các IBOutlets vi phạm không bao giờ được sử dụng cũng như không được đặt bên ngoài UIViewController (phương thức thiết lập chỉ được sử dụng trong viewDidUnload và khi ngòi được nạp) ngoại trừ tự động khi ngòi được nạp.

Kết quả từ "thực hành tốt nhất" là:

  • dealloc rải rác với [theElement1 release], [theElement2 release], vv
  • viewDidUnload với [self setTheElement1:nil], [self setTheElement2:nil], vv

Tuy nhiên, vì tất cả những yếu tố được biết là được giữ lại bởi xem anyway, và xem được phát hành bởi UIViewController vào thời điểm thích hợp, tôi thấy hoàn toàn không có lý do gì để tôi quản lý thủ công việc này.

Lý do cho "thực hành tốt nhất" cụ thể này (theo như tôi có thể biết) là phù hợp với số tiền còn lại của bạn. Nhưng một khi bạn bắt đầu có một số lượng lớn các cửa hàng, bạn có nhiều khả năng bỏ lỡ việc xử lý một số cửa hàng ở một trong hai phương pháp, bạn sẽ gặp khó khăn khi thay đổi cửa hàng để "giữ lại" cho những cửa hàng đặc biệt mà bạn thực sự muốn để giữ lại ngay cả sau khi xem là tạm biệt.

Có một số lý do cho "thực hành tốt nhất" khác với cái tôi biết hoặc tôi nên cảm thấy khá tự do để phá vỡ "quy tắc" này trong trường hợp cụ thể của các bản xem trước cho chế độ xem của UIViewController?

+0

Tôi thích chủ đề của câu hỏi này. "Thực sự" – VoodooChild

Trả lời

4

Bạn nên tuân theo phương pháp hay nhất này. Nó bảo vệ bạn khỏi các sự cố rất kỳ lạ khi bạn truy cập IBOutlets sau một cảnh báo bộ nhớ. Có, bạn cần phải quản lý IBOutlets theo cách thủ công. Accessorizer thực hiện tốt công việc tự động hóa mã này.

Trước ObjC 2.0, chúng tôi cũng phải viết tất cả các trình truy cập của chúng tôi bằng tay (@property và @synthesize là những bổ sung rất mới cho ngôn ngữ). Mọi thứ trở nên đẹp hơn rất nhiều. Khi chúng tôi chuyển sang ABI 64-bit và thu gom rác, mọi thứ trở nên đơn giản hơn (và bạn sẽ mong đợi những điều này cuối cùng để thực hiện theo cách của họ cho iPhone).

Nhưng hiện tại, hãy làm theo các quy tắc quản lý bộ nhớ như được trình bày trong Memory Management of Nib Objects. Bạn giao dịch một số lượng rất nhỏ của việc gõ cho một số lượng lớn của gỡ lỗi. (Hmm, có vẻ như họ đã cập nhật tài liệu này lần nữa; thời gian để tự học lên.)

+0

Tuyệt vời - Tôi chưa từng thấy tài liệu Quản lý bộ nhớ Nib trước đó. –

+0

Chỉ thay thế lành mạnh khác của tôi sau một thời gian trở thành tạo ra các phần tử giao diện người dùng bằng tay và gắn chúng vào một NSArray. Nhưng điều đó giống như vẫy cờ và bỏ cuộc. Có điều gì đó giống như 20-30 IBOutlets là một cơn ác mộng bảo trì. Và tại sao tôi có nhiều cửa hàng bạn có thể yêu cầu? UILabels được bản địa hóa là câu trả lời của tôi. – Nuoji

+0

Khác hơn là làm cho nó khó khăn hơn để gỡ lỗi lỗi liên quan đến các lĩnh vực này, những hạn chế là gì? Thực tế, đối với các trường cụ thể này, bạn có thể từ bỏ toàn bộ thuộc tính @/@ tổng hợp và tạo các trường @private để ngăn bất kỳ lớp nào khác nhầm lẫn tin rằng chúng có thể được sử dụng ngay cả khi chế độ xem bị xóa. Tôi đang nói trong bối cảnh rất cụ thể của UIViewControllers và (chỉ đọc) subviews để xem điều khiển đó. Vấn đề với một số lượng lớn các IBOutlets dường như không có khả năng phát sinh ở những người khác. – Nuoji

Các vấn đề liên quan