In xamarin should I always configure the app to use the platform specific httpclienthandler or is it ok to use the default httpclienthandler. I have read that you get better performance but I was just wondering if it is so much better that this should be a standard practice for all my xamarin apps.
It is ok to use httpclienthandler in the portable class library(pcl). Feel free to use HttpClient to run in a PCL library that supports iOS, Android, and WP8.
Here how i did it. Restart from a clean project.
Create a PCL with iOS, Android, .NET 4.5 and WP8. Add the microsoft Http nuget. It will install 2 other packages into the PCL.
Create the Android and iOS projects. Reference your PCL in both projects. For me that's all. It just works.
You may add the reference "System.Net.Http" in both platform projects. The reference is under Assemblies/Framework.
NEVER add Microsoft.Http nuget in any native project, nor the BCL nuget. It will create mess and you'll have to clean lots of things before it can work again.
It is extremely important that your NuGet manager is up to date, go to Tools-> Extensions and updates -> Updates
Related
I want to create a xamarin cross platform using PCL. I do not find this option while creating a project. Am I missing any installations?
Is "Xamarin.UITest Cross Platform Test Project" similar to that? But that does not open Android and IOS directories in it
The PCL option is deprecated .
From the official documentation:
Portable Class Libraries (PCLs) are considered deprecated in the
latest versions of Visual Studio. While you can still open, edit, and
compile PCLs, for new projects it is recommended to use .NET Standard
libraries to access a larger API surface area.
If you wan't to create a Xamarin.Forms solution, you must select the Mobile App (Xamarin.Forms) template. Nowadays, everything moved to .netstandard 2.0
I'm a bit confused about the dlls that are installed when using Nuget to install libraries to my Xamarin Projects. I mainly manage the nugets for the whole solution. So when i install a nuget i choose all platform projects as targets, meaning the PCL, the Android and the iOS Project. In most cases there are different dlls, like #.XForms, #.XForms.Android and #.Android, for example in the Community Toolkit (FormsCommunityToolkit), which is also available from Nuget.
In my understanding the .Android dlls need to be used in the android platform project, and the XForms dll without android should be used in the PCL. A good example is the Converters.dll. That's code only used in the pcl, but the dll is also automatically referenced in the platform projects. So my question is, why is this the case?
I see this behavior not only for this toolkit but also for other apis, like Syncfusion.
PCL dlls will contain codes that accessing common API for the targeted PCL profiles. For the UI project (Android and iOS) need to be using different dlls most of the time because it need to access to platform specific APIs. For example, API to check network connection is different in iOS and Android.
But you should not be worry about which dlls to use. NuGet package manager already handle which dlls to be use in the solutions. So, you will just need to include the packages and let the package manager to handle the rest of it.
We have migrated the xamarin forms project to unified api.
But we have the strange compile error like this:
Could not AOT the assembly '.../iOS/obj/iPhone/Debug/mtouch-cache/Build/Xamarin.Forms.Labs.dll
So I changed the settings in iOS project's options.
In ios Build Tab of Project options(iOS) I changed the "don't link" to "Link all assemblies".
But the app is crashed when it is started.
xamarin version is 5.7.1(build 17).
xamarin forms's version is 1.3.5.6337.
xamarin forms labs's version is 1.0.1.5.
Please help me if you have the experience with this error.
Replace Xamarin.Forms.Labs with XLabs.Forms.
There has been a major refactoring on how the XLabs project is structured so your existing project based on the 1.x.x will break. The reason for the refactoring was simple; separate functionality that does not depend on Xamarin.Forms into different assemblies. This allows the use of functionality like IoC, Serialization and even platform specific services without referencing XF.
To upgrade:
Uninstall any existing Xamarin.Forms.Labs packages from your
project.
Install XLabs.Forms package to your projects (PCL, iOS, Droid & WP). This will update Xamarin.Forms to the latest stable release (1.4.x)
Refactor code to reference the correct namespaces.
I have a project which greatly depends on ServiceStack, unfortunately the V4 releases, which includes PCL release for most platforms(especially after forking out for a Xamarin Licence), is just way out of my price range as an ISV. I have cloned the MvvmCross code but before I start messing around I would like to know what pitfalls I could run into when attempting to create a Non PCL based version compatible with the platforms I target (Currently Xamarin.Android, WPF and WinRT). The idea would be to able to reuse the code for the WPF project to build Android and WinRT clients.
Does anyone have any pointers?
I don't think there is any problem or pitfall with what you are describing - and I don't think you'll need to fork the MvvmCross source.
You should be able to build your apps as native code, and should then be able to reference the MvvmCross PCL libraries directly from the native libraries you are building - you don't need to rebuild MvvmCross to do this. Plenty of people already use MvvmCross using "file linking" rather than PCLs - it's not the default setup encouraged by the Nuget packages, but it still works fine.
I have some confusions About the IDE to use for MvvmCross
a) VisualStudio (VS) uses Xamrarin.iOS and Xamarin.Android plugin for iOS and Android development. But can we also use PCL(Portable Class libraries) and MVVMCross/Monocross frameworks in VS? I see the PCL option on VS but, i don't see the support for Android & iOS. Do i need to install additional plugin for PCL to support these two platforms as well?
b) Xamarin IDE supports Android and iOS development on Mac but, is it true that Xamarin doesn't support Mono.iOS on windows? Isn't it strange that Visual studio can use the network mac for iOS development but why not Xamarin Studio?
Thank You for your time.
Regards,
Saurav
a) VisualStudio (VS) uses Xamrarin.iOS and Xamarin.Android plugin for iOS and Android development. But can we also use PCL(Portable Class libraries) and MVVMCross/Monocross frameworks in VS? I see the PCL option on VS but, i don't see the support for Android & iOS. Do i need to install additional plugin for PCL to support these two platforms as well?
MvvmCross currently uses Profile104 for Portable Class Library development. You can easily develop for this profile without installing Android and iOS. The mapping of PCL profile to platforms is, however, quite confusing (it's not exactly obvious) so the easiest way I find to create a Profile104 PCL is:
to create any PCL
then to manually edit the csproj file to say Profile104 - look for a line like: https://github.com/slodge/MvvmCross-Tutorials/blob/master/Babel/Babel.Core/Babel.Core.csproj#L14 in the csproj
I have customers who develop in medium size teams where only some people have the Xamarin tools installed - most people have just Windows tools and work on the PCLs using Unit Tests and using WindowsPhone/Store user interfaces.
b) Xamarin IDE supports Android and iOS development on Mac but, is it true that Xamarin doesn't support Mono.iOS on windows?
Yes, this is true.
Isn't it strange that Visual studio can use the network mac for iOS development but why not Xamarin Studio?
This may feel strange, but I believe this is actually this is Xamarin listening to their customers.
I believe, that the reason customers wanted Windows support for iOS was because they wanted to use Visual Studio and they wanted to use plugins like Resharper. Xamarin provided this in their 2.0 release.
It is true that they could also have added iOS functionality to XamarinStudio for Windows as well - but this (I believe) wasn't what any of their customers were asking for - so adding it would have created more work (both in creating and maintaining it) without adding any significant benefit (IMO)