Re:A Year’s Worth of Opinions about Objective-C
by Strilanc on Saturday December 14, 2013 @11:58AM
(#6906189)
I haven't done enough UIKit stuff to really comment on it, other than to say I also still find a lot of the conventions confusing or at least weird and also find that the documentation fails to answer my questions.
I also don't get the distinction between a UIView and a UIControllerView. In C# land I always associated view=.xaml and controller=.cs. In obj-c land both views and view controllers have a .xib and .m/.h, so it's not clear to me how responsibilities are divided.
Re:A Year’s Worth of Opinions about Objective-C
by mmorey on Saturday December 14, 2013 @12:23PM
(#6906262)
A view can be a scene in a storyboard file, a xib file, or you can create your views programmatically (.m and .h).
A view controller is always a .m and .h.
And if you're not following the MVC pattern you can put your view code in your view controller's loadView/viewDidLoad method.
Re:A Year’s Worth of Opinions about Objective-C
by Strilanc on Saturday December 14, 2013 @12:29PM
(#6906285)
Thanks, that's actually a helpful thing to mention and obvious in hindsight. A view controller can be the owner of a .nib but not the class of a .nib, so the .nib is never a view controller.
Are there particular divisions of responsibility that come up w.r.t. what you put in a view's .m/.h vs what you put in the controller's .m/.h? Is the .m/.h of a view considered to be a controller in the MVC sense but not in the UIViewController sense?
After that, the system with small inconsistencies, imprecise documentation and undocumented behaviour. In short, it's not very "systematic". You don't feel there's a well thought-out system that will allow you to predict what will happen. This is especially true when talking about layout, but also other things such how views / controllers interact. There's not a culture of "best practices", so interfacing with someone else's UI libraries can be hell.
@Author: Any thoughts about this?