i am a junior c# programmer and would like to learn silverlight.
is silverlight for progrmmers or for designers?
It is for neither - Silverlight is simply the branding for the runtime engine, library set, etc. The only thing that "uses" Silverlight directly is (broadly speaking) the browser.
The important thing for developers is Visual Studio (regular or Express:Web), and for designers: the Expression suite. Both can contribute to a Silverlight project. Also consider that you may be targeting Moonlight, so even "Silverlight" becomes misleading.
Silverlight is for both developers/programmers and designers.
The User Interface of a Silverlight application is defined in XAML script, which is based upon XML.
Microsoft explicitly target the Microsoft Expression (specifically Expression Blend) suite of products at designers, whilst Microsoft's Visual Studio is aimed at developers (although Visual Studio 2010 can be used for design work as well).
If you have a designer and a programmer working together to create the overall Silverlight application, you can utilise a programming design pattern called MVVM (Model-View-ViewModel) to help separate the concerns between the UI and the back-end functional program code. This effectively allow the programmer to not really care about the names and ID values of specific UI elements that may have been defined by the designer, but simply to "bind" together specific User Interface elements with their "back-end" program code counterparts to create the complete Silverlight application.
It is for both.
Both,
As a programmer it's good to be familiar with the programming model, the related MVVM pattern, the object model etc.
As a designer you can build your designs in Blend and XAML. Then integrate them with the rest of the software
Both.
Usually a developer will do it all, but using the Expression products, designers and developers can work on the same project to utilise their skills.
I guess like most peep said, it is for both.
Being a developer myself, I tend to sway towards the coding.
But when I want to do animation, I will go back to xaml, which is way more simpler than doing in the code behind.
One good thing about silverlight that certainly prove that it is suitable for both is that, no matter how a designer place his UI and animations, and no matter how a developer codes, as long as 1 focus on functionality, another focus on UI.
Things will work out perfect, unless the designer deleted some UI that is suppose to have functionality. :)
It's for both.
However you're also going to need both developer and designer to make it quite good.
Related
Our team is experienced working on Winforms and ASP.net projects.
As what other programmers in programmers stack exchange recommend me to jump to WPF for our team next projects instead of using WinForms for our Client based business Applications.
Now i am starting to Develop my first project using WPF, its a little bit tricky for me as its my first attempt to use this.
Can you gave much deeper information why we need to jump to WPF instead of using winforms?
I need to convinced our manager that we can dig on WPF for our client based projects.
We are using VS 2008.
Pick up a good MVVM Framework. I personally use Microsoft Prism. For other alternatives, look at this StackOverflow question.
Routed Events are for the view only. For example, if you want to scroll to the end of a multiline textbox when the text changes.
Commands are used to bind events in which the logic resides on the view-model (business logic)... For example, a submit button.
If you have designers on your team, get them to start playing around with Expression Blend and understanding styles/layout. Expression Blend allows you to use sample data to see your applications layout without having to run it all the time.
Understand The difference between ContentControl and ContentPresenter.
Understand how ItemsControls work. There is a difference between SelectedItem, SelectedValue, and SelectedValuePath.
Look at a lot of exmaples online. Dr. Wpf, WPFTutorial.net, Josh Smith on WPF, etc.
If you plan to take advantage of Code UI Testing (to test the actual User Interface), then make sure to name controls that matter (most MVVM tutorials tell you that you shouldn't have to name any controls). If you don't plan on doing Coded UI Testing, then don't name your controls unless you need to reference them from the view itself.
IValueConverter and IMultiValueConverter should only be used to convert properties to view-related items. The most commonly used converter is the BooleanToVisiblity converter.
TargetNullValue, FallbackValue, and StringFormat are important when using binding. Don't make assumptions that the data being bound will always be available and correct.
You will almost always expose ObservableCollection<T> or ReadOnlyObservableCollection<T> from your view-models. Very rarely will you ever return any other type of collection, including an IEnumerable<T>.
Be careful in choosing your BindingMode: OneWay, OneTime, TwoWay, OneWayToSource (WARNING: OneWayToSource is tricky... it still requires a getter because it is not a write-only binding).
A good debugging tool that is free is Snoop. It is similar to a DOM explorer for a running WPF application. A more advanced (and not free) tool that is a bit more powerful is Mole.
That's all I can think of for now... Oh, and if you run into road blocks, StackOverflow is your friend :)
I wrote a series on WPF with MVVM specifically targeting developers who have a Windows Forms background, and are planning to jump ship.
It walks through some of the basics of WPF, showing how it allows you to approach your development differently than Windows Forms, including introducing (gently) templating, commands, and other concepts that tie into the vastly superior data binding in WPF.
This would provide a nice introduction to WPF, and show you why it can be better for business applications than Windows Forms.
For those that are reading and wondering "why WPF" instead of Winforms, the answer is that the WPF databinding makes it a heck of a lot easier. MVVM really is just to help you get the most of out of it, but you don't strictly need it.
As someone who is learning just now, I'd recommend just taking WPF out for a spin, open up a project and start doing what you did in WinForms, manually assigning properties and handling events. It will work. But, once you figure out that WPF does this automatically for you, you'll suddenly start to resent the old way, and you'll wind up following the merry path of MVVM.
I need to add functionality to my WPF application (in C#) that allows users to create their own rules and execute an action from a list of pre-defined actions. An example of what I need is the "Rules And Alerts" feature of Outlook.
I've just been recently introduced to functional programming and one part of me thinks this might be a perfect place to implement that. Another part of me thinks that workflows may be the best approach but I've never worked with workflows outside of SharePoint.
So, I'm looking for guidance from those who may have experience implementing such functionality. In my opinion, it is not so difficult to create a script (or whatever it's called), but the tricky part is parsing the script back into the designer.
Any other ideas will be greatly appreciated.
It sounds like for what you want, a scripting engine or Windows Workflow would be waaaay overkill. Those become interesting when there are custom actions to be defined with a high degree of flexibility but if it's really having normal users (without extensive training) select/customize a critera and then select/customize a pre-defined action, then I'd just mimic the Outlook approach you mentioned (also look at the "Conditional Formatting" feature in Excel)
Okay, I'm biting the bullet and deciding to get into the whole Microsoft/C#/.NET culture and I'm going to do this by putting together a simple (hah!) application.
It will basically be an application in which I want to store images and associate with them other optional things.
It must be able to import images from the filesystem (and hopefully camera/scanner) then allow the user to add text, audio and other information.
I plan to store the images and auxillary information into a database. What the application will do with said data isn't important (yet).
Keep in mind I know absolutely nothing about C# or .NET although, as an old codger, I know a great deal about many other things and will regale/bore you with stories and anecdotes until you quietly slip away :-)
What are the first steps to take in developing such an application? I've already set out UI layouts and likely process flows although it may be that the development environment dictates changes.
Development environment is currently XP SP3 + VS2008 (though I can upgrade if absolutely necessary).
What should I be looking at as the first step? Are there any gotchas I should be looking out for?
Have you decided for win forms or WPF? I've been doing win forms for the past 4 years and WPF was a great discovery for me, with the flexibility it affords. It might be fitted for your application and the different types of content you'll want to add and give you a flexibility that win forms can't give.
As for actually developing, I think loading images from the disk would be the first step, showing them in the UI and getting user input for them - you would get to work with the different objects and see how the framework handles things.
A tutorial about the field validation I mentioned in my comment is here - haven't done it, but something similar. You can also see the xaml code paired with the C# code there.
After looking for the differences between win forms and WPF I found that there are a few win forms controls that are missing from WPF. More on that on MSDN (compariosn chart) and a post from March with a more detailed chart.
It's also worth mentioning that you can include win forms controls in WPF applications and vice versa, but there are some limitations.
Just a couple of pointers, it would be easy to overwhelm you as you are just starting with this tech stack. First step, use SQLServer 2008 Express, it has better ability to deal with image data (images can be saved directly to the filesystem, but they are still in a table).
Apart from that, you can design your screen with the GUI, and then hook the bits up one by one to your retreived data. Create a new Windows Forms app, or a WPF one, and start from there (i'm assuming that you know about the toolbox window and just dragging components on to the designer and setting their properties in the Properties window).
If you're looking win forms you're going to have drag-and-drop UI pretty easily.
If you want to use a database than you're probably going to find MS-SQL the easiest to cooperate with. Look up LINQ-2-SQL, it lets you access your database through an object layer by simply dragging your tables onto a pane.
Fun things to use: extension methods, partial classes, LINQ (query any collection with inline lambdas) and even class/method attributes.
My $0,02:
a) Get to know the platform a bit, types, collections, events/delegates(/lambdas), etc etc
b) Dive into WPF
c) Learn about database connectivity (LINQ2SQL or NHibernate (or ....)
d) Learn about the MVVM pattern to get to deliver solid wpf applications, doing so forces you to dive deeper into the workings of WPF (routed commands, tunneling/bubbleing etc)
e) Learn more about patterns to get a more solid grasp of OO (this: http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1276066663&sr=8-1 is an absolute pearl for that)
f) etc
If you aren't too desperate to get your hands dirty straight away I'd suggest this book: CLR via C#.
It is written for those with programming experience on platforms other than .Net and provides a clear and comprehensive explanation of C# and how it runs on the .NET CLR.
By reading this initially you might avoid writing some of the poorly constructed applications that many of us wrote before properly understanding the technology.
Buy a book on C# & .NET FW fundamentals!
Read! :-)
Read good books about .NET for example CLR via C#.
Read this:
Hidden Features of C#? https://stackoverflow.com/questions/380819/common-programming-mistakes-for-net-developers-to-avoid
In WPF i can make my UI using .NET 2.0 style like designer.cs, my question is what are the advantages of using XAML for UI design instead of code.
The main advantage is that if you keep a clean separation of markup and code (e.g. by applying the MVVM pattern), you can concentrate on the behavior of the application (i.e. the code) and let professional graphic designers worry about applying the look and feel of the application.
These two tasks can even be worked on in parallel by two different people using different tools (e.g. Visual Studio vs. Expression).
The main advantage is that you can split the appearance of your application away from the code.
By interacting with the code by use of command bindings and events it allows the business logic to be completely separate to the GUI.
This allows graphic/web designers to concentrate on the front end and coders the business logic. You'll also find that things like animation can be handled completely by the front end in XAML, without any source coding behind it.
This means that you will be able to change all visual aspects of the application without changing any business logic.
There are few reasons that I can say...
Supported by Expression Blend and Expression Design. They are more powerful and easy to use than Visual Studio design pane.
Its easier to change the Xaml manually for some simple things like say
< Rectangle Margin=20,20,10,0" VerticalAlignment="Center" Fill="Red" />
Xaml is easier to understand for a designer than C# code.
Can easily separate design view (XAML) and code. Its not so obvious while using designer.cs
XML is especially utilized for exploring webs, making interactive pages, to automate specific web tasks. However, Xaml is used to design and handle Windows and web apps.
It operates the Extensible Application Markup Language (XAML) to express views in a declarative way. It has built-in support for resources, graphics, data binding, and much more.
The XAML layout system delivers automated sizing of elements, layout panels, and visual states to help you make a responsive UI. With a responsive layout, you can create your app look fantastic on screens with different app window sizes, resolutions, pixel densities, and orientations.
While HTML has limited programmatic functionality and command, XAML and other new-generation declarative markup languages offer back-end scripting language support to sidestep this limitation.
I'm about to start developing a small Windows application using Microsoft Visual C# 2008 (Express edition). I'm very new to C# and .NET, so this is a newbie question. Should I start with WPF or should I stick with the old WinForms?
My application has several screens, all having several text-boxes, check-boxes, combo-boxes, not anything more. The application will retrieve data from several COM objects, and communicate through standard TCP/IP sockets, both of which are unrelated to the UI.
The UI is not fancy in any way (and I don't need it to be). However, the world seems to be moving to WPF. What are the considerations of choosing WPF over WinForms for my case? What's the recommended approach?
Thanks
I have not used Forms enough to say anything about which is better, but I have found WPF to be easy enough to use for minor applications.
I figure that if it's the standard people are moving towards and it's not difficult, then it's good practice to start using it.
WPF = Future + Fancy stuff
WinForms = WYSIWYG greatness
Choose whichever of the above you find the most atractive :)
It depends. Stick with WinForms if you're comfortable with it.
If you want to be able to have a better look-and-feel with more customized controls, and you're willing to spend the time to learn XAML and the differences between WPF and WinForms, then go for it. But expect it to take some time, there is a learning curve.
Interesting, how all answers target the developer: familiarity with a framework, the learning curve, the technical features of a framework etc.
If it's a simple application, none of the technical aspects really matter. You sound like you have some experience programming, in that case the chosen framework doesnt really matter. Focus on your users instead.
Can you guarantee that your users have the latest .net runtime installed? Are they willing/able to install it if they dont?
Will your users be put off by an "outdated" look and feel?
The way you phrased your question, i think you should use WinForms. You seem to imply ("stick with winforms") that you have experience in WinForms and that you dont have any fancy demands for the UI, so i see no reason to put yourself on a steep learning curve that WPF can be.
I personally like alot of the things that WPF provides. It has easy data binding, validation, and customizing UI things is simple. Plus with the new Expression Blend 3.0 that was released yesterday they have sketchflow WPF apps that you can share with others and get feedback files from. It is a pretty interesting little addition to the WPF world.
The nice thing is that if you find a Winform control or something that needs to be WPF and you picked the other way, they seem to work well with each other now.
It's a trade-off.
You will most likely be more productive starting off in Windows Forms because the programming paradigm is closer to most other UI development libraries you might be familiar with. There are also many libraries of UI control available for WinForms (including ActiveX) that make creation of attractive, functional UI easier. Unfortunately, MS has indicated that WinForms will not see any more advancement in the future because their emphasis is on WPF.
WPF, on the other hand, is more more sophisticated and robust and can help you create very attractive, rich interfaces. WPF sometimes requires the use of more sophisticated back-end programming paradigms like MVVM to create effective applications. Also, as a newer technology, there are fewer mature libraries and tools to help you develop WPF apps. For development tools you have VS2008 and Expression Blend (which is quite nice BTW). Advanced graphics features like gradients, color themes, skinning, control customization are all more powerful in WPF. But this power comes at a price - most developers find WPF to have a more significant learning curve that WinForms.
WPF is something completely new if you are used to WinForms, so it'll take quite a while to get used to it. But i prefer WPF not because of the looks, for me it's more the great layout system (once you got used to it), its databinding infrastructure and in combination with patterns like MVVM, the separation of UI and business logic.