1

In an Android or iOS project that is has been implemented with MVVM architecture what is the correct approach for navigation?

  1. ViewModel decides when the navigation occurs and which is the destination
  2. ViewModel decides when the navigation occurs and the View decides which is the destination
  3. View decides when the navigation occurs and which is the destination
Christos Chadjikyriacou
  • 3,763
  • 21
  • 37
  • Option 1 and 3 are the same. – Andrew Mar 06 '21 at 22:56
  • But we do not have any concept of **ViewModel** any more in SwiftUI!, the all idea was making it Value type unlike what happens in UIKit. – ios coder Mar 06 '21 at 22:59
  • @swiftPunk MVVM and `ViewModel`s (usually in the form of `ObservableObject`) are very common in SwiftUI. Perhaps you're thinking of `UIViewController`? – jnpdx Mar 06 '21 at 23:27
  • As I mentioned we do not have View type model that could we call it **ViewModel** instead we have value type View which they are struc in SwiftUI. – ios coder Mar 06 '21 at 23:41
  • @swiftPunk -- check out this for example: https://www.vadimbulavin.com/modern-mvvm-ios-app-architecture-with-combine-and-swiftui/ or https://nalexn.github.io/clean-architecture-swiftui/ View/ViewModel are two distinct things. Both exist in SwiftUI – jnpdx Mar 06 '21 at 23:54
  • I think you did not understand me, or maybe I was not good in explaining, I was talking about View topic that they are struct not reference type, we do not have View or views in form of Class or reference type, there for we can not make an instance of that, because they are not reference object type. – ios coder Mar 07 '21 at 00:05
  • I think I just chose bad naming from beginning, my meaning of using the word **ViewModel** was a class that we could make an object from that model/class, because we have no such thing in SwiftUI that was the reason I said we have no concept of **ViewModel** any more in SwiftUI. :) – ios coder Mar 07 '21 at 00:38
  • Does this answer your question https://stackoverflow.com/a/62909832/12299030? – Asperi Mar 07 '21 at 05:49

1 Answers1

2

I believe it's supposed to be like so:

  1. The ViewModel decides when the navigation happens, the destination, and also the data, if any, to be passed to the destination.
  2. The View performs the actual action, decides on the navigation animation and other UI stuff.

So ultimately we need the logic to be in the ViewModel and the UI stuff should be the responsibility of the View.

One way to go about it is to fire an Event in the ViewModel when navigation needs to happen. This event should specify the destination and data to be passed if any. The View subscribes to this event and whenever it is fired, it decides upon the navigation animation and then performs the actual action (the actual act of navigation is a part of the UI) taking into consideration the destination and the data to be passed.

Xid
  • 4,578
  • 2
  • 13
  • 35
  • So you believe in option 1 right ? :) But I find option two to be a valid answer. For example you can have multiple events like (navigateToDetailsEvent, navigateToAboutEvent) and if you have a button that its action is to navigate to an about screen then you connect that button to navigateToAboutEvent. With this architecture the view decides that his button needs to navigate to the about screen , but the viewModel decides when that will happen. – Christos Chadjikyriacou Mar 07 '21 at 10:05
  • 1
    Hmm, I get your point. I guess both ways could be correct in different situations. Let's say you have a button that can have different actions depending on the user type (e.g. For Manager it goes to a different screen and for Employee it goes to a different screen), then the determination of user type should be in the ViewModel. So here the `ViewModel` could decide the destination or the `ViewModel` can have different events for each case and the destination is decided by the `View`. You have a very good point here. – Xid Mar 07 '21 at 11:01