3 ms·

> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed ex

> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril. I dont understand this. MVVM is an extremely abstract pattern. It transcends the technology stack. How it is implemented on the platform differs, and yes you are not going to avoid the UIViewController when doing it on iOS. But you are still doing MVVM even if your V is actually a UIViewController. I use MVVM almost exclusively now, and I usually do it in a cross-platform framework (Xamarin/MAUI). The codebase is portable across both iOS and Android with no re-architecting of the high-level architecture pattern.

ChrisMarshallNY 4y ago
I liked the "cut with the grain" comment, someone made earlier. The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers. It's entirely possible to basically use a "skeletal" one, and have the main code in the linkages between the Model and the View, but that makes the Storyboard Editor useless. I use the Storyboard Editor a lot. It is not my favorite editor, but it allows me to work incredibly quickly, and to make a really reflowable UI. I know that the app I'm working on now, is larger than any I've seen from SwiftUI (around 40 screens, and communicating with three servers in realtime, using a couple of SDKs). I am able to make it all work. I feel as if MVVM would make the parts of the app that link the UI to the servers a lot more graceful (it's a nasty state engine, right now -ick). I feel as if this kind of app is the kind of thing they had in mind, with SwiftUI. I do know that it's really important to derive subclasses, and extend ObjC classes, when using UIKit/AppKit/WatchKit, and I feel sorry for folks that avoid inheritance like the plague. It must be a fair bit of work. Looks like SwiftUI doesn't really need that at all, but I haven't spent enough time with it, yet, to know for sure. I have no doubt that I'll end up mastering it. I'm a quick study. I've spent 35 years, surfing the tech wave.
- JamesSwift 4y ago
  > The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers. I dont think you understand the point I'm making. Just because Apple has created a framework that has something called UIViewController which has child UIViews doesnt matter when using a pattern called MVVM. The V is just the _visual_ representation of the pattern. It could be a terminal console if you want, it doesn't have to be the "underlying" view of the platform! Don't fight the platform to align its idea of the view with a specific thing called a View in the pattern. EDIT: and yes IB is an issue if you want to be programmatic. I do all my views in code.
  - ChrisMarshallNY 4y ago
    Actually, I understood just fine. I’ve been doing this kind of thing for a while. I’m not even disagreeing. I understand where you are coming from. It’s just Apples and oranges. I write in Swift, as a native developer of Apple software. I won’t go into all the reasons I do what I do (actually, I’ve covered a lot, in this thread). I have my reasons, and there’s nothing wrong with my approach. I get a lot done, very quickly, and at a fairly high Quality level. Life is a compromise. We always need to make trade-offs.

ChrisMarshallNY 4y ago

I liked the "cut with the grain" comment, someone made earlier. The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers. It's entirely possible to basically use a "skeletal" one, and have the main code in the linkages between the Model and the View, but that makes the Storyboard Editor useless. I use the Storyboard Editor a lot. It is not my favorite editor, but it allows me to work incredibly quickly, and to make a really reflowable UI. I know that the app I'm working on now, is larger than any I've seen from SwiftUI (around 40 screens, and communicating with three servers in realtime, using a couple of SDKs). I am able to make it all work. I feel as if MVVM would make the parts of the app that link the UI to the servers a lot more graceful (it's a nasty state engine, right now -ick). I feel as if this kind of app is the kind of thing they had in mind, with SwiftUI. I do know that it's really important to derive subclasses, and extend ObjC classes, when using UIKit/AppKit/WatchKit, and I feel sorry for folks that avoid inheritance like the plague. It must be a fair bit of work. Looks like SwiftUI doesn't really need that at all, but I haven't spent enough time with it, yet, to know for sure. I have no doubt that I'll end up mastering it. I'm a quick study. I've spent 35 years, surfing the tech wave.

JamesSwift 4y ago
> The UIViewController must be present in a UIKit app. Most classic UIKit apps have the lions' share of code in UIViewControllers. I dont think you understand the point I'm making. Just because Apple has created a framework that has something called UIViewController which has child UIViews doesnt matter when using a pattern called MVVM. The V is just the _visual_ representation of the pattern. It could be a terminal console if you want, it doesn't have to be the "underlying" view of the platform! Don't fight the platform to align its idea of the view with a specific thing called a View in the pattern. EDIT: and yes IB is an issue if you want to be programmatic. I do all my views in code.
- ChrisMarshallNY 4y ago
  Actually, I understood just fine. I’ve been doing this kind of thing for a while. I’m not even disagreeing. I understand where you are coming from. It’s just Apples and oranges. I write in Swift, as a native developer of Apple software. I won’t go into all the reasons I do what I do (actually, I’ve covered a lot, in this thread). I have my reasons, and there’s nothing wrong with my approach. I get a lot done, very quickly, and at a fairly high Quality level. Life is a compromise. We always need to make trade-offs.