ViewDeck
This is a follow-up post to this post, wherein I started a quest for a new ViewDeck maintainer. I say quest, but I actually meant "let's just throw it out there and see how it goes".
So I had already left for my job at Apple and had my first work day there done, when I received a DM from Michael Ochs, asking if I had already found a new maintainer. To be honest, at that point, I was a bit afraid I might not find one. That was fine it itself, but I really wanted to "disconnect" myself from the project, even though I hadn't really touched it in a few years.
Wanted: new maintainer for ViewDeck
I'm pretty sure that if you found this blog, you also know about a little piece of software I wrote a few years ago: ViewDeck. The initial commit was on December 3rd, 2011. I'd been doing nearly a year of iOS development at that moment, and both the Facebook and Path apps came with this nifty new feature we now call "a hamburger menu".
I remember finding it an interesting piece of user interaction and wondered how it was implemented, and so set out one night to try to recreate something like it myself. At that point, not an awful lot of libraries existed that recreated that UX, so I had no way to base my code on somebody elses creations. By the end of the night I had a mostly working prototype, and decided to continue working on it, and to share it with the world. After all it might come in handy for someone else and it was a fun way of showing of what I did (YEAH BABY).
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
Swift: an array of protocols
I was working on a side project yesterday, a side project which I decided to develop using Swift. My day job mostly consists of Objective-C (which I still love) but all the hip kids are doing Swift and it doesn't hurt to keep along with the latest trend, right? And learning is fun.
So I was coding away, and I had this component which needed to notify several other components of certain events that happened. In practice this meant that I needed a sort of multicast delegate. Now, I could have solved this the old Cocoa way by using notifications, but I try to stay away from them unless it really makes sense. The contract they offer is pretty loose (which can be handy too), but I wanted to try something more set-in-stone right now.
SwiftyAs
Let me introduce: SwiftyAs. It's a tiny little library to provide sort of the same functionality as as? from Swift in Objective-C. Let me explain...
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.
New Horizons
A tweet, 2 FaceTime interviews, a trip to Cupertino for 5 two-person interviews lasting a whole day (including lunch at the Caffé Macs), a bucketload of mails and 2 handfuls of international phonecalls.
That's what got me a job in the UIKit team at Apple.
It's safe to say it's been a crazy ride so far, and it's about to get even better.
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.
Explicitly implemented protocols
While traveling home from NSSpain yesterday, I got an idea for a new app. Nothing groundbreaking, and more on that later, but it required the use of health kit. I also decided to write this one in Swift, for fun and profit but mostly for fun (and perhaps also because practice makes perfect).
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?
Cocoapod All The Things
So, am I the only one who manages to get sidetracked a lot when working on (personal) projects?
For example, I have a few generic components written for various projects. In the past I would just add a vendor folder to my project, put the component there and be done with it.
But I've become to like CocoaPods to much that I cannot get myself to use this simple approach anymore. The CocoaPods approach makes using external libs so clean that it feels dirty not to (unless there's no other option).
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.
A Swift Test
At the latest iCapps Monthly Teammeeting (today!), I presented our developers with a small Swift test. It was supposed to be a bit tongue in cheek, but also a bit serious. This new language coming out of Apple is pretty new but also here to stay, so it can't hurt to get on the bandwagon sooner rather than later. A few of us got to go to WWDC and see everything for themselves, the rest of us maybe spent some time with the videos or even started coding but I guess the majority hasn't really gotten around to seriously looking at this new language.
And so, to spike the interest a bit more, I made this little test to see how much we all knew about Swift. It's not complete by far and it only touches on a few specifics, but I had it set up as a multiple choice test so it was kind of hard to touch on every feature in the language (for example: try asking a question on the brand new enum syntax without spoiling it). And the main goal was to show the difference from Objective-C.
Show me some id
Brent Simmons touches on the use of abbreviations in Cocoa. I've noticed this behaviour too, and other uncocoalike things too. This is especially apparant in code of devs coming from other programming language/platforms.
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.
Inspiration
I am currently at NSConference 6. For those who haven't heard of NSConference, it's a "community conference for OSX and iOS developers". It's a 3-day conference about developing for OSX/iOS by and for developers. If you're an iOS or Mac developer based in Europe, it's a great way to meet the community and learn new stuff.
The problem with these conferences is inspiration. The talks are usually pretty good, and get you fired up to start doing something. Not necessarily with the knowlegde you learn at the conference, but even with what you've been working on at home (or work). The great thing about NSConference (and in general about the smaller conferences) is that they're mixed technical and non-technical. Not everything is about "how to code this-and-that", but it's also how what other people have learned, passing on their experience onto the attendees. Sometimes the talks are mainly about your own "wetware" (thanks @bmf!), how you deal with building apps and interaction with your customers, clients or colleagues.
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.
Followup
I was listening to the most recent Debug episode, the one featuring the ever apologetic @caseyliss talking about C#. It's another great episode (but most of the Debug episodes are great - I love the interaction of @gte with his guests). I was particularly interested in this one since I have a similar background: I spent most of my working days on a Microsoft platform and produced a bucketload of C# code (ever since it came out early 2000). Since late 2010 I've been mostly dabbling in Objective-C on the iOS platform. So I was quite curious on what Casey had to say.
While I'm not going to rehash everything here (go listen to the podcast), I agreed with most of it. I do think he forgot an important feature of generics and c# in general: "compile time breakage".
categories-for-@protocols (2)
And a follow-up post for this one. Already!
I forgot about it, but @pjaspers reminded me that we actually did something similar to this using "regular" language constructs.
What you could do:
- extend the protocol with the method you need (as has been suggested before)
- implement the protocol extension method a seperate .m file (similarly named to the .h file the protocol is defined in, I guess). Forgo the @implementation/@end dance, just put the method code "naked" into the file.
- for each class conforming to the protocol do a
#include "Protocol+Implementation.m"in the class' implementation file. You read that right: thats an include and not an import.
Categories for @protocols
Yup. Categories for protocols. You heard that right. It started with me asking about it on twitter:
This question caused much confusion. "How is that even possible?" "Categories are used to extend existing classes, surely how can you extend a protocol?"