iOS Mobile application architecture

Model Stores data.
View presents data.
Controller manages moving and manipulating data.

Model should basically be structs for organizing data.

View would be things like layout files in Android or xibs or storyboards in iOS.

Controller is everything else.

That's how I understand it, anyways.

This is for any OO programming, it's not specific to mobile.

ArtOfWarfare said:

Model Stores data.
View presents data.
Controller manages moving and manipulating data.

Model should basically be structs for organizing data.

View would be things like layout files in Android or xibs or storyboards in iOS.

Controller is everything else.

That's how I understand it, anyways.

This is for any OO programming, it's not specific to mobile.

Click to expand...

That is the on going , lingering question I have with the MCV design as well. The view presents the data, great, got that. The controller handles the transfer from the model to the view, and the model does the processing or so it should.

The best response I got to this in the past was that the View and View Controller should be independent from the model. This way you can attach any model to the ViewController so the data entered and displayed in the view passes right through to the model.

I have always looked at MVC design as M-VC. The ViewController and the View have to go together to pass data in and out of. My "M" Models have been what ever custom Classes I need. I create different classes to handle different things. One class for reading and writing to memory like plists and ceching if things exist. Then another Class to process images and return the result back to the screen.

So in fact my my MVC design has been looking more like MMM-VC for example. My Models are the different Classes that handle the workload. Or at least this is how I have come to understand it.

It takes designing and refining a lot of programs to see it, but I think the division is pretty distinct.

Your view is your interface file. Your storyboard and your xib are your view on iOS and OS X. Your layout is your view on Android.

Your model is a bunch of dummy classes that store data. They have getters and setter methods traditionally, but with Obj-C 2.0, these were hidden away behind properties.

Your controller is all of the logic that makes your app work.

Models are interchangeable between programs. CGRect and CGPoint are examples of models. They do nothing but store a few primitives. You use them in a whole variety of programs. An entry in an address list is a model. You can use it in a whole variety of programs, from something social related to something that stores business contacts.

Views are interchangeable between programs. UIButtons and UITableViews are examples of views. They can display any data that you please.

Controllers are generally not interchangeable between programs. They take the data stored in the model and make sense of it and pass it to the view to display it.

I think the reason people don't see the division is because they haven't made classes of all three types yet. I think when this started to click for me was when I needed to make a bunch of special views for an Android application. IE, I needed a "Sort Buttons", which allowed the users to tap on any column header to sort it up or down or not at all. I also needed to make models that stored ~400 different variables and to be able to send them between different devices.

I guess something that maybe makes it easier to understand is this: DRY - DONT REPEAT YOURSELF. If you ever need code twice, move it to a separate function, or class, even. In moving my code around like that, I accidentally came to understand MVC.

uba2012 said:

Hey people. I have a question regarding the architecture of mobile apps like fore iPhone and android.
I have written an application in objective c for iPhone but I need to know how the 3 layers/tiers are:

Tell me if i am doing this right:

The presentation layer/ front end : the GUI made in interface builder. And / or for android.

Business logic : I don't know what that is in my application

Back end / database server layer:
I have a back end in parse but my code is in Xcode not on any server.

So is this a good explanation for an essay ?

Click to expand...

What design pattern are you talking about? The other posters are assuming that you are talking about model-view-controller (MVC) but it sounds more like you're talking about a client/server design pattern.

AOW it was funny that you said "DRY - DONT REPEAT YOURSELF." because that is how I first started writing my own Classes and got away from writing all my code in the ViewController. I found myself pasting identical code around to do the same thing. That's when I began to think about creating my own classes. I think that is a good rule of thumb, DRY

Sorry to disturb the original intent of this post if it was not MCV.

uba2012 said:

And should i put my "business logic " hate that word on the server or on the client side ?

Click to expand...

There are always exceptions, but in general, if its a client-server app then it's better to put your "business logic" on the server.

Think about this: is it the sort of app that will have different clients? You might have Android and iOS clients, maybe also a web client? Is the "business logic" you're writing applicable to all of those clients?

If the answer is yes, then you don't want to rewrite your "business logic" every time. Putting it on the server means you only have to write it once, and your clients are simpler.

----------

uba2012 said:

I am thinking more about the three tier architecture. Is it the same as MVC?

View= presentation tier
Controller=middleware/business logic
Model = data tier / back end

Click to expand...

Well, a "View Controller" in iOS development is not really "middleware/business logic" - it's really still part of your presentation tier.

From the perspective of writing iOS client code, your "middleware/business logic" all comes under model.

uba2012 said:

Ok. Thanks. But in which language should I write the business logic in then? It needs to me something that different clients can use like android, iOS and maybe also web.

Click to expand...

It doesn't matter what language you write your server code in. You can use whatever you're comfortable with, or what makes the most sense for the particular task at hand. I'm a Java guy myself, but things like Python, C#, Ruby, and PHP are also very popular.

The server will typically return data to the client in either JSON or XML format - it's really how you define your data model/schema in the client-server interaction that's important, rather than what languages you're using.