Mvvm on blog.iankulin.com

Towards MVVM

Sat, 03 Dec 2022 00:00:00 +0000

On one of the more mediocre episodes of Fireside Swift, McSwiftface and Zach talk about the SOLID principles of class design, although I don’t hold the principles as the article of religious fervour that many interviewers apparently do, they are a useful touchstone for considering class quality. OOP had been in swing (in a commercial way) for a few years by then - I was writing in Delphi and C++. The spaghetti code era was a long way behind us and the idea of separation of responsibilities was well established.

I have been thinking about architecture a bit anyway - the introduction of Core Data into the #100Day apps I’m up to (day 63) means that there’s complicated looking code scattered around my views. In the cs193p lectures, MVVM is right near the start, and I made some early forays into it, but so far no talk of architecture in 100Days (although I know it’s coming soon.

I have certainly had the experience before of needing a layer between my apps and the database tech so they can be swapped out, and it’s basically a reflex to me to always wrap any commercial external code I’m introducing in any reasonable size program to abstract it a bit and make the (likely) task of having to replace it in the future a lot easier.

Once again, YouTube serves me up a timely video.

When I watch this, I can see why Paul Hudson might have left it for later in the course. There is a lot of complexity. It’s not simple code, it’s scalable code. This is good for real life apps, but it does not follow that it’s good for learning programming.

@ObservedObject v @StateObject

Sat, 13 Aug 2022 00:00:00 +0000

The Youtube algorithm thinks I need to watch more MVVM videos, and it turns out it’s probably right. A day or two ago in an MVVM post using a super simple example, I stored the view model as a property of the view using the @ObservedObject wrapper, as I created it.

struct ContentView: View { @ObservedObject var light = LightViewModel()

var body: some View {
 VStack{
 Spacer()
 if light.isOn(){
 drawLitBulb
 }
 else{
 Image(systemName: "lightbulb.fill").font(.system(size: 72))
 }

But then today, Youtube served me up this video from BeyondOnesAndZeros

They start off with @ObservableObject, but then say that if the View Model is instantiated there, that this is repeated every time the View is recreated (which happens every time it’s redrawn).

I don’t really understand the property wrappers (like @ObservableObject) but I assume this was a type property - ie static. Apparently not. The Apple documentation on managing data says:

SwiftUI might create or recreate a view at any time, so it’s important that initializing a view with a given set of inputs always results in the same view. As a result, it’s unsafe to create an observed object inside a view. Instead, SwiftUI provides the StateObject attribute for this purpose.

So that code should use @StateObject, and @ObservedObject should be used where I pass it down into other view structs in the hierarchy.

Paul Hudson gives a good example in his explanation on this topic here.

Simple MVVM

Thu, 11 Aug 2022 00:00:00 +0000

MVVM (Model-View-View Model) is an architectural pattern for apps that separates the data (Model) from the user interface (View). The communication between these two parts is facilitated by a View Model.

Model <-> View Model <-> View

Model

The Model is platform independent - we should be able to pluck it out and add it to a different application running on a different platform without any trouble. Any business rules will be part of the Model along with the data. For example, if it’s a rule that every customer has a sales contact, this can be enforced in the Model.

The Model (or Models - an app could have more than one) does not know anything about the View or the View Model. In a SwiftUI app, we’ll almost always have the model in its own file.

Our simple example app for this post is going to be a light bulb app. There will be a picture of a light bulb, and a button which will toggle the light off an on. It’s difficult to think of a simpler Model. This is what I’ve come up with.

struct Light{ var on: Bool = false }

A Model in a real application could be massive - with connections to online data stores and complex business rules. Our light just has two exclusive states - off and on. We could make it more complex - it could be an incandescent light with a particular resistance and a formula for the brightness output for any particular voltage that was applied. All of that would go into the Model. But for today, we’ll just have on or not.

In all of the SwiftUI examples I’ve seen so far, the Model has been a struct. Perhaps it can be other things, but Swift has deep magic (structs are mysteriously immutable, so they are actually rebuilt when any properties change) for efficiently knowing if structs have changed, so perhaps not.

View Model

The View Model will have the Model as a property. That way it can do things to the Model, and to access the bits it needs to pass off to the View. The View Model is always a class, as it needs to comply with the protocol of ObservableObject. If protocol and ObservableObject are foreign to you, don’t panic. You don’t need to understand any more than that the View needs to know when the View Model changes, so it observes the View Model, and for that magic to happen, the View Model needs to be a class having that ability (of being observed) which it gets from having the protocol ObservableObject.

The View Model will also have properties or methods that the View can use to access the Model data. Remember the Model is completely hidden from the View, so the View Model provides that access. In a real situation, it would also do whatever translation or packaging was required to make the View’s life easy. In our example it is rather simple.

class LightViewModel: ObservableObject { @Published private var lightBulb = Light(on: false)

func toggle() {
 lightBulb.on = !lightBulb.on
}

var isOn: Bool { return lightBulb.on }

}

Again, the View Model is in it’s own file. The only thing we haven’t mentioned is the @Published used in the property for our Model. This is just part of the magic mentioned earlier in the discussion about ObservableObject which allows the View to know that something has changed, and that it needs to react to this by rebuilding the View.

View

The View is just our regular SwiftUI view. A crucial part is that it holds the View Model for the light as a property wrapped with the @ObservedObject. This completes out connections between the three parts of our architecture.

The Model View is an @ObservableObject which has the Model as a @Published property
The View contains the View Model as an @StateObject property

These connections have these effects

The View cannot ever access the Model directly
If the Model changes, the View Model is aware, and broadcasts this in a way that the View knows about
The View just redraws itself if that happens
As the View does this, it asks the View Model for the parts of the data it needs
This both protects and hides the Model from the view, and is an opportunity for the View Model to do any work it needs to to the data to make it easy for the View to put on the screen.
Any user interaction that occurs in the View is passed to the View Model to deal with.

struct ContentView: View { @StateObject var light = LightViewModel()

var body: some View {
 VStack{
 Spacer()
 if light.isOn {
 drawLitBulb
 }
 else {
 Image(systemName: "lightbulb.fill").font(.system(size: 72))
 }
 Spacer()
 Button("Toggle Light", action: {
 light.toggle()}
 )
 .padding()
 .font(.title)
 .foregroundColor(.white)
 .background(Color.accentColor)
 .cornerRadius(10)
 .padding()
 }
}

var drawLitBulb: some View {
 // view of an iluminated bulb
 ZStack{
 Circle().fill(.yellow).frame(width: 150, height: 150)
 Image(systemName: "lightbulb").font(.system(size: 72))
 }
}

}

To make the code read nicely, the View Model is called “light”, and it’s an @StateObject so for the redrawing trigger to work correctly. The rest of the code should be reasonably clear if you’ve made a few SwiftUI views.

We check if the light is on (by asking the View Model), if it is, we draw a lit bulb, if not, an unlit bulb is drawn. The last UI element is our Button() whose action is the toggle() method of light - our View Model.

The source for this project is on GitHub here.

MVVM Explained

Sun, 07 Aug 2022 00:00:00 +0000

The first nine minutes of this video from Emmanuel Okwara finally gave me a clear understanding of the difference between MVC and MVVM.

In both MVC and MVVM the data & logic (Model) are separated from the part that the user interacts (View). Usually the View is a screen with controls and so on, but that’s not compulsory - for example a voice mail app interface would be all audio and DTMF. The point is that in both, the user interface (view) does not mess directly with the data (model) - it has to go through some sort of gatekeeper.

The new understanding I got from Emmanuel is that in MVVM, the View Model does not know what is in the View. It does not alter the view, just broadcasts that there’s been a change and lets the view go ahead and update itself. It makes sense that this would be the paradigm for SwiftUI’s declarative interface style, and is also (I imagine but actually have no idea) the basis for React.js

One thing Emmanuel mentions that I’m not clear on is that each View will have it’s own View Controller. Currently all my tiny apps have had one view in the SwiftUI sense. I have pulled out sub views, and some have had views within views - for example with the Navigation View. So I guess my question would be, “What constitutes a View in MVVM?”

I noped out at the nine minute mark as soon as Interface Builder showed it’s face. I’m an iOS15 SwiftUI baby - I will, eventually, need to learn the old magic, but competence developing iOS apps using SwiftUI current methods is the MVP.

With this understanding, and having finished lecture 4 from the cs193p series, I think a good project for today would be the simplest possible MVVM app with the correct separations and bindings.