Where to store global constants in an iOS application?

Question

Most of the models in my iOS app query a web server. I would like to have a configuration file storing the base URL of the server. It will look something like this:

Answer 1

An approach I've used before is to create a file Settings.plist and load it into NSUserDefaults upon launch using registerDefaults:. You can then access its contents with the following:

// Assuming you've defined some constant kMySettingKey.
[[NSUserDefaults standardUserDefaults] objectForKey:kMySettingKey];

While I haven't done any Android development, it sounds as though this is analogous to the strings resource file you described. The only downside is that you can't use the preprocessor to swap between settings (e.g. in DEBUG mode). I suppose you could load in a different file, though.

NSUserDefaults documentation.

Answer 2

You can also concatenate string constants like this:

  #define kBaseURL @"http://myServer.com"
  #define kFullURL kBaseURL @"/api/request"

Answer 3

The accepted answer has 2 weaknesses. First, as others pointed is usage of #define which is harder to debug, use instead extern NSString* const kBaseUrl structure. Second, it defines a single file for constants. IMO, this is wrong because most of classes don't need access to those constants or to access all of them plus file can become bloated if all constants are declared there. A better solution would be to modularize constants at 3 different layers:

1. System layer: SystemConstants.h or AppConstants.h which describes constants at global scope, which can be accessed by any class in the system. Declare here only those constants that must be accessed from different classes that are not related.

2. Module/Sub-system layer: ModuleNameConstants.h, describes a set of constants which are typical for a set of related classes, inside of a module/sub-system.

3. Class layer: Constants resides in the class and are used only by it.

Only 1,2 are related to the question.

Answer 4

Well, you want the declaration local to the interfaces it relates to -- the app-wide constants file is not a good thing.

As well, it's preferable to simply declare an extern NSString* const symbol, rather than use a #define:

---

SomeFile.h

extern NSString* const MONAppsBaseUrl;

SomeFile.m

#import "SomeFile.h"

#ifdef DEBUG
NSString* const MONAppsBaseUrl = @"http://192.168.0.123/";
#else
NSString* const MONAppsBaseUrl = @"http://website.com/";
#endif

---

Apart from the omission of the C++ compatible Extern declaration, this is what you will generally see used in Apple's Obj-C frameworks.

If the constant needs to be visible to just one file or function, then static NSString* const baseUrl in your *.m is good.

Answer 5

Global declarations are interesting but, for me, what changed deeply my way to code was to have global instances of classes. It took me a couple of day's to really understand how to work with it so I quickly summarized it here

I use global instances of classes (1 or 2 per project, if needed), to regroup core data access, or some trades logics.

For instance if you want to have a central object handling all restaurant tables you create you object at startup and that is it. This object can handle database accesses OR handle it in memory if you don't need to save it. It's centralized, you show only useful interfaces ... !

It's a great help, object oriented and a good way to get all you stuff at the same place

A few lines of code :

@interface RestaurantManager : NSObject
    +(id) sharedInstance;
    -(void)registerForTable:(NSNumber *)tableId;
@end 

and object implementation :

@implementation RestaurantManager

+ (id) sharedInstance {
    static dispatch_once_t onceQueue;

    dispatch_once(&onceQueue, ^{
        sharedInstance = [[self alloc] init];
        NSLog(@"*** Shared instance initialisation ***");
    });
    return sharedInstance;
}

-(void)registerForTable:(NSNumber *)tableId {
}
@end

for using it it's really simple :

[[RestaurantManager sharedInstance] registerForTable:[NsNumber numberWithInt:10]]