Is it possible to link two Core libraries into your app?
I would like to create one Common.Core library that has login and account view models.
I would like another one Domain.Core library that has some domain view models in it.
These could be used across a couple different projects.
In my app, I do a new Setup().Initialize().
My Setup class overrides CreateApp() ...
public class Setup : MvxPhoneSetup
{
protected override IMvxApplication CreateApp()
{
CreatableTypes().EndingWith("Service").AsInterfaces().RegisterAsLazySingleton();
return new Common.Core.App();
// TODO: can I setup a Domain.Core library here too?
}
}
I have tried doing this ...
CreatableTypes(Assembly.Load("Domain.Core")).EndingWith("Service").AsInterfaces().RegisterAsLazySingleton();
but I'm getting a ReflectionTypeLoadException when I try to resolve a domain model from there.
Anyone tried something like this?
Thanks!
Yes, using multiple 'core' projects should work.
The ReflectionTypeLoadException occurring on Resolve suggests that maybe your second Assembly requires another Assembly that isn't available? Do you get the same problem with a very simple second core project? Can you get any more information about the exception? Which platform is this occurring on?
If you want to load ViewModel types from multiple assemblies, then there is a Setup method you can override - The default ViewModelLocator in MvvmCross gets its list of ViewModels from the assemblies listed in Setup - see MvxSetup.cs
(Sorry this list is in the ui project - should really be in the main core project)
For cross-platform compatibility, I don't recommend using Assembly.Load - better to use a more static method like typeof(Domain.Core.Something).Assembly
Working on 'packaged application' platforms like xamarin.android and (especially) xamarin.ios I don't recommend using Assembly.Load - this will only work on the iOS platforms if the assembly is referenced statically and has already been loaded - that's the reason plugins have a special bootstrap file on iOS. Also be aware that the name used in Assembly.Load is different on different platforms - eg in Android you must use the filename ending in .dll - see MvxAndroidSetup.cs. For other platforms like WP and winRT, then Assembly.Load may work more conventionally though - although I've personally spent hours/days/weeks swearing at this sort of code in the last year.
Related
I've got a static library, which was used to generate the wrapping code by Sharpie. The library was Built after that (including, generated *.dll) successfully.
AppDefinition.cs contains the namespace and the mappings, like this:
namespace TheNamespace
{
// #interface TheParameters : NSObject
[BaseType(typeof(NSObject))]
interface TheParameters
{
The library itself built in Release mode with LinkTarget.ArmV7 | LinkTarget.ArmV7s | LinkTarget.Arm64.
However, when referencing this binding project from my iOS project, it works only in Debug mode.
When I change it to Release, the namespace (and all the related clasees) not available. Also, when exploring the binding library reference in Object Browser, it doesn't display any elements: it's totally empty.
Just to point that: it gets available when changing it in the dropdown to Debug and disappears on Release, what's interesting, undependently on what actually project is selected in Current Project dropdown!
What might be the issue? Thanks!
I think the problem should come from when building static library .When generating static library , there is a build type of release/debug to select.
Above screenshot shows static library types after building , there are three types (Two is Debug and One is Release ). You can see that tt distinguishes between release and debug .
After some Googling I found the solution.
The issue happens because of Visual Studio bug, I guess. And also referred here. (And it's weird it's not mentioned in Xamarin docs on Microsoft website.
To resolve the issue the Binding Project(s) must not reside in the same solution with the main project. Just remove them and attach the library as regular reference.
I want to make a multilanguage program via using resources(.resw files).
Its really easy for PCL but I dont know how to do it in Shared Project?
Create a Portable Class Library (PCL, or just Class Library Project) using .NET Standard, in order to localize resources in a Xamarin.Forms shared project.
Create the PCL, and then reference it from all 3 projects (Android, iOS, UWP).
Using a naming convention like AppResource.resx for the main resource, select that code generation should be Public, from inside the resource editor (in the top toolbar, there is a drop-down.)
Afterward, create a resource filed named AppResources.fr-FR.resx for French, for example. Always use the format ResourceFile.Language.resx.
Code generation will automatically be disabled for the localized resource when you name it, by the project manager. Keep it that way. It doesn't need code generation.
Voilà! You can now access localized resources from a shared Xamarin.Forms app using a Portable Class Library.
Now you can follow the rest of This Tutorial From Microsoft from within the PCL.
I've faced some day ago the same problem (and with .net standard there isn't documentation about it).
I've created a library to do quickly the localization also in shared project.
Hope it helps:
https://github.com/andreabbondanza/DewXamarinLocalization
I have small problem - I'm trying to implement class that needs to contain a lot of events. Due to memory concerns I planned to implement EventHandlerList which is available for me in my Android Library project target also in my iOS Library project target but is not available for me inside PCL Project. Tried to change PCL Target project to most commonly used but none of them contained what i needed.
Type missing for my case :
System.ComponentModel.EventHandlerList
Is there any possibility to write such class once or I'm forced to write it two times because of missing PCL Target.
You will need Inversion Of Control (IoC) to use platform specific features or non-portable methods
Please take a look at this IoC example
Another option if you want to avoid IoC is to use Shared Project in Xamarin
I'm building a project that includes an MVC Web Api hosted in Azure and an iOS app. I'm trying to use Xamarin to build the app. As I understand it, I should use a portable class library in my Xamarin project to allow me to share the code between my Web Api project and the Xamarin app, as well as any future apps on other platforms like android.
So right off the bat I would want to put my models in the portable library. The app and the web api will pass those models back and forth. But the portable library doesn't have the Azure Table Storage library. It doesn't even have some very basic stuff. My models need to reference the Azure Storage Library so I can save instances to storage.
What is the best way to make this code shareable? Obviously I need to duplicate my model classes so they can exist in each location. But should those in the PCL inherit from those in the Web Api project? Vice versa? Should there be an interface that both inherit from (actually the Azure Table Storage library requires the classes to inherit from ITableEntity already...). Just looking for the best way to share these classes between the Web Api project and the PCL used by the Xamarin project.
Using a PCL - Portable Class Library is a great way to get started! There are a few quirks that you may want to understand prior to sharing your code.
The PCL Profile is a limited set of APIs available. Meaning that certain classes/assemblies might not be included. You can typically look up the class/assembly via MSDN and see if it has a PCL icon next to the class name.
If the library you are trying to use has assemblies not inside the current PCL Profile but can be found on the native platforms, you will want to use the IoC/DI pattern.
Hopefully the library you're using supports PCL. Otherwise, you will need a library that does support the PCL Profile. (You can check this by downloading the .nupkg, extracting, and looking at the libs folder). Note: You may want to check the Prerelease NuGet channel for PCL support. Sometimes you can find an open source project and remove/replace certain assemblies/code to make it Portable.
General Guidelines:
Keep your POCO classes simple in the PCL. If you have platform specific quirks you need to add to the models, make a Model layer on that platform that inherits from your simple PCL models. EX: Your Web API has a specific [Attribute] tag or interface that you need to apply to your model. You might already have a Model such as Person which is a simple POCO class in your PCL, and then you can create a PersonApiEntity model which might inherit Person and any platform-specific APIs you need to apply to it.
It seems ITableEntity/TableEntity is not supported in the PCL Profile.
https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.table.itableentity.aspx
Seeing the source at a quick glance(https://github.com/Azure/azure-storage-net/blob/master/Lib/Common/Table/ITableEntity.cs)
I have some Model code that requires some methods from the System.IO.Compression namespace. However it is not present when using a PCL that targets VSMonoTouch and MonoAndroid as well. I see that some stuff is TypeForwarded in the MvvmCross solution, though when creating a similar project I can't seem to find out how to use it.
I created a MonoAndroid library project and added a Forward.cs class with the following content:
using System.Runtime.CompilerServices;
[assembly: TypeForwardedTo(typeof(System.IO.Compression.CompressionMode))]
[assembly: TypeForwardedTo(typeof(System.IO.Compression.DeflateStream))]
[assembly: TypeForwardedTo(typeof(System.IO.Compression.GZipStream))]
I have set the namespace of the project to System.IO.Compression. Trying to add it as a reference to the PCL project I have with my Model code which contains ViewModels, Services and what not it of course says that it can only reference other PCL projects and assemblies.
I especially need GZipStream and I cannot seem to find out how to add it to my project, so the question is how do I do that?
PCL Extension route
How to do this by extending PCL... I'm not entirely sure! One of the PCL guys might be able to assist with that.
Plugin route
The way I'd go about this is by defining the functionality I want in an interface and wrapping the code in a plugin.
For example in Cheesebaron.Plugins.Gzip.dll you could create an interface like:
public interface IGZipStreamFactory
{
Stream Decompress(Stream binaryStream);
}
This interface would then get plugged inside a PCL library that just contained this interface and the pluginmanager class.
Your PCL Core project can then reference this PCL plugin library and your ViewModel can use code like:
Cheesebaron.Plugins.GZip.PluginLoader.Instance.EnsureLoaded();
followed by
var service = this.GetService<IGZipStreamFactory>();
var unzipped = service.Decompress(inputStream);
For each actual platform implementation, you then prepare a platform specific library, you implement the GZip factory interface, and you provide a simple Plugin class implementation.
For example, for Droid you might create Cheesebaron.Plugins.Gzip.Droid.dll:
public class MyDroidGZipStreamFactory : IGZipStreamFactory
{
// the implementation
}
And you'd then add:
public class Plugin
: IMvxPlugin
, IMvxServiceProducer
{
public void Load()
{
this.RegisterServiceInstance<IGZipStreamFactory>(new MyDroidGZipStreamFactory));
}
}
Finally... to pull it all together, for MonoDroid you then reference both the PCL and the platform specific implementation in your UI project - and it should all work!
Note that there is a little convention based magic going on behind the scenes here - the framework loads the Assembly Cheesebaron.Plugins.Gzip.Droid.dll based on the PCL Plugin namespace being Cheesebaron.Plugins.Gzip
(For WP7 and other platforms, there's one additional step - there's a setup method to override which registers the plugin)
Note you can register as many services as you want to inside a single PlugIn, and you can perform extra common initialization/setup code too. This can help to reduce some project maintenance overhead: you can put your CheeseBaron IoC objects inside one single CheeseBaron.Plugins.Utils project if you like and then share just this one plugin across all your apps.
The DownloadCache Plugin provides a small sample of this - it registers all of IMvxHttpFileDownloader, IMvxImageCache and IMvxLocalFileImageLoader.
The downside with doing this is: eventual linked exe size - you're potentially adding unneeded code to each app.
Obviously this plugin approach has a little bit of a learning curve... and it does add a little project maintenance - but the good news is that these plugins can be used over and over again between projects - and can be shared between organisations (at least, that's my hope!)
More on creating plugins at:
MvvmCross vnext: merge plugins with monodroid
http://slodge.blogspot.co.uk/2012/06/mvvm-mvvmcross-monodroid-monotouch-wp7.html
For examples of plugins (not all available on all platforms), see https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/Plugins
Other routes
If you don't want to use Plugins - e.g. if you are ever in a hurry or if you are writing code for a module that you don't want to reuse, then there are alternatives:
You can define an interface like IGZipStreamFactory in your share Core PCL library. You can then provide a platform specific implementation of this interface within each UI project, and can then use normal IoC/DI in the ViewModel/Model/Service layer in order to locate the correct implementation at runtime.
Or...
You can just dump the shared PCL core library and create separate platform-specific DLLs into which you then manually link in platform-specific files (I try never to do this, but others like it)