I started a long and mostly one-sided debate in the office last week, by suggesting that we should not change our delegate method signatures to conform to the Swift principle of omitting needless words.
I started learning Swift the day it was announced and read Apple’s The Swift Programming Language in the first couple of days. I began writing small components and playing around with Swift at the same time, but never felt it was mature enough to begin a big project with it.
That was until Swift 2.0 was announced in June. Since then I’ve been using it more and more and recently started writing a major project at The App Business purely in Swift 2.0.
Read on for some of my observations – some are obvious and common, but hopefully some will be new to most people. Let me know if you have any of your own that I could add to the list!
When protocol extensions were first mentioned at WWDC in June, they immediately stood out as a necessary feature. But it was only after I started playing around with them that I realised the true value these bring to the language.
Stencil is an Xcode plugin that provides the ability to create custom file templates and use them in your project to create new files. It’s intended to save you time while making it easy to extend a project in the future: for you, next week; for your current colleagues; and especially for people that might inherit a project from you in the future.
Once you’ve used Stencil to create a custom template, you can create new files based on this template. The new files can include Objective-C headers and implementation files, interface builder files (.xib and .storyboard), as well as Swift source files.
It really adds benefit when there’s a particular class that you commonly subclass, especially if the new subclass requires an interface builder counterpart.
Of course you would want to document your project to explain that you have defined custom templates, which can be used with the Stencil plugin. But if one of your co-workers doesn’t have the plugin, then it doesn’t matter. No harm done, it just means they won’t reap the benefits. And you can spend longer on your tea break, while they’re spending longer doing things manually!
Love them or hate them, macros are an integral part of C development, and are widely used throughout the Objective-C Cocoa and Cocoa Touch frameworks. If you’ve ever used
NSAssert, then you’ve used a macro. (And if you haven’t, then what have you been doing?!)
Now please bear with me… before all you macro-haters completely disregard this blog post, this is not another one of those posts that explains the trivial procedure of re-writing a function-like macro as a function in Swift. Nor will I show the Swift alternative to a macro definition of a primitive constant, as I’ve seen in other recent posts within the community.
In this short series, I’m going to look at some of the more creative uses of C macros and investigate how we could use some of Swift’s advanced language features to accomplish the same results.
I recently found myself in a situation where I needed to listen out for changes to a UIScrollView of which I couldn’t set the delegate. My situation was with the underlying UIScrollView of a UIWebView instance, but there are other situations where you might want to receive delegate method calls from an object for which you are not allowed to set the delegate.
The problem is that UIWebView exposes its underlying UIScrollView, but it would be bad etiquette to set its delegate, because you are not the owner of the UIScrollView instance and you don’t know the implementation of UIWebView.
So, the question is: how can we listen out for the delegate messages from a UIScrollView, when we are not acting as the delegate?
Many of the projects on which I’ve worked have had the problem of “theming”, because it’s difficult to keep a project’s codebase clean when dealing with multiple themes. When I refer to a “theme” I mean something that only affects the look and feel of an app, but not the functionality.
By “theming”, I’m referring to a project that might have different targets, each with different colour schemes, fonts, sizes, etc. to deliver a different user experience with the same functionality.
But theming can be extended to a single app, with a single theme, where different interface builder (nib/xib) files are backed by a single class. This might be as simple as having a different interface file (or nib) for iPad as opposed to iPhone, where each nib is backed by the same class.
Theming is often even more complex. For example, I might have an app that can display the same content in various forms. A news app, for example, might have a timeline in which it displays article teasers as either: a small widget with headline only; a double-height, more-impactful widget with headline and thumbnail image; a double-height widget with headline and article summary. That’s three nibs, and I’ll also need each one styled slightly differently whether it’s on iPad or iPhone. So that’s six nibs all backed by a single class!
In this article, I’ll discuss my latest solution to “theming” using User Defined Runtime Attributes.
Foundation’s KVC Collection Operators are often overlooked and underused, but for those in the know they are a powerful tool to have in your Cocoa shed. The obvious advantage is their consicion, but the big disadvantage is that we don’t get compile-time errors when we misuse them and nor do we get code-completion. And herein lies the problem. In this article I’ll discuss KVC Collection Operators in more detail and propose a solution to this problem.
User-defined runtimes attributes in Xcode’s Interface Builder are a great way to keep view controller and view code clean, while obeying Separation of Concerns. They allow you to configure properties on the view or view controller that you are unable to configure from within Interface Builder’s Attributes Inspector or Size Inspector.
But sometimes you may want to setup from Interface Builder a scenario which you can’t do from simple KVC-compliant property manipulation.
One example I ran into recently was trying to set the content insets on a collection view in a normal view controller in an iPhone-specific storyboard. In Xcode 5.1 you are unable to set the content insets of a collection view (I’m not sure in which Xcode version this was first missing - I’m sure you used to be able to do it). So with this feature missinh, it would be nice to be able to do the same thing using user-defined runtime attributes.
Because contentInset is of
UIEdgeInsets type, this isn’t possible with any of the types defined in Interface Builder under user-defined runtime attributes. But it can be done!
Another example I will show below is how to set the borderColor property of a
CALayer, even though the runtime attributes don’t support
CGColorRef type. All will be explained!
This post is based on a really cool effect I saw in the Facebook Paper app released last week. In this app, the user can drag a photo up to the top of the screen to view it full-screen. In doing this, the photo actually appears to be in front of the status bar.
Enumerated types are very useful and widely-used. Foundation framework gives us two macros to help give definition to an enumerated type: NS_ENUM and NS_OPTIONS. But their intended use – and correct use – isn’t immediately obvious.
First a bit of background: Enumerated types are a part of the ANSI C standard and, if I was a gambler, I would bet my entire future life’s earnings on the fact that every single iOS or OS X programmer has encountered them and is very likely to use them daily, even if they are unaware of it. They are defined in a similar way to a struct and it’s very common to
typedef an enumerated type for easier use.
In this post I will discuss the Objective-C macros
NS_OPTIONS, their origins and, most importantly, the correct way to check the value of a variable of an enumerated type.