CODEWITHSUNDEEP
mvvmxamarincaliburn.micro
Elliot Blackburn
Elliot Blackburn

Reputation: 4164

Caliburn + Xamarin navigation

Background:

We're using Caliburn.Micro 3.0.0-beta2 with a WPF + Xamarin iOS / Android project and we want to ensure the view models can be cross platform to reuse as much code as possible.

We've been looking at how to abstract our our navigation to be testable, cross platform and so callable in the view model rather than the views.

I was wondering if anyone had suggestions about how we should handle our app navigation. Our screens require us to inject some data such as database ID's into screens as we're navigating around. Currently we've done this with a view first approach by injecting the data into the view and having that pass it into the view model, but this doesn't feel ideal as it should really go into the view model as it's view logic (right?).

The view model is created for the view view using ViewModelLocator.LocateForView(this); and this then satisfies the rest of our dependencies using the SimpleContainer.

We Understand that navigation hasn't been implemented into 3.0.0 yet according to https://github.com/Caliburn-Micro/Caliburn.Micro/issues/142. We're really looking for a way we could do navigation that may be similar to the Caliburn.Micro solution implemented soon, with a hopeful view to contribute towards this if possible.

Questions:

  1. How would we go about getting the data into the view model rather than the view to make it easier to test and more similar to how our WPF application will need to work?
  2. Is this even sensible for a mobile app or should we be taking a view first approach? If so, what would be a testable approach for this?

Upvotes: 0

Views: 372

Answers (1)

mvermef
mvermef

Reputation: 3914

Unless you have setup Caliburn.Micro for view-first approach (can be done there is a sample for this) the framework is almost completely viewmodel first in nature. I find it rather difficult to work in view first. Most of my "screens" are developed around the view model in question. With that in mind I also at times have multiple views for each viewmodel depending on the operation (add/ edit/ details/ list) for example.

1) DI, usually through repository or other context of that nature then using BindableColllection to hold and notify of changes to the view. Pretty much the same as WPF would work. Most recently my code has started to be cross platform (WP to WPF, now more Universal) to help reduce my headaches. Most of the patterns used are DI(SimpleContainer), Repository (EF 6x), Pub/Sub (IEventAggregator). The one exception is Repository but to an extent I still use it on WP but since I use Sqlite, up until recently EF was out of the question (EF 7 to the rescue)...

2) Do what is comfortable. If you are use to using Fakes then do it. It shouldn't matter as long as you have the correct results you are looking for in the end. Of course I am sure each test is going to be slightly tweaked for the platform they are tested on. Since each platform has its own nuances that you have to take into account.

Upvotes: 1

Related Questions