Marc (34) [Avatar] Offline
#1
Hi,
The ViewModel implements UI logic, including Navigation.
All of the examples I can find, either in the book or elsewhere, are user-driven navigation, like button taps.
What about data-driven navigation?
If, while loading data in the Initialize method, a specific condition requires a different screen, how does the ViewModel navigate to a different ViewModel?
Are there restrictions on which methods in the ViewModel can initiate a Navigate request?
What about the back stack of screens? Should I (how do I) remove the screen that was almost, but not quite, shown?
What about the data that was loaded? Is that data available to be passed, via Navigate?

Thanx,
M.
Jim Bennett (82) [Avatar] Offline
#2
Data-driven navigation is pretty standard - the most obvious use case is to fire up a login screen if the user isn't logged in. I honestly don't know what would happen if you did it in the
Initialize
method, I would imagine things might go wrong as you are already in the middle of a navigation at that time. The same with the
Prepare
method.

Decision based navigation probably the kind of thing you'd want to do further back in the chain. If you want to change the first view to show a login screen if the user is not logged in then I would put the condition around the setting of the App start VM. If you were thinking of navigating from VM1 to VM2, then putting logic in VM2 to navigate immediately, instead put the logic in VM1. The advantage of putting the logic in the first VM is there is nothing on the back stack to remove.

You can read up on all the MvvmCross navigation methods here: https://www.mvvmcross.com/documentation/fundamentals/navigation

There's methods documented there that can pass data in, and get data back.
Marc (34) [Avatar] Offline
#3
Hi,
So much about the Android and iOS environments (like, all of it) is unknown to me, I don't know how to make tradeoff's.
We seem to share the same FUD: Will navigating, while navigating, break Navigation?
And if so, in what ways? Could I simply run a test and look for a consistent, hard failure?
Or, like non-threadsafe code, expect my first failure a year from now?

Given the way these OS's do memory management, could I:
Create a singleton, lets call it Cache, do all my database fetches into it, rather than local (aka automatic) variables?
Using Mvx.Resolve, each ViewModel could quickly access the data it needs, and I could do the 'heavy lifting' before deciding where to navigate?

Even slicker, maybe, keep the data in the ....Service object itself?

Thx,
M.