How do you draw presentation logic, screen navigation and validation logic of controls in UML?
When a new screen is needed or existing screen is modified, I use MS Paint to get the new screen layout approved. I find myself in this situation of how best to draw presentation logic, screen navigation and validation logic of controls.
I currently use Activity Diagram and Sequence Diagram, and put the hyperlink next to the controls and put a link between these two (control and hyperlink).
Please let me know how can I improve upon and represent these pieces in a better way.
I work in windows based application.
Notwithstanding whether it belongs here or not, a couple of possibilities:
IFML, the Interaction Flow Modeling Language. Recently adopted UML notation for modelling user interface flow & content
Jesse James Garrett's visual vocabulary which covers similar ground, albeit isn't endorsed by the OMG or any other standards body afaik.
hope that helps.
Related
I am currently working on a project where i want to display data of a game and my own graphs on a rebuilt minimap.
The data is given as ticks of the game with the entitydata changed in that tick. At first i want to draw the map and then all entities existing at the first tick. Then for every tick i want to update positions and draw lines between entities
My WPF User Interface is set up with the MVVM Pattern.
Now i am struggling with the creation of and techniques for the minimap.
What i want the minimap to support/create:
Interactivity
Click on entities on the field to display more information about them.
Zoom the map
Follow entities(with a zoomed in game field)
Toogle different visuals (disable one team, highlight sth etc)
...(and other interactions like the above)
Performance
Graphics should look as smooth as possible(Map,Images, anti-aliasing, no stuttering)
High framerate (at least 30FPS)
At best it should be a solution with most of the above features built in(see 1.)
Exporting screenshots and a video of the whole game(with my own graphs and stuff)
What i already considered(from this post WPF real-time rendering)
Data binding and canvas
Problem: Slow and not performant..at least as I implemented it)
- WriteableBitmap(Problem: No funcitionalities built in(see 1.)
DrawingVisuals
Problem: How to realize as MVVM? Is it efficient?
WriteableBitMap
Problem: I have to build the functionality of 1.) on my own. But looks like it is efficient
Before i start implementing a lot of my wanted features myself i wanted to ask if there is anything fitting my needs or if any of the above technologies is not suited.
I hope that my question is clear enough.
Feel free to let me know if anything is missing.
DataBinding is nice for connecting view models to input controls, but not for updating the state of graphic objects in real-time.
I would go with DrawingVisual because it is relative lightweight and supports hit testing. Even if you don't have MVVM support, it is easy to update the visuals "manually".
I'm trying to get into WPF and have been reading articles saying MVVM is generally the way to go for WPF.
What about application that doesn't require user interactions such as button clicks?
An example would be a Card reader application:
User connect card.
Application read and display card info on screen.
Perform backend validation.
Display result on screen.
I could be wrong but I don't see MVVM being suitable for such application. Is there a more suitable design pattern that I should be considering instead?
The point of MVVM is to detach your views from your code.
Lets say in a month you need another view, you can easily create one without having to worry about "logic" being part of the view.
Mind you, some things are still easier done in the code behind ... but depending on your "purist" status, it'll vary.
Having said that, you can still happily use MVVM for your card application, and use the GUI to switch around and show different views ...
Last thing is I'll recommend picking an MVVM framework to help you jump start. There's plenty of them out there, varying in complexity and goals.
MvvmLight , Castel (?), Prism, Micro mvvm (?) ... run a quick search and see which you like .
Having said the above, let me shamelessly plug this article: The big mvvm template
I am working on a winforms client server application that will load one of many forms that would be used to enter data or retrieve data or search for data. I want to put buttons on the left side of the screen to select which form is loaded on the right, and buttons at the top for the usual New, Open, delete etc.
I began working on this by making an MDI form that would popup a child window that allows to user to pick the application they want to use. Then when they select it, it would load the appropriate form on the right and update the text and functions of the buttons on the left. I was using panels to load the forms into for the button form (which I called the Navigator) and the application form. I had to use events to make changes to the different button forms when the form on the right was changed. A friend of mine said that I was probably going about this in the wrong way. He said there is probably a better design pattern or methodology or controls that already do that for me.
I dont know how to even search for something like this on the web.
Can someone give me some direction on this?
I can do the research if I am pointed in the right direction.
Maybe there is a control that already does all this?
Thank You.
We use a similar pattern. MDI parent with menus for objects and tasks. MDI Child forms (about 30) for each object/task. Left "nav" button in three groups: 1:1 (calling up l related objects), 1:N (display lists of related objects - inspections, equipment, etc.), N:N:X (other complex relationships or tasks). The body has a tab control to group data. At least one tab is a datagridview that is reused for the 1:N lists.
Left nav button sets are dependent on the object being managed. We add the buttons dynamically but in most case they are hard coded - we just don't use the toolbox to place the buttons on the child forms. Each button set is in a Panel - I would probably use a FlowPanel if I were to start over.
We build a "model" form on one of the more complex objects, built all the data binding logic, and then used that form as a basis for the other objects. We didn't use inheritance as supplied by Visual Studio/VB.Net.
We do our own control data "binding." We use ADO.Net and SQL Server. Our child forms only display one record and do not support the typical record navigation seen in the wizard generated forms - this works fine in our case as we navigate sideways through our data. e.g. Application, Authority to Construct, Permit - then inspections, renewals etc. all related to one Facility. (we're a regulator agency)
We use VB.Net as a lot of the business logic was developed in VB6. I'd still use VB.Net today vs C# - much easier to use for business logic and more maintainable IMO.
One issue to consider - some have out the long knives for WinForms (and VB.Net.) I can't see Microsoft depreciating WinForms but there are those advocating that. Many cannot appreciate the simplicity (albeit limited flexibility) of the WinForms that allows us to concentrate on the business being done. I keep looking at WPF but simply cannot see the usefulness of all the UI power it provides. WPF proponents will push MVVM but that is just more complexity that is not needed for small scale development or production (20 users with desktops o a LAN) environments. WPF does not lead itself to our sideways navigation.
I think the left toolbar for selecting the form is a good pattern, but make it collapsible (hide) so the user could use all the desktop space.
As for MDI personally I don't like it because fell a bit outdated and cluttered. But again look for a balance of form and function.
For the top toolbar I would make it part of each form so it would be easy to program the logic. It an unnecesary complication put them on the master form.
As a recomendation you could look, Designing Web Interfaces even it's more focussed to web could give some pointers in user interaction.
For more informacion search ui patterns, user interaction design.
I'm writing an application that is supposed to show and hide the content of the main window stack panel based on the user choice. For example, the user clicks on the button that displays the list of the customers, then click on the button that displays the ordering form. The customers content should be hidden and the ordering form should be visible. Moreover, if there are contents with related information (like customers and their data) I want to be able to change the data in one window and it should automatically refresh the data in the other window when the user decides to open it. Is there a good way to do it in MVVM?
Thanks for any suggestions.
Because this question is so generic, the answer must be as well, and the answer is that this is exactly what MVVM is for - modeling data and binding it as needed. In fact, I would argue that a majority of MVVM examples you find online will be some flavor of an answer to your question, most likely using good ol' Northwind.
It sounds like you need to really take a good look at how you want to do your design before you jump in and start coding.
You might want to check out Prism (or as it is really named Composite Application Guidance). You can build really complex and modular designs with it.
You might be interested in the MVVM sample applications of the WPF Application Framework (WAF).
Writer: Shows how the Views (UserControls) can be switched (Edit mode; Print Preview mode).
BookLibrary: Shows how data modified in one View is automatically updated in other Views.
We were building out the next version of an in-house thick-client application using WPF/Prism (Composite Application Library). As we were nearly done with the client our team was put under new management and shortly thereafter:
We were then directed to drop the Prism framework to keep things simple. This includes not using any type of Inversion of Control.
We were directed to build out the WPF application without using MVVM or similar; and more along the lines of a traditional WinForm application. The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing without having to traverse through a view-model (or similar).
We have now been tasked with building out the WPF application using one primary Window, use a Frame Control to contain the content, and use a Ribbon outside of the frame for the menu items. Reason we were provided to use Frame Control:
a. We will show a view in the Frame with a Page (not a user control) and then load the page in the Frame.
b. When a new view is to be shown in the Frame, the current view (Page) will be closed/disposed and the new view (Page) will take its place in the Frame.
c. When a developer looks at the Page in design view, (s)he will be able to click on any control and see exactly what is being done.
Given the restrictions of 1 and 2 above, we’d like to present another method of building out the application that:
Can be presented as an alternative to using the “Frame Methodology” (item 3 above) but still provides the same type of functionality.
Does not use MVVM (see #1 and #2 above).
Provided the direction we’ve been given, any suggestions as to an alternative we can present? I’d request that the responses be kept on the professional level and thank you in advance.
I'd personally try to argue to use Martin Fowler's Presentation Model. (That's a joke, btw...)
Basically, you're being given a restriction that says "Use WPF, but don't use any of the features that make WPF usable." It really sounds like your requirements are such that you would be much better off explaining, reasonably, the advantages of patterns like MVVM.
It sounds like the weird requirements are really boiling down to this:
The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing
If that's the main issue, and the reason you're avoiding MVVM and other similar patterns, I would seriously take the time to educate the management. Looking at a Command, by name, instead of an event, by name (which is what you see in the designer) is really no more difficult.
However, in a large scale application, the separation of concerns is key. Even a properly designed Windows Forms application requires a clean separation of concerns - but with event based programming, this becomes much more difficult, especially from the designer. If you try to develop a large scale, clean, application using an event approach, you'll have event handlers, but those event handlers will all eventually need to delegate their work to a separate component.
This is actually adding an extra level of effort, from an understandability and maintenance point of view, on top of what you get with MVVM. With MVVM, you only look to the ViewModel, which is very discoverable.
BTW - The "rationale" for using a Page instead of a UserControl doesn't make any sense. You can do exactly the same thing you're describing with UserControls... The only reason to use a Frame and Page is if you want to take advantage of navigation, in which case, you can't dispose the old pages directly (or they get regenerated constantly). Also, the navigation tools probably wouldn't be used with a ribbon - the two conceptual models are quite different.
There are criticisms of MVVM which may be applicable to your project; however having unreasonable dictates of programming methodology is always a recipe for disaster.
One of the reasons that we have frameworks and spending time building layers and separation is to avoid the coding mess that always results when you can "simply click on the button in visual studio to see the code that is being executed".
There may not be a way of achieving what you've been asked to do without something similar to MVVM, because anything that has an architecture may well be labelled as being too similar.
However I have been using a system for many years that provides simple inter-object plumbing currently called Emesary you may want to read my C# .NET Emesary walkthrough.
But basically it allows my buttons to be implemented thus:
private void addButton_Click(object sender, RoutedEventArgs e)
{
GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
}
This may be an answer to your problem. It's under hyped, small and so simple but it just works well.
I've achieved a solution to the second question by using a Window, a user control for the ribbon bar (the user control contains the listview), and another user control for the Frame part. This second user control obvious is built using other user controls using a very simple view class. All views and controls are connected using Emesary.
As a school project I had to develop a WPF client which allowed for multiple people to make use of it at the same time. And I used Pages. My verdict: Save yourself a huge amount of effort, and use UserControls instead.
Sometimes the Page Navigator (which you'll use to scroll through) tends to bug out and cause you a lot of problems. Maybe it was my crappy coding, but who knows?
Though I must say, the control being called "Pages" is somewhat misleading... I went "Eureka!" when I found them, and swore at them thereafter.
I totally agree with #2 (MS bigs take note!). It would be cool if you could double-click a Control and it would take you straight to its command (or event if its command is lacking). However till then, make sure that you organize your Views and ViewModels in separate folders.
Having a dual screen (or a very wide one) will allow you to have two instances of VS open on the project, one focused around the View and the other around the ViewModel (my personal choice was having Expression Blend on the View).
Although not a very big application, I managed to convert my project to proper MVVM (ie. ViewModel for every UI element, RelayCommands and Mediator) in a matter of days, so once you understand it it's not too complicated to implement. Plus, there are tools out there (such as Josh Smith's RelayCommand and Marlon Grech's Mediator - totally free, by the way) which make MVVM half as difficult, and twice as powerful.
Using WPF without MVVM is like trying to eat rice without a fork. You'd be better off using WinForms if you're not going to take advantage of what WPF has to offer. My 2 cents.
I wish I could say your management is totally wrong.. but I cannot say that as it will not be the most accurate truth. I guess that the main reason to the changes you described is either because the new manager is not comfortable with the concept of MVVM being the new messiah of UI development or/and another reason could be the cost of educated sophisticated developers vs. cheap developers which can be instructed to get the things done as fast as possible, a concept which is widely known as lean development.
So, putting all I wrote so far under "not what you asked for", here is what I suggest:
you can still use object oriented pure approach, meaning you can have a model object which already have method to show UI information. so every object will be a window derived object, that way you will loose on SOC but you still going to be OOP/OOD.
But LOL, The next phase will bring you to seperation of model from view in order to not repeat the same code in many derrived windows which relay on the same data... so your management will endorse MVC/MVP as good solution .. and the distance from it to MVVM is kinda of short if they want WPF.
Conclusion: you will have to teach your manager why it is better to go for MVVM, unless the project is very short.