Mobile application architecture

Discussion in 'iOS Programming' started by uba2012, Nov 19, 2012.

  1. uba2012 macrumors member

    Joined:
    Jul 5, 2012
    Location:
    Denmark
    #1
    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 ?
     
  2. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #2
    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.
     
  3. larswik macrumors 68000

    Joined:
    Sep 8, 2006
    #3
    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.
     
  4. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #4
    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.
     
  5. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #5
    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.
     
  6. larswik macrumors 68000

    Joined:
    Sep 8, 2006
    #6
    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.
     
  7. uba2012 thread starter macrumors member

    Joined:
    Jul 5, 2012
    Location:
    Denmark
    #7
    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

    And should i put my "business logic " hate that word on the server or on the client side ?
    And is it possible to put business logic code using fx java on a server so I don't have to write the whole application for android ?
     
  8. Reason077 macrumors 68000

    Reason077

    Joined:
    Aug 14, 2007
    #8
    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.

    ----------

    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.
     
  9. uba2012 thread starter macrumors member

    Joined:
    Jul 5, 2012
    Location:
    Denmark
    #9
    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.

    I am writing an application (ios) or a prototype for a class project
    but I still need to explain the technical aspects of the whole system and distributed system.
     
  10. Reason077 macrumors 68000

    Reason077

    Joined:
    Aug 14, 2007
    #10
    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.
     
  11. uba2012 thread starter macrumors member

    Joined:
    Jul 5, 2012
    Location:
    Denmark

Share This Page