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 Support #8

Closed
MrWolfPST opened this issue Jan 2, 2016 · 16 comments
Closed

UWP Support #8

MrWolfPST opened this issue Jan 2, 2016 · 16 comments

Comments

@MrWolfPST
Copy link

Have you plan a porting for Universal Windows Platform?

@FantasticFiasco
Copy link
Owner

I haven't planned for it, but if there is a demand for it I'll look into it.

@rockthethird
Copy link

This is clearly the direction Microsoft is taking the development community. I would be more than grateful if this supported the UWP. Projects on devices like the Raspberry Pi need some dialog love too :)

PS. This is a great framework you are contributing to the world, thanks!

@FantasticFiasco
Copy link
Owner

Well, the number of people requesting this feature just got raised by 100%, at least that is something.

The first step for me will be upgrading from Windows 7 to Windows 10, which I don't mind. I can swere the 'please upgrade now' dialog shown every time I boot my computer has become slightly aggressive lately.

I can't promise anything more than I'll start to look into it. I don't own any Pi myself, so if any of you could try it out before I release I would be ever so grateful.

@rockthethird
Copy link

@FantasticFiasco the very idea that you would be willing to investigate is all anyone could ask. I would be happy to help in anyway I can to further your great project into the world of the UWP.

In Christ,
Rock

@FantasticFiasco
Copy link
Owner

FantasticFiasco commented Apr 16, 2016

We have a beta version on NuGet now, namely 1.2.58-beta. Make sure to include pre-releases, otherwise you won't see it.

I will improve the tests around the UWP support before I feel confident to officially release it. Please let me know if you find any bugs.

Oh, btw, in UWP you no longer have to register the views in XAML, just use the dialog service as you otherwise would.

@k563
Copy link

k563 commented Apr 20, 2016

Great framework ! I've been looking at the WPF version, most impressive, especially the comprehensive tests for both the framework and the demo app. The UWP version looks interesting as well - is there a demo app and a set of tests for that version too ?

@FantasticFiasco
Copy link
Owner

I've released the UWP support as beta because I'm not confident with the testing situation. I'm currently in the process of implementing automated UI tests for both the WPF and UWP version of the framework. After that I plan to update the documentation, and after that I will officially release the UWP support.

To answer your question, the demo app will be replaced with numerous applications that are used in the automated UI tests, and will also serve as blueprints for how one would use the framework for a specific feature. Due to MVVM Light being incorporated in the .NET Foundation, I've also decided to move away from Reactive UI in favor for MVVM Light, thus building on a platform that should be familiar for most UI developers.

@k563
Copy link

k563 commented Apr 20, 2016

Many thanks for your instant reply - great news, I'm really delighted that
this excellent library will be available both for WPF and for UWP, and that
there will be a suite of examples - sadly lacking in most MVVM frameworks.
I also approve of the move to MVVM-Light ; which happens to be the
framework I've adopted too, having been interested in ReactiveUI but
frustrated at the lack of docs and examples.

A minor point about the UWP IDialogService : might it be better to return
Task instead of IAsyncOperation ? That might make it possible to use
the same flavour of IDialogService in both WPF apps and UWP apps, rather
than having distinct (albeit similar) interfaces, if the WPF version were
also to return Task ...

On Wed, Apr 20, 2016 at 7:58 PM, Mattias Kindborg [email protected]
wrote:

I've released the UWP support as beta because I'm not confident with the
testing situation. I'm currently in the process of implementing automated
UI tests for both the WPF and UWP version of the framework. After that I
plan to update the documentation, and after that I will officially release
the UWP support.

To answer your question, the demo app will be replaced with numerous
applications that are used in the automated UI tests, and will also serve
as blueprints for how one would use the framework for a specific feature.
Due to MVVM Light being incorporated in the .NET Foundation, I've also
decided to move away from Reactive UI in favor for MVVM Light, thus
building on a platform that should be familiar for most UI developers.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8 (comment)

@FantasticFiasco
Copy link
Owner

I had to think on this one. I really like the idea of an uniform API across WPF and UWP, however there are a couple of problems.

  1. Task was introduced in .NET 4 but MVVM Dialogs are also available for .NET 3.5. So if I changed the WPF API to feature Task I would have a discrepancy depending on the .NET version you where using.
  2. Up to this point I have tried to keep the API as close as possible to the .NET API, to have a sense of familiarity when starting to use MVVM Dialogs. Whether there is any value in that, well I have no idea. I haven't heard that the API is easy to understand, nor that it is hard.

I would like to thank you for asking these questions, feedback is why I am involved in the open source community. Thank you!

@k563
Copy link

k563 commented Apr 22, 2016

I take your point about continuing to support 3.5, but in fact Microsoft
are recommending that everyone update to 4.6.1 at least. Apparently 3.5 is
no longer officially supported - see
https://support.microsoft.com/en-us/lifecycle?p1=13003&wa=wsignin1.0 ; and
https://blogs.msdn.microsoft.com/dotnet/2015/12/09/support-ending-for-the-net-framework-4-4-5-and-4-5-1/
; So, I would have no qualms about making it necessary for users to update
to 4.x !

You API is perfectly easy to understand ! My only comment would be that it
seems unnecessary to return 'bool?' (ie nullable) when the only possible
return values are true/false (from reading the docs about the underlying
Windows API's that are being called).

Introducing Task<> definitely makes things harder to understand, and there
are a lot of subtle pitfalls (as explained in various excellent articles by
Stephen Cleary, can send links if you're interested). Maybe it would be
better to keep a distinct API for the UWP platform, in the interest of
keeping the WPF API simple.

On Fri, Apr 22, 2016 at 6:51 AM, Mattias Kindborg [email protected]
wrote:

I had to think on this one. I really like the idea of an uniform API
across WPF and UWP, however there are a couple of problems.

Task was introduced in .NET 4 but MVVM Dialogs are also available for
.NET 3.5. So if I changed the WPF API to feature Task I would have a
discrepancy depending on the .NET version you where using.
2.

Up to this point I have tried to keep the API as close as possible to
the .NET API, to have a sense of familiarity when starting to use MVVM
Dialogs. Whether there is any value in that, well I have no idea. I haven't
heard that the API is easy to understand, nor that it is hard.

I would like to thank you for asking these questions, feedback is why I am
involved in the open source community. Thank you!


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8 (comment)

@FantasticFiasco
Copy link
Owner

I will take a look at the nullable bool situation. If null isn't returned, I will change the API.

Regarding the links to Cleary's articles, please send them. We live to learn, right?

@k563
Copy link

k563 commented Apr 22, 2016

Here are some of my favourites ...

Await, and UI, and deadlocks! Oh my! (Stephen Cleary)
http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115163.aspx
http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html

Async Programming - Brownfield Async Development (Stephen Cleary)
https://msdn.microsoft.com/en-us/magazine/mt238404.aspx

Async/Await - Best Practices in Asynchronous Programming (Stephen Cleary)
https://msdn.microsoft.com/magazine/jj991977

Async Programming : Patterns for Asynchronous MVVM Applications: Data
Binding (Stephen Cleary)
https://msdn.microsoft.com/magazine/dn605875

Async Programming : Patterns for Asynchronous MVVM Applications: Commands
(Stephen Cleary)
https://msdn.microsoft.com/en-gb/magazine/dn630647.aspx?f=255&MSPPError=-2147217396

Concurrency in C# Cookbook
https://www.amazon.co.uk/Concurrency-C-Cookbook-Stephen-Cleary/dp/1449367569

It's actually quite sobering, to see how easily it is to screw up 'async'
programming without a quite deep understanding of what's going on :(

Yup, we live to learn ... but these days the amount to know is getting
rather overwhelming ...

On Fri, Apr 22, 2016 at 3:39 PM, Mattias Kindborg [email protected]
wrote:

I will take a look at the nullable bool situation. If null isn't returned,
I will change the API.

Regarding the links to Cleary's articles, please send them. We live to
learn, right?


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8 (comment)

@FantasticFiasco
Copy link
Owner

Version 2.0.1 is now live on NuGet and officially supports UWP. Thanks for all the feedback guys, its much appreciated!

@k563
Copy link

k563 commented May 19, 2016

Looks really useful - thanks especially for providing all those nice
examples, which are often not present in open source projects ... that was
what ultimately put me off ReactiveUI ; although it seemed very elegant and
clever, it was just so hard to figure out how to use the library correctly.
Going with MVVM-Light was a good decision !
Steve

On Thu, May 19, 2016 at 12:33 AM, Mattias Kindborg <[email protected]

wrote:

Version 2.0.1 is now live on NuGet and officially supports UWP. Thanks for
all the feedback guys, its much appreciated!


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8 (comment)

@rockthethird
Copy link

My apologies for just now being able to finally resume work on my project which incorporates your fine library. If there are any issues I will be sure to add my findings to the discussion. Thanks again for all of your hard work.

@FantasticFiasco
Copy link
Owner

@rockthethird No worries Mr In Christ, Rock, I took my sweet time to finish this en devour. Don't feel that I expect anything from you, you participating in this issue is enough for me.

If you publish anything about your work, please send me a tweet or something!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants