after my post a few days back regarding strongly typed navigation, now I ran into another problem. Mainly caused by overusing the navigation for things it is not supposed to do. In this case "setting modes". My main list has only 5 modes. I know,
I should give each mode a parameter and switch the ViewModel or do some other fancy stuff.
But for now, to get a rough draft of the application, I just created 5 Pages. I mean its just 5 pages, and it works like a charm. My ModeSelectorViewModel looks like this:
AllCommand = new DelegateCommand(x => App.LocalNavService.DebugNav<ListAllPage>());
FilterCommand = new DelegateCommand(x => App.LocalNavService.DebugNav<ListFilterPage>());
LikeCommand = new DelegateCommand(x => App.LocalNavService.DebugNav<ListLikePage>());
RecentCommand = new DelegateCommand(x => App.LocalNavService.DebugNav<ListRecentPage>());
TopCommand = new DelegateCommand(x => App.LocalNavService.DebugNav<ListTopPage>());
And it works really good. BUT, of course, after you clicked 10 times on the different modes, have fun to navigate back to the last page. You have to revist all previous pages. Now I am not using the navigation service directly, there is a local wrapper.
My question is:
Which method or way should I use instead of navigate to replace e.g. ListAllPage with ListFilterPage, without loosing the other nice features of caliburn. Does the FrameAdapter need some additional function? Just a tip in the right direction, I will implement
it and come back with a result..
Sep 28, 2010 at 12:04 AM
If these are really just different views over the same page, then I recommend that you implement some sort of state variable in your VM and use that in combination with something like VSM to switch out your views. If it's more complex, you could model this
as a parent VM with child VMs for each state. Then your parent VM would be a Conductor and you would use a ContentControl to bind to the ActiveItem of the conductor. Have a look at the WP7 sample in the docs. The second VM does this. Just get rid of the ListBox
and you have it...more or less. Also, you really don't need to use a DelegateCommand with Caliburn.Micro. Have a read through of the Actions feature. I think you'll find yourself writing less code that way.
Sep 28, 2010 at 12:25 AM
Edited Sep 28, 2010 at 12:30 AM
thanks for your fast answer. I know the current way is not exactly best practice, but there are some reasons for my approach:
- Designer Support
- Quick & Kind of Dirty
The most important part is the integration into blend. I tested the following approach, which works pretty good:
- SomePage using SomePageViewModel
- ListAllControl using ListAllViewModel
In SomePage I can define the SomePageViewModel
as designer data context, which means it basically works out of the box. In the control view of VS or blend, when looking at the single control (in this case
ListAllControl) I can set the designer datacontext to the appropriate
On the main Page (e.g. SomePage) I use a property on the
SomePageViewModel named ListAllViewModel and bind my control data context to it.
On first glance this seems messy, and if there would be more then 5 pages I would not do it that way, but 90% of the application will be GUI look and feel, and for that I want to keep the blend parts really simple. In my approach I ALWAYS have a
Page with the PageViewModel, and for every
Control I create I ALWAYS have a ControlViewModel.
So for now I will stick to this concept, just to get the whole application mocked up. Afterwards I may consolidate some of the pages into one, IF i am sure they really should look similar. Not clear yet. For now I may just write a kind of "makro"
navigating back for me, as I said, quick and dirty..
Regarding Actions, I am currently using the MVVMLight EventAsCommand feature (maybe you have heard of it), and it works all pretty well. Its sometimes some dragging around in Blend, but this takes seconds. I got the idea from the video player sample, see
The Actions you refer to, is it similar (I think I read about it), and most important, does it play as nice with blend as the examples in the blog post (see second half, where he can design without any worries about the code, I really like this)..
PS: Important to mention again, I am working in WP7, so I try to keep it as simple as possible. With the above approach I may have to copy and paste some stuff, but with good naming conventions errors are obvious, and if you keep it that simple, at least
you can estimate the time required very accurate...