Just wondering if any has successfully managed to make use of PRISM v5 composition features like Regions, and View-Based navigation? These features, seem complementary to ReactiveUI in their scope but I am wondering if their any any gotchas one needs to keep in mind before trying to use both libraries in the same solution.
Maybe this answer will help you.
All regular features of RxUI will play well within Prism, but one is competing: RoutedViewHost and ViewModelViewHost (View locator by ViewModel, or routing navigation)
Basically the gotcha is this:
Prism tries to resolve a VM type for a given view, whereas RxUI does it the other way around and resolves View for the current VM.
Because of that, mixing them back and forth can be confusing (at best), but you can bind one to a region, and use only RxUI View resolver for that region.
Related
I am using Full Calendar for event management utility in one of my project. However, my requirement is to show a year view similar to one shown here (as I want to display event in a similar fashion. Ignore the red dot).
I tried forking the original code to make some changes, but could make much out of it. Seems like every view gets a lot from common code, not much distinction among different views.
Is there a way to achieve this using FullCalendar. Or is there any other known library to achieve this. Our project is looking for a supported library only
I'm currently working on a project that uses the routing approach (not documentation yet for Dart):
https://angular.io/docs/ts/latest/guide/router-deprecated.html
And I wonder how could I control the transition between different views. I read about the CssAnimationBuilder, but there is no much documentation about this class.
Even though the question is related to the Dart environment, TypeScript and JavaScript programmers are welcome, since Dart is still a small group.
There is a new router coming again and there is also new animation feature work in progress and it looks like it is about to be shipped (https://www.youtube.com/watch?v=Hr4IKlr9mhg) I think it's better to wait until these become available.
If you need or want a solution immediately I would create a custom <router-outlet> that adds the new component, before it removes the old one and adds/removes CSS classes as required to make it easy to apply animations.
I want to convert a small MonoMac application that I created so that it uses the MVVM pattern (especially to port in easily to Windows). I want to use the ReactiveUI framework. The current application uses an NSOutlineView control with a corresponding data source. As far as I could see there is no support currently for this control.
Is there a guideline how to adapt the NSOutlineView and data source so that it supports data binding as used by the ReactiveUI framework?
Unfortunately the data source support that ReactiveUI provides is iOS only and the code is quite complicated, but you can have a look at ReactiveTableViewSource and friends and try to create an equivalent for NSOutlineViewDataSource.
The general idea is, create a NSOutlineViewDataSource that can follow around a ReactiveList of ViewModels, and create Views for them as-needed.
Assume you have to develop an app, which needs a completely customized user interface so that you can not use any standard UI objects in Xcode.
How would you proceed to create such an user interface? Would you use the interface builder? Would you create something like a master parent UIView? What are the best practices to achieve this?
What would be the most elegant solution with less code duplication?
If by "complete customization" you mean the look and feel of the app,
then I suggest to design the IB objects you require using some design IDE's such as photoshop and then use those slices for your project.
This is the best option I find so far to get a complete customized look with minimal code, and by minimal, I mean you don't actually require any coding. You can do this complete customization within your Interface builder.
However, I don't think you can completely ignore standard UI objects as you require them to add basic functionality.
If customized controls are what you are looking for, then I suggest you to create separate custom control classes so that they can be reused anywhere in your project, or in other projects too.
Here are two wonderful tutorials on custom controls:
http://www.raywenderlich.com/36288/how-to-make-a-custom-control
http://www.raywenderlich.com/56885/custom-control-for-ios-tutorial-a-reusable-knob
Hope this helps!
For a mid sized application that makes use of MEF catalogs is there really any advantage in my using Prism modules rather than just putting the different functionality into different class libraries. I just can't see why I would need to use Modules.
Anyone have any thoughts on this?
Thanks,
Richard
Modules are used when you want to perform initialization actions when the module is loaded. This can be for example the registration of views to regions using the Prism IRegionManager interface.
Whater PVitt Saying is correct plus i would like to add to it.
Modules are always a good option for the scalability.
you can easily do future enhancements by having Regions,each region having some view associated with it and each view in different module.
when i say each view in different module it means you should find out which view is having some other view related to it and make a clubed view of these two views and have single module for these views. after all its your call.
for e.g.consider your application has a menu.Toolbar for each menu item is same i.e. having same functionality then you can have ToolbarView+Menuview inside "MenuView".MenuModule will have this final MenuView.
So my opion is go with modular approach if you have any future enhancement or if your project is going to change time to time like new functionalities on user demand etc.
Modules are a wonderful way to allow multiple development teams to develop at the same time. Also assist your to organize and maintain the Single Responsibility principle of SOLID principles in a Project level.
It helps your to have separation of concerns.