I try to dynamically call certain viewController/Feature depends on his Name.NSClassFromString
(that kind of idea was suggested by Facebook).
For Instance from my server I can define in IOS app which feature or viewController should be used.(or On/Off them)
I searched all over Stack but still cant find an elegant way to implement what I want
Class myclass = NSClassFromString(className);
id obj = [[myclass alloc] init];
will work.
But I would like to call my custom init.
Class myclass = NSClassFromString(className);
id obj = [[myclass alloc] initWithCostumInitializer:userInfo];
I cant find a proper way to do it. Of course every time I receive an error because initWithCostumInitializer is not recognised.So I need to make the decision in run time.I believe I missing something.
Tnx a lot.
First off, you shouldn't get a compile-time error about an unknown method if the headers for the possible classe(s) are imported into the .m file where this code is running. Because of exactly this sort of dynamism, ObjC should let you get away with calling fairly arbitrary methods on objects of type id.
But that's just a bandaid solution. Really, if you know that that custom initializer method is present, then it's not an arbitrary class, right? You have some idea what kind of object it is, or at least what kind of base class it derives from, otherwise you wouldn't know to call that method. So you could always:
id customObj = [((BaseViewController *)[myclass alloc]) initWithCustumInitializer:userInfo];
If your error is a runtime error about the receiver missing that selector, then you have a real problem, which is: why are you calling a named method on an object that might not be the kind of object that has that method? If that's what's happening, you'll need to look at the class first to figure out what kind of thing you're actually about to create, and then behave appropriately for the init.
Related
when I'm trying to call a method on an object of type id, i get a warning raised (method not found). how i call the method :
Class A *instanceACasted = (ClassA *)idvalue ;
then call the method
[instanceACasted methodCall];
This is one way but i dont know about the class name using id how i call the method
You can use introspection and performSelector:
SEL selector = #selector(yourMethodSignature:);
if ([obj respondsToSelector:selector]) {
[obj performSelector:selector];
}
Apple documentation on how to use introspection.
To get rid of the warning method not found , you must cast/convert your id type object to the proper object type. But in this case you need to know the Class name of id type object.
If you don't know the class name then follow this answer.
The correct answer depends heavily on what you are actually doing. Your code doesn't compile, and your error message "method not found" does not exist in Clang, so I can't tell what is actually happening. Also, your subject contradicts what I might guess from your code (there is no mention of "id" in your code). Here are a few guesses:
You are calling a method that has not been declared
ObjC mostly reads code from top to bottom, and reads each source file (implementation file, .m file, not header) separately, as its own "compilation unit". So if your source file tries to call a method that is not in your file, you'll get an error message like error: no known instance method for selector 'doSomething' or error: no known class method for selector 'doSomething'.
To fix that, you need to #import the header that declares the class/protocol that defines the method you want to call.
You are calling a class method on an instance (object) or an instance method on a class
Class methods start with a +, instance methods with a -. They are totally separate. So if you declare a method with a +, then call it on an object of that type (instead of on myObject.class or the class name), the compiler may warn you about error: no known instance method for selector 'doSomething' resp. error: no known class method for selector 'doSomething'. Here the important part is that it is looking for a class method, even though an instance method exists, and vice versa.
You are calling a method that the given object/class does not have
In that case, you get an exception that bounces you back into the run loop and a log message at runtime. This could mean that your code is expecting a newer OS's version of a class (which has that method) but is running on an older OS (where this method didn't exist yet). In that case, you get a message like unrecognized selector sent to instance 0x7fffdb13cf38 or unrecognized selector sent to class 0x7fffdb13cf38.
To fix that, you can check whether an object responds to a given method by asking it [theObject respondsToSelector: #selector(doSomething)], and only then calling it, otherwise doing something equivalent that doesn't rely on that method. Or you could check if that method is available ahead of time and just hide the button or whatever that needs this on older OSes that way.
Note that, if you had e.g. an NSObject* and you knew that in one special case it could actually be an NSString*, and you use -respondsToSelector: to verify that it implements #selector(characterAtIndex:) in that case, you may still get an error message that NSObject instances do not responds to -characterAtIndex:. In this case, you can turn off that warning by doing:
NSObject* myNSObject = myArray.firstObject;
if( [myNSObject respondsToSelector: #selector(characterAtIndex:)] )
[(NSString*)myNSObject characterAtIndex: 0];
or whatever. You usually never write code like this, though. Checking "what class is my object" is usually an indicator that you built your class hierarchy wrongly, so I only mention that for completeness' sake.
How does 'id' figure into this?
You mention id in your headline, but your example doesn't use it. If you call a method on id, ObjC will let you do anything. All it wants is that somewhere there is a class or instance method declaration for the given method, on any object. In that case, it will only blow up at runtime if you call a method the given object doesn't have.
I am trying to write a test case for a method in Objective-C class which returns void. The method mobileTest just creates another object of class AnotherClass and calls a method makeNoise. How to test this ?
I tried to use OCMock to create test this. Created a mock object of AnotherClass, and called mobileTest method. Obviously, the OCMVerify([mockObject makeNoise]) won't work, as I am not setting this object anywhere in the code. So, how to test in such cases ?
#interface Hello
#end
#implementation HelloWorldClass()
-(void)mobileTest{
AnotherClass *anotherClassObject = [AnotherClass alloc] init];
[anotherClassObject makeNoise];
}
#end
#interface AnotherClass
#end
#implementation AnotherClass()
-(void) makeNoise{
NSLog(#"Makes lot of noise");
}
#end
Test case for the above is as follows :
-(void)testMobileTest{
id mockObject = OCMClassMock([AnotherClass class]);
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
There's not a simple answer to this without going a bit into what OCMock is meant for and what test design paradigm it implies.
The short version is: You should not test this like that in the first place. Tests should treat the tested methods as a black box and only compare & verify input vs output.
Longer version: You're trying to test for a side effect, basically, since makeNoise doesn't do anything that the HelloWorldClass even registers (or "sees"). Or to put it in a more positive way: As long as makeNoise is properly tested in the tests written for AnotherClass you don't need to test that simple call.
The example you provide may be a bit confusing, since obviously that doesn't leave anything meaningful to test in mobileTest's unit test, but considering that you might also question why to outsource the simple NSLog call to another class in the first place (and testing for an NSLog call is kind of pointless, of course). Of course I understand you're just using this as an example and envision a more complex different scenario in which you want to ensure that a specific call happens.
In such a situation, you should always ask yourself "Is this the correct place to verify this?" If the answer is "yes" that should imply that whatever message you want to test to be called needs to go to an object that's not completely inside the scope of the tested class only. For example, it could be a singleton (some global logging class) or a property of the class. Then you have a handle, an object that you can properly mock (for example, set the property to a partially mocked object) and verify.
In rare cases that might lead you to provide a handle/property for an object simply to be able to replace it with a mock during testing, but that often indicates a sub-optimal class and/or method design (I'm not gonna claim that's always the case, though).
Let me provide three examples from one of my projects to illustrate something similar to your situation:
Example 1: Verifying that an URL is opened (in mobile Safari): This is basically verifying that openURL: is called on the shared NSApplication instance, something very similar to what you have in mind. Note that the shared instance is not "completely inside the tested methods scope" as it is a singleton"
id mockApp = OCMPartialMock([UIApplication sharedApplication]);
OCMExpect([mockApp openURL:[OCMArg any]]);
// call the method to test that should call openURL:
OCMVerify([mockApp openURL:[OCMArg any]]);
Note that this works due to the specifics of a partial mock: Even though openURL: is not called on the mock, because the mock has a relationship to same instance that is used in the tested method it can still verify the call. If the instance weren't a singleton that would not work, you would not be able to create the mock from the same object that is used in your method.
Example 2: Adapted version of your code to allow "grabbing" the internal object.
#interface HelloWorldClass
#property (nonatomic, strong) AnotherClass *lazyLoadedClass;
#end
#implementation HelloWorldClass()
// ...
// overridden getter
-(AnotherClass *)lazyLoadedClass {
if (!_lazyLoadedClass) {
_lazyLoadedClass = [[AnotherClass alloc] init];
}
return _lazyLoadedClass;
}
-(void)mobileTest{
[self.lazyLoadedClass makeNoise];
}
#end
And now the test:
-(void)testMobileTest{
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
id mockObject = OCMPartialMock([helloWorldObject lazyLoadedClass]);
OCMExpect([mockObject makeNoise]);
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
The lazyLoadedClass method might even be in a class extension, i.e. "private". In that case, just copy the according category definition to the top of your test file (I usually do this, and yes, this is, IMO, a valid case of basically "testing private methods"). This approach makes sense if AnotherClass is more complex and requires elaborate setup or something. Usually stuff like this then leads to the scenario you have in the first place, i.e. its complexity makes it to more than just a helper than can be thrown away after the method finishes. this will then also lead you to better code structure, since you have its initializer in a separate method and can test that accordingly, too.
Example 3: If AnotherClass has a non-standard initializer (like a singleton, or it comes from a factory class) you can stub that and return a mocked object (this is kind of a brain-knot, but I have used it)
#implementation AnotherClass()
// ...
-(AnotherClass *)crazyInitializer { // this is in addition to the normal one...
return [[AnotherClass alloc] init];
}
#end
-(void)testMobileTest{
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
id mockForStubbingClassMethod = OCMClassMock([AnotherClass class]);
AnotherClass *baseForPartialMock = [[AnotherClass alloc] init];
// maybe do something with it for test settup
id mockObject = OCMPartialMock(baseForPartialMock);
OCMStub([mockForStubbingClassMethod crazyInitializer]).andReturn(mockObject);
OCMExpect([mockObject makeNoise]);
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
This looks kind of stupid and I admit it's plain ugly, but I have used this in some tests (you know that point in a project...). Here I tried to make it easier to read and used two mocks, one to stub the class method (i.e. the initializer) and one that then is returned. The mobileTest method should then obviously use the custom initializer of AnotherClass, then it gets the mocked object (like a cuckoo's egg...). This is useful if you want to specially prepare the object (which is why I used a partial mock here). I am actually not sure atm if you could also do this with only one class mock (stub the class method/initializer on it so it returns itself, then expect the method call you want to verify)... as I said, brain-knotting.
I have an NSProxy subclass called EBManagedObject and an NSObject subclass called EBObject. EBManagedObject is initialized with a guid that is used to retrieve an EBObject from EBObjectRepository. EBManagedObject will forward any message sent to it to its EBObject, except for some restricted messages, in which case it will throw an exception. So wherever you can use an EBObject you can use an EBManagedObject. My problem is that Xcode doesn't understand this and gives me an incompatible pointer types warning when trying to do the following:
EBObject *object = [[EBManagedObject alloc] initWithGuid:guid];
It's simple enough to fix:
EBObject *object = (EBObject *)[[EBManagedObject alloc] initWithGuid:guid];
But I am wondering if there is any way to make Xcode consider EBObject and EBManagedObject compatible pointer types?
I know I could create a protocol that both of them implement and do something like:
id<EBObject> object = [[EBManagedObject alloc] initWithGuid:guid];
But I have good reasons not to do that.
By the way, all the class names are made up. My actual scenario is more complex, so I made a simplified example to explain my problem.
I have found the class PSCellularDataSettingsDetail and its method +(void)setEnabled:(BOOL)enabled;, which I think will give me what I need, which is accessing the mobile data setting.
I found this method by opening up the compiled Preferences.framework using class-dump-z.
Now I found this answer and tried to access the class and method that way, but the class is private too. How can I open this class up to Xcode?
Have you tried calling performSelector? That is usually the trick to call private methods. Remember all that makes a method private in Objective-C is the fact that it is not advertised in the h file. But if you send a message to an object and the object can respond to that message it will, regardless of what's in the header file.
If it's a class method like +(void)setEnabled you would just call [MyClass performSelector(#selector(myMethod)] and if it is an instance method you would call it on a variable that is an instance of the class:
MyClass *c = [[MyClass alloc] init];
[c performSelector: #selector(myMethod)]
It gets tricky when you need to pass parameters though like in this case, because the only way performSelector can pass parameters is if they are objects not primitives. You can also look into using objc_msgSend.
There is a ton of stuff online explaining how those two work. Either way it's messy to try to call private methods and is very risky.
So I'm getting myself into a confusion over where my data's going and where it's stored in my application. It's not a specific question so hopefully someone can provide a generalised answer.
I need to pass some data around between a few UIViewController instances, and I'm currently doing that with a singleton object called my dataManager. This class has one method, a class method, called + (LCDataManager *) sharedDataManager, and that method basically checks if whether the sharedDataManager already exists, if so, return it, if not, create it and set up its variables. This means that I can refer to that class anywhere I like, access and modify its variables anywhere I like, from across multiple classes.
First question: is this the correct / best / most appropriate means of passing data around like this? I'm hoping it obeys MVC, it feels like it does, and I hope I'm right.
Second question: what if I want to put an instance method in that class, and call it from within the class method? Let's say my sharedDataManager needs to call a method to grab some objects one of its variables (an array), and put them in another array, then send that back out again. I can't do that, can I? What's the way around that? If I make an instance of that class (rather than using the shared instance), I lose the ability to use that instance across multiple viewControllers.
I'm hideously confused, and it seems like it's not the problem I'm making it. Appreciate any guidance, and preferably not that "Read the Apple documentation" stuff – they write as if you already know what you're doing, and frankly I don't yet.
First question: is this the correct / best / most appropriate means of passing data around like this? I'm hoping it obeys MVC, it feels like it does, and I hope I'm right.
Your design is perfectly MVC compliant.
Second question: what if I want to put an instance method in that class, and call it from within the class method?
you can surely define an instance method and call it like this:
[[MyModelClass sharedModel] myInstanceMethod];
indeed, [MyModelClass sharedModel] will give you an instance of MyModelClass (which should be guaranted to be unique being it a singleton).
If you want to call the instance method from the sharedModel class method, you could also do that, because sharedModel owns a reference to your singleton, so it can send messages to it.
is this the correct / best / most appropriate means of passing data around like this?
There's nothing wrong with only having a single instance of LCDataManager, but using the Singleton pattern has potential problems. An alternative is to just initialize one LCDataManger and to pass it around to wherever it's needed.
what if I want to put an instance method in that class, and call it from within the class method?
The accessor + (LCDataManager *) sharedDataManager should only return the instance. I guess what you want is something like
+ (LCDataManager *)preparedDataManager {
LCDataManager *shared = [self sharedDataManager];
[shared doSomeInstanceMagic];
return shared;
}
- (void)doSomeInstanceMagic {
// magic!
// grab some objects one of its variables (an array),
// and put them in another array
}
Matthijs Hollemans has an excellent three-part tutorial on his blog about the correct way to make your view controllers talk to each other:
Part 1
Part 2
Part 3
there is no problem with this development architecture, and it is the must used (I think) in the iOS development. In the book IOS Programming: The Big Nerd Ranch Guide they call it Model View Controller Store.
Regarding your second question, yes, you can declare instance methods and call then from your sharedDataManager. What is not usual is creating other instances of a singleton class, but it is possible.