Navigation in Windows Store apps is strongly based on the browser model, i.e. the application is keeping a back stack of previously shown pages which will be traversed again when navigating back. but there are some cases in which you don't want the user to navigate back to a specific page in the history. There's no such built-in functionality available in MvvmCross, but it's really simple to add it with the right approach.
I'm developing an application in MvvmCross, using SQLite for local data storage. I'm taking advantage of MvvmCross SQLite-Net plugin. Recently I stumbled across a very strange behavior, involving a fairly simple table with a DATETIME column. It turns out, SQLite's handling of DateTime values is quite strange.
The best resource on the subject of testing navigation in MvvmCross view models that I managed to find, was Slodge's blog post from almost two years ago. While it still contains useful guidance for today, there have been changes in the framework. After I got it to work in my own project I decided to publish a more up-to-date set of instructions here.
Most of the time there's no need to use an IoC container in unit tests. Still, testing the IoC container configuration makes sense in an application to avoid runtime errors which will occur when not all required dependencies for the created object are registered in the application beforehand. This doesn't necessarily mean, the right implementations are being used for all dependencies, but that's not what we want to test.
In sqlite-net only the first statement in a command is actually executed. The remainder is silently ignored. In most cases you won't notice that when using sqlite-net. You will either use its micro ORM layer or execute individual statements. The only common exception that comes to mind, is trying to execute DDL or migration scripts which are typically multi statement batches.
A great side effect of view models being implemented in portable class libraries when using MvvmCross, is the ability to unit test them on any platform, not necessarily the one you are targeting. So even when developing a mobile application, you can test it in full .NET framework and take advantage of all the tooling available there.
Although MvvmCross allows creating portable converters which can be used on multiple different platforms, they can still only return types which are also portable. Of course there are cases when it is desirable for a converter to return non-portable classes such as Visibility, Brush or BitmapImage on Windows platforms. The basics are probably already covered by MvvmCross itself; it includes visibility and color converters which can be used on all platforms. Still, there will always be other native classes you will need.
MvvmCross is a MVVM framework for XAML platforms, similar to Caliburn Micro and MvvmLight. Unlike its competition it very much focuses on portability and code reuse across all supported XAML platforms (WPF, Windows Phone and Windows Store), and the Xamarin platforms as well (Xamarin.iOS, Xamarin.Android and Xamarin.Mac). Therefore it has its own approach to creating converters, allowing them to be implemented in a portable class library and reused on all supported platforms.