Two Core Classes That You Must Maintain in an MvvmCross Forms App - PeterBurke/MvvmCross-Forms GitHub Wiki

There are two core classes that you need to write in your App to gain access to the MvvmCross-Forms framework. They cannot be provided via a NuGet package, however if you start your App by cloning one of the Samples, these classes will already exist, but you may need to modify them.

In the above diagram we see the anatomy of an MvvmCross-Forms App. The two core classes have been shaded.

Starting from the bottom left we have the "NATIVE APPLICATION". This coding varies dependent on which native operating system it sits. In our examples this coding was contributed originally via the Xamarin Visual Studio Template.

The Setup class is actually a subclass of one of the Mvx???Setup classes provided via linking to our NuGet package. There is one of these classes for each target platform, e.g. MvxTouchSetup, MvxDroidSetup, ...

The up arrow indicates that the native application will make calls to the Portable Class Library and remain in there for the life of the Application.

The shaded App class lives in the PCL and contains a constructor and an Initialize method. We will return to those shaded classes below.

When the PCL MvvM needs to do something external like drawing on the screen, it does so by calling into additional PCL's provided by Xamarin, MvvmCross and other providers such as SQLite. When one of these needs to do something at the operating system level it must make a call into a native library again provided by Xamarin, MvvmCross, ..., as shown in the lower right.

These additional native libraries cannot be linked at compile time as that would create a circular reference. The way out of this is to make these reverse path assemblies expose an interface and then link to the interface at compile time. The actual linkage in then made concrete via an Inversion of Control container, of which MvvmCross provides. These native assemblies can then, given permissions, access the services provided by the native platform.

The Setup Class

    public class Setup : MvxAndroidSetup
    {
        public Setup(Context applicationContext)
            : base(applicationContext)
        {
        }

        protected override IMvxApplication CreateApp()
        {
            return new App();
        }

        protected override IMvxTrace CreateDebugTrace()
        {
            return new DebugTrace();
        }

        protected override IMvxAndroidViewPresenter CreateViewPresenter()
        {
            var presenter = new MvxFormsDroidPagePresenter();
            Mvx.RegisterSingleton<IMvxViewPresenter>(presenter);

            return presenter;
        }
    }

This is very low maintenance coding. The CreateApp method is what creates an instance of the App : MvxApplication class in the PCL. The CreateViewPresenter method instantiates a singleton instance of the PagePresenter, a native component, and registers it with MvvmCross so the PCL will be able to access it using IoC.

One small complication that applies to Android only is that Android has a splash page shown once only at startup and for Android you need an additional class "MvxFormsApplicationActivity" to handle the Splash page.

The App Class

    public class App : Cirrious.MvvmCross.ViewModels.MvxApplication
    {
        public override void Initialize()
        {
            CreatableTypes()
                .EndingWith("Service")
                .AsInterfaces()
                .RegisterAsLazySingleton();
				
            RegisterAppStart<ViewModels.FirstViewModel>();
        }
    }

The sole purpose of this class is to provide the Initialize method that registers things with MvvmCross. Firstly it looks for assemblies that have names ending with "Service" and registers them. MvvM Services that are commonly used in Applications include SQLite, Restful Web Service, Calculation, WebBrowser, Text Messaging, ...

Our very first example has no Services, but all Applications must have a RegisterAppStart method to provide MvvmCross with the name of the first ViewModel to navigate to.

MvvmCross also provides many other things may register here, for example a replacement for the simple convention relating ViewModels to Pages.