12

I'm sometimes using a Singleton (to store data that is used by several different classes) in my projects and I'm thinking why not use my AppDeletage, since it's already a Singleton and easy to access. Is this a bad practice and if so, why?

Man of One Way
  • 3,904
  • 1
  • 26
  • 41

5 Answers5

12

There is no right answer to this one. You'll get many opinions on this. I see no issue with using the AppDelegate, and I do it for all my apps:

  • The delegate is practically mandatory for iPhone apps,
  • it's there for the lifetime of the app;
  • and one can access it from anywhere in the program (although don't abuse that!).

One must remain vigilant though, so that code that doesn't necessarily have to be there, isn't there. You don't want your AppDelegate to become massive and unmaintainable.

The question has been answered before on StackOverflow:

Application Design and AppDelegate

The answers on that may help you also.

Community
  • 1
  • 1
ageektrapped
  • 14,482
  • 7
  • 57
  • 72
  • How would you directly access the AppDelegate from other classes? For example, access a property in it or something – darksky Jul 15 '11 at 14:54
  • 1
    To get typed access to your delegate, call YourAppDelegate *delegate = (YourAppDelegate *)[UIApplication sharedApplication].delegate; – ageektrapped Jul 15 '11 at 14:58
  • so is it ok to import Appdelegate in various viewcontrollers? If not, Kindly point me somewhere that explains it – nr5 Jul 09 '14 at 11:28
4

AppDelegate should handle app behavior in states of launch, background entry and so on. You should not make it more complex as it's not a good design pattern. But you can always keep a reference to your dataStore class in your AppDelegate, and access it via AppDelegate. This way you abstract data storing from your AppDelegate but you will still be able to easily get to it.

Cyprian
  • 9,423
  • 4
  • 39
  • 73
3

I get a lot of guff for this, but for smallish data that has global relevance, I have no problem at all keeping in the App Delegate.

Bigger pieces of data need a store that's out of memory (Core Data, the filesystem, SQLlite, or what have you).

My very first app had a TON of data sloshing around (text in NSDictionaries, UIImages in various sizes, etc). I built a data management singleton to keep it all in one place and handle server requests for updates. It worked okay. If I knew then what I know now, I probably would have worked out a Core Data synchronization strategy instead.

Dan Ray
  • 21,623
  • 6
  • 63
  • 87
  • It really depends though - I am writing a game app and I need a singleton class to manage the scores, players etc... Singleton in this case works better than Core Data. I am writing another app which actually stores data and downloads content online. In this case, I am using Core Data. – darksky Jul 17 '11 at 10:06
  • 1
    Yeah, that's fine too. I also get guff for not being staunchly Anti-Singleton. I think it's a fine tool that, like many fine tools, has the potential to be misused. – Dan Ray Jul 17 '11 at 14:04
0

Well, in terms of data abstraction it may be a bit on the unsafe side, but i believe it is a handy place in the memory too. What you should do, may be to encapsulate the variables with accessor methods so that you have a place to do the concurrency related operations (if any)

But if what you mean is passing objects from one UI class to another, then probably you should use something else, like setting member variables of one from the other, or use datastore etc.

lithium
  • 995
  • 7
  • 13
0

For little bits of controller code that are relevant to the entire app, I use the AppDelegate. If there's a sensible way to split off the code into a separate controller object then that would be preferable, as I've seen app delegates that have ballooned to unmanageable size.

It can also be a good way to 'singletonize' controller objects, without burning your bridges if you want later to have more than one of them.

I actually put a class method on the AppDelegate to access it, so I can do things like:

[[AppDelegate get].dataStore getRecordNumber:x] // or
[[AppDelegate get].server refreshData]

But I'm sure there are those that think this is bad design in a team setting.

joerick
  • 16,078
  • 4
  • 53
  • 57