A manager asked me to do some quick research on the possibility of doing Silverlight development on Windows CE devices.
After 15 minutes I was surprised that:
Silverlight for Windows CE seems to be nowhere in sight, with some sites wanting to report it so bad they they are quoting twitter tweets as their source of news, the word "mobile" is even missing on Silverlight 3 Feature Lists but you find it in the comments with people saying things like I was hoping to hear an update on getting Silverlight onto Windows Mobile and Nokia devices.
Windows CE 6.5, which is not even out yet, is getting scathing reviews such as this article which basically says: nothing new, interface improvements behind the curve, UI tweaks (honeycomb) skin deep, no capacitive touch screens, not due till Q4 2009, not backwards compatible, no zune, no new windows media player, no decent screen keyboard, browser pales against competition and, number 10: by showing little innovation on their latest mobile OS, Microsoft is showing zero leadership in the mobile space. It seems that Microsoft is weakly limping along in the shadow of the iPhone. The apparent lack of Silverlight on Windows CE 6.5 didn't even make the list of woes.
I thought things were different. So I sadly have to report that Silverlight on mobile devices may have to wait a year or more.
Does anyone have any more positive, substantial news that I can report about Silverlight on mobile devices?
Update by YMS (not the original OP):
This question is somehow deprecated now that Windows Compact 7 has been released with (some kind of) Silverlight support.
I also very recently researched the use of Silverlight on Windows CE. The result is that while it seems to be almost there, with videos showcasing it from MIX08, it may be released some time this year, but likely not in the first half. They said "some time 2009", and for some months now, it was in "private testing".
Because of that, while I'd love to use Silverlight, I decided to go with OpenGL ES 2.0 and OpenVG, which is fully hardware-accelerated on our current target device. Plenty of power and not that hard to use, even from .NET Compact Framework.
Oh, and the iPhone is all that cool for a phone (or a music player), but Windows CE is available for many more devices, including non-personal-gadget / non-mobile products. That's an area where Apple does not shine because they don't license their platform.
I've heard rumors that the UI for WindowsMobile 7.0 will be Silverlight/WPF based. It doesn't sound like Microsoft is putting any effort into any version before that, because as soon as WM7 is out, they'll want to kill anything off that came before.
Related
I have asked this question several time form many developers about the future of WPF in 2015 and in coming years. Someone told me that Microsoft is interested to take this technology in the future also.
Actually i like to develop enterprise and LOB business application in Winforms and now want to move to WPF. Time is short and i need a concrete answer that should i invest my time in WPF or not? If the answer is not then what is the new Microsoft tool to develop business application like Point of sales applications and other large database business applications. I have a keen of new technologies so i don't want to invest my time and money in old technologies. If Microsoft is also not interested in these technologies then i am not also.
So please anyone can tell me that what is the best and new suitable technologies to create business application now a days from Microsoft?
Thanks.
I'll chime in.
This is a tricky conversation because we are on the verge of Windows 10. Let’s start out talking about Windows 8. WinRT XAML for Windows 8 is certainly not ready for you to use it out-of-the-box for to create a full-featured, LOB application. There are too many things missing like validation, windowing, and advanced binding. The Ent. app was not it's primary mission.
On the other hand, WinRT XAML for Windows 8 is perfectly suited for creating a companion, touch-first app that delivers value to tablet-based or phone-based users who would interact with your app in a more limited way – like reporting or workflow. I talk about this more here:
http://blog.jerrynixon.com/2012/08/windows-8-apps-whats-enterprise-to-do.html
WPF is a different story. WPF is proven, right? It totally is. There’s nothing you can dream up that WPF can’t do great. No line-of-business requirement holds it down. It's awesome. What’s more, is that WPF runs on Windows XP, Windows 7, Windows 8, and soon Windows 10. That’s a lot of operating system options.
The future of WPF is quite bright, too. The team is reinvigorated and the improvements slated this year and the new tooling for XAML developers makes it an even better experience. I talk about that more with the WPF team here:
http://blog.jerrynixon.com/2014/11/hey-future-of-wpf.html
WinRT XAML for Windows 10 is different. For one, it’s not going to be an operating system-based system. That means, more like .Net, you just target the framework you require installed and go from there. It is also more fully tooled to compete with the fidelity of WPF XAML to build LOB apps.
But with WinRT XAML for Windows 10 you have to ask yourself how many people will be running Windows 10 because it will not work on previous versions of Windows. Since Windows 10 will offer itself as a free upgrade for the first year, you could argue that many will be running Windows 10, but since the Enterprise version of Windows 10 is not part of that deal, you can only determine that by knowing your IT roadmap. Nobody can do that for you.
All things being equal, if you are simply trying to choose between WinRT XAML for Windows 10 and WPF today, you will choose WPF. Once you have an adequate install base of Windows 10, I think most LOB developers are going to be surprised how tempting an option Windows 10 is. The future of WPF is solid. But the most significant investment into UI technologies at Microsoft is, hands down, WinRT XAML for Windows 10. Does that mean WPF is not future-proof? Of course not. I would choose WPF without any hesitation, as I have done for years.
Best of luck!
Anything can be a gamble, especially with Ms. They (and Intel) tend to throw darts at a wall and when one sticks, it marks the current direction for the week.
According to Microsoft WPF never went away. They forget to tell many employees that. For a while XAML was so very WPF like it was almost the same thing, and for a point of sale system, it seems like if you are going a Microsoft direction, XAML would be the better choice. But again, it is almost the same thing; Windows store app with XAML as opposed to desktop app with WPF. But the direction of the week is yes WPF will go forward and even possibly be Ms strategy for cross platform.
But I would also really ask is Microsoft the right choice for your target? I would think heavily about Android. Not so much just Java, last I looked their roadmap had wpf like functionality targeted for 2024. Or iOS as I don't expect to see Apple sell a cash register anytime soon, so I doubt if they will ever be in the Point of Sale business.
I did a fairly big Point of Sale system a long long time ago. Actually 2 of them. With what I know I would target XAML/Store apps today. But it is about a 51/49 split with Android in my mind. If the customer wanted Android, I would not argue very much.
When I create new Windows Phone project I have an option to create a "Windows Phone" or "Windows Phone Silverlight" app. I know that they have different runtimes and different APIs.
I was under the impression that Microsoft wants to unify Windows and Windows Phone platforms so why is there even a Silverlight version? What benefits does it bring?
Also, if I want to create an app just for Windows Phone and never have plans to bring it to Windows, what should I choose, Silverlight or Windows Phone?
I'd suggest you go with "Windows Phone" (non-Silverlight). It's the new API, which works for both Windows and Windows Phone. At some point you may want to port the app or create a new one for Windows and you'll already know the API (and porting will be way easier). Also, the new API will most likely get more updates and features added, and at some point you may even be forced to update to it (either because the old one is no longer supported, or because it does not have some features that you need).
As it was said in the other answers - the Silverlight option is there only for backward compatibility and is likely to be phased out in time. That is - it's good if you already know the API and have many libraries (yours or others) for WP Silverlight, but if you're just starting - you'd better go for the new technology.
Edit
There is one other thing to consider before choosing between the two types of apps. Some features are only available in a Silverlight app, and others (smaller amount) - only in a Xaml app. Here's an article with some info on the differences: Migrating your Windows Phone 8 app to a Windows Runtime XAML app
Windows RT Xaml is quite new and People have to generate some knowledge first.
Silverlight for phone has been around for years and there's a load of tools available: Phone Toolkit, diverse Controls, etc.
Just killing it off would have hurt many developers who built up intellectual property over a long time forcing them to start over.
When starting a project with Silverlight you will have more things around that help you get stuff done.
When starting with WinRT Xaml, you will have better performance, but will have to figure a lot out by yourself.
So the Silverlight option is there to not throw of Silverlight developers.
I recently started a new project on WinRT Xaml and my experience was that I had to recreate a lot of common tools like Caches, etc. But also a lot of things that were in Toolkits previously are now part of the platform itself. Also, when moving over to Windows 8, you get to share a lot of code which is nice.
Unifying the environment(s) would be ideal. In my opinion, it hasn't been very successful. At one point in time, you could only develop under Silverlight, so what you are seeing is just a newer version of the same thing to keep backwards compatibility as well as to keep Silverlight's developers happy. In the future, it will probably be phased out. Plus if you want to support older Phones, Silverlight is basically your only choice (you'll be surprise, how many WP users haven't updated their 8.0 to 8.1)
There really isn't any other real benefit of Silverlight other than maybe the Windows Phone Toolkit which has been tremendously useful (you can see how many SO's answers rely on this simple addon). Once the universal runtime gets fleshed out to the point where the documentation reflects what's actually available -- then I think it would be the default project for developing in Windows going forward.
If you're just starting, I would use Silverlight the knowledge based is much greater. After you get use to the WP environment then switch to runtime.
I'm interested in making a desktop application which I would want to use as a Desktop Manager. This kind-of goes to Desktop Enhancement Category. My requirements are:
Application has to be visually rich, with panels sliding,fading,wiping,rotating and etc.
It should also support flash playback. (swf, flv)
Animations/Transitions should run smoothly.
Lower CPU Usage.
My question is which is a better option to build this application. Microsoft's "WPF" or Adobe Flex(running in Adobe Air to run on desktop). And also respond as why it is better.
Be suspicious of anyone who will give you an answer like "Definately use xyz" to this question. There are pros and cons to both sides.
First, I think you might be confusing what WPF and Air are... WPF is a presentation layer on top of the .Net framework, where Air is a framework by itself. Apples and Oranges. If you want an analog to what Air is for the .Net stack, you probably want to look at Silverlight Out-Of-Browser, which is a much closer comparison to Air.
What is the difference, then, between WPF and Sliverlight OOB? Again, WPF sits on top of a very large .Net framework where Sliverlight OOB is a very light framework (in comparison) like air. It is the difference between a 200 MB download/install and a 12 MB download/install.
So, that being said, I think you should also ask what platforms this needs to run on. Silverlight OOB runs on Mac and Windows where WPF only runs on Windows. Air runs on Mac, Windows and Linux.
The next thing that I see is that you need to do SWF and FLV playback. This will be easier to achieve with Air, since it is native. You CAN do this with Silverlight OOB but you will find yourself rigging something up where you host an HTML control and run the flash movie inside the HTML control. It is a bit more clunky, but it will work.
Other than that, Air and SLOOB are very similar in features. It then comes down to your team and the expertise, IMO. If they are already familiar with the WPF/Silverlight, then a SLOOB app is well suited with minimal ramp-up. If your designers are more familiar with the Adobe suite of tools, then it might be easier to build a shiny app using Air.
In all, the decision between Air and Silverlight/WPF really comes down to preference. That is, once you get past any particular techincal limitations like the flash playback or OS support.
Hope this helps,
Brian
So Windows Embedded Compact 7 (another classic from the naming department) supports Silverlight for Windows Embedded.
http://www.microsoft.com/windowsembedded/en-us/products/windowsce/compact7.mspx
But this is a C++ only stripped down version of Silverlight 2 XAML.
Does anybody know if Windows Embedded Compact 7 will support real Silverlight? This seems to be out of step with Windows Phone (which I think is based on Windows CE 6) and the fact that Windows Embedded Compact 7 supports Flash 10.1.
Not in the first release, no, it will not support managed Silverlight (or, IMO, what the entire world considers to be "Silverlight").
They may, at some point, move the work done by the Phone team to create a managed SL implementation, but they've made no announcements as to if or when that might ever occur.
You'll see "Developers,Developers" Balmer come out later like he has done before and admit they made a mistake with this. Its the developers that produce the apps and if you make all the microsoft technologies linq, wpf, ria and patterns such as MVVM unuasable developers won't trust you and move to another platform. They dropped the ball on the Phone OS by not having a great consumer oriented phone. Now they will focus on consumers stick it to the business developers that they had built up on Windows Mobile. They did a great job with the silverlight 4 so I don't understand how they can drop the ball this badly on Compact 7.
I agree about the non-uniform development environment, but you should also consider that the processor that are currently powering WP7 devices are not still available on the general embedded market where 1GHz processors are a small minority and 5-600MHz processors are used only for hi-end devices.
Trying to run both the XAML and the .NET runtime could lead to weak performances and disappointing results.
If you need RAD, use the Compact Framework.
If you need cool UI, use Silverlight for Windows Embedded.
You can't have both right now, as you can on the phone...
I'm considering switching from MFC to WPF.
My first concern is that there are too many users who don't have .NET with WPF installed yet. Can anybody point to a source containing the WPF penetration numbers?
My second concern is speed.
Any other considerations?
I've been banging away at WPF for a while now. It is brilliant, but it still has (occasional) holes you've to plug yourself. However all indications are .NET 4.0 will be a significant step forward.
I would say start now. The WPF learning curve is REALLY steep, and it'll be a while before you'll be releasing software to users, believe me. Also do yourself a favour and get the WPF Unleashed book. It's superior.
Speed isn't a consideration. The power WPF gives is well worth any drawbacks with speed, which - coming from Windows Forms - I haven't noticed to be honest.
What kind of application are you developing? If it's a wide-distribution desktop app that you want your grandmother to install, your concern about .NET 3.0/3.5 adoption is valid. So far from what I've seen, performance is less of a concern.
WPF penetration
First of all, Windows Vista and Windows 7 both have WPF preinstalled, which accounts for 35% of the market automatically. Windows XP has had it as it had .NET Framework 3.0 as an option in Windows Update for over three years, and many applications ship with it, so it is likely to also be installed on a high percentage of Windows XP machines. StatOwl indicates that about 80% of NET Framework installations are version 3 or above.
If you're shipping on CD it is no big deal to include the latest .NET Framework on the CD and have it install automatically. If users are downloading your application, it can contact Microsoft's web server to download and install the latest .NET Framework. Online ClickOnce deployment also has this capability if you want people to be able to start their application directly from the web browser without installing it.
So the bottom line is, you probably don't need to worry about whether people will have WPF installed on their machines or not unless your target market consists primarily of dial up customers on Windows XP who don't run much third-party software (i.e., they just run Windows and your application).
Speed
Not an issue. I have a 200 MHz Pentium Pro with 384 MB RAM from 1998 that I test my software on, and my WPF applications have comparable performance with equivalent MFC applications. If your WPF application uses lots of fancy graphics and animation it will run slowly on ancient CPUs and graphics cards, but so would an ordinary MFC application with the same features.
Don't even bother trying to use WPF if you are sticking with Visual Studio 2008 for the next year or two. The experience will be way too painful. I'm talking about "my IDE crashed again" type of pain.
If you are going to use VS 2010 in the near future, then WPF is a blast. Download the beta, a couple of themes off CodePlex, are start playing. Once you get past the (freaking huge) learning curve I think you will find it to be quite enjoyable.
IMHO, you should wait for Visual Studio 2010 and WPF 4.0 to make the actual migration. They will close some very annoying gaps in the product.
Meanwhile, you can try it out. In terms of coding/readability -- it's going to be WAAAY better than with MFC =)
As for the performance and platform -- it shouldn't be a problem unless you have any very special circumstances (like if you can't require users to install .NET).
Also see this related question on switching to WPF from Windows Forms.
If you are thinking about a larger, modular, appliation I recommend checking out Prism. It's a bit of a beast itself, but you should be able to tackle it after coming to grips with C#, Dependency Properties and XAML. Plus, learning Prism gave me a much better understanding of WPF/Silverlight, at least from the development/binding side.
Mike Taulty posted an excellent 10 part video series on Prism. It's a great way to get your head around the platform.
I'd also recommend the pages linked to from the Getting Started page on codeplex. After all that, you're probably ready to tackle the Reference Implementation which comes with the download.
A previous answer of mine might also help clear up any remaining confusion around Controllers/Presenters in the framework that you might have (I did).