>> All right. Thank you for coming.
I'm going to talk
about MvvmCross today.
My name is Martijn Van Dijk.
I've been a contributor to
MvvmCross for about
five or six years now.
I took over, and beginning
after Stuart Lodge who
originally started the project,
started it and he left
sort of the Xamarin space
to do other things,
he went to do JavaScript.
So big love there, right?
No, just kidding. It's
time for the JavaScript.
But so I stepped in, and from there,
I've run MvvmCross with
mostly Cheesebaron,
whose a friend of mine.
He's from Denmark.
Anybody see his picture?
He's got the bazooka on his shoulder.
Do you think it was a bazooka?
>> A camera. I think it was a camera.
>> You thought it was a camera.
[inaudible] It's actually a bazooka.
So be careful with
him. He's a big dude.
So I worked for Baseflow.
I'm the founder of Baseflow.
It's a consulting company
from the Netherlands,
and we do consultancy for Xamarin
apps, for.NET, for.NET Core.
All sort of things like that.
If you need any help,
then send me a message.
So anybody here use the MvvmCross?
All right. That's nice. Thank you.
It's better than nobody.
So MvvmCross is an MVVM framework,
and MVVM is Model View ViewModel.
It's a pattern that's
been used in forms.
It's been used in other frameworks
like Prism, MVVM Light.
There's [inaudible] out there.
It's been very common in
Xamarin apps since
the last couple of years.
That's basically because
people thought, hey,
we need to have an abstraction layer
that abstracts away
our views from your shared
code that you have.
Otherwise, it all gets mixed
up and you don't have
control anymore,
and you don't have
separation of concern.
That's really what we want
with Xamarin at the moment.
So what is it exactly?
You got a view here on the left side.
It's just a an abstract picture here.
You got the view model
which contains the shared,
sort of, code, everything
that gets executed.
Everything that's shared between iOS,
Windows, Android, the
different frameworks.
Models are usually, think of
them as data, as proper objects.
Then there's this thing
here in the middle,
that's called the Binder.
The Binder is basically
where all the magic happens.
Makes everything happening between
the View and the ViewModel,
takes care of when you press
a button on the screen,
that it will send out
a command to the ViewModel,
gets picked up there automatically,
and you do some processing there,
get some data from the Internet,
you trigger change, and the View
will actually update to that change.
So it's a really nice way to separate
your concerns from the View
and the ViewModel.
So this is [inaudible] MvvmCross
has been around now for
about six or seven years and I
stepped in the very beginning.
It was a small community back then,
but it's grown tremendously.
It's been a really
fun ride all along.
Currently, there's a lot
more people working on it.
This is, I think one of
the things that makes
MvvmCross the best MVVM framework.
I can say that because
I love MvvmCross.
What actually is the best depends
on what your requirements are,
but I think it's the best.
But other reasons are,
that it has support for
all the frameworks.
You have an Android, iOS, Mac forms.
It doesn't matter
what you want to do,
has support for it all.
This is an advantage
that you don't have in
any of the other
MVVM frameworks because you're
either limited to Xamarin.Forms
only or to certain platforms.
It's therefore the most
advanced MVVM Library
and can do the most for you.
It's so powerful, that there's
things in there that you probably,
even if you use it,
you don't know about it.
Personally, for myself, I think that
the community is what
makes it the best for me.
It's the biggest community in
the Xamarin space besides the
Microsoft projects that there are.
So that's over 250 contributors
at the moment in MvvmCross.
That's not seen in any of the other
frameworks that are out there.
So imagine that you start a new
project and your boss is saying,
"Hey, well, why would
we use a framework
from an external community
and work with that?"
It's very easy.
It gives you 250 people
that work on it.
It cannot be that.
That's pretty easy.
I think that another
event it says that,
"We've got a very
fast release cycle."
So that means that
updates keep coming in.
I think we've got on average
every month a new update,
where we get bug fix support
for the latest iOS,
support for the latest Android.
It's always up to date because
so many people work on
it, and make it happen.
Other than that, it's really
clean and easy to use.
So as I said, you can see it here.
All the frameworks are supported,
and you don't realize it but that's
a lot of effort going on to make
all of this cross-platform happening.
Even if you want to do WPF.
If you want to do
the old Win forms, for example.
Say, you have
a Legacy app event forms,
you can actually start using
MvvmCross dropping it in there,
and then expand your code
base that you're already have
to Xamarin.Forms while keeping
that old code base there.
This is something that you cannot do
with any of the other
MVVM frameworks.
So imagine the use case is there.
You've got an old app.
You've got to upgrade it.
You got to add support
for Android and iOS.
You want to use forms because it's
quick and easy to get
going there with the UI,
but you have this whole code base,
all C# there that you
want to keep using.
This is already there,
it's convenient.
Drop in MvvmCross, and
you can go from there.
Handle the UI and the
navigation and MvvmCross,
and let your existing shared code
still be there. Is that amazing?
Did you know about that? It's
maybe not so obvious, but okay.
So about Xamarin.Forms, if you
look at a lot of MVVM frameworks,
a lot of them are
specifically focused
on forms because forms is so popular,
and that makes a lot of sense.
What we think with MvvmCross is that
it's a little bit
different because we
think we're going to
start up from the bottom.
Because in the beginning,
Xamarin didn't have forms,
it was only the native
Xamarin.Android,
Xamarin.iOS,.Mac,
whatever else is there.
So when you support
those at the base level,
you're also able to support
forms perfectly as well
because it's on top of that.
It's an abstraction layer.
With that, you can
easily combine the two.
So same case here, as I just said,
if you've got an old project laying
around with this native
Xamarin Android,
native Xamarin iOS project,
and you want to bring
that to forms but you don't
want to do it in one go,
you just want to add a couple
of pages and forms and
navigate from your old
code base to the new one,
and gradually upgrade
your code base to forms.
That's a perfect use case
for MvvmCross because you
can then start doing
that from one moment,
then the other, and one step-by-step.
So this makes it really
easy to [inaudible].
So how does MvvmCross work?
Of course, because it's
MVVM, it's got ViewModels.
In this case, it's got
a specific ViewModel.
As you can see here,
it starts with Mvx,
and that's basically a convention
that's used everywhere in MvvmCross.
All the classes, all the basis
are starting with Mvx.
So when you start
typing in your editor,
type in Mvx and allow to
complete the rest for
you what's available at
that moment. Very convenient.
So MvvmCross does a couple things
that are really helpful,
and I'm going to tell
more about it later.
What you can see here
is just the base class,
MvxViewModel extends
notify property changed,
which means that if
you trigger change,
raise a property changed
on your ViewModel,
it will automatically
raise those properties to
changed event to your view
and you will update it.
It also has life cycle events.
So this makes it really
helpful if you want to
bring anything from
your ViewModel to your View,
and hook into events that
actually happen on your View.
So say appearing.
That's a View event,
and you can catch it
in your ViewModel.
iOS will bring it to
your ViewModel. Android will.
You can execute logic there
that you normally couldn't do.
So how do you bind?
Well, if you guys probably
have used the forms bindings.
You start opening up your code,
type in binding, space,
and then the property
you want to bind to.
So MvvmCross has support for
that, just basically forms.
What is cool, that you can also
binds to anything in
the native platforms.
The native platforms don't
have that out of the box.
So again, here you can mix
and match what you want.
You can bind to the native platforms
and to the forms' platforms.
Another thing here is
Inversion of Control.
As I said in the beginning,
separation of concerns is one of
the most important things
that you got to
do if you're building a new app,
building out an app.
If you don't separate
what you're doing,
you'll wind up in one big mess
and it might seem
like you're making a lot of
progress in the beginning.
At a certain time,
you will hit that wall
there and you'll be
stopped and slowing
down in development.
So always make sure you
keep things grouped.
Inversion of Control really helps you
to do that between the platforms.
Because sometimes you want
to implement functionality
native but you want to call
it from your ViewModel,
from your shared code base.
So with this, you can actually
register an instance that you make on
iOS to an interface that this in
the shared library and you'll be
able to call that code
right from there.
If you want to just get hold on that,
you use MVX.Resolve to get
an instance in your view model.
Another way to do it, is
Dependency Injection.
Dependency Injection
takes care of injecting
native platform code
or services that you
have into your view models so
you can actually unit test them.
As I said, separation of concerns
also means that you are ready to make
those unit tests because if you
have used service location so far,
so MVX resolve, you not actually
able to inject test into that.
So make sure you use
Dependency Injection as that.
Personally, I'm a big fan of it and
I know that some people
find it a bit hard to use.
But if you get a hold of what you're
doing with Dependency Injection,
you actually be able to much better
test share code and
then equality goes up.
So make sure you do that.
So MVVM crossed this space
on conventions.
I've already told you what
the main convention is.
Everything starts with MVX, right?
So another thing is that,
once you want to hook
up your views to
your view model, you
can do two things.
You can do it based on the name.
So login view, will automatically
connect to login view model.
If you've got a Native project,
you can login activity of
fragments to login view model.
If you're doing forms, you can
login page to login view model.
So I guess you get
the concept, right?
It's based on the first bit and
the last bit to connect the two.
So what if you want
to have a better way?
Well, then you can use generics.
Because generics make it
possible that you get
all the named parameters
into your view.
This is something that's very
helpful and it's also a bit faster.
It goes with generics.
You don't need to use
reflection to look up the name.
So I usually make sure
that I use generics.
It's a little side tip there.
So navigation.
Who's doing pace to
pace navigation here?
Right. Who's doing
ViewModel navigation?
Bit of both. Yeah, right.
So I guess this advantages
to both of them but I guess
that if you want to keep
your view models and your things
as much shared as you can,
you should do ViewModel navigation.
In that case, you can then unit tests
your ViewModel navigation and that's
something you can't do
with pace navigation.
So this is actually very interesting.
[inaudible] very useful things.
It's type safe.
You can also do uri navigation,
do deep linking with that,
and you get a couple of events
that happen on navigation.
I'm just going to show you
an example here what you can do.
So you got your ViewModel,
you inject the navigation service
which MVVM cross provides for you.
What you want to do
a lot of the times,
at least that's what I want to do,
I want to pass on some object to
my next ViewModel which I'll
open up in a next few of course.
When I close that ViewModel,
I want to return something back.
So imagine the use case that
you have your screen open,
you want to ask your user,
do you want to confirm
to delete this file?
You opened this popup,
right? Yes or no?
So you want to send the
message to that ViewModel,
so that it will show up the text,
do you want to delete this file and
then some sort of
picture in it, whatever.
But then, the true or false
if you want to lead it,
if you want to send a result
back to the ViewModel that you
opened from to actually delete
the picture that you have there.
So look at this
navigation pattern here.
Navigate to the next ViewModel.
I'm sending in my object,
it's just random objects
that you create and I'm
returning my return object
which I then sent in.
The result which we
awaits is going to be
passed back automatically
once you close your View.
So isn't that very useful
in a lot of use cases?
So I think so, and I think this would
be very good if
forms would offer something
like this but it doesn't.
So use MVVM cross, okay?
So what enables
the navigation service?
It's something we call presenters.
Presenters are something
that you might have heard
of from the Android side of things.
Android has the MVP pattern.
MVP is the model view
presenter pattern.
A presenter there finds out
what your view should do and
where it should go on the screen.
But what you got to do is you got
to make one presenter per view.
We thought, well, that's
nice but you got to make
a lot of presenters then.
So we rethought
a little bit and said,
let's make one presenter
per platform actually,
and let that handle
all the navigation to the screens
where it should position itself.
What you got to do if you
want to have navigation bar,
a hamburger menu,
all the sort of things.
That will run your navigation service
on the Native platform
so it knows what to do.
So here, you can see an example.
This is a hamburger menu, a tab bar,
segmented control, different things.
You can probably name
a couple of more.
Same thing on Android.
But as you can see,
it's just a little different.
On Android, you've got
the tabs that are up
there and on iOS you got
the segmented controls.
iOS doesn't have a hamburger menu by
default but it does have the tab bar.
So even though you want to have
different navigation patterns,
you want to have a hamburger
menu on Androids
and navigation bar on iOS,
that would be possible
using the presenters.
This is something that's by
default on in MVVM cross.
How do you determine what and
where you're going to show it?
That's what we do with the Android,
not the Android,
the MVVM cross attributes.
The view attributes indicate
how the view should be
presented on the screen.
So you can say MVX Root presentation,
which will show it on
the root of your screen.
You can say MVX Fragment.
Well, there's a whole lot more.
Say, you making this forms app,
you can put in
the MVX model presentation
or automatically show
it over some model.
If you want to have a hamburger,
then use the MVX master detail
navigation. So easy as that.
You put in the attributes
on the top of your view
and it will automatically handle
all the navigation for you.
So with this in the end,
it enables you to have
the best Native UI that's possible.
You can combine, mix, match,
anything you want and it will
really be easy to implement.
Be creative with this.
You can extend it as
much as you want,
you can define your own attributes
which do different navigation
patterns would be possible.
In the end, you get a lot
of code to reuse back.
Because with this, you don't
need to do the page to
page navigation and find out
per page what you're doing.
You put in the attributes,
it's there for you, ready to go.
So let's take a look at setting
up a little project here.
I'm just going to see
if this is working.
I was just talking to Lon in
room next door just before this,
and he said, "Edison,
update of Visual Studio
coming in yesterday."
He's like, "Did you update?"
I was like, "Yeah."
He's like, "I didn't dare to."
But I was like, "Well,
living on the edge, let's do
it, Visual Studio Preview."
So let's call this app Houston.
Yep, I'm fine with that.
See that's what you get
when you run a preview.
It has a lot of the new solution.
Here we go. Just takes
a little longer.
So what you got to do if you
want to start using MVVM cross,
you got at the NuGet
package for it first.
So I'm going to search
here MVVM cross.
Just a couple of a little
of templates available.
Let's see, doesn't open up on top.
So I'm just going to
start with typing forms.
Here we go, 6:3:1 latest available.
Now, this is important.
So if you get started,
there's a couple of steps
you got to take to get
started and to get
the proper files installed.
So MVVM cross actually works.
So I'm just going to go ahead and do
the same thing with Android and iOS,
Dominant Androids.
Here, we go iOS successfully edits.
So what I want to do is
I want to start creating
a cross-platform project first
and here we can see the core
project with just a shared code,
we need to add an AP class to
the root folder which
is in the sample files.
So let's go to GitHub
and we can do two things.
So that's the content files
here is readable
from there for you guys,
can put bigger.
There is also the projects here.
So I would also recommend
looking through
the Playground Project
if you stuck somewhere
because this contains
a lot of samples.
It contains all the things
I just showed,
so you can actually just
look at how the code is
setup there to get you going.
So as you can see here
in the ContentFiles,
there's the App class and it will
contain the basic structure for you.
I see that I'm running
a little bit out of time.
So what I'm just going to do,
I'm going to open up
a recent one that I didn't
mention and run it
from there to save you the time
of copying those files, sparring.
So here we go. I'll show you here.
So what I did here already is change
the app delegate to
MVX app delegate and on core,
I added the Forms application
and the App class to get
MvvmCross initialized.
So if we just run this right now,
there'll be a RootViewModel
here and it says,
"Hello Munchan" and this is
being bind to view right now.
So here, we see that the text is
actually popping up in the view.
So this is being done
using the binding.
Let's have a quick look at that.
So we go to the main page.
Actually, it's the RootView and
here we have the binding
to the title.
The title is here in
the class and the binding is
being set up by MvvmCross,
so very powerful and
very easy to set up.
MvvmCross has a plug-in structure.
So sometimes you want to extend
to native platforms of
certain functionality,
that's not available
and MvvmCross has to
a lot of plugins that
make that possible.
There's a bit of overlap
at the moment with
Xamarin Essentials and I would say,
since that's part of my Microsoft
user essential where you can.
But there's a couple of
things that's very useful
in the plug-ins that we have and
one of them is the Messenger.
The Messenger is something
that enables you to send
different objects and messages from
a view model to another one
which files you think
you need to navigate?
Sometimes you have maybe five view
models are open but you cannot
navigate to a new one because
you want the two that
are already there to
communicate with each other.
You use the messenger with that to
subscribe to a
LocationMessage in this case.
It will trigger the own
LocationMessage and you update
your properties and the UI
will be updated. Easy as that.
Forms also has a message center.
This one though was a bit
different and it's we subscribed.
So that makes it possible to
have bad memory management
if you do it well.
So for everybody here
that knows MvvmCross,
just want to give you
a little update on what's new.
In 6.3 latest version,
we added UIPageViewController
navigation with the attributes.
So sometimes you have
these spaces where you swipe
through and you go to the next one.
On Android, it's called a ViewPager.
With this attribute, you can
just put it on top of any page,
it will put itself into
a PageViewController and
you'll be able to swipe
through back and forth
and it will handle
all the navigation within that
for you and the events as well.
Other things are
small improvements performs
memory management and constructor
overloading for dependency injection.
So what it actually
basically is about now is
that we focused on stability.
We want to just not break any codes,
we want to make sure that you can
keep using the code
that you already have,
updated it to the next version,
and just get the new goodies in
without the needs to
do a lot of changes.
So this was something
that in the past
from going from four to five,
we did a lot of namespace
breaking changes.
So a bit of a trouble to
get that updated and we're
trying to avoid that now.
So there's some questions that you
might have that I just want to
answer already and we're
going to do questions
later but I want to get started.
How do I start a new project?
So I just showed you how
you can do it manually.
There's also Visual Studio
plugins that you can
use to have a wizard
where you can press which
projects you want to have
and what you want to include
in that and the press
"Next" to finish and it will
generate MvvmCross and
the project for you.
So let's spend it very
convenient and it's called
MVX scaffolding and just
install it to Visual Studio,
Visual Studio for Mac and it will
update and install the whole project.
Another one does MvvmCross
make your app slow.
Something I've heard quite some times
because people look
at the repository.
MvvmCross has bit more lines of
code than say prism Mvvm light.
The problem is, it doesn't
make your app slow,
it doesn't make it any bigger
because Xamarin has
the tools to prevent that.
For example, blinker.
If you know the link,
it will strip out any code
that you don't use in
your app and it won't
blow your app size then.
So MvvmCross doesn't make it slower,
doesn't make it bigger.
That's just the same as
any other Mvvm framework.
Of course, you can use
it with Xamarin Forms.
It has special help us
and everything for it.
So go ahead, give it
a try, and you'll see.
Another one is MvvmCross
better than Mvvm whatever?
Of course, it is. Of
course, just say, yes.
Now, seriously, it depends on
what project you're doing,
depends on your requirements,
depends on how you
want to have you UI,
how you want to have your UX,
what things you want to do.
Do you want to do a lot
of native functionality,
do you want to do
a very standard data-driven app.
Just look at the requirements
will get framework fits best.
That's the best advice that
probably you could good give,
just look at what you're doing.
So how do you contribute?
There's a couple of ways.
But while I definitely would like
to say is that when you
want to contribute, do it.
But start off small,
because if you go on GitHub
and you look at the issues,
maybe go on GitHub look at
the camera it forms for posterity.
You get a bit scared by
the pull request that are there,
5,000 lines of code,
big descriptions, big issues.
Well, I'm not sure if you really
can pick that up right away.
So just start small,
start putting one issue
and give a description.
That's it, easy is that.
If you want to help more you make
a pull request but don't do this
huge pull requests with lots
of things just right
from the beginning.
Because that's going to be
very hard to integrate.
So they can't probably for all
opensource projects, I would say.
What does the roadmap look like?
Well, we're planning to add support
for.NET standard 2.1
coming up later this year.
We'll bring in
some new exciting features,
bring better memory management
with new APIs there that are coming,
we'll integrate the new JSON APIs
that are coming up very
interesting as well.
But as I said earlier,
we focused on stability now.
We try and not to break
any things but instead we
expanded to nice features
that actually help you
build better apps.
Can use it with Reactive programming?
I don't know if you went
to someone thought that talk
to right Reactive.
But of course you can,
Reactive and Mvvm go
very well together.
So this needs to be that
you pick one or the other,
you can mix, combine,
and do whatever you like.
So it's number one Mvvm
framework, show more.
No question there. Easy to
learn, extend and customize.
Very customizable and you
get the most code reuse
of all your projects.
I think that's just
fantastic that you can
use some of that code
from a shared library,
makes it very easy and fast
to deliver your projects.
If you want to know more,
go to MvvmCross.com, go to GitHub.
That's a Slack channel
on the Xamarin chat.
If you need help after this,
I'm on that as well.
So you can always struck me message.
No guarantees that I
answer but you can
try and there is Stack Overflow.
So are you doing it right?
You know the answer to that.
I know the answer, it depends
because everything is right.
Just make sure that
you always keep on
improving and that
you're doing it right.
So now, there's only one thing left,
jump in, get to GitHub,
and start using it.
Thanks for listening and
hope to talk to you later.
