We have a shared PCL that uses the Xamarin.Mobile dll to read contact's from a user's device and show a subset of them in our application. Because the Android and iOS versions of the dll are different we are required to reference both in our shared PCL and then the OS-specific versions in their respective projects. The issue is that you cannot reference two dlls with the same name.
Is there a way to reference both dlls in the shared PCL using some kind of alias? Or is there a better way to implement this so that we can access contacts on different devices using Xamarin.Mobile in the same solution?
You will be better off referencing Xamarin.Mobile in your platform specific projects:
Reference Android Xamarin.Mobile (dll) in your Android project
Reference iOS Xamarin.Mobile (dll) in your iOS project
If you want to abstract that functionality into a shared PCL, you can do so using a shared interface and injected (dependency injection) platform specific implementations.
Related
Why there is a Class Library in Xamarin in iOS section "Class Library(iOS)" and what is difference between "Class Library(iOS)" and PCL Targeting Xamarin.iOS
Why we need this and what are the pros and cons
A Class Library is a project that creates a DLL file targeting a specific platform. An iOS Class Library creates a DLL for consumption by Xamarin.iOS projects only.
A Portable Class Library (PCL) is a library that can target multiple platforms, including Xamarin.iOS and Xamarin.Android, as well as Windows Phone and other .NET platforms.
If you want to share code between multiple platforms, you would use a PCL. If you are only interested in a single platform, use a platform specific class library.
We're creating a webservice with ServiceStack (current v3-fixes branch) and another company is programming an Android and iOS App against it.
My DTOs are (of course) in separate assemblies and compiled against .Net Framework 4. I can use these assemblies without problems in .Net projects and also in the Xamarin.Android project. The other company now told me, that they are not working in Xamarin.iOS.
They are using the latest (precompiled) ServiceStack.MonoTouch dlls with version 3.9.55. I read somewhere that I have to compile my DTOs against the MonoTouch version of the ServiceStack dlls.
Is this correct and is it possible to do this in a windows environment?
Thanks in advance
Steffen
Yes this is true you will need to compile your DTO's against the MonoTouch version of the ServiceStack dlls. The reason for this is because Xamarin.iOS does not support the full desktop version of the .NET assemblies. Rather it is a subset of them, much like the Silverlight platform. See here for more information.
Note: Xamarin.iOS is not ABI compatible with existing assemblies compiled for a different profile. You must recompile your source code to generate assemblies targeting the Xamarin.iOS profile (just as you need to recompile source code to target Silverlight and .NET 3.5 separately).
While Xamarin does have a Visual Studio plugin, Xamarin doesn't support Xamarin.iOS without a Mac OS X environment. There are services online where you can hire remote Mac OS X systems.
I'm creating a cross platform set of applications, and some of the assemblies are constructed as multi-file assemblies using a set of modules compiled under visual studio 2010. Does the monotouch compiler support multi-file assemblies like these?
You can create a MonoTouch Library project to do this, however you will have to compile the library for MonoTouch.
To do this properly, here is an example:
On Windows create 2 projects MyApp and MyApp.Code (a class library project)
On iOS create 2 projects MyApp and MyApp.Code (a MonoTouch library project), in a different folder in your source control, of course
Put all the code into MyApp.Code (Windows version), on iOS "Link-In" every file you want to add the to the project from the Windows copy. This keeps one copy of the file, but allows you to compile for multiple platforms
MyApp will just contain UI-specific code on both platforms and is completely different on both platforms
Add #if IPHONE or #if WINDOWS preprocessor directives anywhere you might need them throughout the MyApp.Code project
Rinse and repeat if you want to do the same for Mono for Android, Windows Phone, etc.
I need to extend the functionality of the android.hardware.Camera class and so I have written my own class and companion JNI library to meet my needs. If I place my JNI code and Android.mk file in the Android source tree and build the OS, my library builds and I can use it and the Java class in an application without any problems (on an evaluation module at least).
The problem is that I would prefer to build my JNI library with the NDK but I need several libraries that are not in the NDK (e.g. libandroid_runtime and libcamera_client).
Is it possible to use the NDK to access hardware such as the camera? If so, what is the proper way to get access to OS libraries?
You can access non-standard shared libraries from NDK, but that is undocumented and is not guaranteed to work on different devices. Vendors like HTC, Samsung and other can simply implement them differently.
Only proper way how to use functionality not available in NDK is to wrap it with Java classe/functions, and then use them from native code.
I'm all about code reuse. One of the best ways in .NET/Mono is to create a class library. I have a few custom UIViews that I would like to place in a class library (.dll) so that I can redistribute it but for some reason I am not able to create a project that references monotouch from a stand-alone library. The only way to reference it is to create a full blown iPhone project -- not what I want.
Any help would be appreciated.
Under MonoDevelop project types C#->iPhone and iPad, I have
iPhone Window-based Project
iPhone OpenGL Project
iPhone Navigation-based Project
iPhone Utility Project
MonoTouch Library Project
Empty MonoTouch Project
iPad Window-based Project
Universal Window-based Project
You want MonoTouch Library Project. This will compile a DLL that can be referenced in another MonoTouch project.
I know this works because I have 2 projects that reference a DLL I created just for the benefit of reusing code.