I have a class object that i'm using a lot from different places.
Now i'm using the class like this:
myClass.delegate = self;
[myClass doSomething];
doSomething creates a new class object that calculate stuff and can take up to 1 min before it sends back a result to the delegate like this:
-(void)doSomething {
CalculateStuff *calc = [[calculateStuff alloc] init];
calc.delegate = self;
[calc calculate];
}
/* Calculate Delegate */
-(void)didCalculate {
[[self delegate] didDoSomething];
}
Problem is that i from another place is calling the same thing it will call my latest delegate and this causes a lot of problems.
Question:
Is there a way to send the delegate as an object without having to set it as the property?
I've written it like this and Xcode give me warnings "Incomplete implementation of MyClass"
[myClass doSomethingWithDelegate:self];
And
-(void)doSomethingWithDelegate:(id)delegate {
CalculateStuff *calc = [[calculateStuff alloc] init];
[calc calculateWithDelegate:delegate];
}
/* Calculate Delegate */
-(void)didCalculateWithDelegate:(id)delegate {
[delegate didDoSomething];
}
EDIT
Just tried it out and it seems to work, but how can i get rid of the warnings in Xcode?
I think your problem is that you forgot to remove the declaration of doSomething and didCalculate from your class's interface (or class extension).
Ideally you should create a protocol to ensure that your delegate has the required method(s). For instance:
#protocol DoSomethingDelegate <NSObject>
- (void)didDoSomething;
#end
Then use id<DoSomethingDelegate> instead of just id.
Passing a block would also be a valid solution to this problem, although it's a bit trickier.
Related
This is something very fascinating I observed today. Maybe that's how Objective-C works but I didn't know about this. See the following code below:
// ATableViewController.h
#interface ATableViewController : UITableViewController
#end
// ATableViewController.m
#interface ATableViewController ()
#property (nonatomic) int volly;
#end
#implementation ATableViewController
- (void)viewDidLoad
{
[super viewDidLoad];
self.volly = 5;
}
#end
// BTableViewController.h
#interface BTableViewController : ATableViewController
#end
// BTableViewController.m
#interface BTableViewController ()
#property (nonatomic) int volly;
#end
#implementation BTableViewController
- (void)viewDidLoad
{
[super viewDidLoad];
NSLog(#"%d", self.volly); // returns 5
}
#end
I am not sure why the above is valid. I do understand that I passed a message 'volly' to the object 'self' which in turn probably looked at the value from the super class but shouldn't these be initialized? Some explanation would be of great help. Thanks.
EDIT: This is a big problem IMO though. Considering I don't know any of the private properties defined in the super class, my own set of values might end up being different.
For example, a developer may set a boolean flag hasAppeared in viewDidAppear:. This same value will be set for my subclass instance in viewDidAppear: after the [super viewDidAppear:] call. This will be before I actually get to set it myself.
Currently, the solution is I know exactly the variable used by the super class and I can avoid using the same value but I deem this to be a larger issue than it seems.
EDIT 2: The behavior is consistent with binaries (with only headers) as well as with frameworks where implementation is available.
I am answering this without reading all of the comments.
There is no issue here. Both AViewController (AVC) and BViewController (BVC) each have their own private property named volly.
You created an instance of BVC. It can't see the volly property from its parent class (because it is private), just its own.
Now the fun begins.
The viewDidLoad method from BVC is called. It in turn calls [super viewDidLoad]; which of course calls the viewDidLoad from the AVC class. That method, in turn, calls self.volly = 5;.
The confusion seems to be with this line. Remember, self.volly = 5; is really a call to:
[self setVolly:5];
Both AVC and BVC have the (synthesized) setVolly: method. Since self is a pointer to an instance of a BVC object, the call to [self setVolly:5]; results in a call to the setVolly: method in the BVC class despite being called from a method in the AVC class.
Here's the code with some annotations:
The 'BVC' class:
- (void)viewDidLoad
{
[super viewDidLoad]; // calls the method in `AVC`
NSLog(#"%d", self.volly); // returns 5
}
The 'AVC' class:
- (void)viewDidLoad
{
[super viewDidLoad]; // calls the UITableViewController method
// The following is really [self setVolly:5];
// Since "self" is a "BVC", the private "volly" property of
// the "BVC" class is actually set here.
// The private "volly" property of the "AVC" class will still be
// 0 after this call.
self.volly = 5;
}
In the end, the subclass is not using the private property of the parent class. The original premise in the question's title is incorrect.
Now I am developing an iOS application which works like this:
User scans QR code,
App searches for a specific key - > value,
it gives out a value to the user.
Currently I have two ViewControllers - the main and "value" ViewController, which is inherited from main. The problem is that if I create NSDictionary in main VC it is not visible in "value" VC. Main VC gives only the string (QR code, the key) through the segue. So, the value VC has to search for key and display the value.
What I ask is some kind of global variable or one DataSource visible across the whole app. Of course, I can implement NSDictionary initialisation inside value ViewDidLoad method and it will work, but this is not the point. New modules are to be added there and the variable has to be global. I googled a lot and got the idea that singleton pattern can be helpful here. I tried to implement it, but no idea how to do. Do I need it, or it is too complex for this kind of DataSource?
Thank you!
The basic idea is, you will still need to #include the header file of the place where this dictionary will be. The solution that Naveen proposes means that you will be including the header for the app delegate wherever you want to access it. Whether to use the app delegate for this purpose or not is kinda grayish. Some people often do this, some say its a bad use of it.
The singleton approach means that you will create a class, that will always contain the same information since the init method will return object that was previously created.
For the singleton aproach, imagine I have a database manager class. So in the header of this class (the DatabaseManagerSingleton.h) ill have this:
#interface DatabaseManager : NSObject
+ (DatabaseManager*)sharedInstance;
// Your dictionary
#property (nonatomic,strong) NSMutableDictionary* someDictionary;
The implementation will look like this: (check how "sharedInstance" initializes the object)
#implementation DatabaseManager
#pragma mark - Singleton Methods
+ (DatabaseManager*)sharedInstance {
static DatabaseManager *_sharedInstance;
if(!_sharedInstance) {
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_sharedInstance = [[super allocWithZone:nil] init];
});
}
return _sharedInstance;
}
+ (id)allocWithZone:(NSZone *)zone {
return [self sharedInstance];
}
- (id)copyWithZone:(NSZone *)zone {
return self;
}
- (id)init
{
self = [super init];
if (self != nil)
{
// Custom initialization
_someDictionary = [[NSMutableDictionary alloc] init];
}
return self;
}
Now, a VERY important thing is that, any place you want to use this object should first include the header:
EDIT: To use it in your code:
1) add the header
#import "DatabaseManager.h"
2) initialize the object
DatabaseManager *databaseManager = [DatabaseManager sharedInstance];
3) do whatever you need
// Initialize the dictionary
databaseManager.someDictionary = [[NSMutableDictionary alloc] initWithObjectsAndKeys:#"OBJECT",#"someKey", nil]; // In this case the object is just a NSString.
// Access
[databaseManager.someDictionary objectForKey:#"someKey"];
Put as a property on Appdelegate
#property (nonatomic,strong) NSDictionary * sharedData;
Access anywhere like
NSDictionary *sharedData= ((APPDelegate *) [UIApplication sharedApplication].delegate).sharedData;
As a part of my transition process from C++ to Objective-C, I intensively read book Cocoa and Objective C Up and Running.
In one of the book code examples, there is a line that does not make sense to me with my current level of knowledge:
It is a declaration of class method + (Photo*) photo;.
Could anybody explain me the reason, please, why the author had decided for the method (Photo*) photo; to declare it as a class method instead of instance method?
I have studiet the theory, that the instane method is something like a class member function and that class method is something like static function in C++. But this still does not answer my question.
Here is the declaration code:
#import <Foundation/Foundation.h>
#interface Photo : NSObject{
NSString* caption;
NSString* photographer;
}
+ (Photo*) photo;
- (NSString*) caption;
- (NSString*) photographer;
- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;
#end
The implementation code follows:
#import "Photo.h"
#implementation Photo
- (id)init
{
self = [super init];
if (self) {
[self setCaption:#"Default Caption"];
[self setPhotographer:#"Default Photographer"];
}
return self;
}
+ (Photo*) photo {
Photo* newPhoto = [[Photo alloc] init];
return [newPhoto autorelease];
}
- (NSString*) caption {
return caption;
}
- (NSString*) photographer {
return photographer;
}
- (void) setCaption:(NSString *)input {
[caption autorelease];
caption = [input retain];
}
- (void) setPhotographer: (NSString *)input {
[photographer autorelease];
photographer = [input retain];
}
- (void)dealloc
{
[self setCaption:nil];
[self setPhotographer:nil];
[super dealloc];
}
#end
The + (Photo*) photo method is a Factory Method that encapsulates the details of creating an object of the Photo class.
A Factory Method enforces
encapsulation, and allows an object to
be requested without inextricable
coupling to the act of creation.
In this particular example the information being hidden by the factory method is memory management, since the client does not need to worry about releasing the returned object.
It is a common practice in Objective-C APIs to provide factory methods in classes that return autoreleased objects of that same classes. These methods must not contain any of the words “alloc”, “new”, “copy”, or “mutableCopy”, which, according to the convention, indicates that the caller doesn't own the returned object, i.e. it doesn't have to be explicitly released.
Related resources:
Memory Management Rules
Meta answer:
One issue; that method should be
declared as returning id and should
return [[[self alloc] init]
autorelease]; (one line or two,
doesn't matter -- just should refer to
the Class directly). As it is, Photo
is gonna be a pain to subclass.
Expanding -- given this:
+ (Photo*) photo {
Photo* newPhoto = [[Photo alloc] init];
return [newPhoto autorelease];
}
If the class were subclassed, this factory method would not work without being overridden to do pretty much the same thing. However, since Objective-C doesn't support co-variance and contra-variance, there would be no way to declare the subclass's implementation of +photo to return an instance of the subclass without also running a significant risk of compiler warnings. Alternatively, you could down-cast the return value to the more specific class, but that is rife with fragility.
Instead, do this:
+ (id) photo {
id newPhoto = [[self alloc] init];
return [newPhoto autorelease];
}
This fixes both issues:
since it uses self, it'll instantiate an instance of whatever class it is implemented on, including subclasses of Photo.
since it returns id, callers can do both of the following without issue:
Photo *p = [Photo photo];
SubclassOfPhoto *s = [SubclassOfPhoto photo];
In this scenario, photo is a convenience method, which returns you an autoreleased instance of the class.
Since the purpose of photo is to give you an instance, it wouldn't make sense to make it an instance method which would require you to already have an instance.
If you're familiar with Factory Methods, the photo method is similar to that.
+photo is like a constructor. You need a way to get an object to send instance methods to, and this gives you an autoreleased one.
It is equivalent to a static method, as you say. In this case (and all cases of [ClassName className] methods) it's basically a factory method. You're asking the class to construct an instance of itself and pass it back. All such methods should return an autoreleased object.
You can safely ignore methods like that if you want - there will usually be an alloc+init equivalent, but it's often more convenient to use the class method, especially if you're creating a throaway object and don't want to retain it.
Finally, you'll sometimes find classes which require you to use the class method, as they'll hide some clever logic wherein an instance of another class is actually returned. You'll sometimes hear these described as 'class clusters'.
Could anybody explain me the reason, please, why the author had decided for the method (Photo*) photo; to declare it as a class method instead of instance method?
It's basically a wrapper of the constructor litany. Note the source:
+ (Photo*) photo {
Photo* newPhoto = [[Photo alloc] init];
return [newPhoto autorelease];
}
Allocate a new Photo, initialize it, mark it autorelease, and return it. Since it creates the object, there is no object yet to operate upon, ergo this needs to be a class method.
The below code behaves as expected however the compiler keeps telling me this:
warning: 'StatusViewController' may not respond to '-beginLoadingThreadData'
How do I get rid of that warning and most important why xcode believes that is the case?
here is my code:
[self beginLoadingThreadData]; // called in the loadDidView block
- (void)beginLoadingThreadData
{
[NSThread detachNewThreadSelector:#selector(loadThreadData) toTarget:self withObject:nil];
}
- (void)loadThreadData
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSThread sleepForTimeInterval:2];
[self performSelectorOnMainThread:#selector(finishedLoadingThreadData) withObject:nil waitUntilDone:NO];
[pool release];
}
- (void)finishedLoadingThreadData
{
[[BusinessLogic instance] startTracking:self];
}
Declare that method before you use it. I'm assuming it's a private method, in which case you would add a class extension at the top of the implementation file:
#interface MyClass ()
- (void) beginLoadingThreadData;
#end
If it's a public method, make sure you've declared the method in your header and #imported the header at the top of the implementation file.
You have to either move the definition of loadingThreadData before the definition of viewDidLoad, or define it in the header file for StatusViewController, for example by inserting -(void)beginLoadingThreadData; before the #end in the header file (probably StatusViewController.h).
The reason is that if you don't do this, when the compiler reached your viewDidLoad method, and sees the call to beginLoadingThreadData, it has not yet seen the definition of beginLoadingThreadData, and hasn't been assured (by seeing a declaration with the method signature in the header file) that such a definition exists. Therefore it warns you that the method you're trying to call might not exist.
I am trying to create an object only instantiatable through a factory method. I prevented init being used by throwing an exception (see Creating a class with no init method). However this meant that I had to create a new method secretInit to use in the factory method.
//Factory method
- (URLReqs *)buildURLReq:(NSString *)location
{
URLReqs *tmp=[[URLReqs alloc] secretInit];
tmp.str=location
return tmp;
}
- (id) secretInit{
return [super init];
}
This method is messy and while we can avoid declaring secretInit in the header file, someone could still access it. Is there a nicer solution?
One idea is to try calling init on the super object of URLReqs directly rather than creating a function to do it.
You don't want to do it this way, but it is possible:
#include <objc/message.h>
#implementation MyClass
+ (id) factoryMethodWithParameter:(NSString *) someString;
{
struct objc_super instanceSuper;
id myInstance = [self alloc];
instanceSuper.receiver = myInstance;
instanceSuper.super_class = [self superclass];
// instanceSuper.class = [self superclass]; // use this line if the above doesn't compile
myInstance = objc_msgSendSuper (&instanceSuper, #selector(init));
//continue on setting up myInstance's ivars . . .
[myInstance setVariable:someString];
return myInstance;
}
- (id) init
{
self = [super init];
if (!self) return nil;
[self release];
[self doesNotRecogniseSelector:_cmd];
return nil;
}
#end
This will allow you to continue to send init messages to myInstance's “super” object, but won't allow anyone to send init to MyClass instances.
Be careful though, although this is using standard runtime functions declared in objc/*.h, don't expect Apple to keep this runtime API consistent.
The solution is to use a category on your object to hide the secret initialization method.
Private Methods through categories
What goal are you trying to accomplish? There might be a better solution than this.
It only exposes it if it's referenced in the header file.
No, wait. I should state that another way. There's no better way to hide it than to not declare it in the header file. Private methods don't exist in Objective-C.