Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Apple, for memory management issues, recommend defining outlets on properties, not in the attribute declaration. But, as far as I know, declaring properties exposes the class to external classes, so this could be dangerous.
On UIViewController we have the main view definition and the logic, so MVC is slightly cheated in this cases.
What is the beter approach, Apples’s recommendation for memory-management or armored classes?
MVC isn’t cheated by
UIViewController, as that class implements a Controller. It defines connections between the View objects (usually stored in the XIB) and the Model objects (sometimes Core Data entities, sometimes other things).Anyway. The point of defining outlets as properties is that you get to state explicitly what the memory management requirements on the properties are in the class interface. The NIB-loading mechanism uses the accessors if they exist, so you if you define a retain property, the outlet gets retained. If it can’t find accessors it will set the instance variable directly.
Whether you define properties or not for your outlets is really a matter of personal taste. I do, because the outlets are set by an external object (the
NSBundleclass) so to my mind represent part of my view controller’s API contract.