I am using System.Drawing.Common (https://www.nuget.org/packages/System.Drawing.Common/) package in .NET Core application to create bitmap image using GDI+. When I use the same package in Xamarin application which throws PlatformNotSupported exception.
Is anyone know when Xamarin support will be provided for this package?
I don't think it will ever be supported. GDI+ is very specific to the Windows platform. If you need any drawing library, you could have a look at SkiaSharp, which is supported by Xamarin.
You can replace System.Drawing.Common with Aspose.Drawing that has the same API and truly cross-platform. (I'm one of the developers.)
Related
Currently, we are developing a .NET Standard class library that will be used by different Xamarin.* platforms.
I was wondering if there is a way to use the shared code in a native Android project (maybe produce an AAR/JAR file).
The reason I need this functionality is because our company provides an AAR to one of our customers (that is used by a native Android project), and we would like to keep a single source base instead of two.
Thanks in advance!
Update:
The name changed to ".NET Embedding" and it is at v0.4 at the time of this update.
https://developer.xamarin.com/releases/dotnetembedding/dotnetembedding_0/dotnetembedding_0.4/
New instructions:
Installing .NET Embedding
Original post:
You can use Mono's Embeddinator-4000
It supports various language consumers, so it surfaces .NET code as idiomatic code in the target language. This is the list of supported languages at present:
Objective-C: mapping .NET to idiomatic Objective-C APIs.
Java: mapping .NET to idiomatic Java APIs.
C: mapping .NET to an object-oriented like C APIs.
Embeddinator-4000 is a tool that allows your existing .NET Code (C#, F# and others) to be consumed from other programming languages and in various different environments.
Java is currently in a preview state for macOS, Windows, and Android.
The platform is selected by passing the --platform= command-line argument to the embeddinator. Currently macOS, Windows, and Android are supported.
re: https://mono.github.io/Embeddinator-4000/
As a part of the requires For Android you will need Xamarin.Android 7.4.99+ and Android Studio 3+ (Java 1.8) but if you are building Android apps with Xamarin and Java you would have those already.
Note: This tool is in Preview, so review the open issues and post new if needed.
re: https://github.com/mono/Embeddinator-4000/issues
Note: This is not trans-compiling, but embedding Mono's runtime in a native package that allow CIL code, AOT'd (i.e. iOS) or not to run within a different language/runtime.
We are getting following exception when we try to call storagefolder.getfilesasync() method in Xamarin Forms UWP enviornment.
is ther any alternative to that?
I suspect the reason is that you are trying to use files inside the shared Portable Class Library. Because this library is shared across UWP, Android and iOS, you can't use Windows specific StorageFile there.
To work around this, you will need to create an interface for file access and implement it for each operating system separately. Working with files is very well described in Xamarin Documentation.
I need to implement a dead reckoning application using xamarin. In order to do this, I need to access the pedometer/accelerometer from Android/ios and windows phone. Since they have their own APIs to be called, I believe the approach would be to create an interface in the PCL project and then have native implementations for each platform. These could then be made visible using assemblies. Apart from this, are there any approaches using which the entire code can be implemented in the PCL project itself? Without having native implementations for each platform?
The logic of your app can be done in the PCL but calling the pedometer or accelerometer must be done natively.
The basic approach is (just an example)
public interface IPedometer
{
int GetSteps();
}
and this interface is in your PCL.
On each native platform create a class (e.g. NativePedometer), implement this interface and natively code to get the result.
Use dependency injection on each native platform, e.g.
DependencyService.Register<NativePedometer>();
Then just use the below in your PCL.
DependencyService.Get<IPedometer>() and perform the business logic in your PCL. This allows you to reuse as much code as possible across platforms.
It is the best approach but you can't avoid writing native code and by native code I mean C# in the traditional/native Xamarin projects.
I am developing an application using xamarin.android, xamarin.ios and windows phone 8.1 silver light. I am using an encrypted data and want to decrypt data in PCL project. For encryption AesCryptoServiceProvider class has been used. I want to decrypt my data in PCL project but not found any library for doing this. The above mentioned class is worked well in Android and ios project but I am not be able to use in windows phone project. Any help regarding this is much appreciated.
Thanks in advance
Dependency injection/IoC is your friend. Basically you would implement an interface in PCL and implement it at OS level with whatever type is there that does the job.
Have a look at PCL Crypto. It probably supports the functionality you need.
I need to work with some bitmaps in managed code and save them as PNG files. Should I use Microsoft.WindowsAPICodePack.DirectX.WindowsImagingComponent, or System.Windows.Media.Imaging? They both seem very similar, and I'm not sure why I would choose one over the other. Can anybody compare and contrast them?
They both use WIC, that's why they are so similar. The Windows API Code pack is retired content, you'll want to use the WPF namespace since it is available on .NET 3 and up and doesn't require a separate install.
Microsoft.WindowsAPICodePack.DirectX.WindowsImagingComponent is in the Windows API Code Pack, which is a source code library that you would need to build into your application. On the other hand, System.Windows.Media.Imaging is included in the .NET Framework.
If you have no other use for the Windows API Code Pack, I would recommend using System.Windows.Media.Imaging. I believe the inclusion of a WIC API in the Windows API Code Pack is primarily for interoperability with the DirectX APIs in the Code Pack, which have no equivalents in the .NET Framework.