2 ms·
Do you realize that the whole Apple's UIKit Framework is a version of MVC? I have seen many versions for it in iOS, MMVC, MVVC, or whatever, but really they
by ardit33 5y ago
Do you realize that the whole Apple's UIKit Framework is a version of MVC?
I have seen many versions for it in iOS, MMVC, MVVC, or whatever, but really they are iterations of separation of business logic and view/display logic.
You can disperse the view logic, without having traditional centralized controllers, but your business logic will end up centralized in one place. So, in practice you end up with a Model-Business-Logic / View paradigm, where traditional controllers end up just being a thin layer.
Protocol driven development, reminds me the old Java style of having a class (eg. MyFunctionalityClass), which was either abstract, or had only protocols declared, then have another MyFunctionalityClassImpl to actually implement it.
I didn't think it was pretty, and it seemed it was done by C++ developers to simulate the lack for header .h files in Java.
Ps. Before you reply on a ad-hominen way, I probably have much more iOS experience than you, since I both have worked on it since day one, and have worked on some the currently largest apps in the world.
- swiftaccount1 5y agoI basically agree with you, actually. It feels like a lot of this is breaking down into semantics. I’m not fond of acronyms, I believe it’s important to go to core principles and never do anything blindly, but only when it’s useful. The fundamental challenge of iOS architecture is picking the right level of abstraction for the complexity of your application. The trouble that comes in with MVC, as I see it, is how easy it is to shoot yourself in the foot. It’s too easy to do it “wrong”, which is why so many have tried to come up with something different. Of course you can’t escape the MVC-ness of the platform, it’s all about how you manage it.