dotnetrocks 0638 rob eisenberg

Recommendations

Info

examples of apps that you'd used where these classes would come into play. If you start by thinking of a basic web browser and not a modern web browser with tabs but back a generation or two web browsers where you navigated from page to page and that was it. Think of the lifecycle that the web browser is enforcing upon that page. There are certain actions that occur at the load of that page. There are certain actions that need to occur at the unload of that page, and in fact there are certain JavaScript things that can happen that would prevent navigating away from that page. So there's sort of a lifecycle around that. So one of the things that conductors do is we extract that notion of a screen lifecycle into a super class and we basically say, hey, if you inherit your ViewModels from screen and you put them inside of this conductor class, then we'll sort of maintain this workflow of activation and deactivation and call back into various key points so that you can affect the logic in the flow of those things. This scenario comes up all the time. Just imagine if you're building a Silverlight navigation app, that's one scenario identical to what I described. If you're building a Wizard, you can think of that as a series of pages you're navigating to and you may need to stop the navigation back or forward at certain points. Or if you're thinking of . . .perhaps you're editing a customer record and somebody wants to close the record, and they have changed the data but you want to stop them from closing that record without notifying them, hey, you're going to lose what you save. . . these sort of scenarios start cropping up all over the place and you have to -- what we found ourselves doing, at least, was re-writing a lot of the logic to handle those over and over again. And this is also a place where you end up getting into. . . if there is any place I've seen or found myself really creating spaghetti code, it’s around these types of scenarios because you end up starting to, you know, if you start from scratch you start to wire up events and you want to see, okay, when is this unloading and when is this loading, and I've got to call back into this method, and it turns into a tangled mess. So we approach this from a ViewModel-first perspective where we sort of embed these lifecycle patterns into a couple of different types of ViewModels and if you inherit from these you just override a couple of methods and we'll just tell you, hey, activate yourself, or deactivate yourself, or hey, we're about to close. Do you want to allow the screen to close? And so on and so forth. So there are various different incarnations of these patterns and you can compose them in different ways to create all different kinds of shell behaviors. So if you think you like Visual Studio, it’s got a bunch of screens active at the same time but for the most part you've got that document area where you've got maybe a C# file open, maybe a XAML file open, maybe an XML file open. Depending on which one of those files is active, the toolbars change. Rob Eisenberg MVVMs Us with Caliburn.Micro! February 17, 2011 Carl Franklin: Yeah. Rob Eisenberg: You might get an XML document specific toolbar or you might get toolbar icons related to C# when you’ve activated that. So all these kinds of scenarios where you need to sort of know what the user is looking at, what's activated, because you've got to change other parts of the application, those are the kinds of things that the screens and conductor pieces are literally just like Lego blocks; you can kind of assemble them together to make whatever type of shell you're making and then override the appropriate method that's necessary to control the workflow and things like that. So a little bit, you know, at first I think as people try to jump into this particular feature it can be a little bit confusing but when you're building a real application and you come across these scenarios and you try to solve them, that's when using these features just make it as simple as driving and overriding a method and everything just works. We've gone through several different implementations of these types of patterns across various different projects we’ve built and we arrived at the implementation we have now and they're all composable. So you can imagine -- let me give you a little more complex scenario so you can imagine how this might work. Back to the web browser, think about the modern web browser where you have multiple tabs, each one of those individual tabs goes through multiple pages. So the web browser knows which tab you're looking at right now and may do things depending on when you switch from tab to tab, but also things happen inside of that page when you go from page to page to page in front of the tab. So you've got all these kind of complex interactions that are happening and we can model this all very simply by composing our screens and conductors in a particular way to form that type of a shell pattern. So it just make those things really, really simple and helps you avoid spaghetti code. Like I said, if you don't come across that scenario, then it would overly complicate your solution to use them. But when you do find yourself needing to handle activation or shutdown of certain screens, cancellation, all these kinds of things, then it’s there for you to compose in and very simply to use – that’s it in a nutshell. There's a lot of thinking and a lot of evolution behind that and a lot of personal pain trying to solve those problems in the past. Richard Campbell: I'm trying to imagine how this shows up in Visual Studio. Is it pretty much just transparent, just a set of libraries you've loaded? Rob Eisenberg: So you know all those things are just base classes for ViewModels. Richard Campbell: Okay. Transcription by PWOP Productions, http://www.pwop.com Page 10 of 13
Rob Eisenberg: But each one them would have their own View and you would edit the View. So for a conductor you might create a View that was basically a tab control over a collection, but the ViewModel itself would be the conductor ViewModel that controls how that tab control actually works and hooks into the activating and deactivating of those different tabs. Richard Campbell: Right. Rob Eisenberg: So in Visual Studio you just see your View just like you normally would in the designer and you just have your ViewModel that would probably inherit from like a conductor as a normal class and that just happens to be the class that encapsulates the behavior of that user interface and conducts it, if you will, through its paces. Richard Campbell: The main thing is that you’re basically picking a base class to work from and you go from there. Rob Eisenberg: Yes. As I said, it's a base class for the ViewModel, not for the View. Richard Campbell: Right. Rob Eisenberg: But it controls the behavior of the view. Richard Campbell: And do I understand there's some ability to build Win Phone 7.0 apps using Caliburn.Micro? Rob Eisenberg: Absolutely. Caliburn.Micro works on WPF, Silverlight, and Windows Phone 7, and one of the things that we did was try and bring as much of this workflow from Silverlight into the phone as we could and to go a little bit further to integrate with some other phones' specific features. So for example, if you build a Phone 7 app, you know that it sort of has a navigation paradigm built into it. Now what we do is we hook into that navigation paradigm and we do some neat things with that. The phone, via that navigation paradigm, is sort of a View-first approach because the phone itself is loading pages and there's no way to intercept that and sort of load the ViewModel first. So we work backwards and we connect things the other way. So if you load a certain page, we’ll then locate the ViewModel and then we'll bind them and we can apply all the same conventions that we do with Silverlight and WPF against your phone pages. We do some other neat things. One common thing with navigation in phone apps is that you would navigate to a page and have some query string parameters. Richard Campbell: Right. Rob Eisenberg MVVMs Us with Caliburn.Micro! February 17, 2011 Rob Eisenberg: So we take those query string parameters, we parse them out and we look at your ViewModel and we see if you’ve got any properties with the same names as those parameters, and if you do we'll coerce, type coerce, the values and push them in into those properties. So you never need to worry about how am I getting that parameter string, that query string information into my ViewModel. As part of that navigation note that we do, we push those things in there. The other thing, a couple of neat things we do, is there’s a real problem with doing ViewModels against the app bar in the phone because the app bar is actually mostly implemented in native code with a very thin wrap on top of it so it doesn't support data binding or behaviors or any of the things you would typically use. But because our binder is applying all these conventions, one of the things it does is it inspects the View to see if it has an app bar, and if it does we do a little bit of extra work behind the scenes so that we can take all the features of actions and apply them into the app bar, to the app bar buttons and app bar menus. Richard Campbell: That's clever. Rob Eisenberg: So you get a very simple, very seamless experience. You don't really have to change the way you deal with the app bar versus the way you would deal with other buttons throughout your app and so on and so forth. Richard Campbell: It just sounds like we're close to an idea where you could actually build a chunk of code that ran fairly well in both the phone and on the web. Rob Eisenberg: Fairly well. But the main thing is going to be that basically the outer shell of the app, because the phone is really using that navigation framework and from that point in the architecture it's going View-first and have a very explicit way that the phone expects to run your app, you have to take that into account. But with inside of each individual page, that can be identical across the platforms for the most part. Richard Campbell: Like you'd almost build a framework onto the web side of things that would support that behavior, maybe a little different interpretation so you use the screen better and use a paradigm that's more web-centric. But you got me thinking now, Rob. There are some interesting ideas here about getting to that nirvana of write once, run across the platforms. Rob Eisenberg: Well, the main thing for me is, it’s not even the differences between the technologies but starting with WPF back in -- I don't know when I started, 2005 or 2006, developing a sort of methodology and a way of thinking about solving and Transcription by PWOP Productions, http://www.pwop.com Page 11 of 13
Page 1 and 2: HTTP://www.dotnetrocks.com Carl Fra
Page 3 and 4: Pandhi, our resident graphics and A
Page 5 and 6: Rob Eisenberg: The blue screen. Tha
Page 7 and 8: ind them together and so on and so
Page 9: Rob Eisenberg: It's got a simple ba
Page 13: Carl Franklin: Am I right in assumi

dotnetrocks 0638 rob eisenberg

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?