Understanding Objects, Classes and the MVC

Well I looked at two books one by Robert Clair. I am having difficulties understanding how objects relate to methods and the whole Mvc.

Also looked at Stanford videos. I watched two. One where he makes a calculator. Which I can do by coping him but I find myself not understanding why it works.

Rather frustrating.

I believe if I can get the whole concept of the MVC and how it talks to everything it will be better.

Any advice to make life easier?

Thanks.

 

Oh well I've just started the book it is : Learning Onjective C 2.0. By Robert Clair. Second book is : Learn Objective C on Mac by Mark dalrymple and Scott knaster.

I have gotten to chapter two on both books. I just find when they go into objects and Mvc it seems to go over my head. As they don't show exactly what is a model or view or controller and same goes for when they talk about methods etc

Sorry for the lack of information.

 

Which book is BNR? Also you make some good points. I have decided to stick with Apples own language

 

BNR = Big Nerd Ranch. I can't say anything other than I've heard the name of the book tossed around a lot here.

Quick run through of basics you might be stuck on...
There are classes and there are instances. Classes are like factories with templates. Instances are the things made from the factories or templates. Class names start with capital letters while instance names start with lowercase letters.

Classes and instances have methods. Class methods are prefixed with a + while instance methods are prefixed with a - . Class methods generally return an instance. Instance methods are where the actual work gets done.

Model - The part of your program where data is stored and accessed.
View - The part of your program that the user interacts with. The view presents the user information, and collects the user's actions.
Controller - The part of your program that routes the flow of data between the models and views.

 

I appreciate the help guys.

I will drop the two books I am reading now and get the BNR book - looks easier to follow by going through the sample chapters on their site.

Will try not to just rush through it and see how it goes.

ArtOfWarfare - I appreciate the explanations. I guess it will sync in more once I start actually writing the code and making some simple applications and take i from there.

I will however come back here should I need more assistance.

Thanks all!

 

One other thing to consider when buying books. Most entry level books cover the same thing. Before you buy a bunch of books, I'd give them a close look and see if they cover anything new to you.

After you get more knowledgable about the subject, it'll get harder to find good books to cover things you don't already know.

 

http://www.macresearch.org/cocoa_for_scientists explains objects and methods nicely

Small addition to the mvc:
The View and the controller tend to be located in the same file, the ViewController. The model is separate and is for example a NSObject. The model knows about your data and how to save it to persistence storage.

The VC will ask the model for a value and present this value to the user. When the user has finished modifying the value, the VC will take the changed value and will pass it back to the model. Any number crunching should happen in the model. The VC should think only about presenting the results.
Doing it this way will avoid the roadblock later called "How to pass data between views?". (That's a rather common question here )

 

Now, I'll admit mvc is a weak point of mine, but I believe you're quite wrong on this.

A "ViewController" is only a controller, not a view. It controls the view. It's like the title "Slave Master" - a person with this title isn't a slave, they're the master of slaves.

Your confusion likely stems from the fact that the views being controlled often require no programming - instead, they can often be made by dragging and dropping UI elements provided by apple in a xib file.

Similarly, a model class doesn't always need to be created. Your entire model portion of your app could be handled by CoreData. (Although, personally, I find CoreData so confusing that I tend to just write my own model classes. I understand it theoretically... but... I often feel lost when I'm trying to set them up. Maybe I just need more practice with them or something.)

 

Ah, yes, right, sorry, wrote the View part a bit sloppy.

The ViewController will load the view (from a nib) or will create it from code. The VC will control what will be seen on the screen. So one might have a xib-file and the VC, or if one prefers to create views in code, only the VC.
For certain type of apps views created in code are the optimum. When Interface Builder came out Many programmers hated it and continued with wiring views by hand. The current IB (now integrated into Xcode) is usable and creating xib's is not a difficult thing.

A model can be a single class or a collection os classes, depending on complexity. It can be written from scratch or a collection of Core Data entities. If the data is complex the model will be complex, for simple data a single class can be enough. Just try your best to keep it outside the ViewControllers.

For a new starter (read: the OP ) Core Data might be a bit much to swallow, although is not confusing. The Problem is that many are mistaking Core Data for a relational database where it is actually an object graph manager. Once treated as such it is rather easy to manage. It has a lot of glue code that otherwise would have to be coded manually and more important, supported manually. Any line of code that does not need support is a good line of code.

 

Even in this case, I'm pretty sure that views in code should be kept in a separate class from the VC.

 

Well, see, there are times when a view in a separate file is needed. But IMHO that is very advanced stuff.

The OP has problems understanding instances, methods and accessors. I have been there, too. Swearing about the "+" and "-" in front of the method name, I mean.
So to get started I recommend to keep the view in the ViewController file. When it becomes clear why separating the view from the controller provides an advantage then Classes and Instances will have been mastered a long time ago.
The model engine keep separate from the views and the controllers. It really makes it all easier in the beginning.

Many online tutorials try to explain concepts but hardly ever position them in terms of complexity. There are some books well structured, I like Programming iOS 5 from Matt Neuburg. But that book I found only recently, not four years ago, when I started with iOS programming. I don't know the other books mentioned, so I cannot say if it contains the same info.

 

I worked my way through Programming in Objective-C by Stephen Kochan. It made life much easier for me. Especially when it comes to really understanding the Beginning iPhone Development books from Apress.

 

Hi all,

Sorry I have yet to reply - I actually got stuck into the BNR book and really loving it.

It is a different approach to C and Object -C and more hands on every step of the way, and I haven't even gotten to Object C yet in the book, but learnt so much already.

I also love the fact that the aurthur gives you challenges at each chapter to test your skills.

Thanks ArtOfWarfare for the recommendation bud!

Forum User: I appreciate you taking the time to explain what all the various classes, methods etc mean - I will go through all the posts over the weekend when I have more time to sit and study.

PS: Dejo will be splitting this thread as it has gone off topic - the new thread will be in the same section with everyone's posts related to questions regarding Object-C it self.

 

[Mod Note: This thread was split from a previous one concerning MonoTouch. As such it may start of rather awkward.]

The syntax is not really the issue I am having - it's understanding, methods, objects, getters, setters = all quite confusing, lol.

Anyway, thanks

 

As for books, I liked the BNR. Most sites offer a 'preview' option. Run thru the chapters and see if they cover the basics.