CocoaPods is being under constant development, and as the zero as major version number suggests, it is still in unstable status. So you should only be mildly surprised if calling the pod command outputs that a newer version is available. Here are some tricks for updating.
A couple of months ago a publisher contacted me about writing a book. I have written a lot in my lifetime, blogging in general on my German-language personal blog and later on my Cocoa development blog Cocoanetics. But of course I’ve never written something spanning more than a couple of pages.
Like everybody who likes to write I’ve toyed with the idea, but not knowing about what is involved in creating a technical book I shied away from it. I was assuming that all those book authors have to take time off their normal jobs for writing. I couldn’t imagine exclusively writing for 6 months and not having time for my regular development interests.
But then there was this contact who took the time to walk me through the initial steps toward my first book contract.
Like most people I could get buy blissfully without dealing too much with Auto Layout. But there are layout-heavy scenarios where you start having the feeling that they might be much easier to solve using auto layout than by setting autoresizing masks (aka “struts and springs”).
One such example is the layout of controls in an inspector panel where I laid out the controls distanced from each other with layout constraints in Interface Builder. Architecture-wise I am using such an “inspector palette” in a DMInspectorPalette which gives me several collapsible sections. These are contained in a NSTabView (using DMTabBar as header) to get multiple inspectors laid out like in Xcode. And these are the right-most view in an NSSplitView to allow resizing of the inspector panel.
I was having some issues with that beginning with 10.9 which I’d like to document here.
The Cocoanaut asked on Twitter:
“Does anybody know what this error means? (compiled on a white MacBook with 10.7.5 and Xcode 4.6.3)”
He attached this screenshot:
I’ve been seeing this error quite often lately and so I’d like to document my answer for posteriority.
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.
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.
“I’m doing some Objective-C exercises from a Big Nerd Ranch book, and I’m getting these errors. I’m still pretty lost in terms of how to handle unexpected errors and stuff, so I would appreciate the help.”
I’m going into go into much greater depth here answering this question, because of “teaching a man to fish”, ya’know.
Amy Worall asks:
How do I centre an image in DTCoreText? I’m working with attributed strings not HTML. Any sample code?
In this blog post will answer this.
I was having a problem in DTCoreText where the multi-byte sequence making up an Emoji would not get properly encoded by DTHTMLWriter. A quick peeking into NSHTMLWriter didn’t bring relief either, Apple is not encoding these characters, but leaves them unencoded.