And you do not get this error when you implement this method like this:
So why does the stubbing of this method create this error?
The reason is, that the implemented method does know it’s return type, so the 4 will automatically be typed to NSInteger. Which means that it will be of type int on 32-bit architectures and of type long on 64-bit architectures.
OCMock on the other hand has no idea what the return type of the 4 should be. It just sees the 4 and assumes that it is of type int. Regardless of the architecture. So when running this this on a 64-bit device you will get this error, because the stubbed method is supposed to return a long.
The fix for this is quite easy. You just have to be clear about the type of the value that your stub should return:
One of the new operators that comes with Swift is the Nil Coalescing Operator. In the documentation it is explained as: The nil coalescing operator (a ?? b) unwraps an optional a if it contains a value, or returns a default value b if a is nil.
This operator already exited in C but for Objective-C developers it is kind of new (more about that at the bottom of this post).
With this operator assigning values to a property with a fallback to a default value becomes really concise:
Instead of doing this:
You can simply do this:
Pretty cool, isn’t it?
Actually something like this was already possible with Objective C:
To check if a customer has selected a certain feature you use the bitwise AND operarator (&):
// user has selected navigation system
Now there might be a situation where you want to remove a feature from the bitmask of selected options. In my simple example that might be the case when a user selects the option FeatureConvertible. If the customers does that, you might want to make sure that the feature FeatureSunRoof is not selected (because obviously a convertible does not have a roof).
So you want to remove the option FeatureSunRoof from the selected options while leaving the rest of the selected options as they were. This is where our friend the bitwise NOT operator (~) comes into play:
This removes the FeatureSunRoof from the selectedFeatures bitmask.
During my current project I had to move a time consuming CoreData operation to a background thread to avoid a frozen UI. After reading some horror stories about using CoreData on a background thread I was actually surprised how straight forward it was. I used Apple’s sample code ThreadedCoreData as a guidance. When I tested my changes everything went smooth. Until I started to touch my app’s UI while the background process was running. Suddenly the app crashed and the following exception was thrown:
***Terminating app due touncaught exception'NSGenericException',<br>reason:'*** Collection <__NSCFSet: 0x1f0ec200> was mutated while<br>being enumerated.'
The exception was being thrown on the background thread during a call to
In Apple’s example code the CoreData operations happen inside the main method of a custom subclass of NSOperation. That subclass is initialized using a custom initWithData: method and then added to a NSOperationQueue.
When doing CoreData operations on a background thread it is important that the background thread uses it’s own instance of NSManagedObjectContext. And this NSManagedObjectContext has to be instantiated on the background thread.
And that was the problem.
In Apple’s example the NSManagedObjectContext for the background thread is instantiated in the custom initWithData: method of the custom ParseOperation class. But that method is called on the main thread when instantiating a new ParseOperation object before adding it to the NSOperationQueue. So the NSManagedObjectContext instance is created on the main thread!
The solution was quite simple:
After moving the code that instantiates the NSManagedObjectContext from the initWithData: method (called from the main thread) to the main method (called from the background thread), the problem vanished and the code run smoothly.
So, when using CoreData in a background thread make sure that the background thread has it’s own NSManagedObjectContext instance that was created on the background thread!
I really like the plist format. Being able to transform a plist file into a NSDictionary with one line of code really appeals to the lazy guy in me. So when our backend developer asked me what my preferred format for server responses would be, I told him to send his responses in plist format. That’s when I came across a little problem: When accessing the response body of the request, all I got was a NSString. The string contained the plist, but it was still a string and not the usual XML structure that you normally get when you open a plist file.
Recently I had to use NSDecimalNumber objects to avoid the rounding errors that come with float values. While comparing two float values is as easy as it gets comparing two NSDecimalNumbers works a bit different:
NSDecimalNumber is a subclass of NSNumber so you have to use NSNumber’s compare: method to compare the values:
This function gets called as soon as the HTML document is fully rendered. It puts the height into an URL and sends a request with this URL.
2. Intercept the request in the UIWebView’s delegate
A UIWebViewDelegate has a method, that get’s called everytime the HTML inside the UIWebView sends a request. Here’s what to do in this method:
Return NO to stop the UIWebView from trying to load the request. Don’t forget to return YES for all other requests or the HTML content won’t even get loaded into the UIWebView in the first place.
Because I often need to convert a hex string (e.g. from a parsed XML file) to an UIColor I added 2 methods to this category. You can now get an UIColor from a hexadecimal uint value or an NSString that can have the 3 following formats: “0xFFFFFF“, “#FFFFFF” or “FFFFFF“.
Just add this category to your project and you can use it like this:
Of course the cleanest thing to do would be to separate the html code completely from your Objective-C code by putting it into a separate HTML file and load that into a string. But hey, who wants to be perferct all the time?