I'm hitting a road block and I'm wondering if the brilliant collective minds here can help. In ObjC CocoaTouch I'm trying to mock an object that takes struct parameters and returns a struct. OCMock is coughing up a hair-ball so I tried wrapping with a Hamcrest matcher. No die. The function/method I'm testing looks something like this:
- (CLLocationCoordinate2D)pixelToLatLong:(CGPoint)aPoint;
I use code like this:
#define OCMOCK_STRUCT(atype, variable) [NSValue value:&variable withObjCType:#encode(atype)]
-(void) testMyWidget
{
CLLocationCoordinate2D ulLL = (CLLocationCoordinate2D){123,456};
CLLocationCoordinate2D lrLL = (CLLocationCoordinate2D){654,321};
[[[(id)myObj expect] andReturn:OCMOCK_STRUCT(CLLocationCoordinate2D, ulLL)] pixelToLatLong:(CGPoint){0,0}];
[[[(id)myObj expect] andReturn:OCMOCK_STRUCT(CLLocationCoordinate2D, lrLL)] pixelToLatLong:(CGPoint){320,460}];//lower right point
}
That kinda works. So in my object that I'm testing I make the necessary required edits to get a green bar... err.. green button in the build info window. When I'm certain that my test should pass I get assertion failed errors. The errors inform me that the method was invoked unexpectedly and lists the values for these structs as question marks. I tried wrapping the structs with Hamcrest matchers but I'm getting nowhere. I'm getting ready to break out my debugger which will no doubt show me what's wrong. Has anybody here had similar trouble with OCMock/Hamcrest and structs? If so, what's the best way to handle these types?
You're very close. Your #define should be:
#define OCMOCK_STRUCT(atype, variable) [NSValue valueWithBytes:&variable withObjCType:#encode(atype)]
The best answer is actually Cliff's himself: http://codeforfun.wordpress.com/2009/02/07/ocmock-return-a-struct/
He just didn't update this question, shame shame :)
I had problems with the macro answer; writing a helper function that returned the struct in the testing class and using:
[[[mockObject stub] andCall:#selector(selectorName) onObject:self] someMethod];
worked really well.
Sometimes a hand-coded mock is easier than trying to coerce a mock object framework outside of its normal use patterns.
Related
I'm looking into a project, trying to get a grip on the code. I just ran in to a #selector. As far as I understand it, selectors call methods (I'm sure there's more to it, of course).
One thing that struck me is that the selector call doesn't pass an argument to the method even though the method itself takes a parameter. The code works fine, so I take it that this is normal behavior with a selector. Here is a sample of the code:
[Communication sendVerifyNumber:ps.address verificationCode:#""
withCallbackMethod:#selector(numberVerificationCallCompleted:)
callbackFailMethod:#selector(numberVerificationCallFailed:) onObject:self];
}
And the numberVerificationCallCompleted:
-(void)numberVerificationCallCompleted:(NSNumber*)responseNumber{...}
So, my question is, is this a thing with selectors. I mean, is that why they are used? And how does it work? The method still needs an argument to work properly, so it has to come from somewhere, right?
A selector describes a method within an Objective-C class, allowing you to call it at a later point in time. Parameters are passed when it's called, not when it's described.
You store selectors in a SEL type and call them using performSelector: making them ideal to use as callbacks.
The method you show above, will do something like this:
- (void)sendVerifyNumber:(NSString*)address
verificationCode:(NSString*)verificationNumber
withCallbackMethod:(SEL)callbackMethod
callbackFailMethod:(SEL)failedCallbackMethod
onObject:(id)callbackObject
{
BOOL success = doWhateverIDo();
if (success) {
[callbackObject performSelector:callbackMethod
withObject:someArgumentToPassback];
} else {
[callbackObject performSelector:failedCallbackMethod
withObject:someArgumentToPassback];
}
}
Note: you can only call a method that is described by a selector if it takes zero, one or two parameters (using performSelector:, performSelector:withObject: and performSelector:withObject:withObject: respectively).
I've seen a lot of discussions NEAR this subject, but none that actually work in Xcode 5.x, especially using ARC. I have a simple problem:
I need to pass a method reference to a CreateButton method so that when the button is called it calls my custom function, and not some generic one.
I've tried using (SEL) type, but that doesn't work with ARC. I've tried using the &func method, but that claims I haven't declared the function yet.
So my need is:
Class A calls Class B and sends over the info to make a UIButton. Within that call, I want to send over the action:method in a reference. I'm sure this is done routinely, but I can't seem to find an iOS 7 / Xcode 5.x method of doing it. I've also reviewed the O'Reilly iOS 7 fundamentals and cookbook code and couldn't find this discussed anywhere.
Thanks for you help.
When I have to pass selectors around, I convert them to strings with NSStringFromSelector() and back to selectors with NSSelectorFromString().
Passing the strings around is a lot easier. You can store them in collections (arrays, dictionaries), serialize and unserialize them, and they will work naturally with ARC.
Example:
In your class A where you gather the information to create a button:
NSString *selectorString = NSStringFromSelector(#selector(yourActionMethodNameHere:));
// Gather more information needed by Class B here, then package
// it all up into a dictionary, for example
NSDictionary *buttonInfo = #{#"selectorString": selectorString, /* more stuff here */};
At this point, you can call your button-constructing method in Class B, passing along buttonInfo, which contains all the information that that helper method needs, including the selector. The method can convert the string back to a selector and use it like this:
SEL actionSelector = NSSelectorFromString(buttonInfo[#"selectorString"]);
// configure your button to use actionSelector here
You should be able to use SEL parameters? I know I have done before.
ARC might complain and give you a warning, but it won't fail to compile. It's simply a warning because it can't quite figure out what to do memory wise.
If you really can't get that to work though, another alternative would be to use a block, so you might call your method like
[objectA performMethodWithParam:paramA paramb:paramB completion:^{ ... do somethhing ... }];
Then in that method you can just call
completion();
Instead of actually calling a method.
Another alternative would be to use the delegate pattern. Create a #protocol defining a method such as classADidFinish then make class B implement that method. Then set the instance of classB as the delegate for your classA instance, and have it call that method when it's done.
Both of these approaches will stop ARC moaning at you.
But as I said, using SEL params should work fine. There is a way you can even get the compiler to stop showing you the warnings but it's a little ugly.
I'm just beginning with ObjC. I'm wondering how to find out when looking at code, written by me or from a template that comes when you use the wizard to create a new class, how you can tell if a method is overriding something.
In Java, you can mark a method with #Override, and then it's very easy to see if it's overriding something. That's not foolproof, because #Override is optional, but if I'm still unsure I can just type that in and see if it generates an error.
Is the only way to look up the source of the superclass, or in the case of a framework to read the documentation?
I don't know a way to see this immediately, but you could check if super responds
to the same selector. Example:
- (void)myMethod
{
// Temporarily add this line. If the compiler does NOT complain,
// "myMethod" overrides a method from some superclass.
[super myMethod];
// ...
}
You can use instancesRespondToSelector to see if your instance has an implementation of the method in its object hierarchy.
[MyClass instancesRespondToSelector:#selector(myMethod)];
or depending on what type of checking you need to do
[MyClassSuperClass instancesRespondToSelector:#selector(myMethod)];
I have written this trivial action method associated to a textfield.
Every time I enter text into a textfield a search in a PDF is performed and PDFView automatically scroll to selection:
- (IBAction) search:(id)id
{
NSString *query = [self.searchView stringValue]; // get from textfield
selection = [document findString: query fromSelection:NULL withOptions:NSCaseInsensitiveSearch];
if (selection != nil)
{
[self.pdfView setCurrentSelection:selection];
[self.pdfView scrollSelectionToVisible:self.searchView];
}
}
Problem is that after 3 or 4 searches I get EXC_BAD_ACCESS on row (i).
If I debug I see that query contains an NSCFString and not an NSString.
I think it is a memory management problem..but where?
I replicated the same issue inside a trivial testcase:
#interface PDFRef_protoTests : SenTestCase {
#private
PDFDocument *document;
}
........
- (void)setUp
{
[super setUp];
document = [[PDFDocument alloc] initWithURL: #"a local url ..."];
}
- (void)test_exc_bad_access_in_pdfdocument
{
for (int i =0 ;i<100; i++)
{
NSString *temp;
if (i % 2 == 0) temp = #"home";
else if (i % 3 ==0) temp = #"cocoa";
else temp=#"apple";
PDFSelection *selection = [document findString: temp
fromSelection:nil
withOptions:NSCaseInsensitiveSearch];
NSLog(#"Find=%#, iteration=%d", selection, i);
}
}
Update:
1) It seems that it happens also if I use asynchronous search (method beginFindString: withOptions) every time I perform second search.
2) I found a similar problem to mine in MacRuby Issue Tracking: http://www.macruby.org/trac/ticket/1029
3) It seems that if I disable temporarily garbage collection it works but memory goes up.
I wrote something like:
[[NSGarbageCollector defaultCollector] disable];
[[NSGarbageCollector defaultCollector] enable];
surrounding search code
Another Update
Very weird thing is that sometimes all works. Than I clean and Rebuild and problem arises again. From a certain point of view is is not 100% reproducible. I suspect a bug in PDFKit or some compiler setting I have to do
Update Again
Dears it seems very crazy. I'd concentrate on testcase which is very trivial and which replicates easily the problem. What's wrong with it? This testcase works only if I disable (by code or by project setting) GC
Another Update
Boys it seems a bug but I downloaded an example called PDFLinker from Apple website (http://developer.apple.com/library/mac/#samplecode/PDFKitLinker2/Introduction/Intro.html#//apple_ref/doc/uid/DTS10003594). This example implements a PDFViewer. Code of my app and this example are quite similars. For the same search action on same PDF, my memory rises at 300/400 MB while PDFLinker rises at 190MB. Clearly there is something wrong in my code. But I am comparing it bit by bit and I don't think I am inserting memory leaks (and Instrument doesn't give me any evidence). Maybe is there some project-wide setting ?
Update Yet
Changing from 64 bit to 32 bit memory consumption lowered. Surely there is a problem with 64bit and PDFKit. BTW still EXC_BAD_ACCESS on second search
SOLUTION
Crucial point is that PDFKit with Garbage collection is bugged.
If I disable GC all works correctly.
I had another issue that had complicated my analysis: I disabled GC on Project Setting but GC remained enabled on Target Settings. So Apple's example PDFLinked2 worked while mine not.
I agree you have found a bug in PDFKit.
I got various forms of errors (segmentation fault, selector not understood, etc) running your test case. Wrapping the code in #try/#catch doesn't prevent all errors associated with this method.
I also got errors printing the log message.
To work around the bug(s), I suggest you disable GC during your invocation of -findString:fromSelection:, as you've already discovered.
Also, be sure to make copies of the values of interest from selection before re-enabling GC. Don't just copy selection either.
If you conduct searches from multiple places in your code I also suggest you extract a separate method to perform the search. Then you can invoke that one to conduct the searches for you without duplicating the GC disable/enable nesting.
This sort of thing is usually evidence that you're hanging onto a pointer to an object that has been destroyed. Turn on zombie objects (with NSZombieEnabled) to see exactly where and when you're accessing a bad object.
Judging from your screen shot it doesn't seem like you have NSZombie turned on. Probably the reason why it doesn't help you. Here's how you turn it on:
How to enable NSZombie in Xcode?
The screenshot you provided was otherwise very useful, but you really need NSZombie to figure out this kind of errors. Well, unless it's obvious, which it isn't from the code you posted.
EDIT: I read the comment that you're using garbage collection. I'm an iOS developer, so I have very limited experience with garbage collection in Objective-C, but as far as I understand NSZombie doesn't work in a garbage collected environment.
I'm not sure it should be possible to get EXC_BAD_ACCESS in a garbage collected environment, unless you create your own pointer and try to call methods on it without having created an object and I don't see why you would do that.
I've heard that some frameworks doesn't work well with garbage collection, but I wouldn't think PDFKit was among them. Anyway, the solution might be to not use garbage collection. Perhaps you should file a bug report with Apple.
keep PDFSelection *selection as a member variable and pass it in fromSelection: instead of nil.
It is possible that PDFDocument keeps the returned PDFSelection instance to improve the performance.
Did you try retaining the searchview stringvalue object before using it?
As you say it happens when you type fast and it happens for async calls, it is possible that the object stringValue is pointing to is being released between the time your query object is pointing to it, and the time you use it int the search.
You could try something like this to see if the problem persists:
- (IBAction) search:(id)id
{
NSString *query = [[self.searchView stringValue] retain]; // get from textfield
selection = [document findString: query fromSelection:NULL withOptions:NSCaseInsensitiveSearch];
if (selection != nil)
{
[self.pdfView setCurrentSelection:selection];
[self.pdfView scrollSelectionToVisible:self.searchView];
}
[query release];
}
Of course there is also the possibility that document is relased. How do you declare it? is it a property with retain? Can it be released by the time you are searching?
EDIT:
I see that you posted the code with the second parameter as NULL, but in your screenshot, this value is nil.
The documentation says you should use NULL when you want to start the search from the beginning.
http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/QuartzFramework/Classes/PDFDocument_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40003873-RH2-DontLinkElementID_1
And as the compiler interprets nil and NULL differently, this could be leading to some weird behavior internally.
I am sure this question has been asked before, but I searched and couldn't find it so I apologize in advance for duplicating content here on SO.
That being said: In Objective-C, in an overridden method you can call the parent class method using something like [super methodName]
but how do prevent the rest of the code from executing in the child class from the parent? It could because it's Friday, but I stared at my monitor for a few minutes and couldn't get past it in my head.
Example (in child class):
- (void)methodName
{
[super methodName];
//Everything below this line shouldn't execute if tell it not to from the parent
NSString *aString = #"This should never be called.";
}
Help me out! I know there's a simple solution, but my brain just isn't picking it up today...
You could maybe have another function returning True/False which you use to decide if you wanna proceed with the remaining code in the child. This 'control' function can depend on a variable set in the parent class
Having said that, it sounds like an interesting requirement to me. Maybe you need to take another look at your class design and hierarchy.
you could test the object type and determine if you do or don't want to run additional code for example:
if (![myObject isKindOfClass:[MyChildObject class]]
{
//run only superclass code
}
As I write this, I can't help but wonder if you don't have some issue with how you setup your classes though. If your design is spot on, you shouldn't have to go through these kinds of contortions.