I've been watching CP193 classes on itunes and the common message that comes about is reusability.
I'm creating a program that has a list in the form of an NSMutableArray. I will be accessing this class over and over again.
So I created an NSMutableArray class with a function to setup NSStrings in the array
#interface Geology : NSMutableArray
- (void) setuparray;
In the implementation file I have
[super addobjects:#"object1"];
I would like to initialise this object with objects already inside. I imported the header file inside my ViewController with the following code:
Geology *geology = [[Geology alloc] initWithCapacity:5];
[geology setuparray];
NSLog(#"%#", [geology objectAtIndex:1];
However the program does not compile with the following error:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -[NSMutableArray initWithCapacity:]: method only defined for abstract class. Define - Geology initWithCapacity:]!
So from that I need to define the capacity inside my new file. However even though I add [Super initWithCapacity] inside the file it still does not work?
edit:
Geology.h
#interface Geology : NSMutableArray
- (void) setupGeology;
#end
Geology.m
#implementation Geology
- (void) setupGeology{
[super initWithCapacity:1];
[super addObject:#"object1"];
}
#end
In my ViewController I have
#import "Geology.h"
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view.
Geology *geology = [[Geology alloc] initWithCapacity:5];
[geology setupGeology];
NSLog(#"%#", [geology objectAtIndex:1]);
}
First of all you don't have initWithCapacity declared and defined in your .h and .m since NSMutableArray is an abstract class, so you will need to have to define this and secondly I am not sure if this is the correct way to do it... Whenever you need to add extra functionality to an existing class you can always use categories in objective-c. Subclassing is uusally done when you need to add extra properties to a class along with some functionality.
I believe you should look into categories , because subclassing NSMutableArray is a very rare thing and I have never felt the need to do it.
You can refer to this answer for more clarity.
It looks like all you want to do is to create an custom initialiser for a NSMutableArray so that it is better suited to the way you use it in your application.
You don't have to subclass NSMutableArray to do this.
If all you want to do is add functionality to an existing class and not add extra storage, you can just create a category on NSMutableArray that performs your setup for you.
You're subclassing NSArray when it's inappropriate. Subclassing is used for specialising or extending. You're not specialising or extending NSArray here - you're just using it. So just use NSArray, as normal; no need to subclass. So you might have a helper data object that contains an NSArray as a property.
Also, I'd expect a subclass of NSArray to at least have 'Array' in the class name.
Note also that when adding functionality to an existing class in Objective C, class categories are sometimes used rather than subclassing. Categories are particularly useful when you want to add new methods to an existing class without adding any new state (i.e. ivars/properties).
Related
I have a subclass of NSMutableArray which in fact deals with a certain type of data i.e. say Employee. The problem is I don't like the inherented names of addObject insertObject and etc. and want to change them to something like addEmployee insertEmployee.
How should I deal with this?
If you are not going to inherit the methods of the superclass then you should not use that superclass!
When you inherit it is a 'is a' relationship between the sub and super classes. "Employer is a NSMutableArray" - no, that is not true and thus don't make Employer a subclass of NSMutableArray. Additionally, in the future you might use a dictionary to store employees (like mapping 'name' -> 'employee') and then having the representation being inherited as an array simply won't work.
#interface Employer : NSObject {
NSMutableArray *employees;
}
- (void) addEmployee: (Employee *) employee;
#end
Like such. Now addObject: isn't workable on instances of Employee; only addEmployee: works. Additionally, you'll only want to specialize methods like filteredArrayWithPredicate: eventually - so it won't be an advantage to inherit them.
You add a method addEmployee: and in that call addObject:. Similar for insertObject:
You can inherit NSMutableArray and add methods like -addEmployee: then add this in your .h file:
- (void)addObject:(id)anObject __attribute__((unavailable("Use -addEmployee:")));
This is a clang extension which will cause a complier error.
References:
How do I flag a function as being deprecated in an iPhone Objective C header file?
http://clang.llvm.org/docs/LanguageExtensions.html#messages-on-deprecated-and-unavailable-attributes
I'm looking to create a class in Objective-C for an iOS project that is focused on fetching data. I'm familiar with how classes normally work, setter and getter methods and variables. However, for this class since it's only performing a function (returning NSMutableArrays) I don't want to have to create an instance of the class to use the methods inside the class.
Any idea how I can do this neatly and efficiently?
This is a little bit atypical in Objective-C. Since classes in Objective-C can't actually have state beyond what is available to ordinary functions (i.e. there are no class variables), a class that's never instantiated is relatively useless in most cases. The normal design patterns for this kind of functionality are:
A singleton class (if you need lots of state)
A set of functions (if you don't)
You want to make class methods?
#interface Foo : NSObject {}
+(NSMutableArray*)someClassMethod:(id)params;
#end
...
#implementation Foo
+(NSMutableArray*)someClassMethod:(id)params {
// whatever implementation
return nil;
}
#end
...
NSMutableArray* array = [Foo someClassMethod:nil];
If you're only performing functions, and you don't need to support subclassing etc, why not just write them as C functions rather than a class with methods?
If this is just a class that performs some functions, you could write it as a C function.
In your header file --
NSMutableArray *functionThatReturnsMutableArray(NSObject *param1, NSString *param2);
In your implementation file --
NSMutableArray *functionThatReturnsMutableArray(NSObject *param1, NSString *param2)
{
...
return aMutableArray;
}
And that just include the .h file in your class that needs these functions and call them directly.
NSMutableArray *anArray = functionThatReturnsMutableArray(param1, param2);
Depending on what you are doing (the same NSString operations, UIView manipulations, etc), you could implement a category (I answered a question yesterday with the explanation below -- copied for your convenience ;).
Categories extend an existing class with additional methods or with your version of existing methods. For example, let's say you want to add a method that returns the first letter of a string to NSString. To do this you would create a category as follows:
Interface - JULString.h
#import NSString
#interface NSString (JULString)
-(NSString *) firstLetter;
#end
Implementation - The typical convention is that the filename of the category is the name of the class you are extending followed by “+” and the name of the category. In this case the file would be called NSString+JULString.m
#import "NSString+JULString.h"
#implementation NSString ( JULString )
- (NSString *)firstLetter
{
return [NSString stringWithFormat:#"%C", [self characterAtIndex:1]];
}
#end
The neat thing about categories is that now they extend the behavior of ANY instance of the class you are working with. In other words, any NSString in your application will have your new methods (provided that you import the proper header file of course). Beware though, as with great power comes great responsibility. Overwriting class using a category behaviors may lead to undesired effects, so be cautious.
A couple of links you may want to check are:
Apple's guide to Objective-C
Learn Objective-C
Note:
I don't have my Mac with me so I'm writing this code basically off the top of my head (and using some code from the sites above as a reminder). So I apologize in advance for any mistakes ;)
Are there alternatives to "delegates" to pass back data from one controller to another?
Just seems like a lot of work implementing a delegate just to pass back the result from a child controller, back to the parent controller. Is there not another method? Are "blocks" one answer, and if so some example code would be great.
Delegates aren't a lot of work, aren't a lot of code, and are commonly the most appropriate solution. In my opinion they're neither difficult nor messy.
Five lines of code in the child's interface. Before #interface:
#protocol MyUsefulDelegate <NSObject>
- (void)infoReturned:(id)objectReturned;
#end
Inside #interface:
id <MyUsefulDelegate> muDelegate;
After #inteface's #end:
#property (assign) id <MyUsefulDelegate> muDelegate;
One line of code in the child's implementation:
[[self muDelegate] infoReturned:yourReturnObject];
One addition to an existing line of code in the parent's interface:
#interface YourParentViewController : UIViewController <MyUsefulDelegate>
Three lines of code in the parent's implementation. Somewhere before you call the child:
[childVC setMuDelegate:self];
Anywhere in the implementation:
- (void)infoReturned:(id)objectReturned {
// Do something with the returned value here
}
A total of nine lines of code, one of which is merely an addition to an existing line of code and one of which is a closing curly brace.
It's not as simple as a returning a value from a local method, say, but once you're used to the pattern it's super straightforward, and it has the power of allowing you do do all kinds of more complex stuff.
You could use many ways:
Calling a method of the super controller, needs casting maybe
Notifications
Simple Key-Value-Observing
Core Data
Example for for 1.
interface of your MainViewController: add a public method for the data to be passed
- (void)newDataArrivedWithString:(NSString *)aString;
MainViewController showing ChildController
- (void)showChildController
{
ChildController *childController = [[ChildController alloc] init];
childController.mainViewController = self;
[self presentModalViewController:childController animated:YES];
[childController release];
}
Child Controller header / interface: add a property for the mainViewController
#class MainViewController;
#interface ChildController : UIViewController {
MainViewController *mainViewController;
}
#property (nonatomic, retain) MainViewController *mainViewController;
Child Controller passing data to the MainViewController
- (void)passDataToMainViewController
{
NSString * someDataToPass = #"foo!";
[self.mainViewController newDataArrivedWithString:someDataToPass];
}
KVO or notifications are the way to go in many cases, but delegation gives a very good foundation to build upon. If you plan on extending the relationship between the view controllers in the future, consider using delegation.
Blocks are not really relevant to the above, but in short - it is a technique introduced with iOS 4, where you pass around blocks of code as variables/ parameters. It is very powerful and has many uses. For example, here is how you enumerate objects in an array using a block:
[someArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop){
NSLog(#"obj descriptions is - %#", [obj description]);
}];
The part from the ^ until the } is a block. Note that I've passed it in as parameter. Now, this block of code will be executed for every object in the array (i.e. output will be the description of each object).
Blocks are also very efficient performance-wise, and are used heavily in many new frameworks.
Apple's blocks beginners guide is quite good.
Check out NSNotificationCenter — NSNotificationCenter Class Reference
Folks pay a lot of attention the the V and the C in MVC, but often forget the M. If you've got a data model, you can pass it from one controller to the next. When one controller makes changes to the data stored in the model, all the other controllers that share the same model will automatically get the changes.
You might find using a singleton is practical. Just use it as a central storage for all your shared data.
Then throw in saving the state of your application too;)
In one classes .h i have
NSMutableArray *rountines;
and in another classes .m i want to do something like this
[routines addOject:#"Hello];
the other class is an ModalViewController type set up.
So, in essence i'd like the .m file of the MVC to be able to read, and edit and do other things to the ivars i declare in the header.
Cheers,
Sam
edit
Another example, which is similar to what im trying to achieve is like an edit screen.
You can't share ivars between classes really. ivar stands for instance variable, and that is a variable that belongs to some particular instance of an object. The way to solve this problem is to allow other objects to access this object's state. This is most commonly done through setter and getter methods. Objective-C 2.0 makes this easier by providing the #property and #synthesize keywords.
If you had access to the object that had the routines array, you could access it through its property (getter method) like this:
[[someObject routines] addObject:#"hello"];
you can either do this by making the ivars you want to share globals (in which case they would be ivars of the singleton class or app delegate class) or by passing a reference to the class you want to modify the ivars of as an argument to a method of the ModalViewController class:
#implementation ModalViewController
......
-(void)addObjectToRoutinesFromClass: (MyClass *)myclass {
[myclass.routines addObject:#"Hello"];
}
#implementation MyClass
......
ModalViewController *myModalViewController = [[ModalViewController alloc] init];
[myModalViewController addObjectToRoutinesFromClass:self];
#end
I want an array that gets data from one class to be avaliable to me in another class with the same data.
If we declare an array on the applicationDelegate class.
Then declare an object of applicationDelegate in both classes.
And assign the array into appDelegate.array from one class, will i be able get the array across the classes?
I'm with Mike. Leave the App Delegate out of it.
You're in control of when and how your objects are instantiated. If it's important for more than one class to have access to the same data, hand off the data, or a means of getting at your data, as you create instances of the dependent class.
An example, given classes WVParent and WVChild.
WVParent has a property, someArray, which is the array your other objects need:
#interface WVParent : NSObject {
NSArray *someArray
}
#property (nonatomic, retain) NSArray *someArray;
#end
Then you have WVChild, which itself has a property called parentObject:
#class WVParent;
#interface WVChild : NSObject {
WVParent *parentObject;
}
#property (nonatomic, assign) WVParent *parentObject;
#end
Assuming the parent is creating the child instance, you'd allocate it and assign the parent:
WVChild *child = [[WVChild alloc] init];
child.parentObject = self;
Then the child instance can access someArray by:
self.parentObject.someArray
This is just one option. You could also just pass the array itself to the child, assuming the data is static and unlikely to change over the course of the application session.
This way, instead of having a source of data living somewhere in the App Delegate, it lives within a class more appropriately responsible for its creation, maintenance and vending. If you've got a class that pops into existence and can only reach the rest of your app by getting the app delegate, you might want to put a little more thought into your architecture.
More on dependency injection here:
http://en.wikipedia.org/wiki/Dependency_injection
Yes, you could declare a member/property on your applicationDelegate class, although you should try to follow the Single Responsibility Principle and make sure you don't end up stuffing lots of miscellaneous shared stuff in your app delegate (which happens a lot with iPhone code).
Another alternative would be to inject the array into the objects' constructors when you create them.
It's hard to know the best solution in terms of design without knowing what this data is and where it really belongs.