What contraints should I be aware of to maximize portability of Mono code?_问答_开发者

I'm interested in writing some cross-platform code using Mono, with a view to targeting mobile iOS and Android runtimes.

I've perused the Mono and MonoTouch sites, but don't see anything that specifically advises on methods not to use, or Mono hooks which should be avoided. However, that seems a little too good to be true.

What limitations should I be aware of going into this project, to ensure maximum portability of the 开发者_JAVA技巧code?

API wise you get a very similar base class libraries (BCL) when using MonoTouch or Mono for Android (M4A) since both share the same mobile profile (which was originally based on the Silverlight profile and enhanced to use more FX 4.0 API).

That's a lot of common code. Differences in the BCL are minimal but some do exists, mostly because running on iOS devices requires some compromises, which creates some limitations.

Outside the BCL both MonoTouch and M4A provides bindings for their platform. E.g. MonoTouch provides monotouch.dll which binds most of the iOS (C-based or ObjectiveC-based) API. That part won't work on Mono for Android (and the same is true for the Android bindings that M4A provides).

That's where you need to come up with a design to minimize the differences. In many cases the most different aspect is the user interfaces and there are a few approaches, many of them are based on MVC (e.g. MonoCross) to make this easier on developers while enabling a native look-and-feel for every platform.

In addition to UI, get in the habit of ensuring that external dependencies have variants that function across all your desired platforms, or be ready to factor them out.

For me, the pitfalls were:

Compression - Not available in silverlight, user sharpziplib if needed (I know you're not targetting silverlight, but just in case.)
Serialization - Protobuf-net is your friend.
Storage - This is the trickiest. Are you using regular IO, or isolatedstorage, or one thing on one platform and something else on another? Also, mono.sqlite works just about everywhere except on silverlight, so go with that and have a contingency plan for silverlight, if needed.
Invented at MS - Forget about this stuff. WCF, entity framework, SQL-CE, LINQ to SQL, and on and on. Mono does the core .NET stuff perfectly, but is very patchy about the peripheral technologies, which IMO are not of much value anyway.

That being said, I found portability to be amazingly painless. In fact it was so good that I was able to move code intended for the desktop over to mobile in just a day or two, though after that I had to spend quite a lot of time optimizing. Just because code is portable doesn't mean that it will perform identically on all platforms! I think its best to do the green-field coding on the most performance-sensitive platform, which, IMO, is monodroid as that has the complications of JIT on a mobile device, cross-VM garbage collection, and so on.

Have you tried the Mono Migration Analyzer (MoMa)? It's not the ultimate solution but it might ensure you decent portability across Mono runtimes.

I've done some cross-platform .Net coding using MonoTouch (iOS), Mono for Android and Silverlight for Windows Phone 7. I found that a good approach was to base my code on the Silverlight runtime since most of this is supported on Mono as well.

If you only want to target iOS and Android then the main difference between them is the UI. As long as you stay away from anything UI related then your code should run well on both platforms.

There is one major difference between the platforms: On iOS your code is pre-compiled, so there is limited support for reflection. Most of the stuff works fine, but you should be careful with using code heavy on reflection on iOS.