3 ms·
I'm considering writing a similar post. For me the biggest write was how steep the learning curve for the whole Cocoa (referring mostly to UIKit, but also to a
by norswap 13y ago
I'm considering writing a similar post. For me the biggest write was how steep the learning curve for the whole Cocoa (referring mostly to UIKit, but also to a few other pieces) shebang was. It's not even that the system is badly designed (arguably it could be a lot better though) but that the documentation is so so bad. API docs are okay, but don't give you the big picture. Their reference guide, on the other hand are so abstract and 1000-mile high that you don't really get practical value out of them.
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?
- Strilanc 13y agoI 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.
- mmorey 13y agoA 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.
- Strilanc 13y agoThanks, 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?
- tvon 13y agoA UIVieController has a view associated with it (typically self.view) which is why XCode offers to create a xib file for you.