Child containers in MvvmCross IoC

I have a WPF MVVM application that I'd like to refactor to use MvvmCross to support a WPF and Mono for Android implementations.

Currently we are using Unity 3.0 for dependency injection and rely on its support for container hierarchies (one main container w/ the main view and view model and services; and for each session with a server a child container with views, view models and services that have a limited lifetime). Can the IoC in MvvmCross support child containers? If not, how would you recommend implementing external IoC that does in a manner that is compatible with MvvmCross?

Update: We don't need to support multiple child containers-- just a single child container is active at any one time.

Thanks!

The MvvmCross framework as it stands today is mainly targeted at 'mobile' and 'tablet' development. In this area there aren't many situations I've encountered so far where you need multiple containers - so the framework has adopted a simple single container approach.

If you do want/need multiple containers, then MvvmCross is designed so that everything can be overridden if you want to. So if you want to override the IoC library used, then you should be able to use any PCL IoC container (or inject different native ones). For each of these you will need to provide an Adapter for our IoC interface - see IMvxIoCProvider.cs

In addition to this, whilst I don't fully understand your current needs (I understand code better than text!), then other possibilities which might suit your particular problem area include:

you could always leave the current MvvmCross container in place for MvvmCross objects, but use a separate IoC system for your classes. While slightly out of date, this blogpost about creating a custom Custom ViewModelLocator helped @gshackles along the way to using TinyIoC and constructor injection - see what he built in https://github.com/gshackles/CrossBar
the MvvmCross container allows you to replace resolvers if you need to - i.e. if you have one type registered for the interface IMyService, then registering a second type will replace the first.
you could register a second IoCContainer with the main MvvmCross container - doing this you could then provide your child objects via that second container. This might not be perfect constructor injection, but should allow you to closely control child container lifecycle
with some small changes (inheritance), you could easily create multiple copies of the current 'simple' MvvmCross container - the only thing that currently forces this object to be a singleton is its inheritance.
with some small changes (virtual added to the interface methods), you could also consider inheriting from the SimpleContainer to override functionality and to provide multiple resolver dictionaries.

Overall, I think you should have plenty of options for this... One thing to watch out for, though, is to make sure you understand the lifecycle of your containers on each application platform. WPF lifecycles are easy - apps start, apps exit - but WindowsPhone, WindowsStore and Android apps can be launched in different ways (shortcuts, tombstoning, search, etc)