I am attempting to come up with a "big picture" outline for a picture manipulation desktop application I would like to make, but due to my lack of extensive experience with implementing UI design patterns - I am struggling to find an appropriate one for my needs.
Most of my experience with UI design patterns was a few school projects utilizing the Model-View-Presenter (MVP) design pattern with Java Swing. Since Java Swing is on the way out, I am trying to use JavaFx for my UI needs moving forwards.
With a couple projects recently I attempted to use MVP with JavaFX with little success as I was stuck with the longest time connecting the user actions from the View (a JavaFX application) to the Model. I kept running into roadblocks where any attempt to connect an instance of the View to a Presenter (which would then give the logic for which Model methods, details here aren't important) would fail since the View would create another instance of itself (separate application thread from start()) with no reference to the Presenter or Model methods.
So in my rush to complete the project, I implemented a very ugly work basically hooking up the Model methods directly with their related View components. The projects works, but violates many fundamental design principles.
Going forward with this next project I would like to avoid making that mistake from the get go with a better overall design that can adequately deal with the issue I face (described above) while still maintaining fundamental design principles.
Any solution I think of involves having the View (the JavaFx Application) be where the program runs from, but that appears the violate the whole idea of having interchangeable Views. Is JavaFX just not meant to be flexible for what I'm looking for? Does anyone have any potential solutions to my problem here, both on the design pattern and JavaFX front?
The MVP pattern in JavaFX is implemented as an FXML View connected to a controller class as the Presenter that launches separate Model threads as needed for various computations/tasks that feed into the View controls. In JavaFX you create the FXML view with SceneBuilder. SceneBuilder creates the visual part of the GUI in a FXML file that is a passive file containing all of the visual attributes. Then you attach a controller class that handles all of the events from the GUI controls. This implements the Presenter aspect of MVP. Then the Model is a separate thread running various computations in the background and interacting with the JavaFX thread as needed. If the computations are not too intensive, you can just run them in the JavaFX thread itself. If they take a lot of CPU cycles, you must run then in a separate thread so you don't lock up the GUI.
Related
Does there exists any GUI platform (e.g. Windows-API, Apple’s Cocoa or Java/swing) for desktop GUI applications that allows (or supports a mechanism) to implement a small GUI application comprising many data driven GUI components in a class definition?
Let me explain this using an example. Assume if I need to create a City_GIS application containing several sub-components, which include a City_ATC (a component to display Air Traffic Control for the city), a City_Ambulances (a component to monitor ambulances), and so on. The air-planes and ambulances must update their locations every few seconds and clicking on the airplane/ambulance must make an Ajax call to get latest data and display in a Table.
I want to implement each component as an individual GUI application (i.e. in a GUI class), so that I can refine it and test it individually. Then I must be able to assemble each small GUI application implements as a class can be assembled by writing just two lines of code, for example:
// Code needed to assemble City_ATC into the application is:
RepComp AirTraffic= new CityATC_RCC (ACi, AirportCode);
ParentCanvas.AddChild (AirTraffic, 0, 0, null);
// Code needed to assemble City_Ambulances into the application is:
RepComp CityER= new City_Ambulances (ACi, ZipCode);
ParentCanvas.AddChild (CityER, 0, 0, null);
If this application has dozen such sub-components, I should be able to implement and test each as a small GUI application (in a class, which can be used to assemble this component). Each mini GUI application/class implements all the application logic and presentation logic. It must not take more than 3 to 5 lines of code to assemble each sub-component, and removing the lines must effectively remove the sub-component.
For example, the airplanes shapes must reflect model (e.g. Boeing 747 or Airbus 330) & must be colour coded to show in-coming, out-going etc. Each engineer responsible for each such component can refine his component continuously and/or frequently to add such features and test it individually free from spaghetti code. Since each mini-GUI-application/class can have an independent codebase (a set of files) and version control mechanism, he is not forced to see even single line of code implemented for another mini-GUI-application/class. That is, no spaghetti code for each component.
Although it is possible to create this kind of GUI library, I could not find any way for any existing GUI API to support this useful feature. I am absolutely sure that it is possible support this kind of feature, because we created a Java GUI library for creating such GUI classes that can be assembled to build complex data driven GUI applications for web (e.g. to run in web browsers).
You can see demo of such components by going to web site http://pioneer-soft.com and selecting: “DEMO” -> “Real CBSD” -> “Assembling Replaceable Components for Multiple Cities” (on the left side of the webpage). We created a Class for each city (by assembling objects of ATC & ambulances) & passed multiple objects to a Tab-component. Is this possible for desktop for any desktop GUI platforms?
Best Regards,
Raju
If I understood your question properly, I think you are talking about dialog boxes.
1> In windows MFC, there is CDialog class. You have to derive a class from CDialog, Modify its constructor if you want, put you http calls in OnInit function. After that you just have to call it using
CAirTrafficDlg AirTraffic(ACi, AirportCode);
AirTraffic.DoModal();
You can put the class in a dll and call from different EXEs.
2> Still better WPF. I don't have enough experience in WPF, But with WPF as user interface is designed using xaml, you can copy the class along with its GUI to another project which is complicated with MFC.
Please help - I'm getting lost!
I'm writing a small desktop application which has some controls and some screen. This should later be integrated with a small web site, also having some screens. The idea is to let the user edit videos and select images, and then share their results with her friends.
The desktop app is using C# WPF, the web site - ASP.Net MVC.
I read that growing the application past a few screens would be easier using MVVM. So I started searching and discovered Caliburn.Micro and MVVM.Light. I have downloaded some tutorials but, just as I was getting ready to deep-dive into the material, I found here on S.O. that there's also Prism, MEF, Unity, ReactiveUI - This is becoming too much!
I'm terrible at learning new things - It's taking me ages to study WPF and ASP.Net MVC. I don't want to study lots of new material only to find out later that it's not relevant. And I don't have an architect to instruct me.
So my question is: Could you put these frameworks and technologies in perspective, and suggest which I should focus on studying and using (esp. what can be later used with Windows 8)?
If you want to build an MVVM application (which you probably do for various advantages), then you want an MVVM framework.
I would recommend Caliburn.Micro, as it is straightforward to implement following the examples on the Caliburn.Micro documentation page. It also has a very compelling convention over configuration mechanism, and uses an Actions system to invoking verbs (methods) on your view models from the view. This is more powerful than any other mechanism I've seen.
Prism is quite a heavyweight framework which includes elements of MVVM design to help the implementation, as well as being particularly tailored towards building composite applications (applications that are built up of decoupled components within a hosting shell).
MEF is useful for these types of applications that need to discover plugins or extensions to the application (even after the application has bootstrapped), and can be used alongside an MVVM framework such as Caliburn.Micro. MEF can also be used for implementing inversion of control, but doesn't provide some of the core features found in other inversion of control containers, so you may decide to only use it to implement plugin functionality.
Unity is an IoC container, and would be used to implement dependency injection for your general application infrastructure. There are lots of IoC containers in the .NET space though, some of which offer either improved performance, additional features, or a more friendly API.
I don't know about ReactiveUI as I haven't used it.
If you're talking about maximising code reuse for a move to WinRT, then MVVM is a great choice.
PRISM already include MEF and MVVM logic :)
Ok little bit of explanation here:
MVVM stand for logic in your application. Actually clever way of decoupling of View, View-Model and Model. Don't know any best (?) framework to do it - you could check Catel if you want or MVVM Light but it just a tons of code from someone who understand the MVVM logic and just make it easy to implement it. You could actually try to write your own MVVM framework and see that 'there's no secret ingredient' - just the same repeating code and same classes, etc... Actually you don't need any MVVM framework to implement MVVM.
Once you learn and write MVVM you immediately run into question - How I NUnit test it in decoupling way (this is not trivial problem in Silverlight for example) - so here all IOC/Inject framework come into play. For example MEF. Consider following example to understand a big picture about Inject framework:
Project 'Shared', written in 'least delimiter' (for example Portable Library)
public interface IAmSharedInterface
{
string SayHello();
}
Project 'Main', reference only 'Shared' project
public class IAmMainClass
{
[ImportingConstructor]
public IAmMainClass(IAmSharedInterface SharedInterface)
{
SharedInterface.SayHello();
}
}
Project 'Implementor', reference only 'Shared' project
[Export(IAmSharedInterface)]
public class IAmImplementor: IAmSharedInterface
{
public string SayHello()
{
return "Hello from implementator class to whoever using it";
}
}
You see - there's no direct reference between 'Main' and 'Implementator' projects - all 'magic' happens in MEF/Unity build/resolve process. So you could easily run NUnit test on Main without using 'Implementor' project and 'Implementor' with 'Main'. There's also a scenario where other project could implement and export 'IAmSharedInterface' specially for testing purposes.
So back to PRISM - it have all (!) this. I know it's not easy framework to understand right away and it doesn't suitable for simple 'Hello World' programs but once you learn it - there's no way back. It just glue all the parts together and give you big degree of freedom in using whatever moq framework you want (for example Rhino).
Prism developing in Microsoft so (I hope) it will be supported not just in Windows 8 but in Windows 9 and in all future versions.
Whatever you asked it's all inside: MVVM, Inject, decouple/plug-ins, easy to read and test
To save adding to the detailed information above, I'll attempt to make life easy for you.
1) For now, forget about IOC / Dependency Injection / Plugin architecture. You say you're creating a simple app, so forget about this for now. Keep your code tidy and you can implement this later if necessary (it's good stuff).
2) Out of the frameworks you've listed I would suggest Caliburn.Micro. It's relatively straight-forward and lightweight. It wouldn't take you long to get up and running.
3) Create your model in a separate assembly which you can use for both your windows app and your MVC website.
Keep it simple and don't get bogged down with all the technologies.
This answer reproduces some abridged chunks of Rockford Lhotka's Blog article "Using the MVVM pattern requires a framework" which was cited in another answer.
It is sort of a meta-answer to this question (though it does contain a specific recommendation), but it seemed very useful to explain the role of a framework in MVVM in the first place.
There are three fairly
popular presentation layer design patterns that I collectively call
the “M” patterns: MVC, MVP, and MVVM. This is because they all have an
“M” standing for “Model”, plus some other constructs.
The thing with all of these “M” patterns is that for typical
developers the patterns are useless without a framework. Using the
patterns without a framework almost always leads to confusion,
complication, high costs, frustration, and ultimately despair.
These are just patterns after all, not implementations. And they are
big, complex patterns that include quite a few concepts that must work
together correctly to enable success.
...
Trying to do something like MVVM without a framework is a huge amount
of work. Tons of duplicate code, reinventing the wheel, and retraining
people to think differently.
At least with a framework you avoid the duplicate code and hopefully
don’t have to reinvent the wheel – allowing you to focus on retraining
people. The retraining part is generally unavoidable, but a framework
provides plumbing code and structure, making the process easier.
You might ask yourself why the MVC pattern only became popular in
ASP.NET a few short years ago...
Strangely, MVC only started to become mainstream in the Microsoft
world when ASP.NET MVC showed up. This is a comprehensive framework
with tooling integrated into Visual Studio. As a result. typical
developers can just build models, views, and controllers. Prior to
that point they also had to build everything the MVC framework does –
which is a lot of code. And not just a lot of code, but code that has
absolutely nothing to do with business value, and only relates to
implementation of the pattern itself.
...
Typical developers really do want to focus on building models, views,
and viewmodels. They don’t want to have to build weak reference based
event routers, navigation models, view abstractions, and all the other
things a framework must do.
...
In the meantime, Caliburn Micro appears to be the best MVVM framework
out there – certainly the most widely used [as of 2012]...
(Text copied inline for preservation reasons.)
if the user press the button, handling this event should put on controller or event? Thanks.
It really depends of the platform you are working on, because there are huge differences with desktop development (like .NET's WinForms / WPF or Java's Swing versus ASP.NET and Java Servlets or PHP, for example).
In desktop programming the event system makes it really easy (and sometimes even natural, depending how you look at it) to do a lot of the work in the event itself, but eventually you'll find yourself coding A LOT of the program's logic there, making your view a mess. In web programming this is harder to do because you can't really to much of the system logic in the browser (you can't open a connection to the database, you don't have access to the session or any other kind of information that wasn't previously make available by the server).
Also, it is much easier to apply MVC in Web development because of the nature of how the requests and responses work. On the other hand, when programming to Desktop everything is right there at your need, you can easily access any control from probably everywhere, and even if you don't, you will think it is OK (even when it's not) to share things using static variables (or a lot of singletons).
To make a long story short, I'd say that you should make all necessary efforts to resume logic programmin in the events as possible. With some practice, you will discover that delegating the logic to a regular object instead of the view itself will make your life easier in the long shot.
In time: the kind of controller that you use could be important too. For example, ASP.NET uses some kind of Page Controller, while many PHP and Java frameworks are more kind to use a FrontController (it's not a rule of course, but can make a difference of how you see things).
I want to develop an application which has a graphical user interface that could be developed by using different widget toolkits. For example I want to use Qt, GTK+ or even ncurses as a building block for my user interface for the same application. Moreover users could choose which GUI implementation will be used during the next startup of the application without recompiling it first. I wonder what are possible design strategies and design patterns used in the implementation of this design?
The classic design pattern for multiple GUIs is MVC.
You have one model (application data and rules), the controllers (one per view) - these control UI interactions and mediate between the UI (views) and the model.
You can have different views talk to the controllers - one view can be Qt, another GTK+ or even a console application.
Why would you want that?
Each toolkit has its own strong points and weaknesses. If you want to design something that will work with them all, you will be limited by the cumulative sum of all of the weaknesses and gain none of the strong points.
For instance if you're using Qt then you won't be able to use QT's signals and slots. that will make writing the GUI and the interaction with it quite painful. You'll basically need to write a whole wrapper layer around something that is already a wrapper layer (to the native APIs)
I see no possible reason why a user would care to choose between Qt or GTK+ or ncourses. just select one thing and stick with it.
I've done plenty of programming before for CLI and the web, however recently I am getting into desktop GUI programming.
Most of the tutorials for GUI programming I found just explain the different controls you can use and leave it at that. Some of the better ones also skim over a few usability issues.
However, my problem is not with the APIs, or the theory but with my code.
How are you supposed to organise different views your application might have (e.g. a IM application has a login view, a contacts list view, a conversation view etc.).
Are these supposed to be different classes or different methods on one class?
Different panels that are hidden and revealed, or different windows altogether?
I'm hoping for answers as language agnostic as possible, but in case that's not possible, the languages/frameworks I am considering are Java/Swing or C#/WPF. However, if there's another language/framework that is significantly better for learning from, I would consider using that.
Normally each view will be a seperate class in a seperate file. The class will then most likely implement some base class like Window or Control.
As far as organization, if it's a simple app, put them in the root or in a UI folder. Or perhaps a Window folder and Controls folder.
If it's a large app with several views, than break them out into functionality, i.e. an IM folder.
I would say go with what Joshua said and as far as using different panels that are hidden and revealed, i've worked on old code and it's a nightmare to re-use (8000+ lines of Delphi 6!) so stick with different windows as much as possible!
The generally recommended overall structure of the program is the model-view-controller (MVC) type of structure. So, first off, don't make the actual data part of the views, it goes into the model. From here, since the only data in each view window is now almost entirely just layout information and what to do on an action (click, data display, etc), if these are different, they should probably be different classes. If there's some general functionality that can be factored out, you can make this a base class and inherit from it, but in the end, windows with different functionalities should be different classes.
If you are going to be using one of the mainstream IDEs it will handle some of this work for you. The default will be a different class for each form. Hidden panels and tabbed interfaces are nice features but do yourself a favor and learn the ins and outs of embedding groups of controls into form. Some frameworks allow you to directly embed one form into another. Others have special containers that can be be embedded.
The point of these is to break up your functionality so you don't wind up with a bloated form class that's difficult to wade through.
I would also spend some time looking at some of the architectural patterns for keeping your business logic separate from your UI. Check out this link for a good starting point.