If (you wanna read the whole stuff) start from here;

else goto Serious_talks;

Okay people, I’m not the guy to tell something in the most expected or formal way possible, neither I will try to. I believe in clarity in the most homey, informal way possible. And as the picture right in the header indicates this is a personal adventure on Windows Phone, I’m gonna keep it informal and simple of course.

Let’s get to the basics. How you define anything beautiful? The obvious answer would be by looking towards it. Truth, isn’t it? The problem lies here doesn’t concern the word “beauty” here. The only thing it concerns is the preposition following the word “looking”. So you see, on a generic concept how you define something beautiful? Only by its outlook or the beauty inside? Let’s move more into a humane concept. How can you tell that someone is beautiful? Does it only encapsulates his/her beauty on the outside or the inside matters too.

If you are someone who has a working brain, you’d seriously answer me with the answer that ‘”inside matters too”. So, if you think you and I are in a common ground that we can only declare someone beautiful if he/she is beautiful in inside. The beauty on the outside is not mandatory rather is a plus. Now come to the point of apps. If we treat an app like a human then you’ll get the same picture actually, not exactly the same but yes, kind of same. The beauty lies inside. The beauty on the outside do promotes the app to a certain level and gets it the “swag” and love it needs from the users but you just can’t ignore the inside. Let’s just face it, if you give an app a wonderful inside, you’re kind of made a big progress on giving it a stunning look. You can change, modify, upgrade or practically do anything make it look more and more “hot” and appealing as it needs to be. Or else your app will get a user group of dedicated bunch of geeks who understands the value of your awesome codebehind and the app will struggle to get into the brains of regular people. Still, your app is not a failure.

Serious_talks:

Well, philosophy isn’t the thing developers usually look for, they need precise, concise treatment of what they need to know. Well, here it goes, if you write a clean, sanitized codebehind you’re one step ahead on making a great UI on it. If you have used any code separation approach, you’re a delight for the guy who’s building your UI for you. You might ask why? Why on earth Im gonna go through this hell to make my app’s code sanitized? I’m good as long as I can understand my code. My point here is “think!”. I made the same mistake you’re about to make. When you’re thinking of an UI in your dreams, what do you think of first? The UI only or how the app will work with the UI? How the app will talk using the UI? So you see with our build as it goes approach we’re only making things worse.  Cause we can’t see how our app will look unless we provided it with a fair amount of data and logic behind to get it going. So, what’s the solution? How are we gonna build our UI and our code behind at the same time?

The answer lies in , yes I know you guys know the name, it’s MVVM. Well MVVM is kind of a brotherlike guy of MVC. I’m not gonna bore you more with it. Just go through the internet to find about history of MVVM if you are excited enough. Those who are absolutely new to these (like me :P) kindly don’t get scared out here and leave. The magic lies just a bit later.

Let’s take a dive, shall we?

MVVM stands for Model-View-ViewModel. Now the questions come into play. Who on earth should I call the model or the view? Or even who is Mr. Viewmodel?

Like all other tutorials I should get you guys a smartart with a block diagram showing basic architecture of MVVM.  Nope, not gonna do that now actually. Think of a car first. If we divide the car into three basic parts like below:

• The body
• The driver / steering wheel
• the engine

You’d gladly find the body determines whether the car looks appealing to people or not. The engine makes the car run, makes it actually work and the driver is the link between these. In the end of the day a car is as good as it’s driver is.

Here comes the traditional block diagram, yes it’s taken from the blog of geekchamp and msdn.

If you understand the three lines I wrote above, believe me when I say this,  “You understand MVVM”. You might think what on earth I’m talking about? I didn’t the say the first thing about MVVM and I’m claiming you guys understand it. Weird as it sounds, you guys actually do. The body of the car i.e. the view of your app defines how it looks from the outside. The engine, i.e. the data your app needs to run a.k.a. the model makes your app worthy to use and last but not the least the driver i.e. the viewmodel who connects view with model (no wonder there). Here the viewmodel is the guy who actually makes things work. Cause if he doesn’t provide data to the view the view is worthless, if he doesn’t provide the logics needed for the app to actually run, even with the data the app is not user friendly.

In my times with windows phone, I found people talking about the learning curve of MVVM. Sometimes it do seems a bit steep. But you see, as Im gonna write frequently you’ll find a total detail as this series goes more and more into MVVM. Although in the end of the day you’ll find a very basic app, I think I would be able to successfully transfer a bit of ABCD on MVVM in your brain without making you feel I’m talking about a lot in a day.

So, until next time, ciao! Next we’ll talk about how the view talks with Viewmodel and how the viewmodel gets model for the data it needs. 🙂