Loading Swift UIViewController from XIB in storyboard

Uncategorized

Some developers prefer to keep ViewControllers design in separate XIB files instead of placing everything in Storyboard. Especially on displays with the smaller real estate (like working on a MacBook), navigating and editing the storyboard could be tedious.

There is a simple technique which lets us keep storyboard ViewControllers and segues between. Following one of the tutorials available is simple:

  1. Place UIViewController on storyboard
  2. Highlight its View and delete it. You should now have “hollow” ViewController.
  3. In identity inspector, set the custom class to name of your choice.
  4. Click File -> New, create new Cocoa Touch subclass of UIViewController. Don’t forget to check “Also create XIB file“. Name the class exactly as on Storyboard.

It works perfectly with Objective-C projects – iOS takes care of loading view from XIB, provided it has the exactly same name as the class. But if the class is written in Swift, all you get is black screen.

Fixing on Swift side

Apparently this smart mechanism is broken newest Xcode builds (including GM). Fortunately, simple remedies exist.

Name the XIB

Just change name of XIB file to ModuleName.ClassName.xib and view should be loaded.

Load XIB programmatically

If renaming XIBs is not appealing to you, you may keep XIB name as it is, and override loadView: method with short snippet of code:

November 2016 Update

In Xcode 8.x/Swift 3.x naming the XIB in smart way seems to not to work anymore. Still there is programmatic way, which may be preferred as more explicit. In Swift 3, loading code would look slightly different, because of different conventions of mapping Foundation classes to Swift:

loadView is responsible for creating ViewController’s view. Override it to get control over view creation process. 

Xcode 6 beta 5 update

Uncategorized

With release of Xcode 6 beta 5, cat and mouse game continues: virtually every open source project/library written in Swift, needs to be updated. Not complaining at all, let’s see what I needed to update in example Actor library project and what is probably waiting for you to encounter.

LogicValue is now BooleanType

Swift engineers are willing to make naming consistent, and all built-in protocols shall be called something-able, -ible or -Type. If you happen to have implemented LogicValue somewhere:

  1. Rename it to BooleanType
  2. Remove getLogicValue() -> Bool function, moving its body to:

New BooleanType protocol defines not a function, as it was in LogicValue, but required property. Now we have a bit of extra consistency.

Optionals are no longer LogicValue (nor BooleanType)

To prevent ambiguous constructs, you can no longer use Optional value in if statement, now it needs to be explicitly compared with nil. I have used it in my functional extension to Optional, which I wrote about, and which has been rendered almost useless with Beta 5.

Elvis operator

Short ?? (two question marks) operator does the same as Optional+getOrElse() extension.

Converting String to C String

Apparently String.bridgeToObjectiveC() is gone, and I needed to find other way of converting Swift’s Strings to C Strings. Existing code which creates serial dispatch queue:

Now is replaced by cleaner code:

Required keyword in initializers

Any subclass inheriting required initializer need to place ‘required’ keyword in front of each required initializer.

This concludes my opinionated, subjective list of breaking changes of Beta 5. I hope the more obscure ones will be found helpful!

 

getOrElse in Swift’s Optional

Swift

Now I couldn’t resist throwing my own two cents onto buzz around Swift  language. Right now, we are on early stage of excitement, which means lots of tutorials, and emerging libraries and extensions, including a few ones which sometimes recreate features that already exist 🙂

Update: As of 4th August 2014, this article is obsolete. Swift language has been enhanced with ?? operator, which does the same.

I’ll leave remaining of the post for proof of that I was first 🙂

But to the point.

One of respectable Swift features are optionals. They are more important than many of you may think, so it is good to take closer look.

Optionals are wrapping value which may or may not be present. Consider an example: we have string which we want to convert to a number:

When typed in Playground, asNumber value is {Some 456}. If you really want a number, you need to unwrap it

Forced unwrap operator, exclamation mark, will, however generate an error when input value is not a string. Eventually you end up with if-checking:

Optional type implements LogicValue protocol, so any Optional variable can be used in conditional expression.

This is not satisfactory for me, though. If language is borrowing so many good parts from functional language like Scala, why not steal more? Scala’s Option type offers a number of methods, including getOrElse(default), which returns a wrapped value if it exists, or provided default otherwise.

There’s no such thing in Swift (yet). So that encouraged me to implement it by myself. Swift documentation is very high-level, with little to none specific of under-the-hood operation.

After fiddling with undocumented methods a came to my own implementation of .getOrElse() using extension:

You can find in in my GitHub gist. Now, instead of creating if on the very end of chained Optional calls, use nice and clean:

I really hope to find such feature in Swift 1.1, otherwise it is a good start of functional extensions library for Swift.

Reboot

Uncategorized

This is unintentional reboot of blog and website. It used to be hosted on friends server provided to me as a courtesy. It ran there for years, and suddenly stopped functioning.

The friends server has been sunset, and he forgot to notify me. Looks like I was extremely trouble-free tenant.

It is a good opportunity to start from scratch, possibly revive some posts from archives.