Go Back   MacRumors Forums > Apple Systems and Services > Programming > iPhone/iPad Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old May 6, 2012, 02:12 PM   #1
larswik
macrumors 65816
 
Join Date: Sep 2006
Making Class vs Creating Methods

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.

Code:
- (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?
__________________
I know more than yesterday.
Lars
larswik is offline   0 Reply With Quote
Old May 6, 2012, 02:26 PM   #2
ArtOfWarfare
macrumors 603
 
ArtOfWarfare's Avatar
 
Join Date: Nov 2007
Send a message via Skype™ to 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.
__________________
Don't tell me Macs don't last: 2007 iMac, 2007 Mac Mini, 2008 MacBook Air, all Vintage.
(iMac obsoletion: April 28, 2015, MBA: October 14, 2015, Mac Mini: March 9, 2016)
ArtOfWarfare is offline   0 Reply With Quote
Old May 6, 2012, 03:34 PM   #3
PhoneyDeveloper
macrumors 68030
 
PhoneyDeveloper's Avatar
 
Join Date: Sep 2008
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:

Code:
// 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.

Code:
NSString * DocumentsFolderPath(void);
PhoneyDeveloper is offline   0 Reply With Quote
Old May 6, 2012, 10:43 PM   #4
larswik
Thread Starter
macrumors 65816
 
Join Date: Sep 2006
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!
__________________
I know more than yesterday.
Lars
larswik is offline   0 Reply With Quote
Old May 7, 2012, 06:58 AM   #5
PhoneyDeveloper
macrumors 68030
 
PhoneyDeveloper's Avatar
 
Join Date: Sep 2008
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.
PhoneyDeveloper is offline   0 Reply With Quote
Old May 7, 2012, 03:03 PM   #6
larswik
Thread Starter
macrumors 65816
 
Join Date: Sep 2006
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!
__________________
I know more than yesterday.
Lars
larswik is offline   0 Reply With Quote
Old May 7, 2012, 04:58 PM   #7
PhoneyDeveloper
macrumors 68030
 
PhoneyDeveloper's Avatar
 
Join Date: Sep 2008
This is the complete contents of these two files:

Code:
// 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:

Code:
#import "Utility.h"

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

// do something with the paths here...
}
PhoneyDeveloper is offline   0 Reply With Quote
Old May 8, 2012, 04:04 PM   #8
larswik
Thread Starter
macrumors 65816
 
Join Date: Sep 2006
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?
__________________
I know more than yesterday.
Lars
larswik is offline   0 Reply With Quote
Old May 8, 2012, 05:37 PM   #9
PhoneyDeveloper
macrumors 68030
 
PhoneyDeveloper's Avatar
 
Join Date: Sep 2008
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.
PhoneyDeveloper is offline   0 Reply With Quote
Old May 8, 2012, 05:40 PM   #10
chown33
macrumors 603
 
Join Date: Aug 2009
Quote:
Originally Posted by larswik View Post
Huh... I have never seen that before?
Yes you have. You posted one:
Code:
    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.
chown33 is offline   0 Reply With Quote
Old May 9, 2012, 03:20 AM   #11
larswik
Thread Starter
macrumors 65816
 
Join Date: Sep 2006
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.
__________________
I know more than yesterday.
Lars
larswik is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > iPhone/iPad Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
creating methods with Completion Handler hassoon iPhone/iPad Programming 2 Aug 20, 2013 03:10 AM
iOS 7- Making html5 devs second-class citizens? cleo1 iOS 7 5 Jul 26, 2013 04:13 PM
Understanding issues with Class Methods? q64ceo Mac Programming 3 Jul 7, 2013 04:28 PM
Class methods vs instance methods zijianz iPhone/iPad Programming 8 Jul 20, 2012 11:15 AM
Private class methods KarlJay iPhone/iPad Programming 9 Jun 12, 2012 07:29 AM

Forum Jump

All times are GMT -5. The time now is 07:55 AM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC