I'm a web developer who is trying to get into software development. What should I know about desktop applications before I develop and deploy one?
I understand that this question is a little vague, but if it helps, I'm looking for answers similar to "What should a developer know before building a public web site".
I'd work on deployment strategy, i.e. installers, ClickOnce, etc. This really tripped me up the first time I deployed a desktop app.
Debugging will get a LOT more "interesting". While most situations will resolve themselves to a common scenario, just remember that essentially every desktop is unique in its own right and sometimes a given install or special application a user is running could affect your application in unknown ways. I'm still running into an issue with my application that is using the windows "environment folders" but it doesn't seem to work quite right on the Danish language version of Windows.
I'm not saying this to scare you off, but more to make sure you have some kind of way to easily debug or get a dump of the situation should you have to troubleshoot the app on a user's machine.
This really depends on your target application space.
Desktop apps have been written in everthing from Java to VB to C++ to ASM, and even occationally "Good 'ol Boy" basic.
You should let the application drive the technology you need to develop it.
You probably aren't going to write a 3D video game in VB. But then again your not going to write a account package in ASM.
Edit:
**Know** your customer.
**Know** your application.
**Know** what algorthms are necessary to implement your application.
**Know** your requirements and goals up front.
**Know** the platform. (Win32, Mac0S, Linux, JavaVM, etc...)
Evaluate tools that will help you acheive project requirements and goals.
Design your software.
Implement your software.
One other note occured to me. While it is import to start with a clear definition of your requirements, you also need to be aware that requirements, may be in Flux during the development process depending on your customer. Manage scope creep as it occurs, or it will bite you in the end.
One separate note, data binding is typically different in the desktop model. Since the web model is disconnected, you'll always need to check for a new copy of your data or make sure to rebind to your presentation layer after a chance.
Typically with desktop apps, the language/framework you use will be checking and update its bindings automatically, which makes it nice when you change your underlying data layer, but can be confusing at times when you see your grid/drop down list changing and you didn't expect it to.
Threading becomes more explicit in desktop applications, so you should probably be familiar with the basic concepts.
Desktop application are more OS-dependent, so you may need a knowledge about some OS-dependend featerues, like process and threading management, services (I mean windows services) installing and management, file system and so on.