Part one of a series, probably of seven, on using structured design in Corona.
Uses a very simple pong game to illustrate some ideas (tweaked a little) about the MVP pattern and how it might be useful in structuring Corona SDK projects.
http://coronadev.blogspot.co.uk/2014/04/corona-and-model-view-presenter-pattern.html
Great idea!. I’ll have to read it when I’m not mobile. But I have a question… On quick glance, this looks the same as MVC (Model-View-Controller). Is there any fundamental difference between the two?
Rob
In MVP there are two main differences - in MVP the model and view do not communicate with each other directly, the presenter gets the information from the model and passes it on to the view. In MVC the view can ask the model directly. (Though in practice I just pass the model reference to the view !)
In MVP the presenter is more like the game code - so the model’s code might change the model, but only in the context of the model, it’s got no real idea of the game as a whole entity.
There’s piles of variations - completely dumb data-only models, intelligent views and so on, they are all variations on a theme :)
There are lots of good tutorials, both Corona’s and 3rd party about, but not many ideas about architecture.
I’m not actually sure this is the best architecture, because Corona views and models are so tied together. Might look at binding ideas or something later on.
Interesting because I thought the whole idea for MVC was to prevent the Model and the View from talking with each other.
Rob
It varies. Sometimes it can access the model but not update it, sometimes it can receive messages from it giving it update information. Sometimes it’s a free-for-all 
In MVP the Presenter is definitely in charge.
There isn’t a definitive answer - I think the GoF wrote about the MVC pattern but didn’t formally define it like they did for a Facade say. In some ways it doesn’t really matter in Corona as there is no clear separation between the data and the representation as there would be in a web application, it’s more important that a developer decides on a structure and sticks with it.
(Incidentally, is this the right place to post tutorials ? I wasn’t entirely sure, there doesn’t seem to be a tutorials forums per se)
Hi,
I’m far from an expert. On looking at this and trying to comprehend it - is this is something that complements Composer/storyboad or is instead of - I’m leaning towards the view - instead of , am i right?
T.
Hi.
Could be both Composer or Storyboard would be part of the view, controlled by the presenter.
The core idea is that you separate the representation of the data (e.g. the graphics, text and so on) from the actual data itself. Corona is some-and-some - so programs tend to hold some of the data as part of the display objects (e.g. location, rotation, scale) and some of it elsewhere (say, a characters energy levels).
In a similar way, in Composer the implementation of the graphics and the data representation of the game are all mixed up.
Have added parts 2,3 and 4 to the Tutorial
This tutorial is now complete - seven parts in total, the index is at Corona and the Model-View-Presenter pattern - Index
Great idea!. I’ll have to read it when I’m not mobile. But I have a question… On quick glance, this looks the same as MVC (Model-View-Controller). Is there any fundamental difference between the two?
Rob
In MVP there are two main differences - in MVP the model and view do not communicate with each other directly, the presenter gets the information from the model and passes it on to the view. In MVC the view can ask the model directly. (Though in practice I just pass the model reference to the view !)
In MVP the presenter is more like the game code - so the model’s code might change the model, but only in the context of the model, it’s got no real idea of the game as a whole entity.
There’s piles of variations - completely dumb data-only models, intelligent views and so on, they are all variations on a theme :)
There are lots of good tutorials, both Corona’s and 3rd party about, but not many ideas about architecture.
I’m not actually sure this is the best architecture, because Corona views and models are so tied together. Might look at binding ideas or something later on.
Interesting because I thought the whole idea for MVC was to prevent the Model and the View from talking with each other.
Rob
It varies. Sometimes it can access the model but not update it, sometimes it can receive messages from it giving it update information. Sometimes it’s a free-for-all In MVP the Presenter is definitely in charge.
There isn’t a definitive answer - I think the GoF wrote about the MVC pattern but didn’t formally define it like they did for a Facade say. In some ways it doesn’t really matter in Corona as there is no clear separation between the data and the representation as there would be in a web application, it’s more important that a developer decides on a structure and sticks with it.
(Incidentally, is this the right place to post tutorials ? I wasn’t entirely sure, there doesn’t seem to be a tutorials forums per se)
Hi,
I’m far from an expert. On looking at this and trying to comprehend it - is this is something that complements Composer/storyboad or is instead of - I’m leaning towards the view - instead of , am i right?
T.
Hi.
Could be both Composer or Storyboard would be part of the view, controlled by the presenter.
The core idea is that you separate the representation of the data (e.g. the graphics, text and so on) from the actual data itself. Corona is some-and-some - so programs tend to hold some of the data as part of the display objects (e.g. location, rotation, scale) and some of it elsewhere (say, a characters energy levels).
In a similar way, in Composer the implementation of the graphics and the data representation of the game are all mixed up.
Have added parts 2,3 and 4 to the Tutorial
This tutorial is now complete - seven parts in total, the index is at Corona and the Model-View-Presenter pattern - Index