Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uwp Xamarin.Forms.Shell #5593

Open
allessandrosj opened this issue Mar 17, 2019 · 56 comments

Comments

@allessandrosj
Copy link

commented Mar 17, 2019

Uwp Xamarin.Forms.Shell does not work correctly in uwp, the same way it works on android and ios

@pauldipietro pauldipietro added this to New in Triage Mar 17, 2019

@pauldipietro

This comment has been minimized.

Copy link
Member

commented Mar 17, 2019

Shell support is only provided for Android and iOS at this time. We are continuously evaluating feedback regarding potential future UWP support and will provide more information in the future as it becomes available.

Triage automation moved this from New to Closed Mar 17, 2019

@jcmontoya

This comment has been minimized.

Copy link

commented Apr 11, 2019

I normally use iOS and Android for my phone users and UWP for my tablet and desktop users. So having UWP support will be very important to keep windows users engaged.

@TiBall

This comment has been minimized.

Copy link

commented Apr 13, 2019

What?? MS is really ditching their own platform. This is sad to hear!

@Juansero29

This comment has been minimized.

Copy link

commented May 17, 2019

Isn't there any visibility on when UWP support will be given? Or has the decision already been made?

@snow-jallen

This comment has been minimized.

Copy link

commented May 22, 2019

Shell support for UWP - please!

@akuehntopf

This comment has been minimized.

Copy link

commented May 23, 2019

I'd also like to see UWP support for the Shell.

For my company UWP is quite important because our customers use Windows Tablets in combination with some Android phones to get their work done. We won't be able to migrate to Shell if UWP support is missing.

@dan-meier

This comment has been minimized.

Copy link

commented May 23, 2019

Agreed -- UWP compatibility allows me to bake in Windows tablet capability with my mobile implementation. I'd have to code this completely separately without it. Yuck! UWP compatibility is a must-have!

@cbradbaer

This comment has been minimized.

Copy link

commented May 24, 2019

I don't know if it makes sense, because I have not used Shell yet. But maybe there is a way to use all other elements of the App (besides Shell) for a UWP implementation. After all using TabbedPage and MasterDetailPage would achieve the same thing, it seems.

@JakePorter05

This comment has been minimized.

Copy link

commented May 27, 2019

I also would vote for the ability to use UWP with Shell.

@dgerding

This comment has been minimized.

Copy link

commented May 27, 2019

UWP please... or at least some flavor of Microsoft UX API we can depend on for a few years. This approach of "we'll let you know if we might support it later" is just mean.

So, yes, UWP or whatever will support it but more importantly: A COMMITMENT TO WHEN WE'LL KNOW IF OR WHEN.

Can't move to Shell without that certitude.

@melihercan

This comment has been minimized.

Copy link

commented Jun 2, 2019

Not only UWP but MacOS as well please.

@Mephisztoe

This comment has been minimized.

Copy link

commented Jun 3, 2019

I don't know if you realized that UWP is not only a platform that is still widely used by developers, but also the fastest way to get Android and iOS based XF apps up and running. Because - in comparison - the emulators provided for both the Android and the Mac world are freaking slow, prone to problems and let's not talk about the horrible certification experience or still being forced having a real Mac around, shall we? So even though it cannot replace developing on the real thing after all, an UWP app increases developer productivity by offering a fast, easy and comprehensive way of getting… things... done. And then: Do what it takes to get your app up and running on iOS and Android as well.

So will you please add shell support for UWP?

@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

@mzhukovs

This comment has been minimized.

Copy link

commented Jun 6, 2019

Agree with @Mephisztoe it really is a great productivity tool, and of course the option of actually making the app available for Windows is a nice plus too :)

@drchilds

This comment has been minimized.

Copy link

commented Jun 13, 2019

Please don't relegate Xamarin.Forms to mobile platforms only. I'd like to see continued support for UWP especially, but also WPF and GTK#.

@PureWeen PureWeen reopened this Jun 13, 2019

@nitrouscutter

This comment has been minimized.

Copy link

commented Jun 24, 2019

So basically anyone who has an app that is cross platform for all three platforms in Xamarin Forms right now cant update and use these features. If future development on Xamarin Forms for UWP wont happen why not just remove UWP from the cross platform list?

@GalaxiaGuy

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2019

Different platforms will always have different priorities. After all, you said "all three platforms", not "all seven platforms".

@nitrouscutter

This comment has been minimized.

Copy link

commented Jun 24, 2019

@GalaxiaGuy that's correct, I did say all three platforms considering if I said seven platforms I would be making up imaginary platforms. According to Xamarin.Forms documentation:

Xamarin.Forms
Xamarin.Forms exposes a complete cross-platform UI toolkit for .NET developers. Build fully native Android, iOS, and Universal Windows Platform apps using C# in Visual Studio.

@GalaxiaGuy

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2019

And on the readme it says:

Xamarin.Forms provides a way to quickly build native apps for iOS, Android, Windows and macOS, completely in C#.

That doesn't mean it doesn't also support GTK, WPF and Tizen.

I agree that those platforms are probably less important than UWP, but there are a lot of people who think that UWP is less important than iOS and Android.

I generally agree with the sentiment though, and I'm having to ignore newer features myself because of them not being on UWP.

@JeroMiya

This comment has been minimized.

Copy link

commented Jun 28, 2019

FYI, unless I'm reading the release notes incorrectly, it looks like there's a ShellRenderer implementation for Tizen in the 4.1 preview. No mention of UWP.

If the pull request from @dotMorten takes a while to merge in, maybe someone could take that implementation and move it to a separate "pre-release" NuGet package managed by the community until/if we get official support. That way we can use it without using a full pre-release or custom build of Xamarin.Forms. If we don't get official support, then the repo will already be setup and the community can take over.

@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

I'm sorry this haven't moved faster. I hit some regressions when syncing up with master, and I've been completely swamped with work and family-related stuff, so just haven't had much time to really sit down and try and address it. However I'm more than happy to take PRs for my branch.

@luigicasalegno

This comment has been minimized.

Copy link

commented Jul 15, 2019

We also will use the shell as soon as it is available on UWP. We have the same problem as above. We have a mix of tablets, phones and notebooks both with android and windows. And we also think that the best development environment is UWP

@samhouts samhouts added this to To do in UWP Ready For Work via automation Jul 16, 2019

@dotMorten dotMorten referenced this issue Jul 16, 2019
2 of 7 tasks complete
@dgerding

This comment has been minimized.

Copy link

commented Aug 22, 2019

I want to clarify my need: I don't need UWP for Xamarin Forms. I need some Windows target for Xamarin Forms. UWP just seems like the most viable candidate. If I had to guess Microsoft will eventually punt and go to HTML and Blazor client for desktops since it might give them the broadest UX reach in a post-Windows world. That might also fit better with a composable shell (not xf shell) path. In the absence of any coherent roadmap for the Windows side of UX, I can't imagine what else they might be planning.

But to be clear, dropping Windows support for Xamarin without announcing in big bold letters, "WE DON'T AND WON'T DO WINDOWS", is, at a bare minimum, really, really unkind. It rings of "old Microsoft".

@davidortinau et al: Please do something more than pointing to the now effectively dead (see @dotMorten's latest post) "community support for XF Shell + Windows".

I am super grateful for all the new and cool things in Xamarin. But I need a more honest response about the future viability, if any, of Windows targets using Xamarin.

@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2019

several things that would need to change and require broader buy in from the XF team

I know one of these had to do with WinUI which we are hoping to pull in as a dependency with this PR
#7214

That PR maintains 16299 compatibility and from my tests works great when it's included with a nuget and doesn't require the user to install WinUI. I still need to get 16299 spun up in a VM to make sure but I'm staying optimistic. I know @dotMorten you had expressed some concerns around pulling in WinUI so if I've totally ignored those please let me know :-)

Here's that nuget.

Xamarin.Forms.4.3.0.1853.zip

If anyone else would like to test it out for us and let us know if you have any issues that would be really helpful. I've tested it with the basic UWP template and it works fine for me with no crashes.

The path I see for this currently is

  • get #7214 merged so that we've taken care of the WinUI depedency
  • get the UWP Shell PR rebased (we have this scheduled for a future sprint so we'll either do it then or if someone else beats us to it)
  • Morten already has it working with Gastropods so we just want to test it with a few more samples (mainly Xaminals), once that's working and we make any code cleanup changes that are needed we will merge

If I'm missing anything with that path let me know and we'll try to get it addressed, so all that needs to be done is a rebase and a verification against Xaminals.

@dgerding

This comment has been minimized.

Copy link

commented Aug 22, 2019

@PureWeen,
I can run the App132.zip with the Xamarin Nuget you provided. App seems to work fine ... assuming it's supposed to add timestamped elements to list control. Both the button at the top and the Pull to Refresh behavior add elements.

Not sure what I'm looking for but I appreciate your efforts and will try and help as I can.

Dave G

@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2019

@PureWeen Great to see you're moving forward with WinUI. The dependency on WinUI was creating breaking behaviors for me, as WinUI was adding a dependency that wasn't added transitively. That's fixable if you use VS2019, but I'm not sure if WinUI has taken advantage of that feature yet (and it'll still affect VS2017 users, but at least has a workaround).
In addition there were bugs in WinUI that caused a lot of headaches for me, but I've noticed recently some of the ones I logged got fixed, so that's all encouraging. Ping me once 7214 goes in, and I'll try and start this effort up.
Also would love help with rebasing. Last time I did that, I totally messed up this PR :-)

@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

@dotMorten Sounds good!!

I did test the app I included above on VS 2017 and it worked for me so I think we're ok on that front

Not sure what I'm looking for but I appreciate your efforts and will try and help as I can.

The main thing would be adding the nuget into your main UWP project and just making sure they all seem to compile and run ok.

Just trying to vet that adding a WINUI dependency isn't going to cause any headaches :-)

@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

I did test the app I included above on VS 2017

Without also adding WinUI to the project head? That is the issue I found: if people were to upgrade to a version of XF that depends on WinUI it wouldn't work without also manually adding a dependency to WinUI. IMHO that's a breaking change. WinUI can change their package so it works implicitly, but it would require VS2019 as it relies on a NuGet 5.0 feature (and afaik they haven't made this change so it won't work in either right now).

@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

Here's the issue I logged in WinUI: microsoft/microsoft-ui-xaml#596 (comment)

I might just make a quick PR to at least address that so VS2019 users wouldn't have to manually add the extra dependency.

@dgerding

This comment has been minimized.

Copy link

commented Aug 23, 2019

Just adding that when I tested the app123 it was with VS2019.

@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

Without also adding WinUI to the project head?

Yea the project I have linked above I can open inside VS2017 and it compiles and runs fine. I don't have the WinUI nuget added to the UWP head it's only indicated as a dependency inside the nuspec

@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2019

I don't really get how that works. There's a style that needs to be added and an extra appx framework package that needs to be installed with the package, and it's all done by the .targets. Are the framework package already installed on your machine?

@scottkuhl

This comment has been minimized.

Copy link

commented Aug 25, 2019

Visual Studio Magazine just covered this issue in particular. Microsoft, time for an official response.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2019

@dotMorten I'm out for a couple days but I'll look into that when I get back. I've also reached out to the WinUI team to review

@PureWeen PureWeen referenced this issue Aug 25, 2019
0 of 3 tasks complete
@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2019

This target runs fine transitively when I tested on VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Here's an updated nuget that lets you override the setting in your local forms project
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

In the forms project we forced this to true so it won't surprise people.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff-5e6292d5925c776aa9aa6d6f8c63ddf6R19

@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2019

@PureWeen This is the bit that should work without adding these lines explicitly (since all users would have to update their project heads too):
image

I think you're saying it does work, but just making sure we're on the same page.

It might be you consider this an acceptable breaking change, but I recall this happened recently with another dependency and threw a lot of people off, as the upgrade path isn't as clean as just picking a new XF version.

@SteveReillyBayridge

This comment has been minimized.

Copy link

commented Aug 27, 2019

Re: the need for a desktop/laptop/tablet target for Xamarin Forms

For those of us who are building mobile apps in corporate environments, the ability to produce a "work-alike" desktop/laptop executable from the same basic code base as the Android/iOS base is essential. It doesn't need to be Windows only (a browser-based target such as HTML/JS would be just as good) but the vast majority of our users have a Windows desktop/laptop + iPhone/Android phone, so a Windows executable is fine for the most part.

We have found that when we make a mobile app available within the organization, the majority of our users want to try it out on their laptops/desktops first - and only if they find it useful or appropriately matched to their needs will they deign to put it on their phones. Also, getting user buy-in (and feedback) works significantly better if they can enter data or query results from either desktop or device, depending on where they are working at that particular moment.

Xamarin Forms works well for these scenarios, and we'd really like to use Shell and CollectionView, but they are shelfware to us until they can be used to produce a desktop/laptop work-alike...

@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

@dotMorten so the reason I'm not seeing the exception is that I have WinUI as a dependency on the nuget so if you install XF onto the UWP head then WinUI comes along for the ride and applies its targets.

This does make it so the XF package itself has to be installed onto the UWP head project in order to work. I tested my example above with having XF only installed on the netstandard project and was able to recreate your exception.

We've talked about this a bit over in this issue
#4126

This is breaking if people only have XF installed into the shared library and not the UWP head project. So we'll need to discuss this a bit to see what we want to do about this

@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

@PureWeen ok good. Glad we're seeing the same thing then. A few things to consider in your discussions:

  • If my PR in WinUI gets merged it'll only affect VS2017 users (which however could get weird if a team uses both and it only affects some users).
  • You could detect this during Init() and throw an error that tells users exactly what to do so the pain isn't so bad.
  • I was toying with the idea that XF has a targets file that adds the dependency to the referring project if not already present, but could
    create a weird dev experience.
  • All UWP projects will always use this dependency once WinUI gets separated from the platform (but by then VS2017 is probably out of support anyway).
  • You'll be able to support lower versions of Win10 with this change, creating a value add that could justify it.
  • No one will notice because according to your team, no one really uses UWP anyway 😜 j/k
@dotMorten

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

One more possible approach: Detect if WinUI is referenced during Init, but let the app run. Any renderer that relies on WinUI would instead throw, so it'll only affect users of these new features. So the story becomes "If you want to use Shell or PullToRefresh you must also add a reference to WinUI (if you are on VS2017)".

@samhouts samhouts added this to In Progress in vNext+1 (master) Aug 30, 2019

@samhouts samhouts removed this from In Progress in vNext (4.3.0) Sep 3, 2019

@mnasers

This comment has been minimized.

Copy link

commented Sep 9, 2019

@dotMorten Thank you for all your efforts regarding bringing Shell to UWP! This is very much needed and should have been addressed by the core Xamarin team.

@samhouts samhouts removed this from In Progress in vNext+1 (master) Sep 13, 2019

@samhouts samhouts added this to In Progress in vNext (4.3.0) Sep 13, 2019

@PureWeen

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2019

Here's a taste of Xaminals running on UWP with CV and Shell!!!

image

@samhouts samhouts moved this from In Progress to Done in vNext (4.3.0) Sep 17, 2019

@velocitysystems

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2019

Great work!

@luigicasalegno

This comment has been minimized.

Copy link

commented Sep 18, 2019

Fantastic job. We will include it in our framework for building enterprise level applications as soon as it comes out

@Nioux

This comment has been minimized.

Copy link

commented Sep 18, 2019

Great job, I will try it in a future release of my app ;)

@abrantie1z

This comment has been minimized.

Copy link

commented Sep 18, 2019

Yes, Xamarin Did it! i read one guy say we move to Uno. No!!!! Xamarin has been great for us and saved us lots of time to having to go learn swift + java. Lets be patient with the team and support them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.