With Appledoc + Jenkins it is fabulously easy to have your documentation be automatically generated and uploaded to a documentation site. Let me give you a quick guided tour about the individual parts of our setup. The final result you can admire on our new Cocoanetics Documentation Site.
You probably now how to add static test cases to a SenTestingKit-based unit test. You create a subclass of SenTestCase and add instance methods with their names prefixed with “test”.
When the unit test runs it builds the test classes and then introspects each one to dynamically find all such named instance methods. Those are then executed one after the other.
Usually you get by with this technique but there might be scenarios where you would want to be able to dynamically add test methods based on some external information, like a property list. Let me show you how.
I remember a long time ago when CPUs still had only a single core and the chip manufacturers where racing for getting the highest Gigahertz. Then some technical limit was reached they shifted their philosophy to increasing the number of CPU cores. The unfortunate side-effect of this approach is that we developers need to adapt our code to make use of these multiple cores or else our CPU-intensive code will find a bottle neck in being only able to max out one core.
The reason of this was mostly grounded in some smart using of multiple GCD queues. In this blog post I shall explore how we can get DTCoreText to also make use of all available CPU cores.
The worst thing you can do if you are using somebody else’s code is to complain to them via email about the shortcomings of their software. More often than not you can assume that the Open Source code this person put online is a labor of love. And complaining is as close as you can get to trampling on the other person’s feelings about their “baby”.
Hobbyists and Pros alike, you are a developer and if you have any interest in getting improvements for the other person’s software then you should adhere to these simple steps I am laying out for you to follow. This is specific to DTCoreText, but I am certain that the basic principles apply to any other project as well.
Apple keeps working on making Xcode more stable all the time. While Xcode 4.6 has much improved in terms of simply quitting on you, people report that more often now they see Xcode just hang.
One method to deal with race conditions in a highly parallelized application like Xcode is to add semaphores and locking. Unfortunately locking is not the end-all of all all Xcode problems, even with a liberal sprinkling. A blocked main thread is a blocked main thread.
Here is what you should do next time you encounter the beach ball of doom.
Over the the past few days we’ve been chasing an elusive bug that was testing the limits of our sanity. We repeated the following conversation about 3 times:
“Hey, we did some changes. The jumping views should not occur any more. We didn’t see it even after 2 hours of testing”
“I’m still getting it, right after launching the app.”
“&”§%, $%&% &!”
I would bet that this happened to you to, especially when working with background queues for updating some data and then updating UI to reflect the new information.
Similar to “did you reboot your PC?” being the standard answer to 99% of Windows problems, we iOS developers found that “are you maybe calling UIView methods on a background thread?” solves the Lion-share of problems with views. Here’s a convenient way how you can quickly find these elusive issues too.
The updated linker and libtool that come with Xcode 4.6 apparently contain some changes that are causing problem when building projects that link and depend on static libraries. One appears to be a bug, the other is an annoyance. Fortunately we found workarounds for both.
Update: Not a bug after all. Rather a “learning experience”. Details below.
Here are three small pieces that I discovered while working on my second major Mac app. It’s for internal use by a client, so I cannot tell you about it, but it is a great place for me to learn more about the various oddities you find when developing for the Mac platform.
If you use CoreData then you will probably face the problem of database migration sooner or later. Automatic migration is turned on easily, but how can you be reasonably sure that your fresh app update will still be able to open databases using the old schema? Like when people were using the app and are now installing your update that needs more entities.
We were beginning to face this scenario in multiple apps, so we started unit testing CoreData automatic migrations like I’m going to show in this article.
There are a few trailblazing developers out there who intentionally set their app’s deployment target to iOS 6. When dealing with open source libraries like DTCoreText this might give you a fair share of deprecation warnings. But there is also another problem caused by this that library vendors need to address.
The SDK used should always be the Latest iOS, but the Deployment Target setting tells the compiler and linker at what level of fanciness it can enable the turbo features.