Making Class vs Creating Methods

[larswik]

As my projects are growing I am trying to develop better habits which I mentioned before. I use this code a lot to get a path to a plist located locally.

- (NSString *) getDataFilePath
{
    NSArray *path = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [path objectAtIndex:0];
    
    return [documentsDirectory stringByAppendingPathComponent:@"selectedClientInfo.plist"];
}

A number of viewControllers would access this code. To save space, duplicating code and also keep it out of the viewController, MVC, I created a Class and called it "Strorage". With MVC does it really matter if each VC has it's own Model? I am guessing no as long as it is separate from the VC?

Can I just create a Storage Class. Then write Methods in the Storage Class that would only do task that needs to access the in internal storage by writing or reading? Then I instantiate the object from within the different VC that need those Methods.

Is this kind of how other people are doing it too?

[ArtOfWarfare]

I may be incorrect here, but I believe that MVC doesn't specify that you need a one to one correlation between any of the parts.

So having a single model be accessed by multiple controllers should be fine.

Personally, I decided a while ago to just toss MVC out. I try to just do what makes the most sense and makes the classes as reusable as possible.

[PhoneyDeveloper]

Lars, you ask several questions.

It's OK if more than one VC shares a data model object. This is fairly common. Often this is modeled by the Singleton pattern.

The utility method that you show is the kind of thing I put in a utility file. It could be a member of a Utility class but there's no need for that. Just create a Utility.m/.h file. Add the code as a function with C-linkage like this:

// Utility.h
NSString * DataFilePath(void);

and you can now access this function from any class. You'll probably think of a few more utility functions to put in there.

NSString * DocumentsFolderPath(void);

[larswik]

Ya, you guys got the point. I released my first app but yet somethings are a struggle for me to understand. I could write an app all in 1 Class and just use [self someMethod]; to add functionality. So I am just trying to get a feel how other users decided to break something off into a Class verses writing a Method in a Class that already exists.

So, a question to the Utility Class PhoneyDeveloper. When you instantiate this object within another object to use. Would you instantiate it in the Method that it is being used in, so it is destroyed when the method ends? Or instantiate this object 1 time in the viewDidLoad for example and keep it around to use?

My gut feeling is to using it in the Methods and let it get destroyed to save memory. But then if it is used a lot it might be worth keeping around. I don't if it is a big deal, clock cycles, battery power and such to instantiate an object many times or if it's better to do it one time and use it?

Thanks!

[PhoneyDeveloper]

Re-read my suggestion. It's a function, not a class.

If you really want it to be a class then it would be a singleton. Something like UIDevice. There's no point in having more than one and no point it creating and destroying it.

[larswik]

I have read about Singletons but have not used them yet. I am not quite following you with the creating and destroying. That Method lives in my Storage Class with many other methods that read, write, parse data, alphabetize the data and so on.

I guess I should start to learn singletons to better grasp what you are saying. I am not getting how I don't need to create it to use it and then have it destroyed. I have not used Functions in Object-C. I assumed people were referring to methods since they act much like Functions by takign arguments and returning on 1 thing.

More to learn!

[PhoneyDeveloper]

This is the complete contents of these two files:

// Utility.h
NSString * DataFilePath(void);

// Utility.m
NSString * DataFilePath(void)
{
    NSArray *path = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [path objectAtIndex:0];
    
    return [documentsDirectory stringByAppendingPathComponent:@"selectedClientInfo.plist"];
}

Use it like this:

#import "Utility.h"

// Some method in a class
{
     NSString * docs = DataFilePath();
     NSString * myFilePath = [DataFilePath() stringByAppendingPathComponent:@"MyFile.jpeg"];

// do something with the paths here...
}

[larswik]

Huh... I have never seen that before? I have never seen an ivar declared like that that takes an argument? But (void) implies that there is no argument or it takes none? Or is that how you write a Function in Objective C?

So you import the Utility.h Class and you can use it without instantiating it? That seems so strange to me? I can see what is happening with the code you provided, and thanks very much for sharing it.

Is this a Singleton?

[PhoneyDeveloper]

It's not a Singleton. A Singleton is a class.

That's not an ivar declaration. It's a function declaration. There are a few functions like this in Apple's headers. Look up UIImagePNGRepresentation() for instance. It's just a function. Like NSLog() or sqrt(). C doesn't have named parameters like Objective-C.

The (void) parameter is a C peculiarity. Probably it's not strictly required and could just be ().

Code like the functions in math.h are written in C, most likely. The example I showed is written in Objective-C but has C-linkage since it's not part of a class.

[chown33]

Originally Posted by larswik

Huh... I have never seen that before?

Yes you have. You posted one:

    NSArray *path = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);

The red-hilited thing is a call to a C function. The name of the function is NSSearchPathForDirectoriesInDomains. You're passing it 3 parameters; they're the 3 comma-separated things between the parens, after the function name.

It's a C function. It's not an object. It's not an ivar (plain C doesn't even have ivars). It's not a Singleton.

You should reread your C book on what a function is, and how to make one.

[larswik]

I know what a C function is and a function in Pascal from that computer class.

int inputNumber(int x){
do stuff
return int value.
}

NSSearchPathForDirectoriesInDomains is a good example to clear up a couple of things.

NSArray *path creates a pointer variable to an NSArray. Now the NSSearchPathForDirectoriesInDomains Function takes 3 arguments which the Function uses to process the data. A Function can only return 1 item so I am lost why that is assigned to an NSArray pointer vs. an NSString? Now that I think about it is returning an Array item as the one item which is storing different paths?

Humm. This is a disadvantage to my learning. I have used this code snip-it many times which I found on the web when I was looking for an answer. I copy pasted it without fully getting it but I can see what is happening now.

Thanks... I am going to let this sink in.