How do I initialize the MvvmCross framework withou

Question

In my app I am creating a broadcast receiver which will listen for network changes. In the OnReceive it will check whether the device has just connected to WiFi and then start uploading in the background. No Activities will be shown so what do I need to do to initialize the framework without a splash Activity? I won't need any of the page navigation parts of the framework so a stripped down initialization would be optimal.

    private override void OnReceive(Context context, Intent intent)
    {
        bool isWifiConnected = false;
        bool isMobileConnected = false;

        if (intent.Action.Equals(ConnectivityManager.ConnectivityAction))
        {
            NetworkInfo networkInfo = (NetworkInfo)intent.GetParcelableExtra(ConnectivityManager.ExtraNetworkInfo);


            if (networkInfo.IsConnected)
            {
                if (networkInfo.Type == (int)ConnectivityType.Wifi)
                {
                    isWifiConnected = true;
                }
                if (networkInfo.Type == (int)ConnectivityType.Mobile)
                {
                    isMobileConnected = true;
                }
            }
        }

        if (isWifiConnected)
        {
            StartUp(); //What do I put in this private method?
        }

Answer 1

I have now pushed some changes to GitHub which should hopefully enable you to create your app with its BroadcastReceiver.

Using these modifications, you can now initialize the core application from any Application Component - Activity, BroadcastReceiver, Service or ContentProvider - using code like:

var setup = MvxAndroidSetupSingleton.GetOrCreateSetup(this.ApplicationContext);
setup.EnsureInitialized(this.GetType());

These changes should enable an MvvmCross application to be started in "the Intent.ActionMain" scenario, as well as in the situations:

• when a secondary Intent within the application manifest is requests
• when a Service, BroadcastReceiver or ContentProvider component is requested
• when a restart is requested because the Android OS has previously purged the app out of memory, but the user has now requested the app back in (a bit like hydration after tombstoning in WP7)

---

A more lengthy explanation of these changes is http://slodge.blogspot.co.uk/2012/05/android-application-initialization-and.html

Answer 2

UPDATE

I'm leaving this answer in place only as it's a good record of our conversation and how we came to this current understanding. My other answer provides (I hope) a solution...

---

I've got to be honest and say that it doesn't sound like this particular app or part that you describe needs an MVVM framework?

It feels to me like this might be built as "raw MonoDroid"? Perhaps you could even do this as an Android service?

What is it you want from a framework in this situation? - e.g. is it just an IoC container? In which case you can initialise that yourself without worrying about MVvvm Or is there something more that you are looking for?

---

If you do feel you want a minimal framework booted, then one option might be to take a look at the SimpleBinding examples - like https://github.com/slodge/MvvmCross/tree/master/Sample%20-%20SimpleDialogBinding/SimpleBinding/SimpleDroid

These "simple" apps use an MvxSimpleAndroidBindingSetup setup routine which doesn't create a full "application" - I'm not sure if this is exactly what you are looking for?

One problem you may find in these type of apps is if you use any code which expects to be used in an apartment threaded way - when you start building View and ViewModel aware code, then it's not unusual for some bits of code to expect there to be a UI Thread available. You should be able to work around this - but just be aware of it when designing and debugging your code.

---

As another alternative, consider subclassing Android.App.Application within your MonoDroid project - http://developer.android.com/reference/android/app/Application.html

This Android Application can then do a kickoff a first stage of Setup within its OnCreate - this should be the minimum required for the broadcast receiver to work - a modified SplashActivity could then kick off a second stage - the rest of the code required for the full app to work.

You may find that you need to adjust your Setup.cs and your MvxApplication App code, and that you may need to use a different base class for your splashscreen Activity - instead of MvxBaseSplashScreenActivity.cs. What's important is that something somewhere in your app:

• creates a Setup instance
• calls the necessary Initialize methods on that Instance
• triggers the IMvxStartNavigation.Start() when "normal app" operation is required
• allows the broadcast receiver to operate when this "other" operation is required
• allows for both operations to sit in the same memory space - e.g. what happens if a broadcast receiver is invoked while the "normal app" is running?

Looking at the Android documentation again now, I think we will need to change a bit of mvx to better support this scenario in the future - and also to better cope with rehydration scenarios - where activities are rehydrated after the android equivalent of tombstoning.

---

I think this is destined for https://github.com/slodge/MvvmCross/issues/new - if you can provide an simple demo app then that would be great...