Sharing strings and variables throughout ios app
Asked Answered
T

5

3

I'm making an app for a final project for class and I need to share strings, integers and floats throughout different views in my application. I have to create an app that a waiter/waitress would use on the job. I need different views for different types of items to order (beverages, appetizers, entrées, etc.) and need to keep the items chosen, the price and the quantity of each accessible to different views to keep a running total available in each view (one view for each type of item) and finally for a view that displays an itemized list of what was ordered plus the total.

From what I understand I wouldn't want to use a tab bar application layout because typically users don't expect information to be the same between different tabbed views, so I was thinking of using a segmented controller for this. To get the strings, integers and floats shared between views could declare them in the AppDelegate? I've read that I could use singletons but we haven't covered that in my class so I think that may just add more complexity than I need. If I were to declare them in the AppDelegate would I have to synthesize them in the AppDelegateViewController.m to make them available throughout? I can't imagine I'd have to synthesize them for each different ViewController. Or would NSUserDefaults be perfect for this situation?

If I declared an instance variable in the AppDelegate would that essentially make it a global variable? I know that this is against encapsulation practices but that won't make a big difference with this app, it's not going to be in the App Store and the overhead shouldn't make a big difference considering this is going to be a relatively small app.

Thanks in advance everyone. Good luck with your finals if you still have them approaching!


Edit


I guess I should say that this is going to be a janky, terrible app off the bat, we didn't cover a lot of the more advanced topics such as the MVC paradigm for iOS so I'm pretty limited with what I can do compared to what we're supposed to do. Stupid class, I regret signing up for it when I really could have gone about this myself and gotten a better understanding of Objective-C, which we were taught nothing about, and a better understanding of the iOS framework.

Basically, if I declare the variables in the AppDelegate, even though it's a faux pas, would that work to access the strings and such from the different views? Or would the NSUserDefaults be a better solution in this case? I'm leaning towards NSUserDefaults and declaring them in the projects ViewController.

Tarantula answered 12/12, 2011 at 16:54 Comment(0)
S
2

As hotpaw2 said, using a distinct model class is the best way to go.

But, as this is a small app (while you are learning the basics) implementing these few variables in the app delegate wouldn't hurt and is perhaps a little easier.

If the app grows then you'll probably want to move the model out of the app delegate and into it's own class.

An even easier and simpler method would be to store this small amount of data in nsuserdefaults:

save to nsuserdefaults:

[[NSUserDefaults standardUserDefaults] setObject:howManyDrinks forKey:@"howManyDrinks"];
[[NSUserDefaults standardUserDefaults] synchronize];

retrieve from nsuserdefaults:

NSString *howManyDrinks = [[NSUserDefaults standardUserDefaults] objectForKey:@"howManyDrinks"];
Shoeblack answered 12/12, 2011 at 17:16 Comment(1)
Okay, I was leaning towards using NSUserDefaults because that's what we've touched on. Thanks so much @Seigniorage and ade. Much appreciated.Tarantula
S
4

A typical Objective C MVC solution is to put all your related shared strings and variables into a Model object (create a new class for this object) as properties. Then share that Model object with all the Controllers that need to access those variables or strings.

Using the AppDelegate as a model object is "over-sharing", and clutters up the app delegate with non-delegate related stuff. A slightly cleaner solution is to have the app delegate hold a getter to a Model object that is widely used throughout the app. A solution that can cause code reuse problems, and is otherwise considered politically-incorrect, is to assign the model object, and/or the shared variables themselves, to C global variables (be careful with your retains). (But this usually generates the fastest and smallest amount of code, if you care about such things.)

Seigniorage answered 12/12, 2011 at 17:6 Comment(2)
Unfortunately we didn't cover using the MVC paradigm within iOS, which really sucks because I'm feeling ripped off by this class, so I don't know how to make a Model for apps. We didn't get into the more advanced stuff and the 'text book' that we're using is "Sam's Teach Yourself iPhone Development in 24 Hours", so we had the briefest introduction to Objective-C and what we've been taught is very contextual to what the author is doing in the book. He really only explains what to do in a specific situation rather than the Why and How, plus he doesn't touch on errors or how to handle them.Tarantula
hotpaw2's suggestion of making the quick and dirty approach of using the AppDelegate a bit cleaner by encapsulating all of these values into their own class (Model) is good. ade in the other answer seems to be assuming that we're talking about a smaller number of values, but based on your original post, it sounds like a lot of values.Bywoods
S
2

As hotpaw2 said, using a distinct model class is the best way to go.

But, as this is a small app (while you are learning the basics) implementing these few variables in the app delegate wouldn't hurt and is perhaps a little easier.

If the app grows then you'll probably want to move the model out of the app delegate and into it's own class.

An even easier and simpler method would be to store this small amount of data in nsuserdefaults:

save to nsuserdefaults:

[[NSUserDefaults standardUserDefaults] setObject:howManyDrinks forKey:@"howManyDrinks"];
[[NSUserDefaults standardUserDefaults] synchronize];

retrieve from nsuserdefaults:

NSString *howManyDrinks = [[NSUserDefaults standardUserDefaults] objectForKey:@"howManyDrinks"];
Shoeblack answered 12/12, 2011 at 17:16 Comment(1)
Okay, I was leaning towards using NSUserDefaults because that's what we've touched on. Thanks so much @Seigniorage and ade. Much appreciated.Tarantula
S
0

You can utilize the facility of Delegation pattern using Protocols in Objective C.

Sulfapyrazine answered 12/12, 2011 at 17:35 Comment(0)
D
0

You could also store these values in a plist, which can then be accessed and edited from anywhere within the app. It is easier to implement than a singleton. And since you can set the plist up visually in XCode, it's relatively easy for beginners. I even created a wrapper for my plist to make editing the data simple. Here's a tutorial for plists.

Duston answered 12/12, 2011 at 20:0 Comment(1)
I've been looking at that also, I haven't gotten to the logic quite yet, I've been setting up the views. Thank you for your suggestion :)Tarantula
B
0

I'm not an expert in this yet, but I've been using a singleton, with an object inside. As far as I have experienced, the values inside that object is held. To create a singleton, you'd do something like this:

Create a normal Object, and add this to the header file:

+ (id)sharedManager;

Then in the .m file, add this:

+ (id)sharedManager {
    static SharedInfo *sharedMyManager = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sharedMyManager = [[self alloc] init];
    });
    return sharedMyManager;
}
- (id)init {
    if (self = [super init]) {
        self.myStuff = [[NSMutableDictionary alloc]init];
  //This is where you initialise your variables. The example above is for a 
 //property that I have declared in the .h file
    }
    return self;
}

And then, throughout your app you'd use this:

[[[SharedInfo sharedManager] myStuff] addObject: SomethingTocreate];

Make sure you include the SharedInfo.h in the viewcontroller that you want to use it in.

I hope this helped.

Bonheur answered 29/12, 2015 at 16:35 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.