I am using Xamarin and need to use a PCL
However, I cannot install ServiceStack into the PCL other than the PCL package which is classed as no longer being maintained
Has anyone come across this?
I want to use PCL because I dont want to duplicate code
PCLs are supposed to be supported via the latest Service Stack but this does not appear to be the case
I have code which makes use of ToJson which is in ServiceStack.TExt
I know I could create a folder inside my iphone (and android) assemblies but I am not sure this is a good approach because it doesnt feel right (everything all in one place instead of in proper layers)
Does anyone have any ideas about this?
Paul
Your assumptions aren't correct, ServiceStack PCL Packages ARE still being maintained, but instead of being maintained in individual packages, e.g:
ServiceStack.Client.Pcl
ServiceStack.Text.Pcl
ServiceStack.Interfaces.Pcl
They have now been merged as different profiles into the main client NuGet packages, e.g:
ServiceStack.Client
ServiceStack.Text
ServiceStack.Interfaces
Related
Failing to extend my existing project with UWP , i search for reason why certain existing projects can't be extended with UWP.
Here i get an answer that all the nuget packages of X.shared project should be the same(with the same version) in the UWP project.
However , even after doing that the project failed to start , so i asked in the
xamarin-docs github and they tell me that the cause is a nuget package supported only in Ios and Android.
So my question is :
Should all the nuget packages be the same for *.ios *.droid, **.\shared and *.uwp ?
And what if i have other projects(not xamarin projects) in my solution ?
You don't understand the architecture of Xamarin and it is hard to answer in one paragraph, further reading of documentation instead of your constant asking of basically the same question on different places (please note that on the github you where warned that it was not the place to ask such a question) is highly advised.
But I'll try to answer. The package may use (or even need to use) native APIs to achieve some functionalities. Those native APIs are available only on one platform and such code is useless on another platform. So the package author in that case must write the separate implementation for each platform that he wants to support. He may cover just one platform or two or three, it is up to the package author. If the platform is not supported by the package and contains the native APIs, there is almost nothing that you can do aside to write your own implementation of the package for that. Even if you succeed in installing it won't work.
I am trying to include Judopay in my project, and I was able to add it to Android and iOS, but not to the Xamarin forms project. There is no NuGet to be included and I can't seem to add the component reference. Any idea on how can I add it? I cannot use any of these:
using JudoDotNetXamarin;
using JudoPayDotNet.Enums;
using JudoPayDotNet.Models;
Again, they only work on iOS or Android, but not Xam forms.
That is because they only provide platform implementations. You will need to tell your Forms app which implementation to use at what time.
The correct way to go about this is with some form of IoC, using dependency injection or service location. Luckily Xamarin Forms has this integrated:
https://developer.xamarin.com/guides/xamarin-forms/application-fundamentals/dependency-service/introduction/
Using the references from the Android or iOS projects in your shared code will likely not work completely or break things. Maybe not immediately but surely later on. (Except when there really is no platform-specific functionality, then you might get away with this.)
I have tricky question about SignaturePad updated to Xamarin Forms 2.0, link to GitHub:
https://github.com/mrbelk/acr-xamarin-forms
I did manage to download repo and build it, however I have no idea how to produce proper DLLs that I could use in my project?
The main issue is that SignaturePadView is treated as Xamarin Forms View class instead of Android View, so there is different constructors, methods, etc.
Does smb know how to build these projects to produce proper dlls that iOS/Android solution will treat SignaturePadView as Android View and iOS UIView respectively?
Don't use acr.* any more if you want to save yourself some pain. I had to pull their camera implementation out of one of my apps due to no support for forms 2.0+.
Replace acr with supported NuGets like Plugin.Media and the others found here. For this particular issue no one has created a non-deprecated NuGet so there is this plugin as an option.
Apparently, it happens that we have actually used SignaturePad from https://components.xamarin.com/view/signature-pad but via acr.* nuget package.
What I found in my quick research that both acr.xamforms.SignaturePad and SignaturePad it self were in acr nuget package, and actually we were using components from SignaturePad, luckily. So I did remove this nuget from sln to get rid of acr.* components and add SignaturePad from xamarin components by hand.
Now we are able to use Xamarin Forms 2.0 without any problems.
Cheers,
G
I develop with Visual Studio. I have a class library that contains code common to many products I develop, and is now in use by 15+ solutions. I do LOB apps for my non-software company.
I've been adding this class library project directly to the solutions of all the solutions that need to use it. But I've been using NuGet to pull in many 3rd party packages and I really like its way of doings things. I'm thinking about adding this utility library as a NuGet package in our own repository rather than adding it directly as a project reference in the solution.
Is this a good idea? What criteria should I use to determine when to use NuGet vs when not to for internal class libraries? I realize that some might think this is an opinion based question, but I'm looking for specifically what criteria you'd use to decide rather than opinions about which is better.
Internal libraries that used and worked on by multiple teams can be exposed as Nuget packages. This way, multiple teams can work on the library, and each of them can update to a version as and when needed by that particular team.
I have an app written in MONOTOUCH. It works- I tested it with TESTFLIGHT. It is being added to a larger app, and that developer needs the full xcode project. Do I need to have it rewritten or is there a way to convert it easily.
There is no way to convert Mono code to Objective-C code.
There is an --xcode option that may or may not work. It has not been maintained and we do not officially support it, so I would not depend on it working.
My suggestion is to keep the two applications separate, and transfer control from one to the other by using urls. You register two url handlers "firstApp:" and "secondApp:" and when you need to go from the first to the second, you issue a Url open to "SecondApp:statevariables" and the same process is repeated to go back.
If you have a MonoTouch license, you can use mtouch --xcode yourapp.exe to generate Objective-C code. It doesn't work in the evaluation version.
Much more detail is available in this Stack Overflow answer.