Code Coverage is described on Wikipedia as:
… a measure used to describe the degree to which the source code of a program is tested by a particular test suite. A program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage.
Less bugs? Yes, please!
When implementing iOS 7 support for a client’s app I got a result that might stump even seasoned Cocoa programmers.
On iOS 7 views generally go behind translucent bars. To still get your views aligned correctly – when creating them in code – you have to get the responsible view controller’s top and bottom layout guides.
Those get set sometime before viewWillLayoutSubviews and I found it useful to add a viewInset property to the view controller’s base view. Setting this would setNeedsLayout and then you can rearrange the subviews according to the new insets in layoutSubviews.
The following issue is a head scratcher if you are trying to add unit tests to your project that both run on Mac and iOS. And if you like to use the new inline buttons for executing individual tests.
Filed as rdar://15085316 and Open Radar. The mentioned sample project is the UnitTestTest sample on our Radar Samples GitHub repo.
I’m seeing this issue on my main phone after having begun to use the iOS 7 GM on it.
Filed as rdar://15056186 and on Open Radar.
Following the public availability of iOS 7 and having collected a good amount of fixes, I felt that it is a good time to release the next maintenance update to DTCoreText.
All the while during the iOS 7 BETA phase I’ve been filing Radars and produced samples to go with them to demonstrate the issue to Apple engineers. I wasn’t allowed to blog about these until the general release of iOS 7 and so I kept collecting them in a special folder on my dropbox.
Now that iOS 7 is out I am able to add the samples to my public Radar Samples repo on GitHub. I hope that they can be a good example of how to create samples that allow Apple engineers to quickly reproduce and debug those issues.
More than 3 million people use MailChimp to design and send email marketing campaigns. And today they launched a native iPad client that lets you create and edit such campaigns. For the parts of that which require rich text editing they rely on our DTRichTextEditor component.
Apple recently added the ability for Xcode to automatically create instance variables for you. This means you no longer need to add an @synthesize for each property you create.
But does it really do that always, or are there scenarios where no _ivar is needed? Are there situations wehre you do need an explicit synthesis? For example what about properties which are just passing through values to a sub-object?
I wanted to know, so I experimented a bit. I even filed a Radar with Apple for clarification which came back with a good explanation.
If you have an project that is accepting code contributions then you will want to make sure that those well-meaning additions don’t break existing functionality. Services like GitHub allow you to review such pull requests via their colored diffs or even give instructions as to how to manually pull the commits into a local branch for evaluating this.
But there is a limit that is quickly being reached if you need to check all those pull requests manually. Even worse, this is a mundane task, usually trying out if the targets build and running the unit tests. Repetitive tasks like this are boring and thus nobody can be faulted for starting to neglect them.
In this blog post I will explain how to set up Travis-CI to have all pull requests be automatically checked for you. You will know for each pull request if merging it into your develop branch would break the build or unit tested functionality.
License:
