The MobileFormatter can only deal with types that implement IMobileObject. List<T> doesn't implement that interface.
However, CSLA .NET includes several base classes for objects, lists and dictionaries that do implement the correct functionality. Though I don't know for sure that we handle a list of lists - you'll have to try and see.
Check out the "MobileXyz" types in Csla.Core - what you want is MobileList<T>.
The reason this is necessary is because private reflection isn't possible in Silverlight. Serializers normally rely on reflection to do their job. Without private reflection you can't write a normal serializer (which is why there's no BinaryFormatter or NDCS on Silverlight).
The MobileFormatter avoids the reflection issue by requiring that the objects to be serialized participate in the process. Basically it just asks each object to serialize/deserialize its own state, thus avoiding private reflection. MobileFormatter does know how to handle primitive types all by itself.
The drawback, of course, is that it can't serialize types that don't participate...
The reason this is necessary is because private reflection isn't possible in Silverlight. Serializers normally rely on reflection to do their job. Without private reflection you can't write a normal serializer (which is why there's no BinaryFormatter or NDCS on Silverlight).
Is this still the case for WinRT? If WinRT will supports private reflection then are we going back to whatever serializers ship with WinRT?
I realize that WinRT is still a work in progress and that nothing is for sure but I can't help wondering if WinRT is heading into being just as powerful as WPF or if its going to be yet another framework or full of limitations like Silverlight.
Thanks.
Based on everything we know at this time, WinRT is at least restrictive as Silverlight.
This means the value of improving MobileFormatter is higher than ever, because it will probably become the primary serializer for a lot of applications, and eventually nearly all applications.
The problem with full .NET is that people can use it to create malware. Same with full Win32.
WinRT attempts to solve this by ensuring that all apps run in a sandbox, and that obvious dangerous things (like unrestricted private reflection) aren't available.
I don't think twice about downloading an app on my Windows Phone. People don't think twice on an iPhone either. Sane people think several times before downloading an app on their Android device, or onto their PC. And for good reason - those platforms aren't inherently safe, and the apps being downloaded haven't been screened.
As developers, geeks, and hackers we might find these constraints annoying. But as a consumer I rather look forward to the idea that my worst fear is that an app is stupid or useless, not that the app is going to be malware that takes hours of work to eliminate from my computer.
Copyright (c) Marimer LLC