Reputation: 68750
We've begun to build Cross platform Android/iOS apps
, having built exclusively in MonoTouch before. We're evaluating MonoDroid
.
Our apps need to consume JSON
and we'd like to use ServiceStack
. Xamarin has a ServiceStack branch which we're using - https://github.com/xamarin/ServiceStack
We'd like to have a common project responsible for GETting and POSTing JSON. ServiceStack by Xamarin has different DLLs for Android and iOS
. How do we have a single project
and use ServiceStack to get at our JSON?
We're open to other options to get at JSON in a unified way?
Upvotes: 4
Views: 477
Reputation: 43553
The reason why there are MonoTouch and Mono for Android specific libraries is often because of the (smaller, Silverlight-like) profile available (e.g. things that depends on new FX4.0 features needs to be cut out). They are often the same code re-compiled with SILVERLIGHT
(or MONOTOUCH
, MONODROID
) defined.
The reason for MonoTouch only specific librairies are generally because its environment (iOS devices) do not allow JIT'ing. So there's no code generation (e.g. System.Reflection.Emit
) or dynamically (down)loading code... However it's often possible to provide (less performant) workarounds or skip a few features and keep a special version of the library for MonoTouch.
Now back to having a single shared assembly/project. The special MonoTouch assembly (generally the same code re-compiled with MONOTOUCH
defined) is still a valid .NET assembly and often can be used in Mono for Android, Mono or .NET (once recompiled, even with MONOTOUCH
). It's definitively not optimal but it's something you can try.
Another one is having the same projects (e.g. MyLib), across several solutions (e.g. MonoTouchApp, M4AndroidApp) and use special configurations (just like there's an iPhone|Debug one) to set different defines (e.g. MONOTOUCH
on iPhone*|*). That can allow you to keep the best feature implementation in each platforms (e.g. in case the same feature is implemented differently).
I would try the later first (config), then sharing the MonoTouch special assembly and finally (if it really does not work) look for other alternatives.
Upvotes: 3
Reputation: 3134
By and large, managed *.dll's compiled for MonoTouch that don't have a dependency on MonoTouch specific types are compatible with Mono for Android projects.
ServiceStack is a great example of this. I've personally used it for multiple projects across the Xamarin mobile framework offerings.
As a general rule I tend to encapsulate all invocation to my web services using a partial class with async methods, like FooProjectRestClient
. And then if there ever is any sort of segmentation that needs to occur it can happen in a shared class using #if defs.
Upvotes: 4