I am wanting to port a C# Mobile App for Windows 8 tablets using Xamarin. One of the issues we foresee is the use of MEF. Does Xamarin.iOS support MEF?
It depends on what you mean by MEF support. Using MEF assemblies is possible using Xamarin.iOS. What's not possible (iOS restriction) is dynamically loading code in your application (e.g. plugins).
You might be able to use MEF while ensuring there's not dynamic code being loaded, i.e. that everything is statically referenced and built inside a single binary executable (e.g. by ensuring every plugin is built-in).
Depending on your application that could prove useful (no, or less, need to modify your existing application) or not (if your app can't load/be built with all plugins). In the later case your problem is with iOS itself (not Xamarin).
Related
This should not be so difficult!
In normal C++ one can write static or dynamic libraries that can be used in multiple application projects. I want to do the same thing for UWP apps using C++/winRT.
I have written a simple C++/winRT UWP app that discovers Bluetooth Low Energy Devices. I used the Core UWP project template that set up all that pch.h stuff. What I want to do is to make a library out of the code I wrote that did the Bluetooth work so it can be shared across many UWP apps but I have no idea which project template I should use to do that.
I have come to the conclusion that writing a Windows Runtime Component is not what I want. I am not making a run time component though I need to use runtime components for the Bluetooth.
In the end I will be calling that library from a Java application but that's off in the future.
All my problems would be solved if they had a Java/winRT option (a Java language projection in Microsoft-speak).
Note that the project selection interface in Visual Studio 2019 must be very different than 2017 as none of the demos I have seen online look like what I see.
I need to consume a library that doesn't yet have CoreCLR support (RabbitMQ.Client, to be specific). Is it possible to utilize a mono-based port of that library on a Linux system from inside a CoreCLR executable? If so, how is that achieved?
It is impossible at binary level (unless using a proper PCL profile). .NET Core has a different approach to arrange classes in assemblies, so some assemblies on desktop .NET Framework are broken into smaller assemblies, and types are moved. A desktop targeting assembly (from .NET or Mono) won't work on .NET Core due to such changes.
But it is obviously possible at source code level, as there was an attempt to port Mono's WinForms to .NET Core,
http://forums.dotnetfoundation.org/t/anyone-porting-winforms-mono-to-net-core/898/4
Once a new .NET Core library project is created, the source files should be able to be carried over (with some modification or even none).
However, .NET Core has been evolving too fast, and that attempt might be now out of date. Anyone would like to explore in this area can follow that example and try once again. Good luck.
I am trying to build a project using NDK media sdk, but I need it to run on older phones too (to support 90% of the market...). Now, I am able to include the libmediasdk.so & libOpenMAXAL.so manually, and it seem to link properly, but I am not sure this is a correct practice.
Moreover, the libraries (libmediasdk.so & libOpenMAXAL.so) are expected to be available on the target device, so unless I do copy them manually to the project/libs/arch-arm the application complains libraries are not found.
Have I gone too far ? :) hope not..
You can write code that optionally uses the new native media functions (libmediandk.so), but you can only use it on Android 21+. So if you want to support older android versions, you must make this codepath optional, allowing it to fail cleanly on other devices where libmediandk.so doesn't exist.
If the MediaCodec APIs are optional within your app and you are ok with them only being available on Android 21+, you can just make sure you build this into a separate lib (like libyourapp-media.so), and be ready to handle the case when System.loadLibrary() for this library fails.
However, if you want to use other native code components in your app, there's a few gotchas you need to know. If you build your app targeting android-21 and your native code uses certain functions (such as atof), it will only run on android-21 or newer (even if code using the function atof would build just fine for the older platforms). The reason for this is that the atof function didn't exist before, and calls to it were redirected to strtod. If you build your library targeting android-21, it will actually do the calls to atof instead, which doesn't exist in the older platform versions. This also goes for quite a number of other functions, not only atof. See http://b.android.com/73725 for details on this.
Therefore, if you want to use the new native media APIs in a library that should be loadable on older versions (except for the native media APIs that obviously won't work on older versions), you need to build your native components targeting an older android version. You'd need to duplicate the media/* headers from android-21, but instead of linking to libmediandk.so (-lmediandk in LOCAL_LDLIBS), you'd need to load this library at runtime using dlopen.
If you need to do the same on older platforms as well, you should use the MediaCodec API in java (which you can call via JNI). Then, there's little point in doing all of this extra work just to use the native version of the API on Android 21+, when you can use the java API on all versions (it works from Android 16, and more reliably since Android 18).
I have existing iOS and Android native apps. Is it possible to extend the apps with Xamarin coded part ?
Both Xamarin.iOS and Xamarin.Android are currently setup to take control of your application, so you need to make your main program be written in C# and then call into the existing code.
The way that you would do this is to bind your existing Objective-C or Java code as C# libraries, and then consume those libraries from C#. The binding technology is precisely what drives both the Xamarin.iOS and Xamarin.Android tools, so you would effectively be doing the same.
Once you have bindings, the interoperability works both ways: you can call native code, and native code can call C#.
The bad news is that instead of starting to enjoy writing code with both tools from day zero, the first thing you have to do the bindings, which is in general, not as fun as watching colored squared move on your screen.
Ok I find an answer here : http://www.whitneyland.com/2013/05/why-i-dont-recommend-xamarin-for-mobile-development.html
For example, code written in Xamarin cannot be used in native or HTML5
apps.
I'm working on WinRt version of my class library dll. Finally, after the huge "code cleanup" my project is on building step and I have two ways. To build the solution with Release|AnyCPU as usually or build it with Release|ARM (Which unclear for me). Which dependencies my dll will get or avoid in process of building, what will be different, will there a specific IL optimizations on a second way?
If you're only using managed code, there's no reason not to use Release|AnyCPU. This way the same package will be used for all three platforms (ARM, x86 and x64).
On the other hand, if your project references natively compiled library, you'll need to set a specific platform, like Release|ARM, that your native library is compiled for. If the native library is installed as an extension (e.g. SQLite for Windows Runtime), you'll be able to compile your app for all 3 target platforms, each one referencing the appropriate native library, though they will need to be individual packages instead of a single universal one.
You'll still be able to submit your app to the store as a single app even if it has 3 separate packages, one for each platform.