Oct 01, 2012
Notice: The following text is a rant and entirely my own opinion, not being a lawyer by profession, but a developer at heart.
Over the past month or so I was negotiating with a US-based company who wanted to retain my services as an expert on Rich Text and HTML parsing. Let me share a problem I had with a certain section in the contract that I was asked to sign, a problem that related to my previously created code and for-pay components.
Even experienced developers might be overly anxious to sign their next big contract to put food on the table without knowing what rights in their works they are signing over by this. This should serve as a gentle reminder: Better to read through the contract, all 19 pages of it, than having to be afraid that you inadvertently giving away your crown jewels.
If I learned one thing from Steve Jobs then it is to not trust contracts that are longer than a single page …
Sep 30, 2012
One of the first lucky owners of the iPhone 5, David Smith, kindly ran my Image Decompression Benchmark on the latest 3 generations of iPhone. These benchmarks measure the time it takes for an image to get from disk to screen and encompass 5 resolutions, PNG crushed and uncrushed, as well as 10 compression levels of JPEG. Christian Pfandler prepared the charts for us.
We like to repeat the same benchmarks on every new CPU that Apple likes to solder into their devices, you can read past analyses iPhone 3G through iPad 2, iPad 3. One note of caution if you want to compare these to the results in this article, we changed the methodology of logging the times from NSLog to CFAbsoluteTime. NSLog itself takes up to 50 ms per logged statement. The new method is more exact and does not have this drawback of including the logging time in the measurements.
Executive Summary: the iPhone 5 can indeed be claimed to be twice as the predecessor.
Sep 30, 2012
Hot on the heels of my research into the responder chain comes this bug report. Nikita Korchagin deserves the main credit for mentioning this first to me.
Turns out that Apple broke the responder chain as it used to work on Mac and non-storyboard apps. I’m filing this as a bug report to find out if this indeed a bug or an “undocumented feature”. rdar://12402078
Update Oct 5th: Apple closed this as suplicate of rdar://12395544
Sep 29, 2012
Do you remember, back when you first opened Interface Builder?
How long did it take you to understand the purpose of File’s Owner?
That is a proxy for the object that loads this NIB, usually a UIViewController. This allows you to connect IBOutlets and IBActions with elements contained in the NIB file. IB knows about these because you tell it what class the File’s Owner has and from parsing this class’ header it finds all things that you can connect to by the IBOutlet and IBAction keyword.
That one was easy. Second question: How long did it take you to understand the purpose of First Responder?
If you are like me then you started out developing for the iPhone and other iOS devices. And then you probably also learned to ignore this proxy object because on iOS it does not serve an obvious purpose. In fact you can go for years developing iOS apps without ever doing anything with it. I know I did.
It is only know that I am starting to dabble in developing for the Mac that I had to begin to develop and appreciation for the responder chain. And so finally I understand the purpose and usefulness of the “First Responder” object and I want to share this with you.
Sep 28, 2012
… no, were not talking about the kind of fun that burns when taking a leak. In this article I want to summarize what I learned over the past weeks about working with Universal Type Identifiers.
On Windows files where always only identified by their file extension. In the olden days Apple was using multiple additional methods of determining what to do with certain files, amongst them HFS codes and MIME types.
The modern way to deal with file types is to use UTIs which are typically a reverse domain name, like “public.html” for a generic HTML file or ”com.adobe.pdf” by the PDF type created by Adobe. UTIs have an additional advantage that other methods of identifying types do not possess: a file can actually possess multiple types.
Sep 24, 2012
This is one of those rare jewels of a bug that will cost you days to figure out if you encounter it in the context of a large app. It makes you doubt our own sanity until you come to the painful conclusion that the problem indeed resides in Apple’s code, not yours.
In this special case we had a couple of rare circumstances that worked together to form a scenario where CGRectMakeWithDictionaryRepresentation partially fails to reconstitute a CGRect from a dictionary. This function is literally ancient, it exists since iOS 2 and Mac OS 10.5. This makes it even more implausible that nobody has stumbled across this before us.
In the project where we first saw the problem these where the steps that led to this bug’s discovery:
- Create a CGRect that is not an integer
- Write a dictionary from iOS simulator which contains a dictionary encoding this CGRect
- Open this dictionary in Xcode’s property list editor
- Upon saving some of the least significant digits change in the “real” items
- This new dictionary can no longer be parsed on iOS
What’s even funnier is that some such modified values can still be read, but then the function fails internally and the remaining values don’t get parsed, i.e. stay zero.
From what I have seen researching this bug looks like certain floating point numbers cannot be represented on iOS. The normal parsing functions are able to round to the closest value that can be represented in 32-bit floats, whereas CGRectMakeWithDictionaryRepresentation fails to do so. The first value that cannot be exactly represented is truncated, all following values turn out to be Zero.
This was filed as rdar://12358120 and on OpenRadar.
Sep 22, 2012
I made some updates recently that I wanted to mention so as to minimize some surprises. Also there are some changes that were prompted by iOS 6 being released.
Sep 21, 2012
The great thing about building apps for both iOS and Mac is that many pieces of code work just the same on both platforms. There are some scenarios however where you want to add different kinds of Apple SDKs based on which platform you are building for.
A good place to put all headers that often used is the Precompiled Header File (PCH) which gets precompiled and then reused throughout your app. Whenever you have an #import statement in your code the compiler needs to figure out whether this header has already been imported because the same header file can potentially be imported from several locations.
I generally like to put all imports for Apple headers into my PCH file as well as my own app-wide classes like my DTFoundation library which has a growing selection of methods that I frequently use. Having these imports in the PCH means that the preprocessor can prepare them for faster compiling once and then can virtually prepend all these definitions for every source code file.
Today I learned something new, namely how you can use the same PCH for Mac as well as iOS.
Sep 20, 2012
In the first part of this series we started out by setting up the document type and export the UTI for the system to know about it. We also implemented methods to read the index from a file wrapper as well as persisting it to a new one. These steps where sufficient that we ended up with all the file manipulation candy (reverting to earlier versions, new doc, etc.) functional.
I promised that we would get go something more interesting today. We’ll be wiring up an NSCollectionView to show thumbnails and names of our images contained in shoebox documents. Then we need to dive into pasteboard as well drag-and-drop functionality to be able to manipulate those shoebox images. We want to be able to drag images from Desktop into shoeboxes and – time permitting – also be able to change their order by dragging as well.
Please let me know if this kind of tutorial is of interest to you by using the Flattr button and/or sharing it in your favorite social network.