Author |
Share Topic Topic Search Topic Options
|
Walid
Senior Member
Joined: 14-Nov-2010
Posts: 161
|
Post Options
Quote Reply
Topic: Cocktail 2012 Compatibility assembly Posted: 24-Sep-2012 at 7:51am |
|
|
mgood
IdeaBlade
Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583
|
Post Options
Quote Reply
Posted: 24-Sep-2012 at 4:22am |
Navigation in the traditional sense means that you close the current view and open a different view, so you need to do things like checking if the current view can be closed in it's current state.
In your scenario you toggle between multiple open companies, that's not navigation. The current active VM doesn't get closed when you toggle to another company. It simply gets deactivated, so the Navigator is overkill and misplaced here. It's enough to just call ActivateItem(company).
This scenario is very much like the tabs on the detail VM in TempHire.
|
|
Walid
Senior Member
Joined: 14-Nov-2010
Posts: 161
|
Post Options
Quote Reply
Posted: 24-Sep-2012 at 3:59am |
I have one case where the new NavigateToAsync method doesn't fit my scenario.
I have a module allowing me to create/edit multiple Company at once. A Conductor (OnActive) allow me to keep trace of all CompanyVM instance and a listbox (bind to Items property) allow me to select the one I want to show in the ActiveItem control
before I could just have a method like :
public void ShowCompany(CompanyVM company) { NavigatorService.NavigateToAsync(() => company); }
Now with the new service, what is the best way to have the same behavior ?
When I will call ShowCompany this will create a new instance which will appear in my listbox (the old one will still be there). So I will have to manually remove the "old" instance which looks a bit ugly to me.
Any though ?
|
|
mgood
IdeaBlade
Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583
|
Post Options
Quote Reply
Posted: 23-Sep-2012 at 12:57pm |
You shouldn't see the busy indicator. All cache queries are synchronous. The UI thread is never free to display the busy indicator, by the time it's free, the busy property on your VM will be false. If you look at TempHire, you don't see the busy indicator if you select a staffing resource that is already in the cache, even though it creates a new detail VM.
|
|
Walid
Senior Member
Joined: 14-Nov-2010
Posts: 161
|
Post Options
Quote Reply
Posted: 23-Sep-2012 at 12:17pm |
That's the case, I already have a UOW for the wizard. My concern was more about having a fluid navigation.
If I have to recreate a new instance of the View/ViewModel and load the data (from cache), I can see the busyindicator working and I would like to avoid that (even if it's only during less than half a second).
Anyway I will do like you suggest and will see how it's going.
Thanks
|
|
mgood
IdeaBlade
Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583
|
Post Options
Quote Reply
Posted: 23-Sep-2012 at 12:01pm |
Originally posted by Walid
It looks like each call to NavigateToAsync create a new instance of the target Viemodel while in the previous implementation we were able to provide the instance to the service.
I implemented a Wizard service based on the old Navigate Service, so I need to be able to go back on existing instance. How is that possible with the new service without exporting as Shared the Viewmodel ? |
NavigateToAsync creates instances based on the export part creation policy. If you export as NonShared, then it creates a new instance, otherwise with Any or Shared it will reuse the same instance.
You shouldn't need to share VM instances for a wizard, though. The wizard should be backed by a unit of work that tracks all the changes and data. You pass the unit of work from page to page and each page knows which part of the data in the unit of work it operates on, so if you go back to a previous page the new VM instance can initialize itself from the unit of work in order to show the correct information.
|
|
mgood
IdeaBlade
Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583
|
Post Options
Quote Reply
Posted: 23-Sep-2012 at 11:43am |
Originally posted by Walid
Ok, I wasn't sure how to access the selected button. So, using OperationResult, this is the way to do it ? (The whole solution doesn't compile yet so I can't test it)
OperationResult<DialogResult> op;
yield return (op = DialogManager.ShowDialogAsync(...));
if (op.Result = DialogResult.No)
...
I don't want to use async/await yet, first I want a working migration without changing too much code, the migration to Task will come next.
I also noticed you changed the signature of all the methods previously returning IResult. Does that mean Caluburn micro is also compatible to Task so I can get rid of all IResult reference into the application ? |
Yes, you use the returned OperationResult to access the selected button.
Yes, instead of using IResult you turn actions etc. into async methods. See TempHire.
|
|
Walid
Senior Member
Joined: 14-Nov-2010
Posts: 161
|
Post Options
Quote Reply
Posted: 23-Sep-2012 at 10:32am |
It looks like each call to NavigateToAsync create a new instance of the target Viemodel while in the previous implementation we were able to provide the instance to the service.
I implemented a Wizard service based on the old Navigate Service, so I need to be able to go back on existing instance. How is that possible with the new service without exporting as Shared the Viewmodel ?
|
|
Walid
Senior Member
Joined: 14-Nov-2010
Posts: 161
|
Post Options
Quote Reply
Posted: 23-Sep-2012 at 10:01am |
Ok, I wasn't sure how to access the selected button. So, using OperationResult, this is the way to do it ? (The whole solution doesn't compile yet so I can't test it)
OperationResult<DialogResult> op;
yield return (op = DialogManager.ShowDialogAsync(...));
if (op.Result = DialogResult.No)
...
I don't want to use async/await yet, first I want a working migration without changing too much code, the migration to Task will come next.
I also noticed you changed the signature of all the methods previously returning IResult. Does that mean Caluburn micro is also compatible to Task so I can get rid of all IResult reference into the application ?
|
|
mgood
IdeaBlade
Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583
|
Post Options
Quote Reply
Posted: 22-Sep-2012 at 11:00pm |
I didn't see much value in adding DialogOoperationResult. The only difference really is that you now need to use the Result property instead of DialogResult. The Compat package already requires minor code changes and this falls in that minor category in my opinion. As for NavigateResult, Navigator works fundamentally different then the previous NavigationService. With the NavigationService you navigate to an instance of a ViewModel. With the Navigator you navigate to a type and it creates the instance for you. The signatures are not compatible as such, but I added a signature returning OperationResult to the Compat package, so that you can at least use Navigator in an existing coroutine without having to explicitly convert the returned Task, even though the rest of the signature can't really be made compatible. What specific issues is it creating for you?
|
|
Walid
Senior Member
Joined: 14-Nov-2010
Posts: 161
|
Post Options
Quote Reply
Posted: 22-Sep-2012 at 2:53pm |
Hi,
I notice not all the previous result type are in the Compat package. I am talking about DialogOperationResult and NavigateOperationResult, why adding others but not those two ?
I know there is a new Navigate service but since you kept the signature method I expected to keep the OperationResult.
Edited by Walid - 22-Sep-2012 at 2:56pm
|
|