1

Can an app delegate act the as the glue between all my UIViewControllers for the whole app?

I'm creating a mail client that has a navigation structure very much like sparrow (and fb etc). The first screen would be a login screen.. which would then lead to a UITableViewController that has the famous left menu button, which if clicked reveales other VC's underneath.

To make a long story short, right now it's my app delegate that's running the show.. it's the one that decides if to show the login screen if on first visit, or the default mailbox along with its subviews. If I get information from one subview, it hands off that info to the app delegate, which in turn passes it on to other view controllers.

Is this right from an MVC point of view? I know an app delegate is the first point of contact, it's what kicks off the application, but I haven't seen it used this extensively. I just want to make sure if I'm following iOS MVC best practices here.

Community
  • 1
  • 1
abbood
  • 23,101
  • 16
  • 132
  • 246
  • No, this is NOT a good idea. The app delegate is the place to put code for notifications, library initialization, but nothing else! Use storyboards and other, newer features of objective-c to manage your controller hierarchy. – Richard J. Ross III Mar 12 '13 at 14:02
  • Not a full duplicate, but answered here http://stackoverflow.com/q/9213134/97337 and here http://stackoverflow.com/a/829591/97337 (and the short answer is no, this is not correct MVC) – Rob Napier Mar 12 '13 at 14:08
  • I'm building ontop an old library that was created pre storyboard era.. and it has like 50 xibs.. converting all that to a storyboard will be a new project by itself. Can you be more specific about those other newer features of objective-c? hopefully something that I can still use with a xib based project.. – abbood Mar 12 '13 at 14:10
  • @RobNapier going over the answers.. it seems this matter is less black and white than it appears to be.. I found [this](http://stackoverflow.com/a/9853740/766570) answer particularly interesting, with implementing protocols and `IBOutlets` etc.. do you have strong feelings about that paradigm? – abbood Mar 12 '13 at 14:20
  • It's an interesting approach, and has some similarities to dependency injection (see objection-framework.org for an example of that). I agree nothing is wrong with the provider mechanism, but I wouldn't use your AppDelegate for that object. I sometimes create another object (sometimes called "Model") to provide a one-stop shop for all shared model objects (which allows me to provide mock objects). But again, not the app delegate. It has its own job to do. – Rob Napier Mar 12 '13 at 14:37
  • 1
    One other guideline: if any implementation file gets over 500 lines, you should be strongly asking if it is doing too much. The AppDelegate is the most common in my experience for going over 500 lines, and so receives the most scrutiny. – Rob Napier Mar 12 '13 at 14:41
  • @RobNapier lol i think we're in agreement then (I commented something similar to what you just said to that [answer](http://stackoverflow.com/a/9853740/766570)).. my concern was that if any object can implement that protocol.. then you can potentially get different answers depending on who you ask.. which can be really confusing.. so I like your one stop shop idea (which naturally means it's a singelton). – abbood Mar 12 '13 at 14:42
  • Yes, my current approach (still experimenting with it) is to have just the one singleton (Model) which I use to get all other "singleton-like" things. And I just pass the object rather than using a singleton whenever I can get away with it. I used to use a lot of singletons, but I'm experimenting the other way as I explore TDD concepts (singletons can make things harder to test). – Rob Napier Mar 12 '13 at 14:44
  • @RobNapier oh my.. you got my design pattern curiosity up.. I recall reading about *inversion of control* and *dependency inversion* principles from the excellent DP book [Head First Design Patterns](http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/ref=sr_1_1?ie=UTF8&qid=1363099722&sr=8-1&keywords=head+first+design+patterns) which sounds [similar](http://martinfowler.com/articles/injection.html) to this dependency injection you mentioned. I'm gonna be doing a lot of reading tonight :) – abbood Mar 12 '13 at 14:49

1 Answers1

2

It's not recommended, but it's perfectly legal to do that. I generally use a master view controller class and do most of the heavy lifting in that. Keep in mind that XCode will dump most of the auto generated code in the app delegate if you are using Core Data, so it can get a little difficult to navigate if you are using Core Data. It's really just a personal preference though. If it were me, I would still have the app delegate do the login screen vs. main screen logic, but put most of the app logic in a main screen controller.

JiuJitsuCoder
  • 1,866
  • 14
  • 13
  • for the downvoter: can you please explain why you thought this answer deserved a downvote? – abbood Mar 12 '13 at 14:02
  • 1
    Yes, I can. The reason is that using the app delegate for lots of glue code makes hard to maintain, sloppy code, where you should be using storyboards, or another design pattern altogether. – Richard J. Ross III Mar 12 '13 at 14:02
  • @RichardJ.RossIII I did recommend to the OP to do just that. Read my answer again. I even mentioned that I separate the code myself, but I was merely commenting that if someone insists on doing it that way, it won't break anything, it just isn't the way I (or clearly you) would do it. – JiuJitsuCoder Mar 12 '13 at 14:06
  • @RichardJ.RossIII I clarified the spirit of my answer. Hopefully that'll help. – JiuJitsuCoder Mar 12 '13 at 14:11