I have ContractView. This is to be displayed from 2 separate tiles on my dashboard. One for baseload and one for peak load.
When showing baseload clips the title will be Baseload Clip Definition and when from the Peak Load tile on my dashboard, it will be Peak Load Clip definition
Likewise the ViewModel will need to get Baseload or Peak load clips depending on which tile the user has clicked on
I know one way I could do this is to make 2 separate copies but this seems totally wrong as it would duplicate the views.
On the view model size I am considering creating 2 seperate view models and inheriting them from a ClipDefinitionViewModel. The 2 new view model classes would then know the clip type to obtain from the data service
Is there a better way?
I am using Simple MVVM Toolkit
Paul
One class, two objects with different properties.
Have a Title property that you set when the VM is constructed (either pass into the constructor or set explicitly).
Likewise a LoadSource property can define where the VM should look for its definitions.
Related
I'm returning to Visio after being a power user in the 2000's. A lot of what I'd do back in the day was create custom masters and associate data with the shape with individual labels etc. on those masters. Sort of a multi-part shape bound to the shape data on a given master, with fine-tuned arrangement.
The shapesheet seems entirely gone in 2016 Pro and now we have the data graphic features, which are nice and interesting, but they don't give you the same degree of fine-tuning and baked-in support that my old approach of building custom masters did.
How would I go about taking a text block on a master and binding it inside that master to the master's shape data for a given property? I'm betting it's a custom expression, but I'm not sure what the syntax would be.
Oh, my overall use case here: I want to have a shape with fine-tuned fields that are always visible, but appear in different compartments on the shape. I want to link external data into the shape and have the text blocks pull the value out of the shape data and render it for the area in question. I may use Data Graphics for ancillary things on a case by case basis, but at a core, I know I want certain features to always be present in a master and styled in certain ways.
to display the property of another shape you need to reference it in the form:
sheet!N.prop.X
N being the ID of the other shape, in your case the parent.
Store this value in a intermediate field, the use insert/field.
Here's a tool to do this automatically: http://visguy.com/vgforum/index.php?topic=6318.0
To handle input options to custom properties I recommend the following
1) set up a custom property of the page as semi-colon separated list for holding the desired values. eg: prop.myOption = "A;B;C"
2) in the shape needing this option, set up am according field as fixed list. In the format cell write: thePage!prop.options.
That's it. This way you can edit the list in one central place and have all the shapes updated.
I am developing an application of iphone which is navigation based, and i am showing data on first View Items then on second View Sub Items and so on. So my question is that what will good approach to save this on Data base (sqlite).
Keep this simple.
Each object/View has it's own ID and at least one parent ID.
This will ensure your data can represent trees of any depth and any complexity.
i am not an expert in this field but you can do it like this ... now that you said all you data can be represented something like tree...
Find all the objects that will be leaf of your tree make those objects as a table in DB, (please keep in mind that you make table only for objects that have different structure not because they have different values)
Repeat above step for one level above until you reach top
Eventually you will find that you just got your DB.
To be more precise you need to study DBMS
I've gone through a lot of intro-level tutorials on MVVM and can certainly see its merits but I'm having a hard time applying it to my LOB application. I plan on using MVVM Light, though I don't think that's going to impact the overall design structure of my VMs.
Suppose I want to write a TaxiDispatcher application where I have a service that goes out every minute and fetches the latest status of each of my taxis. I also have a list of fixed locations that people can call from and request a taxi. The dispatcher would then assign an available taxi to that location. At any given time, each taxi would either be available to the dispatcher or assigned to one of the particular locations in order to pick up a customer.
My main screen (let's call it DispatcherView) would consist of a list of available taxis on the left-side of the screen and then two additional pieces of visual content: a list of my locations (whether or not a person is there requesting service, which taxi has been assigned to that location, etc..) and a list of taxi assignments (elapsed time since they've been assigned, location, etc..).
All 3 of those views work off the same 2 sources: the taxi data service and the list of my locations that I can dispatch a taxi to. Right now, I've got separate views and view models for each of the 3 views (UnassignedTaxisVM, DispatchLocationsVM and AssignedTaxisVM), each being injected with one, or both, of the data sources. When the dispatcher assigns a taxi from the unassigned list, I use a Messenger to communicate with the other VMs to let them know that the taxi has been assigned to a location (the DispatchLocationsView and AssignedTaxisView are both updated with this new information as a result). But when I'm wiring up each VM, I'm having to inject the same datasource(s) to each of my VMs and thus having to write similar code in each VM to respond to the command when the dispatcher assigns a taxi to a location. It may just be my lack of experience with the framework but it just smells bad to me.
Does it make more sense to simply have one VM (DispatcherVM), and have the DispatcherView be responsible for rendering all 3 pieces of visual content? I envision this would involve having 3 ObservableCollections (UnassignedTaxis, Locations, AssignedTaxis) in my DispatcherVM and binding the datasource of each of the sub-views. As new data comes in from my taxi data service, I'd parse/update to the appropriate ObservableCollection and have my views respond that way.
What's the best practice here? I've got 3 distinct, but similar, "views" of the same underlying data. Should I create seperate VMs for each of the views or have one VM expose a view that essnentially consists of 3 separate lists/datagrids, etc..?
It sounds like you have reusable plumbing across ViewModels. Have you considered using inheritance (i.g. a ViewModelBase class) to reuse that plumbing? If inheritance isn't right for your solution, you could go the route of one main VM that is composed of child ViewModels that the main ViewModel coordinates.
Both patterns are equally good solutions at a high level in my opinion. It's hard to know which is more appropriate without a lot of context.
I have a Triangle class. Each Triangle has three edges a, b, and c, and also three angles angleA, angleB, and angleC. In addition to the size (length or angle), each datum also stores whether it was entered by the user or was calculated based on geometric relationships to other data.
Corresponding to my Triangle class, I have a TriangleSidesAndAnglesView. This view has six subviews -- one for each of the angles, and one for each of the sides. The contents of the subviews depends on the information in the model class. The subviews are all of class TriangleDatumView.
Information can pass both ways. For example, if the user enters something in a text field corresponding to an edge or angle, the entered value needs to be passed up to the model.
I am trying to figure out how to keep everything organized. For example, should the TriangleDatumView objects contain references to the respective corresponding members in the model class? Does the TriangleSidesAndAnglesView need to keep a table of which TriangleDatumView corresponds to what model object? Should the TriangleDatumView for (say) edge b know that the name of the edge it is displaying is "b" so that it can write "b=" each time . . . or does it grab that info from the model?
Nothing here is fundamentally difficult. The challenge is organizing it all in a sensible way.
Thanks for any help.
A question I ask myself is "What do I want to be able to independently vary?" -- meaning, if I have a model, could I imagine a totally different implementation of the same interface or a totally different view for the same model. In the variations that I care about, what needs to be where.
So, if labels are always A, B, and C -- I see no reason to store labels in the model. If they can change, then yes, you should not hard-code them in the view.
Views in MVC often have references right to the model they are viewing. Sometimes the controller is an intermediary. Models should usually not contain references to views -- but instead use things like delegates to alert of changes to their state.
I'm in the "Do the simplest thing that works, and don't repeat yourself, refactor when necessary" camp. The issue with building in the complexity at the start is that it might be complex on the wrong axis -- let the features dictate how the interfaces grow.
A view controller could sit between model and view, managing an array of TriangleView instances. The controller adds, modifies and deletes views based on what is in the model, and does the same for model instances based upon changes to the parent view (typing in a text field, tapping and dragging, and other UI actions, etc.).
I am trying to learn my first programming language. Unfortunately I picked the Iphone to start. Thought it would be easy... ooops. Anyway 4 weeks later I've actually got a couple of working apps! kind of...
One of my apps that had a couple of text boxes and a couple of labels.
Each person has a has button that starts a timer that decrements a label's text for a countdown.
I have 2 separate timers that fire two separate methods that increment variables, play a song, update some labels etc, relative to each person. Not war and piece on the amount of code, but enough not to want to have to change both sets every time I figure out how to do something new.
What is a better way to set this up so that I can work with just one set of code per person? I get the whole "person" as an object idea and that it should be it's own class and that I should be probably sub classing it from all the reading I've done. I just don't know how to practically apply it with actual code.
I think the first place to start is to realize that timers are (almost always) part of the interface and not part of the data model. Unless you have a very strange set of requirements, the timers shouldn't be related to your person data objects at all.
You want to maintain strict seperation between data and the interface. This is the key idea behind the badly misnamed Model-View-Controller pattern. It should be called Model-Controller-View to reflect that the controller mediates between the model and the view.
In your case, it sounds like you have a person object that is your data model. Ideally, that model will work without any direct links to any particular interface. A good data model will work with standard views, a web view or even a text based command line interface. It shouldn't matter to your model because it is only concerned with storing or manipulating data without regard to how it will be displayed or used.
Timers that update the interface belong in the controller because they have nothing to do with the data. The same data displayed in different interfaces would need different timers. You probably only need one timer that simply calls a method in the controller that updates all the interface elements as needed. In that method, the controller then fetches the data it needs to display from the appropriate objects in the data model (Instances of the person class in your case).
For example, suppose you have multiple person objects each with it's own countdown number. You would have the countdown value stored in the person object as a property. A single timer in the controller would fire once per second and call a method in the controller. That method would then ask each person object for its countdown value. Upon being asked for the value, the person object would automatically decrement the countdown value.
With this design, you could handle an arbitrarily large number of person objects, each with its own countdown attribute, with just a single timer and one method in the controller.
We could talk for object oriented design for hours maybe months and years. Design principles exist by they are best learned and mastered through experience and a lot of practice.
If you need 2 timers each one calling 1 method that plays a unique role then you are probably stuck with the 2 timers. If there are common tasks/responsibilities in your two timers you could create an abstract timer that implements these common tasks and extend it for more specific behavior (method implementation).
I have found role based design helpful in many situations, but as i said you will have to practice and of course know the basics of object orientation and inheritance.