Autofac SingleInstance() and Xamarin Forms

To start, let me say that I have read several questions here about SingleInstance, but still cannot find a direct answer that helps me. That said, I apologize if I missed anything.

Here's my question:

I am building a Xamarin Forms app for iOS and Android. I have a single AppInitializer class in a PCL where I register all of my interface dependencies using Autofac. I then assign the Container from the builder as a static property on the app class. The problem I encounter is that while I'm registering everything with .SingleInstance(), I'm not actually getting a single instance.

Init Logic Example:

var builder = new ContainerBuilder();
builder.RegisterType<ErrorHandler>().SingleInstance().As<IErrorHandler>();
…
builder.RegisterType<MemberViewModel>().SingleInstance().As<IMemberViewModel>();
…
AppContainer.Current = builder.Build();

I am letting Autofac handle resolving interfaces in my constructors. For example:

public MemberViewModel(ISettingsViewModel settings, IErrorHandler errorHandler, …) : base(settings, errorHandler){…}

I then use said model on a page as below:

Example page usage:

public ProfilePage()
{
     InitializeComponent();
     var displayModel = Model.CurrentMember;
     …
 }
 …
 **public IMemberViewModel Model =>
 AppContainer.Current.Resolve<IMemberViewModel>();**

In this example I set Model.CurrentMember's properties immediately before arriving on this page. I've set breakpoints and know for a fact this is happening. However, when I resolve the instance of the model, the properties on CurrentMember are null.

Am I doing something wrong here or have I encountered a bug?

-Edit- Made it clear that I'm using Autofac.

-Edit 2- Adding more detail.

My implementation of the IMemberViewModel class has various properties on it, including an observable object called current member. It is declared as below:

 public class MemberViewModel : ViewModelBase, IMemberViewModel
 {
  … 
  (see constructor above)
  …
  public MemberDisplay CurrentMember =>
        m_CurrentMember ?? (m_CurrentMember = new MemberDisplay())

On the implementation of IMemberViewModel I have a method that sets the various properties on CurrentMember.

The order of operations is this:

The end user taps an image for a member. This fires a command on the (theoretically) singleton instance of the IMemberViewModel implementation. This command executes an async task that awaits an async call to the API to load the data for that member. After that data is loaded and the properties set on CurrentMember, the app navigates to the profile screen. The profile screen resolves IMemberViewModel (per above).

Expected Behavior: The properties on CurrentMember from the resolved instance of IMemberViewModel are set to the values that have just been set from the load data method. This expectation arises from assuming that there is a single instance of IMemberViewModel.

Actual Behavior: The CurrentMember's properties are at their default values, i.e. string.Empty, 0, null, etc.

The odd thing here is that this doesn't happen to every model. I have a message model that I am resolving in the same manner on the same screen and it seems to be fine.

Solution

This issue turned out to be caused by the way we were going about initializing everything. For posterity's sake, I will give a brief breakdown of what was happening and what I did to prevent it.

Previous App Flow:

App opens & constructor is called. This calls into the initialization routine above.
User logs in.
First instance of IMemberViewModel resolved using static container.
A message pops up asking the user for Push Notifications Permissions
When this happens, the app OnSleep is called (iOS)
After the user selects an answer, OnResume is called.
OnResume calls initialization routine
New container created.
Call to load data happens on old container, new pages reference new container.
Issue arises as described above.

Correction to the flow:

First, from what I can tell the init calls do not need to be made on resume and/or start if made in the app constructor. If the app is "killed" because other apps need the memory space, a fresh version of the app will be created on next launch (see the Android Activity Lifecycle and the iOS App Lifecycle).

Second, because I'm paranoid and because it can't hurt, in the app init routine I am now checking to determine whether the container exists and whether the interface is already registered.

public static void Init(ISetup setup)
{
    if (Container != null && IsModelRegistered()) return;

    RegisterDependencies(setup);
    …
}

private static bool IsModelRegistered()
{
    return Container.IsRegistered<IMemberViewModel>();
}