dotnetrocks 0638 rob eisenberg

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