Actually I am trying to structure my project in a clean MVVMV way. Unfortunately to this restriction I need to find a way to set pins to the map without the power DataBinding. One workaround could be to have the View in my ViewModel and set it directly.
Right now I don't have any chance to get the registered view. Does it make sense to extend the XLabs.Forms.Mvvm.ViewFactory?
Before adding a new issue on GitHub, my hope is that there is a better solution to handle such restrictions. I always used MVVM in my (small) WPF projects.
No that doesn't make sense. Your best approach would be to extend the Maps class to make Pins an ObserverableCollection that is bindable.
The new documentation format on the Xamarin site is rather difficult to read and does not provide the information you require at hand like it used to but I believe the Pins object is not bindable.
Take a look at the Xamarin Forms Labs Github project to get an idea of how this can be done. The approach is defined particularly well in the ExtendedPicker classes (here the items are bound to an ObservableCollection).
Related
I'm developing an infrastructure for a major project currently based on caliburn 1.
It works fine but it seems like the future is in caliburn micro, am I right?
If I do, how do I implement filters? How do I specify view to a view viewnodel (non conventional)?
And whats the best place to put my splash logic (not root model)
I recommend moving to Caliburn.Micro as it's simpler and easier to extend. It is where any future innovations will be made and it has a larger more active community. As far as filters go, you can actually build them and plug them in. See here Marco's post You can add non-conventional view specification as well. You just plug into the view locator and teach it how to find views. For example, if you want to use an attribute, you can just have the locator look for that attribute first, use it if found, otherwise fall back to the default behavior. Regarding splash logic, you can do that by customizing the Bootstrapper.
Hey guys!
We used to write our UnitTests with FlexUnit and we were just testing our model. Now we want to test the view too. Before i run my tests i create an instance of my view and my model to test the stuff. When i try to access the view i get a null pointer exception. If i add the view to the displaylist it somehow works - even if i remove it from the list right after adding.
it looks something like this:
var myView: MyView = new myView();
//myView.initialize(); will throw error
Application.application.addChild(view);
Application.application.removeChild(view);
myView.initialize(); // will work
Hope you can give me a hint.
Sims
Flex UIComponents do not walk through the component lifecycle until after they are added to a container. As such, variables may not be initialized and children may not be created if you never add it to a container.
More info on the Flex Component LifeCycle. You'll notice there are 11 steps after the component is added to the container.
I suspect that adding it, then removing it, could cause other issues but it depends what you're trying to test.
To know your exact error, we'd have to see what code is in the initialize method on the view. Most likely it accesses a child that was not created yet.
MXML components will often masks the lifecycle steps, but a component will still go through them.
I hope this helps; but since you didn't ask a question I'm not sure if that was the information you were after.
In addition to what (www.Flextras.com) wrote, which I was just about to post as well, you might consider a different approach to testing your views.
First, consider a separation pattern like Presentation Model, MVP or MVC. They allow you to separate your view from your view behavior and test the behavior separate from the view. An approach like this, when done correctly, will take you a long way because you minimize or eliminate the AS3 code in your view.
If you really want to test your views, I would suggest that you use a functional testing tool for this. Unit test frameworks are good for testing classes in isolation. Once you start talking about views, which have complicated lifecycles, a functional testing framework starts to make sense.
Look at FlexMonkey as an example of a functional UI testing framework for Flex.
I recommend you to use User Interface Facade described here or here. This functionality is designed specially for UI componets testing.
My goal was to enable the ViewModel to tell the View to present a MessageBox and ask the user a question.
I didn't want the ViewModel to have any reference to Windows-specific code.
I take the time to download and install MVVM Light Toolkit. Now I find that even with the toolkit, it is necessary for my ViewModel to reference System.Windows, in order to resolve things like MessageBoxButton and MessageBoxResult.
Why go through all this extra work, when you just wind up with a ViewModel that has a reference to System.Windows? I might as well call MessageBox.Show() straight from the ViewModel. Essentially I have saved nothing by using the MVVM toolkit, so I just don't understand why I would use this.
Can someone please explain to me, why go through this effort, if I still have to reference System.Windows in my ViewModel?
Thanks, Hugh
When you use MessageBox class, you need a reference to System.Windows.Forms.dll. MVVM-Light does NOT require this reference.
It doesn't defeat the purpose of the toolkit. The toolkit provides a light framework for separating your view from your model, which is definitely helpful with unit testing.
They reused the enums, so they didn't have to rewrite them. It definitely does seem a bit strange to reuse UI specific enums, but at least they aren't event handlers and event arguments.
Lastly, MVVM uses commands, which requires the implementation of ICommand interface. That interface is in the PresentationCore and is even more UI specific :)
Overall, the purpose isn't to remove references it is to not use those references as best you can and enums definitely don't break the pattern.
The mvvm light toolkit is there to help you implement a the mvvm pattern. The mvvm light toolkit also has the really nice advantage of being blendable, (some tweaks are made for you so you can use Expression Blend to design very easily). The Mvvm pattern also really helps (as others said) the testing of your application as it is hard to test the view but it is a lot easier to test the viewModel.
If you want to know why you go through this effort and use mvvm light I suggest you check this related answer
Hope it helps and good luck!
I am very new to Flex (started learning a couple of days back), I now have some understanding on how to create user interfaces with Flex and how to do MVC with Cairngorm and I really started liking it. But I am still lost with changing views using Cairngorm or entirely in Flex. Being a Java/J2EE developer for more than 10 years, it helps me understanding new technologies comparing it with Java. Typically in java world or in any MVC framework, the controller once got the updated modal it redirects or sets the new view to the user. Lets say once I added a new movie to movie database, I want to show the user a view Movie screen and when he deletes a movie I want to take user to list of all movies. The example which I have seen so far(including the diagram explorer) are just changing the modal values and the data is updating in the same view (using [Bindable]), but my question is how to change the view depending on the result or if it's a fault I want to take user to a different screen. How to do that in flex and in Cairngorm. Are there any best practices available and somebody please point me to right direction/resource. Thanks in advance.
The usual way to do this with Cairngorm is to put the data about the state of the application (eg. the screen the user is on) in the model too. You can, for example, use the ViewStack as the main container of the different parts of your application and bind it's selectedIndex to a variable in the model which will be used to control the screen that is displayed to the user. Putting it shortly - the state of the application is a reflection of the model.
You may also want to take a look at the Mate framework. We recently switched to Mate after using Cairngorm because we found it was a much easier framework to use and understand.
For your example, you would have a faultHandler event listener that would call whatever method you wanted in your model. You could easily use that to show or hide whatever you needed to.
I'm currently implementing a project using asp.net, c# and the MVP (Model-View-Presenter) pattern. The main purpose of this solution is to deliver a graph to the consumer, to be used by a variety of systems. It is basically a custom graph server.
The view page in this particular case has an MSChart control on it, which has to be dynamically populated and configured based on parameters in the QueryString. This can be as diverse as totally different types of data sets, display modes and so on, using a lot of the properties of the chart control.
Many of these properties are again of types which are particular to the chart control and would require the same dependencies as the chart control itself if they are to be set by the presenter.
I'm trying to figure out the best way to expose the properties to the presenter so it can work its magic.
Should I:
Just expose the whole chart object and live with a system.web type dependency in the presenter project?
Make accessor and translation properties for all of the chart control properties so that I don't have the dependency, but add lots of complexity?
Other, that I haven't thought of?
To me it seems that it would be against the MVP pattern to bubble a display control up into the presenter, but it seems that trying to map all the properties to DTOs or similar would be a lot of work that would add a lot of complexity, and while the solution would be somewhat more loosely coupled, I'm not sure the gain would be worth it in this case.
How would you implement something like this, given MVP?
While doing some more research on this topic, I found the following blog post on adding a Presenter Model to handle complex view controls, to map between the view and the presenter. It actually made a lot of sense to me, and it's an idea I think I'm going to follow up on and try.
http://mikewagg.blogspot.com/2009/01/managing-complexity-with-mvp-and.html
In fact, Martin Fowler has written on this as well:
http://martinfowler.com/eaaDev/PresentationModel.html
Check out Automapper. Makes translating from a Business Object to a View Model almost effortless. The general idea is your View Model should only have primitive system types if possible to avoid formatting/conditionals in your view.