← Back to context

Comment by WorldMaker

8 years ago

I think the evolutionary path connecting WPF and "this WinRT stuff" is extremely clear and if you've built WPF you can build UWP. UWP .NET/XAML is great to work with if you know WPF, it's truly a successor to WPF in every way. (It'll be even better soon [as in next month] thanks to .NET Standard 2.0.)

18 comments

WorldMaker

Reply
emodendroket  8 years ago

That may be so, but WinRT comes with a bunch of limitations, so there isn't really a no-brainer choice for application development, and also, considering how deeply it's associated with the unpopular Windows Store app and Windows phone, who wants to throw in their lot with it? Frankly it hasn't seemed worth investing that much time into any of them and I pretty much just end up reaching for yet another WinForms MVP app. But WinForms practically works against you in the effort to separate UI from behavioral code so that isn't that satisfying either.

  • WorldMaker  8 years ago

    Limitations change as API priorities shift. The platform has grown over time. Some inherent limitations are useful (to be a medium to creativity, to the user's control over their system overriding a developer's narcissism, to the idea that security and reliability are worth engineering for), and yes, unlikely to disappear entirely.

    I can't dispute the unpopularity of Windows Phone, but from what I hear the Windows Store is fairly successful in Windows 10. Many consumers use it to install apps, which is a judge of popularity. However, if by popularity you instead mean sentiment, then I get the impression that currently most people are ambivalent about the Store in so far as it is a pragmatic tool that people neither love nor hate, just as most people neither love nor hate their toaster so long as it toasts. (Certainly there are haters, but volume of their voices is not necessarily an indication of their size/number/consumer spending activity per the first definition of a popularity, just a reminder of the passion with which they feel their sentiment.)

    • int_19h  8 years ago

      > from what I hear the Windows Store is fairly successful in Windows 10.

      Here's one data point for you. Windows Store used to have an official Kindle app. It doesn't since the end of last year, because Amazon basically said they don't see the return on that investment. They now recommend their desktop Win32 app if you want to read Kindle books on Windows.

      Needless to say, iOS and Android do have well-supported Kindle apps.

      1 reply →

    • orbitingpluto  8 years ago

      One of the key issues for me purchasing on the Windows Store is that my purchases my disappear at any moment. I have had half of my purchased apps disappear.

      And it is next to impossible to get a refund.

      Last week I noticed that my purchased music on Groove has disappeared ahead of the end of year termination of service.

      1 reply →

  • tonyedgecombe  8 years ago

    I'm still maintaining a WinForms app, the only problem I've had is dealing with high dpi displays is really messy.

    • emodendroket  8 years ago

      The biggest pitfall on a project you work on with other people is how much it tempts you to just put all the behaviors into the code-behind of the form.

int_19h  8 years ago

The problem with UWP is that it requires Win10. This makes it a no-go for vast majority of developers targeting desktop Windows, given that Win7 is still dominant, and will be for a while to come.

  • themacguffinman  8 years ago

    Why MS didn't create a UWP emulator or wrapper for Windows 7 is beyond me. No Windows 7 compatibility is the main reason my company isn't bothering with UWP for our desktop software.

    • WorldMaker  8 years ago

      It's the same problem that you have, isn't it? You don't want to support two codebases, you just want to build your app once and have it run in two places. It costs time and development budget to maintain two different codebases, and you have to prioritize. Can you really blame Microsoft that they don't want to maintain both a modern codebase and a completely separate fork/back-port of it for a much older branch?

      That said, it has been possible to share a lot of code (if not almost all of it) between a WPF and UWP app for a while now with PCLs, or after that targeting .NET Standard. That gets even easier once UWP support for .NET Standard 2.0 ships soonish. There's also been work recently on Xamarin.WPF for Xamarin's cross-platform code sharing, and the XAML Standard 1.0 work trying to converge much of the XAML across all the platforms Xamarin supports and UWP to get rid of a some of the dialectal nuances.