Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am relatively new to WPF and have been looking at Family.Show. It looks like a great reference application, but it has not been updated since February 2009. When I am looking through this code, are there any outdated techniques in here or improvements in the platform that I should be aware of?
[Edit] I have gotten a number of responses about PRISM and MVVM. I can now see how this question was not clear. Family.Show is one of the few WPF applications that I think really looks like a nice WPF application. I would like to use it as a model, but am concerned that the XAML and controls that they use might have been replaced with newer elements. Would someone give me some guidance in this respect?
[Edit] I should mention that I have read WPF 4 almost in its entirety, but not having much experience actually writing WPF applications, it is not easy for me to spot old or outdated technologies in something like Family.Show.
On the WPF side of things, not much has changed since 2009.
There are still DataTemplates, Styles, Data binding etc. They are used just like they have been used back then.
In the current version of the .NET framework a few more controls are present out of the box, so you might find some user controls in that example that are no longer necessary. However, the existing controls haven't changed as far as I know.
However, that application doesn't make any use of MVVM, which I personally find a big drawback.
So, you can use the application as a means to study WPF, but you shouldn't adept its architecture style in your own applications.
I think Prism is a very good framework to build enterprise(bigger) applications but at first sight it could be a little difficult. If you are new to WPF but want to get to know the WPF and MVVM better, check http://caliburnmicro.codeplex.com/ or http://waf.codeplex.com/. (With them it is a little easer to understand the principles.) You can get the source too and it is a good documentation to both, so you can learn a lot.
I think it is important to be familiar with the MVVM principles as a WPF developer.
I can suggest to you to watch the following two video from MIX conferences too:
http://channel9.msdn.com/events/MIX/MIX10/EX14
http://channel9.msdn.com/events/MIX/MIX11/OPN03
I would have a look at prism - its a great way to build WPF apps.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am in the process of learning ReactiveUI and so far I love it but I now realise that the framework encompasses XAML (i.e. the view layer) as well, offering things like ReactiveUserControl and ReactiveView.
Why do I need, or want these? System.Reactive/ReactiveUI offer massive advantages on the Model/ViewModel side but what are the advantages on the View side, again, in the context of a WPF app? Unit testing perhaps?
Note: I like WPF, I like its data binding. All my XAML bindings are strongly-typed and easy to refactor, customise, re-skin, debug and whatnot. I learned to use but not over-use the converters so never have a prob with those either. I never felt a need to override the UserControl class. With that said, I never had a problem with the WPF itself.
If I decide to use the IVIewFor<T> implementations, will my XAML designer go nuts? Will I lose anything? Will I end up debugging memory leaks, UI stutter and strange CPU spikes? We'll be making a very large app so we go by the 'better safe than sorry' principle as we were burnt by the CAB framework before.
If I decide against, what benefits of the ReactiveUI will we lose? Would I be heathens for doing this, or is it more of an optional aspect of the framework?
So far I understand the benefits in case of WinForms or Android (it offers binding support as I understood) but not WPF. While it sure does have its quirks, I don't feel the need for another framework on top of it.
You would implement IViewFor<T> when you for example want to set up bindings in the view and when you want to handle activation and deactivation, e.g.:
this.WhenAnyValue(x => x.ViewModel.Name).BindTo(this, view => view.Name.Text);
this.WhenActivated(d => { /* do something */});
These methods are implemented as extension methods. Please refer to the docs for more information and examples:
https://reactiveui.net/docs/handbook/data-binding/
https://reactiveui.net/docs/handbook/when-activated/
Of course you don't have to use all features of ReactiveUI. It's perfectly fine to set up bindings in the XAML markup as usual and still bind to ReactiveObjects.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am starting a project in Xamarin. As of now it will be Android only but later I am planning to port it to iOS. Should I start with Xamarin.forms (that will require me to buy an Indie license) or should I first finish up android application and later port it to iOS ?
It depends...
The best way - extract logic to the crosplatform PCL project. Then create 2 solutions for ios and android where you will make UI part + our crosplatform logic.
In any way using Xamarin.forms it's good desicion only for small simple projects, in my opinion in most cases native UI code it's the better solution
Xamarin.Forms is no silver bullet and I would not recommend it for all apps. Maybe, I would even not recommend it for most apps. As mentioned in my comment to your opening question, the answer is primarily opinion based.
To me, Xamarin.Forms is a nice tool to create simple proof of concept apps, also a way of creating prototype apps. However, as soon as you need to do something more complicated. Like, very custom UI or something that inherently is difficult to do on all the supported platforms. Then, you will have to battle the framework and write code for all platforms anyways. So using Xamarin.Forms, at least in my opinion, really depends on the application you are making.
Now, I am super biased towards MvvmCross and the likes, but in any case you should strive to cram in as much logic and behavior into a shared base. For this I usually use the MVVM pattern inside of a PCL. So all my ViewModels, classes for fetching data, behavior etc. goes inside of that PCL.
All views go into the platform specific Application project. So in the end the platform specific project will in best cases only contain UI + some platform specific services such as how to access sensors etc.
There are several MVVM framworks for Xamarin apps. Some of them are MvvmCross, MvvmLight, ReactiveUI and MugenMVVM.
Which approach you take is entirely up to you. However, before you commit to something, consider trying out various things to get a feel for it yourself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've developed Windows Forms applications for 5 years now. A lot of people say that I should look into WPF. I have a few questions about WPF vs Windows Forms to determine which one is best. WPF is newer than Windows Forms and many people say it'll be the future. Others say that Windows Forms is older and therefor more secure. I am not sure what will be the future. I have googled advantages and disadvantages, but I hope that you can give me a more in dept answer to these questions:
Which one is better based upon performance?
What are the top advantages of using WPF instead of Windows Forms?
What are the top advantages of using Windows Forms instead of WPF?
Which one is more used/liked by businesses?
How hard is it to switch from Windows Forms to WPF?
Which parts of WPF should I definitely look into?
There is no meaning to say that WPF is better than windows forms or vice versa. It depends on many factors:
What kind of UI you are building.
Obviously, the complexity of the views you are designing will factor in to performance on both platforms. They have different layout and rendering pipelines.
How effectively you optimize for performance on each platform.
Advantages of using WPF instead of Windows forms:
XAML makes it easy to create and edit your GUI, and allows the work to be split between a designer (XAML) and a programmer (C#, VB.NET etc.).
It allows you to make user interfaces for both Windows applications and web applications (Silverlight/XBAP).
Databinding, which allows you to get a more clean separation of data and layout.
Uses hardware acceleration for drawing the GUI, for better performance.
Top advantages of using Windows forms instead of WPF:
WPF's in-box control suite is far more limited than that of WinForms.
There's greater support in the 3rd-party control space for WinForms. (That's changing, but for now by advantage of time, WinForms has greater support in the community.)
The major drawback of WPF is that Mono doesn't really support it for cross-platform (e.g., it doesn't work on Linux and Mac). Originally, Xamarian/Novella said they weren't going to implement it due to the complexity of implementation. I haven't seen anything to the contrary. Not saying it isn't, but their recommendation is to write model classes and then do a OS-specific front end. Even with WPF being open sourced, it may be built on something that isn't easily ported.
https://social.msdn.microsoft.com/Forums/en-US/e134134a-352f-435b-943a-eda7a2b14fc0/wpf-vs-windows-forms-2015?forum=wpf
Depends upon your learning ability.
Which parts of WPF should I definitely look into?
XAML: Learn about XAML and how it is used in WPF applications.
Layout: Learn about layout panels and how they are used to construct user interfaces.
Data binding: Learn how WPF data binding works and how it can be used.
Data templates and triggers: Learn how data templates and triggers work and how they can be used.
Styles: Learn about how UIs can be styled in WPF.
For more information refer below mentioned URL
Windows Form Vs WPF Windows
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have not created Windows forms applications (using C# and .NET) since 2005 so I am not sure if it is still a good option for rich client applications. Also I do not know if there is any (comparatively) new framework for building Windows apps other than Composite Application Block.
We have a small team (3 people) in our company who manage the content (e.g. musics, mobile games etc) and I want to build a tool for them. Since there are only a few people who will use this tool I am thinking of creating a Windows app so that rather than spending time and effort on creating a rich Web UI (e.g. using ajax, jquery etc) I focus on the business logic.
I understand that WPF is another option but from my knowledge it is a bit more complicated and time consuming to build an app using WPF.
If Windows forms is my best option, is there any fairly new framework for building Windows apps? 10 years ago I used to use Microsoft's composite application block but it seems to me that it's something for the past!
Building an app using WPF is a bit double edged. It's extremely quick for building something simple, hence why so many tutorials can cover specific behaviours without being gigantic. It's excellent for having automatic layouts, and being able to build said layouts in XAML will feel a thousand times better than setting up alignments in forms, especially if you've done web development. However, deviating from the beaten path (smooth datatypes, good-or-error validation, hardcoded database fields...) will leave you with a steep learning curve, as I find digging around the guts of WPF to be a nightmare.
Note that there are also a number of options available for Mono, most of which also work on Windows without indcident.
EDIT: Since I'm still getting upvotes on this answer, apparently, I'll add that it doesn't seem mono is maintaining the attached page, and the only framework from the above list which appears to have ongoing support is Xwt.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have pretty much finished my first WPF project after several weeks.
Now I want to refactor and make my application as clear / reusable as possible.
Does it take a lot of work (meaning would certain logic change entirely?) to change an entire application to the MVVM pattern and would it make the application easier to understand? Also are there other things I should look into except for MVVM?
Basically this application will be used by someone other than myself, so my goal is to make this program more simple since it really got over complicated in certain areas.
The general layout of my program consists of:
10 Classes (1 database class using Singleton)
3 HelperClasses
3 UserControlPages
Singleton in about 3 classes
Does it take a lot of work to change an entire application ?
It's hard to say, cause it depends on the concrete project and how it was coded before, but basically it's never a small amount of work.
would it make the application easier to understand?
Would say: no, but it would definitely make it more testable and more scalable.
Also are there other things I should look into except for MVVM?
It, again, depends on the concrete project (what is target client of your project, who will reuse your code, what is the expected scale of your project...)
Bare in mind that using the MVVM pattern requires a framework, otherwise it is a huge amount of work. I would recommend Caliburn.Micro, and you should investigate the other frameworks available too.
Refactoring effort will depend upon existing code. If you have loose coupling in mind right from start, it should not take much effort.
Following are links to questions related to getting started with MVVM.
Learning WPF and MVVM - best approach for learning from scratch
MVVM: Tutorial from start to finish?
https://stackoverflow.com/questions/2267903/learning-mvvm-for-wpf
If you have any specific question, update the question to mention it.