MVC design pattern in complex iPad app: is one fat controller acceptable?
Posted
by
nutsmuggler
on Stack Overflow
See other posts from Stack Overflow
or by nutsmuggler
Published on 2011-01-14T11:40:01Z
Indexed on
2011/01/15
19:53 UTC
Read the original article
Hit count: 156
I am building a complex iPad application; think of it as a scrapbook.
For the purpose of this question, let's consider a page with two images over it.
My main view displays my doc data rendered as a single UIImage; this because I need to do some global manipulation over them. This is my DisplayView
.
When editing I need to instantiate an EditorView
with my two images as subviews; this way I can interact with a single image, (rotate it, scale it, move it). When editing is triggered, I hide my DisplayView
and show my EditorView
.
In a iPhone app, I'd associate each main view (that is, a view filling the screen) to a view controller.
The problem is here there is just one view controller; I've considered passing the EditorView
via a modal view controller, but it's not an option (there a complex layout with a mask covering everything and palettes over it; rebuilding it in the EditorView
would create duplicate code).
Presently the EditorView
incorporates some logic (loads data from the model, invokes some subviews for fine editing, saves data back to the model); EditorView
subviews also incorporate some logic (I manipulate images and pass them back to the main EditorView
). I feel this logic belongs more to a controller. On the other hand, I am not sure making my only view controller so fat a good idea.
What is the best, cocoa-ish implementation of such a class structure?
Feel free to ask for clarifications.
Cheers.
© Stack Overflow or respective owner