|
i haven't really done too much reading but i think my investment in WPF is now considered obsolete.
dev
|
|
|
|
|
Why is your investment in WPF now considered obsolete?
|
|
|
|
|
i havent read much but is it true Metro apps runs on WinRT API and WPF/.NET all considered obsolete?
Read this?[^]
dev
|
|
|
|
|
devvvy wrote: but is it true Metro apps runs on WinRT API and WPF/.NET all considered
obsolete?
No. You can still run WPF/.NET apps on Windows 8. Where you get some confusion is in what you can run on Windows 8 running on ARM processors.
|
|
|
|
|
From wikipedia:
Quote: Limitations
Only software written using the Windows Runtime (Metro style apps) can be used on Windows RT with the exception of Microsoft Office 2013 and the desktop version of Internet Explorer 10. Developers will not be able to create applications to run on Windows RT using the Win32 APIs.[10]
Eusebiu
|
|
|
|
|
Now read what I actually answered, not what you think I answered. Did I state WinRT, or did I state Windows 8? WPF and .NET both happily run on Windows 8.
Oh, and Wikipedia isn't always correct - something to remember before you quote from it.
|
|
|
|
|
Dude, Windows 8 has four editions; Windows 8 RT (if you like, WinRT) one edition of Windows 8.
So, when you say "Windows 8...", you have to complete the rest of the sentence when it comes to development.
In this case, Wikipedia is correct. And I did not say that Wikipedia is always correct - you assumed that I always think that Wikipedia is always correct (which is not true).
Eusebiu
|
|
|
|
|
Eusebiu Marcu wrote: you assumed that I always think that Wikipedia is always correct
No I didn't. I just pointed out that quoting Wikipedia isn't always a guarantee of reliability.
Eusebiu Marcu wrote: Dude
Please don't. I'm a middle aged white man from the UK. In no way do I qualify as "dude".
Eusebiu Marcu wrote: So, when you say "Windows 8...", you have to complete the rest of the sentence
when it comes to development.
Again, no I don't. Read what I put again. I merely stated that you can run WPF and .NET apps on Windows 8 so the skills aren't dead. There's a reason I mentioned the ARM processor - and that's because that's the one environment where you can't run them.
|
|
|
|
|
Sorry for the "dude".
For the rest... whatever!
Eusebiu
|
|
|
|
|
Pete O'Hanlon wrote: I'm a middle aged white man from the UK. In no way do I qualify as "dude". I was about to say I'm a middle aged white man from the US. and I think I do qualify as "dude".
Then I remembered when I was 25, declared I was middle aged and when asked why, said the current life expectency is 75, so 0-25 is youth, 25-50 is middle aged, 50-75 is old age and anything beyond is bonus time. Using that criteria, I've been old for nearly a decade, but still think its OK to call me dude.
Then there is the definition of dude as someone who is inexperienced and naive. (IE Dude Ranch) I didn't even think to take it that way.
So, being from the UK, you're too staid and stuffy to be a dude? Or are you too old? (The Great Wobowski would disagree with that one.)
That kind of reminded me of the song that goes "when you only live a hundred years..." When I first heard that, I thought "You're a singer, what makes you think you'll pass 40?" along with the documented cases of people going past 110. What does age have to do with your "dude"ness?
|
|
|
|
|
Staid and stuffy. Definitely. I cringe when I think of the crap and stupidity I came out with in my teens and twenties, all in a futile attempt to be hip and cool. Being a dude was one of those things, and I am old enough for it to have different connotations, going back to all the young dudes.
|
|
|
|
|
Pete O'Hanlon wrote: Staid and stuffy. Definitely. Said by someone who would also say
Pete O'Hanlon wrote: pre-emptive celebratory nipple tassle jiggle
|
|
|
|
|
Actually, that was said by Sean.
|
|
|
|
|
Pete O'Hanlon wrote: Actually, that was said by Sean. True, but you think enough of it to include it in your tag line. Even if you are repeating someone else's saying, you are saying it.
I'm too lazy to add a tag line, so you're more hip than I am.
|
|
|
|
|
Pete O'Hanlon wrote: Please don't. I'm a middle aged white man from the UK. In no way do I qualify as "dude".
Quite right; the correct form of address is clearly "Brosicle".
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
You can absolutely write WPF/C#/.Net apps, in fact the Windows Runtime (henceforth WinRT) is just a COM based wrapper around exiting APIs already present in Win32 and the .Net framework and apps can be made in C# or C++ with UIs built in XAML (also in HTML/JS). There is also a set of APIs that are "whitelisted" that are present in the Win32 APIs but are not present in WinRT, that can still be included in store apps and work on Windows RT systems.
So your investment in WPF didn't get obsoleted, it just went multiprocessor.
|
|
|
|
|
Yes I know WPF will run on Windows 8 - but is it considered obsolete that Metro is the new and upcoming and all new candies will be allocated to Metro and not WPF?
Remember Winform > WPF > Metro evolution?
When WPF came out all of sudden seems like Winform no longer cool or funky, like a piece of old technology ready to be spitted out even by Microsoft itself
dev
|
|
|
|
|
No I don't think you understand me.
I'm not saying WPF runs on Windows 8 (which it does on non-RT systems), I'm saying if you have a significant investment in WPF then that investment isn't lost because the development environment, methodologies, and tools are the same ones you'll using to develop Windows Runtime apps. The composition of which is very much like what you'd find on Silverlight or Windows Phone.
If you're leveraging MVVM at all via Caliburn Micro or MVVM Light, those tools are already or soon coming to the Windows Runtime. We have been able to rapidly move our view models from Caliburn Micro desktop apps to Metro apps and it's been an amazing experience in comparison to some the other feature shifts in the .Net world (which I think is the crux of your Winforms example). We also heavily leverage Autofac in our environment, and it has been built as a portable class library for some time now, enabling us to simple tweak (not rewrite) our code and it again has been a top notch experience.
Summing up my rant: WPF isn't going anywhere with the shift to the Windows Runtime, it's just changed slightly. (and did I mention that the desktop isn't going anywhere either
|
|
|
|
|
... I'm not interested in moving our view models from one environment to another, I'm not least bit interested in "Paradigm Shift" - I just want publish apps and income stream coming in.
Unless there's a real increment to capability (i.e. monetary incentive) offered by the new environment/framework, it's a complete waste of effort to migrate to the new platform. Our experience moving from Winform to WPF was exactly this - that the then newer WPF platform was nothing more than a "Paradigm shift", there's no real addition to what Desktop Apps can do. (Imagine yourself having to justify Winform to WPF migration?)
Same can be said for Socket>WebService>WCF migration. Everything from serialization/compression/encryption/load distribution can be so easily done by code/libraries previously written, why bother with hassle of having to memorize WCF configurations? So much hype and so little "Capability".
Now, having read this[^], it appears that "Desktop Apps" (WPF/Winform) will continue run on Windows 8. However, "Metro Style Apps" (touched based/enabled apps) will be built on top of the brand new WinRT API. If I'm not mistaken, the only real addition this time around is that Metro Style apps will be "Touched Enabled", and "Tablet like".
I guess, we need to revisit the fundamental questions every so often
- What can computer do [differently]?
- What can you application do [differently]?
Way I see it, Windows 8 and WinRT - sounds like small/incremental improvement but a lot of code changes/work be done to port code from .NET to WinRT. "Radical" is a gross over-statement.
dev
modified 18-Oct-12 11:34am.
|
|
|
|
|
Chris Maunder wrote: The split of the UI, however, is so clumsily done that the fall is the worse for it being on something that should be so much better.
I agree that it is quite clumsy, and the context switching is a jarring experience, but from a UX perspective it gets even worse.
One of my first experiences when I installed Win8 on my laptop last week was installing Chrome then logging in to Twitter. After a bit of dev work I alt+tabbed back to Chrome, navigated to Twitter then discovered that it had forgotten my credentials.
After much head-scratching I realised that I had logged in and stored my auth details on the 'Metro' Chrome, but the second time had navigated to a desktop Chrome Window. Your "average joe" user is never going to work that one out!
As an app developer I really want to communicate between these two divides in the OS. For example, if I developed a desktop / metro twitter app I would like to share state so that an end user could use the Twitter client in desktop mode at their desk, then pull their fancy tablet from the dock to go for a walk, open up the Metro Twitter client and find their feed is at exactly the same scroll position.
I'm tempted to write a simple concept app to show how I think this sort of thing should be done!
Colin E.
|
|
|
|
|
Colin Eberhardt wrote: I'm tempted to write a simple concept app to show how I think this sort of thing should be done!
Please do! Seriously - this would be incredibly valuable.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Are you going with the message bus approach? That's what I've been playing around with - getting it sitting nicely in the MVVM world takes a little bit longer, but it's worth perservering with. Hmmm - I'm currently working on a Windows 8 desktop app - it wouldn't take much to reuse the code base inside the Metro world.
|
|
|
|
|
message bus? no - I had a completely different approach in mind. I'd really like to have app session state that is cloud-based and accessible from any device. That way you can move from one device to the next, from desktop, to metro, to phone.
Just wondering what you mean by message bus? I have seen a few WCF-based solutions. Is there something more standard?
|
|
|
|
|
I misspoke using the term MessageBus - strictly speaking, what I am talking about is using a ServiceBus. I'm currently using one that runs on a single machine only, but it wouldn't be that hard to convert it to use the Azure Service Bus to give the same functionality you are describing. Effectively, it would just be a plug and replace version for the service bus we are currently using.
I got the idea for this from Mike Brown months ago - I'm pretty sure the germ of your idea will have come from the same source, so it will be interesting to see what you've come up with.
Incidentally, I'm porting your Phone Interaction stuff to work with WPF on Windows 8. That's been quite interesting.
|
|
|
|
|
Colin Eberhardt wrote: I'm tempted to write a simple concept app to show how I think this sort of thing should be done! Don't just be tempted...do it!
We could use to see such an app.
|
|
|
|