Page 2 of 3
Apple has just announced Mountain Lion, the latest update to OS X, and it looks to have some interesting features. The main one I'm looking forward to is the addition of AirPlay to the Mac. I love being able to stream video from the iPhone to the Apple TV. It's really handy for the iTunes U lectures. However for normal videos that I have on the Mac, it's annoying to have to convert them via Air Video Server on the Mac and then use Air Video on the iPhone to get them to display on the Apple TV. Having AirPlay on the Mac stream directly to the Apple TV will be very handy. According to the docs, it's just for streaming applications and presentations but perhaps they will open it up to interactive applications in future. I wonder what the latency would be like on this and if eventually it would be possible to play games via the Apple TV.
I'm finding that as I integrate more and more Apple devices into my setup, they all make each other work better. AirPlay is one example of this. Another is iTunes match which really starts to excel when you have multiple devices. Previously it was impossible to keep multiple iTunes in sync. It was a nightmare trying to add new music as it had to be added to each library separately. Now my music library is always in sync everywhere and when I add music to one library, it gets uploaded and is available on all others immediately. I haven't always been too impressed with Apple's cloud services (i.e. MobileMe was a bit of a disaster) but they've got it right with iTunes Match.
→ posted on February 22, 2012apple
In a previous post, I described how I got code coverage up and running in Xcode 4.2. Apple have just released Xcode 4.3 and unfortunatly updating to this has broken my code coverage. The reason is that 4.3 removes the /Developer folder and moves this internally to the Xcode.app package. While this has good consequences - it should be possible to update Xcode from the App Store like a normal app - unfortunately it has also removed the libprofile_rt library from /Developer/usr/lib. I haven't been able to find a new version of this library in Xcode 4.3. When I tried using the version from 4.2, I got "mach-o but wrong architecture" errors.
This means that when building my unit tests with Coverage I get link errors saying that I am missing llvmgcda functions (llvmgcdastartfile, llvmgcdaincrementindirectcounter, llvmgcdaemitfunction, llvmgcdaemitarcs). I searched on Google to try and find a solution for 4.3 but it seemed all solutions were for 4.2 so I needed to try to solve this myself. The solution I came up with is fairly hacky. I'm hoping that as more people upgrade to 4.3, a better solution will be found and I can switch to that.
My solution is to take the actual file which contained the gcda functions in libprofile_rt, add it to my own source code and compile it myself. The file in question can be found on llvm.org - here. To get it to build locally I deleted the win32 and sys includes (lines 27 to 31 inclusive) and replaced the llvm include (line 23) with #include "stdint.h". This builds fine using the Coverage build configuration and outputs the same gcda and gcno files as before. To make sure that this code doesn't end up in the released project by accident, I've included it in the unit test bundle rather than the app bundle. This is fine for me as I only need coverage when running the tests anyway.
Update: Some feedback from Tom Black, who emailed me to point out that libprofile_rt can be found in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/
However this library did not work for either of us. Instead we got errors like
The bundle “GCUtilsTests.octest” couldn’t be loaded because it is damaged or missing necessary resources.
Library not loaded: @executable_path ... libprofile_rt.dylib
Reason: image not found
Also this library didn't produce .gcda files but instead generated .dia files which didn't work in Coverflow.
What worked for Tom, but not for me, was not to include libprofile at all. This removed these errors and another incompatible binary error. Now however he got the following error.
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
fopen$UNIX2003 called from function llvm_gcda_start_file
He found the solution to this issue here. I still got link errors when I followed this though so I need to stick with my original solution.
Update: Another commenter Rajiv emailed me to say that creating a new target for his project made the coverage work for him. It generated the .gcda and .gcno files when he exited using exit(0). I've tried creating a new simple iOS app and I don't get any errors for this when I enable coverage.
One thing which might explain why it still doesn't work for some of my projects is the type of project being built. My original project was a static library. I tried to create a new static library project and when I try to enable coverage I get the same link errors as above.
→ posted on February 21, 2012development
Apple has posted a new guide to iOS development which ties together all the various strands of creating an app. (via Loop Insight). Looks really nice.
→ posted on February 18, 2012development
If you are going to the effort of having unit tests, then you really need to have code coverage. This will allow you to ensure that your tests are exercising all your code. It is really easy to spot a missing test when you see a branch of an if-else with no coverage. Code coverage for me is also a way to motivate myself to implement the tests. It's like high scores in games - it gives me a target to aim for. Coverage gives feedback that your tests are actually doing something, and with each test you add, you can see the areas of untested code steadily decrease.
To set up code coverage in Xcode 4.2 I used the guide on these blogs - Infinite Loop and Matt Rajca. Originally only the gcc compiler was supported but since then the Clang compiler has had code coverage enabled. This is important as we need to use Clang for ARC and static analysis among other things.
XCode Build Settings
Xcode has the concept of build configurations which can have built settings altered independently of each other. The two default configurations are Debug and Release. We want to add a new configuration named Coverage. To do this duplicate the Debug configuration.
{% img /images/codeCoverage/NewBuildConfig.png New Build Configuration %}
In order to specify different settings for configurations in Xcode, hover over the left hand margin directly to the left of the setting we wish to update. An arrow will appear which when clicked will expand to an additional three lines for Debug, Coverage and Release. Editing the top line will alter the setting for all versions. Altering either of the new lines will only update the setting for that version of the build.
{% img /images/codeCoverage/BuildSettings.png Build Settings %}
Executing Tests
Now your unit tests should run and if you examine the build output files under the DerivedData folder you should find .gcda and .gcno coverage files along with your .o files. To find this folder you can go to the Projects tab in the Organizer and select your project. The path to the Derived Data folder is listed here along with an arrow which will open the folder in the Finder.
{% img /images/codeCoverage/DerivedData.png Derived Data %}
From here the path to the coverage files is Build/Intermediates/${Project Target}.build/Coverage-iphonesimulator/${Project Target}.build/Objects-normal/i386. Replace ${Project Target} with the name of your project target.
Viewing Coverage Data
To view the coverage data I used CoverStory. Simply open the app and point it at the coverage folder. This will give a nice two pane display showing your files on the left and an editor which shows how often each line of code was hit. Now you can identify untested code and add new tests to cover them.
→ posted on February 17, 2012development
I've decided to switch the blog from Wordpress.com to an Octopress site hosted on Github Pages. From now on there will be no more new posts on Wordpress. I've also registered the domain gerardcondon.com and will be using this address for the blog in future.
I have a few reasons for switching
I found Wordpress.com to be an excellent site in general. When starting off it was very easy to create and get the blog up and running. However you have to use their site to create your posts. Even if you use a text editor you still ultimately have to paste the post into their site, and all subsequent edits have to be done through Wordpress.com. Also the definitive version of the posts are stored in their database.
I prefer to write my documents in plain text files using a markup language. Previously I've used Latex and more recently I've started using Markdown. This has a number of advantages, namely the files can be edited in any editor on any platform and they work very well with source control. Also by separating the content from the typesetting phase, I find that you concentrate better on the actual writing. I hate having to wrestle with formatting in Word; I much prefer leaving that to a program. Donald Knuth & Co. have forgotten more about typesetting than I will ever know.
Wordpress.com doesn't support Markdown so posting involved an extra step of converting the Markdown to HTML. This meant that I had two versions of the blog. One in Markdown on my local machine and another in HTML on Wordpress. For me, it's an axiom that whenever you have two versions of the same data, they will get out of sync. One needs to be the main source. I wanted the local Markdown version to be the canonical version of the site and everything else derived from that.
I think the default Octopress theme looks really good (I really like the Archive page). I first noticed it on Matt Gemmell's site and was impressed by how it looked. It also looks well on mobile sites. I have full control of the css using Octopress so I can tweak whatever I want. I liked the Titan theme on Wordpress except I hated the crosses using for lists. On Wordpress.com there was no way to change these. However on Octopress I make any kind of style update.
I realised that I should get my own domain name instead of using the Wordpress.com address. In future if I need to move my site I can just redirect the domain name and any old links will still work. Whereas I will never own or control the gerardcondon.wordpress.com links. It's better to move now, rather than after I create lots of content at a non portable url. Start as you mean to go on.
The posting workflow is much better now. I write my posts in Markdown on the Mac or on iOS via WriteRoom. Then I run a command from the terminal to regenerate the site and deploy it to Github. Edits work in the same way. The Markdown files also get committed to Github ensuring that no matter where I move the blog in future I will always have the content in an accessible file format.
I'll add a few posts in future on how I got Octopress, Github and my domain all set up and working together.
→ posted on February 16, 2012octopress
Wherever possible I think that automating your testing is essential. For this project there is no way that I can manually rerun the same tests over and over again - the time commitment is just too much. I need to be able to click a button and have a framework run all my tests automatically and report back to me the number of tests passing, failing etc. I know that this won't catch all the bugs in the code and that I'll still need to do some manual testing for each release. However, the more I can push into this automated testing, the more time I'll save on the manual testing later.
Based on my previous post I've mentally divided up the code into different layers which build on top of each other. The app GUI is one layer. Then we have the model classes which in turn depend on utility classes etc. These different levels of code require different levels of testing.
For the utility and model layers I plan to use an automated unit testing framework such as JUnit. Xcode provides OCUnit which is a JUnit like framework for implementing unit tests. This framework provides the usual fail and assert macros and functions. There are some annoying things about running unit tests in Xcode. One is that it doesn't have a separate test runner panel like JUnit has in Eclipse. Instead it treats the unit test errors as build failures. All the print output for the tests is dumped into the same console output which can make it tricky to identify which output is for which test. Also there is no way to selectively run these tests. You have to rerun them all together every time. There are other frameworks out there e.g. GHUnit but for the moment I'll stick with the default.
For the higher level GUI code, unit testing is not useful so I'll need a different testing approach and toolset. There seem to be number of options out there. I'm not sure what is available and what is the best to use. Apple have an Instruments application which allows you do perform UI testing using Javascript. I've also seen these Frank and Zucchini frameworks. I haven't evaluated any of these yet as I don't have a fully functional app to test it on. Once I get a nearly complete app I can see how much my unit testing provides, compare that to what I have left to test, and then make a judgement on where to go from there.
→ posted on February 13, 2012development
Up to now my approach to unit testing has been dictated by who I was writing the code for. For instance in college I never wrote unit tests. In the real world some of my employers required unit testing, with certain branch and code coverage goals, while other employers didn’t require much in the way of unit testing, as long as other types of testing were carried out. In practice I found that the as the code became more lower level, the demands for unit tests increased.
For this project I need to define for myself what level of testing I will perform. My initial assumption was that of course I would do unit testing. Personally I thought that the benefits of unit testing were
However I read an interesting and thought provoking article by Will Shipley outlining why he doesn’t do unit testing. My immediate reaction was astonishment. How can you not have unit tests? However instead of unit tests, he beta tests the product. This finds the type of bugs that the actual end users will find. Also he writes his code in a manner that doesn’t require unit tests.
My programming philosophy is “less code is better code.” Unit tests take a lot of code, and in my projects I don’t find that they find very many bugs. Part of this is because I tend not to modify my individual methods much once they’ve been written; if my “append string to string” method works, it’s really not going to get revisited anytime soon unless it has a bug. Part of it is because, in fact, I do do integrated testing of a form, and I probably should have talked about that more. Yes, I use “NSAssert” all over the place, and I perform sanity checks and raise errors if there’s a problem.
I don’t think I’ve come across “Not modifying methods once they are written” before but looking at it now it makes sense. By not changing existing working methods and treating them as black boxes, we should have fewer regression errors in future. I’m not sure how to reconcile this with refactoring though - it’s something to think about. I’d imagine a coding style that favours smaller, more focused methods would be more suited to this approach.
His use of sanity checks and asserts also struck a chord especially when he says
Debugging most errors, once found, should take very little time in a properly-written program, because the error should always be from one of your own sanity checks, and you know where those are in the code, so you just go there and figure out what went wrong.
This was eye-opening for me. I’ve never tracked this before so I’m not sure if the bugs I’ve written have evaded my sanity checks and asserts. I would imagine a lot of them did. I’d never have seen that as important before but looking at it now it seems to me that this is a failure on my behalf. Not catching these errors means that I’m not fully aware of how my code can go wrong and what it is doing in all cases. I think a useful analysis I should run on each bug I find is - did this escape my coding checks/asserts and if so why? I should learn from this and in future code should check for this condition.
In a response to Will’s article, a follow up post by bbum shows how unit testing was of great benefit on infrastructure code, in this case the Core Data library. This would suggest to me that the utility and model code would be amenable to unit testing but that it’s not useful for the GUI code.
Another article on codeville challenged my assumptions that unit tests were about finding bugs. Instead the type of testing that finds bugs is manual testing or automated integration testing. According to him, unit testing is not about finding bugs (except during refactoring) but more about designing robust software components.
TDD is a design process, not a testing process. TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests Also it’s not enough to just write unit tests. The tests need to be either true unit tests which design a single component or else integration tests which automate the entire system. Anything in between are dirty hybrids. Unclear goal. High maintenance, don’t prove much Otherwise when we refactor code, we end up breaking lots of seemingly unrelated hybrid tests. If you change a unit, then its unit tests should change but no other unit tests should.
After all that I’ve decided that I want to do some level of unit testing but I realize that I need to focus it on the right areas. I think it will be useful for the utility type code that I write but that I need to do more research into how I want to implement integration testing and UI testing.
→ posted on February 10, 2012development
One of my favorite features of Objective C are categories. Categories allow you to add your own functionality to existing classes without the need for inheritance. You don't even need the source code of the modified class. You are only allowed add extra methods or modify existing methods. Adding extra instance variables is not permitted. This feature is generally known as monkey patching (what a great name!) in languages such as Ruby.
Creating a category is straightforward. The interface and implementation files look the same as normal interface and implementation files except the category name is placed in brackets after the name of the class we are extending. For example to create a category MyCategory on MyClass the interface file looks like
#import "MyClass.h"
@interface MyClass (MyCategory)
// Declare Methods here
@end
and the implementation like this
#import "MyClass+MyCategory.h"
@implementation MyClass (MyCategory)
// Implement methods here
@end
The standard naming convention for category files is ClassToExtend+Category.(h|m). So for the above we would have both MyClass+MyCategory.h and MyClass+MyCategory.m files. The header file needs to be imported in any file that uses the category. For common extensions we can place them in the precompiled header (pch) files.
This has a number of applications. It allows you to add methods to classes (or indeed to alter existing methods) instead of having to create utility classes comprised of static methods. Thus the code is more clearly associated with the class to which it belongs. It allows you to create object-oriented code that favours composition over inheritance.
To give a concrete example, for my current project I wanted to be able to shuffle an array. Instead of having to create a ShuffleableArray subclass or implement an ArrayUtils.shuffle helper method, I was able to add a shuffle method to the NSArray type via a category.
Not only does the class to which you add the category get the new method, but all its subclasses gain the method also. This can be very useful if you are extending a class high up in the hierarchy. For example, another use I made of categories was to add debug methods to the UIView class e.g. to print data about itself and its subviews. Given that lots of the UI widget classes extend UIView this means that everything on screen got my new methods. I find trace methods like these very useful during unit testing and debugging. I tend to prefer adding print code where possible rather than step through the debugger, and for that case the ability to add functionality to existing classes is invaluable.
Naturally like all programming language features categories can be greatly abused. Changing the behaviour of existing functions can break code which assumes the older behaviour. I'd imaging this would be especially so with system classes such as NSArray etc. However done right, they look like a very useful feature which I'm sure I'll use a great deal.
→ posted on February 4, 2012development
Apple have just released the iTunes U app. I think this has gotten a little lost compared to the attention on the new iBooks Author and its EULA. The iTunes U app looks to be an excellent app which puts some structure on the courses that were available through iTunes. Now you can watch the videos on your iPhone and iPad, and also download the slides to them. You can also use AirPlay to stream the videos to an Apple TV and the app will sync the progress of the course between devices.
The course I am currently looking at is the Stanford iOS Programming course. I've only seen the first few lectures but they are of excellent quality. There are about thirty of these new iTunes U courses at present but more should be added in the future.
While the talk was that the iBooks authoring app would revolutionize textbooks, I'm hopeful that the iTunes U app will do something similar for adult education. I've taken a few evening photography courses locally. These were great for me as a beginner but moving beyond that, it would be great to be able to subscribe to courses given by professionals. Remote learning can offer a wider range of courses than could ever be offered here in Cork. Courses that would be impractical to run locally due to small audiences don't face that problem online. Imagine if you could subscribe to a landscape photography course with lectures by a series of landscape photographers. Or Portrait. Or Sports etc. And this would all come with slides that could be viewed afterwards at any time to refresh the memory.
Currently I'm looking into Graphic Design as I will need to create graphics for my app and I would like to do a course in this. However any real life courses would most likely not be suitable for me. I would need them to run in the evenings after work. Also I want a course that assumes I have lots of experience with computers. However what I'm more likely to find is a full time course aimed at school leavers which assumes no previous software experience. Remote learning offers the potential that multiple courses can be recorded, each aimed at different levels of experience. I could choose the one more suited to my circumstances and the scheduling would now not be an issue as I can do the course in my own free time.
It's still early days but as more and more institutions put their courses up on iTunes U, I hope we start to see them not just put up their existing courses, but instead think about how they create and tailor courses for a wider audience. Although I'm not sure how likely that will be as currently the app doesn't allow for paid courses. Still the free content is more than enough for the time being and I'll look forward to see where iTunes U can go in the future.
Update: Just to clarify. The iTunes U app is separate from the desktop iTunes application. You can just download the iTunes U app on your device and never have to go near iTunes.
→ posted on January 29, 2012development
One thing about Objective C that struck me is the amount of boiler plate code that needs to be written for variables and methods. Ideally Xcode would handle all this but unfortunately it doesn't.
An app I found to solve this problem is Accessorizer. It can generate interface and implementation for properties plus a whole range of other code (all that KVO and coding stuff that I haven't looked into yet). It's only 4 euro on the Mac App Store and it's well worth it. There are some videos tutorials on the site which show you how much can be done with the program.
→ posted on January 27, 2012development