implementation of mvvm architecture in objective-c

Question

How to implement the mvvm architecture in objective-c ? I need sample project to learn the mvvm architecture and also i need to know that what is needed to give in model, view, viewModel and how to separate in objective-c ? what is the difference between the normal project and mvvm project ?

Answer 1

Jesto I can give you details about what you ask briefly.Even if it is explanation you can easily understand what I post here because it has sources with examples and you can directly try the source.

First the Model

The model layer is not as self-explanatory as it may seem.

As you would expect, it will have your model objects, potentially covering most of the layer surface. In the tickets example, you would have a Ticket struct that would live in your model.

I find the following components to also be part of the model layer:

Network Code. The shape should be something like this. Ideally, you’d only use a single class for network communication across your entire app. Persistence Code. You would implement this with Core Data or simply by saving an NSData blob directly to disk. Parsing Code. Any objects that parse network responses and the like should be included in the Model layer as well.

While the model objects and the parser are domain-specific, the network code will be highly reusable.

The controller will then use all the elements in your model layer to define the flow of information in your app.

Second the View

When a user interacts with your app, they are interacting with the view layer. The view is considered the “dumb” part of your app, since it shouldn’t contain any business logic. In code terms, you’ll normally see:

UIView subclasses. These range from a basic UIView to complex custom UI controls. A UIViewController (arguably). Since a UIViewController is strongly coupled with its own root UIView and its different cycles (loadView, viewDidLoad), I personally consider it to be part of this layer, but not everyone agrees. Animations and UIViewController transitions. Classes that are part of UIKit/AppKit, Core Animation and Core Graphics.

Typical code smells found in this layer manifest in different ways, but boil down to including anything unrelated to UI in your view layer. A classic code smell is making a network call from a UIViewController.

It’s tempting to put a bunch of code in your UIViewController and be done with it, so you can meet that deadline. Don’t do it! In the short term, you might save a couple of minutes, but in the long term, you could lose hours looking for a bug, or have trouble when you want to reuse code inside one view controller in another.

Third MVVM

Model-View-ViewModel, or MVVM, is an MVC derivation. Conceptually, it’s similar. The biggest difference is in the communication between layers, and instead of a controller, you use a view model.

In practice, MVVM shines when it has an FRP framework to support it. Since the model is now observed by the view model and the view model by the view, the FRP paradigm becomes a natural choice to manage the information flow. This leads to a better separation between layers, which translates in decoupled components that are easy to test.

Bottom line: architecture is important, but in my opinion the right programming paradigm will influence more the overall quality of your code. It’s also important to note, that most often that not, you will have in the same app different approaches. This includes both architecture and paradigm. You might think this will disrupt consistency inside the codebase, but you should always use the right tool for the job.

Finally MVC

The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries. The collection of objects of a certain MVC type in an application is sometimes referred to as a layer—for example, model layer.

MVC is central to a good design for a Cocoa application. The benefits of adopting this pattern are numerous. Many objects in these applications tend to be more reusable, and their interfaces tend to be better defined. Applications having an MVC design are also more easily extensible than other applications. Moreover, many Cocoa technologies and architectures are based on MVC and require that your custom objects play one of the MVC roles.

Difference between Normal and MVVM

Models — responsible for the domain data or a data access layer which manipulates the data, think of ‘Person’ or ‘PersonDataProvider’ classes.

Views — responsible for the presentation layer (GUI), for iOS environment think of everything starting with ‘UI’ prefix.

Controller/Presenter/ViewModel — the glue or the mediator between the Model and the View, in general responsible for altering the Model by reacting to the user’s actions performed on the View and updating the View with changes from the Model.

MVVM Says

The latest and the greatest of the MV(X) kind The MVVM is the newest of MV(X) kind thus, let’s hope it emerged taking into account problems MV(X) was facing previously. In theory the Model-View-ViewModel looks very good. The View and the Model are already familiar to us, but also the Mediator, represented as the View Model. MVVM It is pretty similar to the MVP: the MVVM treats the view controller as the View There is no tight coupling between the View and the Model In addition, it does binding like the Supervising version of the MVP; however, this time not between the View and the Model, but between the View and the View Model. So what is the View Model in the iOS reality? It is basically UIKit independent representation of your View and its state. The View Model invokes changes in the Model and updates itself with the updated Model, and since we have a binding between the View and the View Model, the first is updated accordingly.

Also the MVVM Design Pattern and How does MVVM work?

Answer 2

Check it out this topic -> What is the difference between MVC and MVVM?

Model-View-ViewModel basic example is here -> https://github.com/futurice/mvvm-example-objc and maybe next step, you can use reactive cocoa because it can be more effective with mvvm -> https://github.com/ReactiveCocoa/ReactiveViewModel

reactive cocoa -> https://github.com/ReactiveCocoa/ReactiveCocoa

goodluck :)