I am having issues with the WinUI-template on Uno-platform. For example when implementing the INotifyPropertyChanged interface from the Microsoft.UI.Xaml.Data namespace (which I guess should be correct), the app works on UWP but doesn't build for the Droid target. Using the System.ComponentModel namespace (which should be outdated for WinUI) the app builds and runs for the Droid target, but it doesn't work on the UWP target (meaning that the notifications aren't handled by the UI).
It seems that there is a mixup in the provided solution template regarding the different targets. I used these instructions to create the solution: Templates for Uno Platform
Also I am experiencing differences on the targets UWP, Droid and Wasm. E.g. ItemsControl.ItemsSource binding to an ObservableCollection works (updates the UI) on Droid and Wasm, but not on UWP. Events fired from an AutoSuggestBox are different on Droid than on UWP, etc.
Updating the nuget-packages several times during the last 3 weeks fixed some of the initial problems, but still the solution doesn't seem to be fully stable. Actually when updating all nuget-packages as of today, the app won't run on Droid anymore, stating that a library is missing at runtime.
Any ideas how to fix these issues and get a stable solution with the same behavior on Droid, UWP and Wasm?
At present time, the UWP for Win3.0 is not well supported (e.g. INotifyPropertyChanged is not properly mapped) and only the Desktop template is properly supported.
If you use the current unoapp-winui template (as of Uno Platform 3.5), the Windows projects target WinUI 3 Desktop.
Related
I am using Visual Studio For Mac. My Xamarin Forms project is quite large and contains many content pages. Some of them will be only used in android project and some of them only used in iOS project. There is no problem when I compile the project into android. However, when I want to compile the project into iOS, it seems like did not accept anything related to android. Please refer to the screenshot. There is no way I can include the android specialised reference and compile into iOS project. So, any idea to deal with this? Maybe there is a way to force build the iOS project no matter what? The error from the screenshot is from the page that will be only used in android. So what I can do for now is delete the page when I want to compile as iOS and recreate the page when I want to used it for android. But there are plenty of them, it is too heavy for me to do this every time. Please help.
You can't call platform specific APIs at the .NET standard libraries that are used to host Xamarin.Forms code by default.
Basically you have those options:
1) using shared project instead of library and using conditional compiling (easier but it is now not available as the option when creating the project)
2) using dependency injection.
I have implemented a Xamarin.Forms effect and spiked i successfully but I now need to create a proper NugGet package to use it as a component in my projects.
I added a .NET Standard lib for the RoutedEffect implementation. Then created three platform-specific lib projects for iOS, Android and UWP. To try everything out I then created a new Xamarin.Forms app with a .NET Standard "common" lib that references the RoutedEffect´s .NET Standard lib. Finally, from the iOS app I reference both the RoutedEffect's lib and the (iOS) PlatformEffect implementation lib.
The problem is that the PlatformEffect never gets instantiated. I tried resolving it from the .NET Standard common lib, just to see what's going on, and I just get back a NullEffect. For sake of sanity I then tried moving the code for the iOS PlatformEffect from its iOS lib into the iOS app. This works. But I have no idea why it won't work when implemented in the iOS lib, when referenced from the iOS app.
Am I missing something?
Ok, this was a bit embarrasing, and an example why you shouldn't code late in the night I guess. :-/
After a good night's sleep I realized the PlatformEffect lib, which consist of one effect only, was only referenced from the iOS project but none of the lib's types was actually referenced and, so, the .NET linker won't link the lib.
Just adding a reference to the platform Effect type solved the problem and it works fine.
Please move on ... :-)
I've got a WPF App using the latest version of Prism for WPF (6.3.0) and Unity. Just a few modules. It works great.
When I manage NuGet packages for my solution, it tells me that there is a new version of Unity (5.4.0) available. Unfortunately, if I try to update to that version, I can no longer build.
It's pretty clear to see why: Upgrading unity via this method removes all references to it (Unity) from my project. Specifically the following 3 references completely disappear from all my projects without any replacement:
Microsoft.Practices.Unity
Microsoft.Practices.Unity.Configuration
Microsoft.Practices.Unity.RegistrationByConvention
(The Prism references remain, of course)
Error messages tell me that IUnityContainer is defined in an unreferenced assembly (Microsoft.Practices.Unity. 4.0.0.0). Given that it removed those assemblies, this all makes sense.
If I then try to go looking to add Unity back in, the Add Project Reference dialog cannot even find Microsoft.Practices.Unity when I search for it.
Now this isn't that big of a deal. I didn't need to upgrade. and it's easy for me to revert back. But I want to understand why this is failing for future reference.
Does this mean that Prism is tied to the older version of Unity and I just shouldn't upgrade?
Does this mean that types have moved to different namespaces and I need to make some other fix?
Some other reason?
Among the Unity 5 updates included a change of namespaces which as you noticed was a major breaking change. There are no plans for Prism 6 to support Unity 5, however the current Prism 7 previews (which is available for WPF) have updated both the Common Service Locator and Unity.
https://www.nuget.org/packages/Prism.Unity/7.0.0.336-pre
I need to implement Map functionality into an application that I'm building.
And I was folliwing this guide.
I downloaded the package and did all of the configuration.
I haven't implemented the Map class into my project yet, I only did the configuration required for both platforms (Android and iOS).
The Portable project and the iOS project are fine, the problem here is the Android project.
It has some broken references, these ones:
And when I try to compile the Android project, I get this error and these warnings:
Can anybody give me a hand? Thanks in advance.
EDIT:
As a sidenote, I'm using the Sdk installed by Android Studio, and that one has the latest Google Play Services installed.
UPDATE:
I just upgraded the version of my Xamarin.GooglePlayServices one by one (the one listed up there in the first image) for some reason it downloaded a really old version of those. So I just upgraded them, and it seems those references are fine now.
But I still get the error:
The "ResolveLibraryProjectImports" tasks failed unexpectedly.
SOLUTION:
I unloaded the Android project, added this:
<UseShortFileNames>True</UseShortFileNames>
To every property group in the .csproj file.
Load my android project back, and it all worked fine now.
I am new xamarin.forms framework, When I started to work for cross platform application for making new solution (new solution->mobile apps), I got following three options for moving further:
Blank App(Xamarin.Forms Portable)
Blank App(Xamarin.Forms Shared)
Class Library(Xamarin.Forms Portable)
After investigating a lot, among those i did not create any difference. Can anyone tell me the difference with example.
Xamarin has the answer to your question here, but I'll give you a short rundown here as well.
Class Library(Xamarin.Forms Portable)
Is an Portable Class Library you can put classes in, which would then be usable by either an Android, iOS or WP app.
Blank App(Xamarin.Forms Portable)
Creates a set of apps for Android, iOS and possibly WP using a Portable Class Library for the common parts
Blank App(Xamarin.Forms Shared)
Creates a set of apps for Android, iOS and possibly WP using a Shared Library for the common parts
The difference between PCL and Shared is that a PCL library is compiled once, and then referenced as a library by each app. A Shared library is compiled directly into each app (and is thus compiled three times as opposed to one for the PCL)