Two interrelated questions:
For an app suite with an app for each major device platform (iOS, Android, Windows Phone 7, and WinRT), is Silverlight a good platform for a "downlevel" (Mac/7/Vista/XP) version of the WinRT app?
If so (or to make it so), what Silverlight components emulate the Metro controls and their themes to minimize the effort of making the Silverlight app consistent with the WinRT app?
I don't think so. Silverlight does not give you the kind of touch support you need to truly match with a Metro style app. You can use things like NESL or roll your own gesture library, but it can never really match the type of experience you will get from a Metro style apps and of course stops being cross platform at that point. The closest I've ever come is building a Silverlight full-screen out of the browser app where we rolled our own gesture library and it was still unsatisfying.
Metro is a new and unique design language and without an OS that has been built from the ground up to support the experience, you will find it a bad experience and worse, you will be battling the technology the whole way.
Responding to comment: It absolutely can be done. See http://www.flickr.com/windows7 for example.
Related
I have a winforms application and was wondering whether I should attempt to move it to Windows store app (and WPF) or not. I would expect metro style apps to have the same potential as desktop apps, but what got me wondering is the fact that VS 2012 is not a metro app. It doesn't really surprise me much as every metro app I've seen so far look like a phone app that can't really do much and I can't imagine how VS would look like as a metro app.
Seems to me like Microsoft wants to slowly move everything to metro, otherwise I don't see the point on introducing a whole new visual experience just to get stuck with having to switch between metro and desktop, but even Notepad is still a desktop application. So my question is, basically, is every kind of application supposed to be movable to metro or is metro only for small phone-like applications?
I don't believe that Microsoft is intending every application to end up Metro. I see more lightweight types apps going to Metro. Heavy duty line-of-business apps will stay on the desktop side of things.
I do see an opportunity for writing both desktop and Metro style apps in enterprise environments though. Imagine this hypothetical scenario:
In an enterprise, I can see Accounts Receivable running the full-blown, monolithic, desktop application on their desktops just like they run them under Win7 because they’re needs are pretty extensive.
The receptionist will run a touch enabled laptop with a Metro app that is tied into just the corporate appointments.
The guys on the loading dock will be running Win8 phones that have the intake/outtake app showing schedules for deliveries and what not.
Managers and executives have Metro tablets that have an app that shows metrics: lots of pretty charts and graphs showing the current condition of what and how the company is operating in it’s different lines of business.
For the users that need the complexity, it’s desktop mode, but for the users that perform smaller, specific computer tasks, touch-enabled Metro apps for them.
Metro-style apps are for content consumption, like you would find on a tablet.
Classical desktop apps are for content creation.
I think metro apps are an additional feature and I do not think, that they are a serious replacement for desktop applications. If you want to deploy your apps to tablet PCs, phones or any other touchscreen/handheld devices, metro style would be a good choice. At the moment there are just not many consumers for metro apps as Windows 8 has not even come to the markets.
As you already mentioned, on desktop PCs metro apps are very uncomfortable and do not provide the full functionality as desktop applications can do.
So my question is, basically, is every kind of application supposed to be movable to metro or is metro only for small phone-like applications?
I don't think so, as this means automatically that many customers who have used previous versions of Windows would have to learn working with the metro interface.
Metro apps provide much more functionality than desktop gadgets have done in Vista, as they can be programmed using C# or other .Net languages, but metro apps use up too much space to be controlled with a simple mouse.
We're building a Silverlight 4 LOB application. However, we're concerned that not all our clients will be able to support Silverlight. For example, most of our clients will be large companies and it's possible their IT department hasn't authorized Silverlight to be installed on user machines. And it's possible that some of our clients will have installed 64 bit versions of IE on user machines. Both of these situations would prevent our clients from using our app.
To deal with this possibility, we'd like to build our app in such a way that it could easily be hosted as a WPF application, if we had to drop back to that position. Our middle-tier and backend would be the same, regardless of the client used.
We're going to initially build our app to be a Silverlight app. A WPF version would come a bit later. My question is this. What precautions should we take, when building our Silverlight app (UI), to make sure the app easily ports to a WPF app (using ClickOnce)?
WPF is (near enough) a superset of Silverlight, so it should be easier going from Silverlight to WPF than it is going the other way. As long as you are using an MVVM framework which abstracts over any platform specific features, then porting the code will be simplified (I would recommend Caliburn.Micro).
Rocky Lhotka (the author of the CSLA business object framework) has a nice blog post on some of the differences between Silverlight and WPF, and things to consider when targeting both platforms.
One of your problems will be solved by Silverlight 5, since SL5 plugin will work in the 64 bit IE.
Porting from silverlight to wpf shouldn't be too hard. One thing you can do to guard against possible issues is to get 3rd party library of ui controls that work on both silverlight and wpf. I'd sugest to start with silverlight and move to wpf only if you see real push back from your clients.
Recently I've stumbled over surface. It's incredible and so easy to develop small applications with surface. Surface is build upon WPF, so surface uses XAML. My idea is now to develop applications with surface. I've searched for some information about this topic. There is nothing about that. My question is now, why nobody uses the surface SDK with WPF to build cool applications. Are there any disadvantages?
I don't really understand your question. But here are some answers to what you may be asking:
Why aren't there more surface applications out there?
Most likely because of the price and the availability. It costs $15,000 for a developer unit and you have to be a business to even get to order it.
Why isn't the surface SDK used to build normal desktop apps
Because it doesn't make sense. The surface SDK contains Surface specific, and multi touch specific additions to the plain WPF stack so it is only useful for surface applications running on a real surface device (or simulator, but that isn't feasible for deployment)
Now if you are building a multi touch application for windows 7, there is a surface toolkit which is based upon the surface SDK. It has most of the nice multi touch enhancements but lacks the hard dependency on the surface hardware. It is very useful for general purpose multi touch development on .NET and is as far as I can tell also used quite much for this purpose.
Do you mean building Windows applications in WPF using the Surface toolkit? There is no reason not to do this. There is a 'good, better, best' model when developing multitouch apps, and if you want to create a true multitouch friendly application, then the Surface toolkit is a good way to go.
I have created an application using the surface toolkit but for normal wpf application.
You have just to have a multitouc tactil monitor.
and every thing will be fine.
It works :)
For the experienced WPFers out there, how re-usable are WPF, Silverlight and Silverlight OOB applications and components? How much overlap is there?
For example, could I write one application and easily deploy it in the three aforementioned ways?
Ideally, I want to write as little code as possible and have the flexibility of deploying it in a range of scenarios, maybe enabling certain functionality depending on deployment. The WPF family of technologies seems like a good starting point to the casual observer.. but is it really?
The simplified version of the answer is:
1. Silverlight is roughly a subset of WPF.
2. Silverlight in browser apps and Silverlight OOB apps are running on exactly the same framework. It is just a deployment difference.
3. Some OOB apps can be installed as "trusted" apps, and have looser security restraints than in browser apps.
Porting a WPF app to Silverlight is likely going to be very difficult, as a WPF app is likely to use many features of the .net framework that are not available in the smaller subset of the framework available to Silverlight apps. This is something you probably want to avoid.
Porting a Silverlight app to WPF is likely to be significantly easier. It would still be a challenge as there are features in Silverlight not in WPF (though not nearly as many as the converse). In addition to the feature delta, the actual framework that runs the Silverlight/WPF apps are different, so during the porting you would likely run into a certain amount of behavioral differences between the two.
Silverlight and Silverlight OOB apps are running on the same framework. It is possible to have the exact same app binary run in both places. For the most part, they will be behave identically. Some differences: in-browser apps can rely on browser features such as accessing the html dom, invoking javascript, etc. An OOB app doesn't run in the browser so obviously this doesn't apply. Also, if we are dealing with a "trusted" OOB app, it can do things that are prevented for security reasons in the browser (e.g. COM interop).
If you want to create an app that runs in all three places, my advice is to start building the app as an in-browser Silverlight app that is self-contained, i.e. it does not rely on the web page that is hosting it, and includes all the necessary resources inside the xap package (rather than relying on them being next to the package on the web server). Porting such an app to a Silverlight OOB app would be a cinch - pretty much just check a box in Visual Studio and you are done. Porting it to WPF would be a significant amount of work, but it would be much better than going the other way.
I'm starting a hobby project in which I would like to have a graphical, touchscreen interface for interacting with a kiosk-like device running on top of Windows XP Embedded. For development of a rich UI experience, I was considering using WPF. However, a number of demonstration videos that I have come across have used Silverlight, while I haven't seen a single WPF demonstration.
It was my understanding that Silverlight was targeted towards website developers, while WPF was more targeted towards desktop development.
So this question has two parts. Firstly, what is the recommended graphical subsystem for development of a rich UI experience on a kiosk-like device hosted on the Windows XP embedded platform? Secondly, if it is Silverlight, which version is suggested (1.0 or 2.0) and why?
It seems that WPF works fine on embedded. See here the second comment.
I think that your choice should be dependent on the type of kyosk you want to build. Some kyosks are just an open browser page. And then you have stuff like Microsoft Surface that can be used like an horizontal kyosk :-)
I would recommend also WPF, have done few kiosk apps using it.
also I would recommend http://fpscomponents.com/Product.aspx?id=8 as a virtual touch screen keyboard software component. it's done in WPF and very flexible and customizable.
User can define custom theme(skin), layout and language of keyboard. guys are working with customers and hear theirs voice so any suggestions might be accepted.