Sound debugging
I'd like to mention a trick I use often while debugging, a trick I learned from my good friend Markos Charatzas: triggering a sound when a breakpoint is hit. It's a pretty simple but useful trick, especially if you're debugging repeatable actions and you want to know when they happen.
I'm talking about this:
imageNamed: and multiple bundles
I've been working on a largeish project for a client for the last few months. We're have to modularized our code into several sections using CocoaPods (this is a post worth on itself, really).
One of the problems you encounter with this approach is that for each pod, CocoaPods creates a bundle with resources for that pod (at least it does so when you tell it to do that). It's the only good way to package pod resources into the main app. This means that our resources do not all live in the main bundle but in seperate bundles (which themselves do live in the main bundle). This is no problem in itself, but it can cause loading problems of resources in those bundles. It doesn't pose that much of an issue when you specify images in a nib since iOS will search in the nib's bundle too, but it's a bit harder to get resources from within your code
WWDC 2015 Predictions
That time of year again: june! Time for WWDC. A special WWDC: given my future plans, it'll be the last (in a while I guess) WWDC I'll be experiencing from the outside. So this is the perfect opportunity to do another predictions post. 😉
The Last NSConference
The last NSConference. I'm happy to say I was there. I'm sad to see it go.
I attended three editions of NSConf. The first one was in 2013: due to scheduling reasons, I couldn't attend WWDC and so I was on the lookout for a replacement. NSConf seemed to be it, and I bought a ticket. I had known about NSConf before (given I'm relatively new to the Cocoa community, having only started in 2011), but I never got around to going. But buying that ticket was one of the best decisions ever made.
Easy Revealing
I have a confession to make: I like Reveal. It's such a great tool to discover why your UI doesn't appear as it should be. It's such a great way to get a decent look at the view hierarchy in your iOS app.
Initially, loading Reveal required you to add the reveal framework to your project before running. While not a hassle, it was rather suboptimal because you had to remove it again before shipping the app.
But when you run your project in the simulator, there's an easier way. Have it automatically start up the Reveal server, so that you don't have to connect manually, and don't have to pollute your project with a debugging lib. Why only in the Simulator? Well, the technique requires the dynamic loading of libReveal.dylib. This is possible on your Mac but not on your iOS device. And the Simulator runs on your Mac, so we can use this trick to load the Reveal lib at runtime without prerequiring it in the project (to be fair, you can dynamically load libs on the device, but you'd still need to add them to your project).
So let's do that. First on: some LLDB tricks.
NSSpain 2014
So I did manage to go to NSSpain this year. Having missed it last year, I had vowed to go this year. But intentions don't always work out in the end, so it was a really last minute decision to actually go (props for my team at iCapps to deliver awesome results so that I actually could go - I am proud of you guys and girls!). Also, a very big thank you to Luis for helping me find a way to Logroño, which proved harder than expected (booking everything last minute doesn't help, of course).
I'm very happy to have actually attended. The suddenly changed circumstances before I left surely had an impact on my expierence. My thoughts and feelings were more at home than in Logroño, but I tried to make the best of it. Thought about "going back" several times, but I'm happy to have stayed. ;)
Now, enough with the emotionalism (is that even a word?), how was NSSpain?
Objective-C or Swift?
I've been planning to get on the iOS8 boat for a while now (well, since they announced it, actually). But as one with a full life, I haven't gotten around to actually do much. I played around with some Swift, watched some WWDC14 sessions but that's about it.
Until tonight: I want to start over again on Drash. There's a half baked iteration made for iOS7 (the current app runs still on iOS6 but feels right into place on iOS7 thanks to its minimal interface). But iOS8 changes so much again that I feel that it's best to start over again.
But then this begs the question: Objective-C or Swift?
There's some pro and cons to both, I think.
The setNeedsLayout pattern
For the project I'm working on we ran into a performance issue on iPhone4 where an interaction would lock up the phone for a few seconds. It ran fine on iPhone5 and in the Simulator, but there was a severe hangup in on the older device. Investigation in Instruments revealed to problem to be autolayout. A lot of time (>3 seconds) was spent recalculating layout.
So I first hunted for [view layoutIfNeeded] calls, replacing them by [view setNeedsLayout] where applicable (sometimes you actually want to layout immediately if you need to do more stuff based on the layout results, but this is rarely the case). To no real avail, the issue remained extremely slow.
Digging in further, I found that two different call trees were doing autolayout of a certain part of the screen at the same time. This was all happening on the main thread which explained the lockup (no surprises there though). But in the timespan of the 2 seconds Instruments reported where (the major part of the) lockup was, there were two blocks where setting a label caused at least 800ms of autolayout calculations. So that's 1.6s accounted for. Which seemed like a good starting point to optimize.
The code was just setting properties (in this case: a title label and a response handler block), but they both touched the same label twice. I pondered on coalescing the two properties in one method but it seemed like an unsatisfying solution. And so I decided to copy a pattern Apple uses too regarding UI: the 'setNeedsLayout' pattern.
The Builder Pattern in Objective-C
A blogpost by Klaas Pieter Annema is doing the rounds on twitter lately. It appears the builder pattern is quite new to iOS devs since everybody is raving about it. In my own humble opinion I do think it is a bit convoluted for what it's worth.
The followup post by Joris Kluivers makes better use of existing classes: NSURLComponents becomes the builder for an NSURL, and given that these classes are already present and used in other use-cases, the builder pattern makes a lot of sense this way.
But I still feel that rolling just a builder class to construct an object is a bit overkill. But it turns out you don't need two classes: you just need to leverage another feature of Objective-C: protocols.
Quick Look for UIView
Xcode 5.0 introduced an interesting new feature: Quick Look for variables. Basically, it lets you inspect variables and their contents in a graphical way. This allows for interesting ways of viewing the state of your app.
I've been using the feature quite a bit: it's a great way to inspect images or colors you're using in your app, for example. Works great on attributed strings, too.
Xcode 5.1 improves the feature even further with the addition of debugQuickLookObject. This method allows you to provide quick look content for any of your own classes. A bit like debugDescription but more advanced. I haven't had the time to look further into it.
app.io
This morning, a tweet from @tomclaus caught my eye:
Being in the apps business, this peaked my interest. So I went and signed up at app.io, just out of curiosity.
WWDC 2013 Hopes and Expectations
No real predictions post. You never know with Apple what they're going to produce at a developer event, so I won't go there. What I will do is list what I'd like to see. Mostly iOS stuff, because that's what I do.
iOS Fragmentation ↦
Kevin Marks writes how about the way iOS handles iPhone vs iPad screen sizes is actually worse than how Android handles it (by doing nothing and "autoscaling" apps). It's a funny read even if it wasn't intended to be. The comments are priceless, too.
(Note: VPs at web companies shouldn't be pretending to know everything about native development - and vice versa.)
WWDC Predictions
My predictions for the WWDC keynote:
- We won't see Jony Ive on stage
- I'm guessing Federighi will take over Forestalls part (on the other hand, how mindbending it would be to have Forstall do the iOS part!)
- Ive will do (at least one) video where he'll do his tilted head magic telling us how they designed the best iOS experience ever (it will be "truly the result of years of innovation and hard work").
I wonder if he'll manage to sneak in an "aluminium" in the iOS video, though.
Clockwork updates ↦
David Smith writes about iOS adoption rates. It seems that it just takes over a week to get to 50% adoption whenever Apple releases a new version of iOS. The second chart says it all: 10% is still on iOS5 (and even 4.x) but the rest is on iOS6 or greater. 70% is on iOS 6.1.3.
That's pretty impressive.
(Also: I love how the graphs are interactive)