Blog

When I recently did some programming while riding in the commute train, I added an new image view, added an outlet using the Assistant editor of Xcode 5 and started to test my program. All worked well, I added a few changes and had to hop off the train.

Some hours later I continued testing and was surprised to see a black window instead of my app. I could not remember what I had changed last time. Could it be, that I had made mistakes in the connection of the scenes? Did not look like so. Did I make a mistake in the code? No evidence for that.

Then I finally saw it:  Instead of putting the button to hidden, I had put my image view to hidden. I had connected the whole view,  instead of connecting the button only  – without noticing it. This meant, I had set the view that was meant to be the background to hidden and thus I had a black view into the endless dark black hole of the background behind the background.

When moving one of my projects to iOS 7, I had a strange effect: In this App, I needed a button, that had to change its size. In iOS 6 and Xcode 4.6.3 I had created a button in the interface editor and I could now change its size and always adjust its center as well. In iOS7, this was not possible, obviously because xcode or the run time system always generated a new constraint on how to lay out the button – although I had not given it any constraints. The default was obviously to always get the default constraints.

I experimented a little and came to no better conclusion than to do the button dynamically in the code. Worked perfectly and was possible with little effort as well. Seems, I still have to get used to the constraints system.

I was working on a project for quite a while, so the storyboard of that project was filled with 19 screen controllers. When the project moved from iOS 6 to iOS 7, we had some issues with autolayout, but we thought we had them all wiped out.
Then one day entering the storyboard in Xcode crashed Xcode V5.0.2. Of course I could have checked in version control which of the last versions would open without problems, but I went down another path.

I had saved the last versions of xcode (v5.0 and v4.6.2) and tried to open the storyboard with version 5.0, which worked. And since the message in the crash contained the word „cell“, I searched for cells by entering cell in the document outline view search bar (the list of all views and view controllers that you can view on the left hand of the storyboard itself).

While the first three table view cells where all OK, the fourth table view cell was in a table view with size zero (0) for height and width. Needless to say, that putting the sizes to zero had been Xcode’s idea, not ours. That zero size was probably the reason, I assumed, so I changed the size of the parent table view to something bigger than two times zero. And yes, this time Xcode 5.0.2. opened the storyboard file without problems.

Here is the error lines I had in my console output and in the crash report (for reference):

Details: Failed to compute auto layout status IBUILabel, IBUITableViewCell, and IBUITableViewCellContentView.
Reason: Any table view cell being added to a layout engine should be contained in a table view in order to get the correct metrics

Todays Surprise using NSMutableArray

I am programming in Objective-C for 4+ years now. And don’t get me counting, how many years have passed, since I programmed my first program in school. After that amount of time, surprises in programming are not that common any more for me. After so many years, you develop a gut feeling, what is safe programming and what is possibly not a good idea.

Today, I was reminded again, that it is a good idea to listen to your gut feeling. I was combining a loop through a collection of items together with an act of deleting one of the items. When I was programming it, my gut feeling told me, wait – this could be confusing for the array management (class) software. May be, it has a reference to an item and I am deleting it and this confuses everything.

So I checked the description of the class. I could not find any comments regarding that and went on.

A few days later however, after I had programmed it, I learned, that I had not looked up the documentation good enough. Somewhere in the documentation I found the hint: Deleting an element while enumerating it (running in a loop through all elements of that array) is potentially unsafe. The same applies to adding elements or replacing elements. So I needed to change my implementation.

I didn’t know what to feel. Should I be proud, because I had “felt it”? Should I feel stupid, programming it that way? Should I be upset, because it sure is possible (for Apple) to implement the array thing without these problems. But when programming, you have to make tradeoffs. This way, the more general case is surely faster.

So how did I do it? I changed my code to first collect all elements, that need to be deleted, in a second array and then, after the enumeration loop has finished, delete them all at once.

The alternative implementation is a good idea as well: Make a copy of the collection, enumerate through the copy and modify the original.