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.
Related
I have a customer who wants an application for his travels where he can update an online DB, he doesn't want to buy a laptop, he wants a tablet or something similar. I have no knowledge nor desire in creating special apps for mobile devices, I want to create a winform just like I always did when it was targeted for pc. Tablet pcs (which from what I understood is just a regular pc?) are still very expensive in my country.
Is there a simple adjustment to make winform app run on a tablet with android or I have to build a special app for it? Any other solution? (I began in writing a web page for it, but it's much easier using winforms)
Native WinForms applications will not run directly on Android (or any non-Windows platform). You may want to begin by looking into MonoDroid for porting .NET code Android (and Mono in general for porting .NET code to non-Windows platforms).
A successful port across platforms will require that the application be structured in a very de-coupled manner. Core business logic in the abstract part of the application should be easily ported, but concrete implementations (specifically views and data/service access) will require some re-implementation for the different concrete platforms. So the overall architecture needs to be very de-coupled and pluggable.
Is a Windows tablet an option? Using various new technologies at Microsoft (Windows 8, Metro UI, etc.) you could build an application that would target multiple Microsoft-based platforms. This could easily satisfy the requirement of being "a tablet" (if the requirement isn't more specifically "an Android tablet"). However, it won't be the old WinForms style of applications.
In general you'll find that the industry has been steadily moving away from WinForms for, well, this exact reason. It doesn't port to other platforms, and there's a wide variety of platforms in demand today.
Forget convertion i was in a similar position years ago and i did something easier faster and i think smarter.
just make a winform with nice big controls take care of docking scaling anchors etc so that it will look nice and can be used with small smart devices.
Make sure you pass some start program parameters in your app and when a special parameter is passed instead of opening the main typically desktop form of your app open that new one in fullscreen.
Now the tricky parts isnelsewhere. I hade setup a tiny windows 2008 r2 server that allows remote apps to be run on it.
Create a user account that you will allow access to that server and only that app of yours with the specific parameter we talked about. (Ex myapp.exe -remote)
The what ever device he will get you can download the free app like 2x rdp or microsoft rdp in android. Make a new connection to your server (you can use any free ddns you like if you dont have a static ip) and connect with that windows server account you did before.
This account if has been properly setuped will only run your app and will only show that new mini winform you did..
The end user will do a simle click and from his internet connection will do a simple remote desktop that is linited to your app only. (Router configuration is needed once)
That way you will keep maintain just one source code and he will have low bandwidth cost and can continue his work without data loose in case of disconnection.
I use that for years in mobiles tablets and pos systems. Its fast its stable its secure its easy to maintain (nothing on the client side) and you don't waste months of learning wpf or doing xamarin converting.
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.
I want to know what are the differences between a WPF Browser Application and WPF Desktop Application. I know that the browser application runs on IE and FF, but about the technology, is the same? I mean, we can do exactly the same by the two ways? (Of course, maybe with different UI)
I have this doubt because I'm looking for a book about WPF Browser Applications, but I only see books about WPF (I don't know if is in general or is only for desktop applications :S)
A WPF Browser Application uses exactly the same framework as a WPF desktop application and could run with the same UI, but with restrictions on trust which means that some APIs are not available. There a number of challenges in developing Browser application. A Browser app must be signed with a certificate. Some of the trust restrictions are not enforced at compile time and are only discovered at run time.
In the time since Browser Applications were first introduced, Microsoft developed Silverlight which uses a similar though not identical XAML technology. Silverlight is easier to deploy than a WPF Browser Application and may be appropriate depending upon your requirements.
A Browser Application not only runs in the browser but also with less authority. If you need to read and write local files then go WPF. Browser is good is you want rapid deployment to lots of PCs. Other wise I will take WPF Desktop every time. Most WPF books with have a chapter on XBAP. I like McDonald from Apress.
I have been using WPF for a while, and I keep on realizing again and again that Microsoft invests its efforst in Silverlight, not in WPF (RIA Services, default theme, controls and more).
I thought it might be a good idea to migrate to Silverlight (i.e. creating standalone desktop apps with Silverlight 4.0), the question is whether this is possible or not.
BTW, I think LightSwitch applications are generated with Silverlight as standalone desktop apps.
From MSDN:
Silverlight 3 applications are no longer restricted to running in a browser. They can be run in a browser or it they can be detached from the browser and run from the desktop. These out-of-browser applications allow you to bring the richness of Silverlight 3 applications directly to the desktop without the restriction of running within a browser.
Link: Building An Out-of-Browser Client With Silverlight 3
It is possible to create standalone desktop apps(Out of browser apps) with silverlight version 3.0 or higher and it works great. Now it is also possible to install the out of browser app even without opening a browser as shown at this blog post .Silverlight is awesome and silverlight apps even run on MACs and Linux(limited support)
However, it is not true that Microsoft is only investing in silverlight. Microsoft is investing in WPF too. Though it is possible to create out of browser applications with silverlight, they have lot of limitations when compared to a full blown WPF applications.Dont forget that silverlight is just a subset of WPF, for example, silverlight doesnt have ADO.NET, Hardware device access etc. So if your application is merely a business application and you dont have to access hardware devices or database directly then silverlight might be an option, however if your application accessing client machines hardware resources directly then you are better off with WPF.
My suggestion is, If you know before hand that it is going to be a desktop application then go with WPF(or may be even XBAP). In my experience, useful applications grow with time, new features are always requested time to time. If in future,a feature is requested that cannot be accomplished with silverlight and can only be accomplished with WPF, then you will be in a big trouble because you need to rewrite your app in WPF and it will be hard for you to convince your CFO to allocate more fund just to implement one feature. Silverlight is not designed to develop desktop applications, its main goal is multi-platform support.
Silverlight 3 supports Out-of-Browser functionality.
Quote from Wikipedia silverlight page :
Silverlight 3 supports Out-of-Browser experiences, i.e., Silverlight applications can be installed to the system for offline access (provided the application manifest is designed to allow local installation) where they run outside the browser.
Also here is a quick howto
Out of browser applications have the same security restrictions as in browser applications.
With Silverlight 4 you can create full trust applications which have full access to the computer.
More on Network Security Access Restrictions in Silverlight
If you mean Out of Browser apps, certainly. The Seesmic Desktop 2 app is an excellent example of one of these apps, with it's own updating mechanism. Seems a no brainer to use the XAP/MEF plug-in Model and Silverlight in this manner.
Seesmic Desktop 2
We're developing an OOB app along the same lines, one internet download and you're done. You're not going to get exactly the same APIs as you get in WPF, though.
As others have pointed out, Silverlight apps can be installed to run 'out-of-browser', but even with elevated trust they still have significant restrictions on what they can do and certainly don't have "full access to the computer".
Creating an app from scratch, you may want to consider parallel Silverlight & WPF builds. The code can more-or-less be shared by adding the .cs files from one project (e.g. WPF) to the other (Silverlight) using "Add As Link". The XAML files cannot be linked this way and need to be duplicated, but that may not involve much more than copying & pasting, depending on your structure. There're good examples of this on the web.
Developing both types in parallel would likely involve a lot less effort than having to abruptly switch types at some point and discovering incompatibilities/limitations too late.
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.