So I tried to create an UI Element in Swift that responds to a specific Gesture. Easy enough let’s look up how that works. The almighty Internet has answers for everything:

Subclass UIGestureRecognizer and override the methods touchesBegan, touchesMoved and touchesEnded.

Okay, I can do that – but wait, what?

It seems like the most recent version of Swift is missing some public declarations for those override-able methods. Probably because access control has just landed for Xcode/Swift the other day. At least Jared Sinclair supports this theory.

He also offers a Solution: Import UIGestureRecognizerSubclass.h in your Bridging-Header. I am new to this, how do you do that? Turns out Xcode creates the Bridging-Header file for you if you create an Objective-C file in your project. Due to some back and forth I learned that it unfortunately only does that once. If you ever deleted the file it will not come back. So how do you create it manually?

1. Create a new Objective-C Header file and name it <projectName>-Bridging-Header.h
2. Go to your Project Root and then find “Build Settings”
3. Scroll all the way down and locate the “Swift Compiler – Code Generation” section
4. Insert the path to your header file into the “Objective-C Bridging Header” field (Notice that the file might be in the root folder [like mine] or somewhere else)
5. Set “Install Objective-C Compatibility Header” to true

Back to the actual solution. Insert this one line into the header file:

https://gist.github.com/552655716a2016b11566

And voila – it works. Suddenly all the desired Methods are avaiable. Well, that was simple.

The post Captain on the bridge appeared first on blog.farly.

https://gist.github.com/1448a92686ee40cb7db6

For people that do not know Objective-C let me guide you through this a litte. This is the implementation of a class method named getFieldTextAtRow:andCol:. It takes to Integers (row and col) and returns an NSString. In the return statement the class method getFieldAtRow:andCol: is called passing the two variables into it. It then asks for the .text property of the returned object. Wow. Calling Methods on an object requires some strange square bracket syntax. Accessing parameters on the other hand is just a plain simple Object.parameter. A dash defines a method. A simple String is a NSString (which is written as @"String") and method name and parameters are entangled. I could go on… but, lets not ramble about dem ol’ days too much: Along comes Swift.

Swift is an innovative new programming language for Cocoa and Cocoa Touch. Writing code is interactive and fun, the syntax is concise yet expressive, and apps run lightning-fast.

Let’s look at the example Method again – this time written in Swift:

https://gist.github.com/d61634ebbf747715e0cd

A String is a string; A method is defined with a func keyword and a method is called just like a function. The name of the method is just getFieldText. Because of backwards compatibility (I guess) parameter names are still in the call. Exception to the rule is the first parameter. Objective-C had it inside the first part of the method name, so Swift “needs” to do that too. func getFieldTextForRow(row: Int, col: Int) -> String would be called like getFieldTextForRow(13, col: 37). The hash symbol in front of the first parameter tells the compiler, that you do want to explicitly name it. So basically that number sign makes stuff more consistent and a little less awkward. I tend to use it all the time.

After all Swift lets you do very cool stuff and in some aspects it is miles ahead of other languages. But some of the “I-need-to-support-all-the-weirdness-of-my-grumpy-father”-aspects just leave me scratching my head.

The post Hashtag Swift appeared first on blog.farly.