photo-1458336458944-27b9f90c7f38

Commit #6: Unwrapping Swift optionals

Update 12 Oct ’16: I’ve updated the code in this post and the Xcode Playground blog post version to Swift 3! Thank you for the wait 😁

As an iOS developer, handling empty value cases in Objective-C is never easy. Let’s suppose we’re making a function that return NSString instance out of a NSDictionary:

Everything seems fine, isn’t it? The method’s logic is pretty clear – it returns the value in user_token key of the JSON. If the key exists, it will return the string. If not, it will return a nil value… dead simple, right?

No.

I left out a sanity check there, but  let’s continue our example for now.

Suppose that the returned string will be encrypted and stored by C++ library. And for that, we need to cast our NSString to C string:

Where’s the problem, Do? Everything looks fine…

Right. The method above looks good – it stopped the process early if passed userToken is nil. Both of them will work correctly, until somebody from the server side single-handedly pass null value in response JSON’s user_token key, instead of omitting it.

Let’s run through the code once again. If the passed JSON is made from NSJSONSerialization process, the user_token key will store a NSNull  instance. Thus, the result from userTokenFromJSON: will be a NSNull instead of a nil or NSString – which will allow it to pass through storeUserToken:‘s early sanity check code (since it’s not a nil), and break the whole app, since NSNull doesn’t have UTF8String method.

Let’s hope this case will never happen in production servers. And yes – I’m looking at you, cowboys.

Due to this issue, nil-checking alone in Objective-C isn’t sufficient. We also need to ensure whether an instance is the right class using isKindOfClass: method. It doesn’t always work well either – for example, if the server on the example above returns a number for user_token value, there’s a chance that it’ll read as _NSCFString (Apple’s private API) instead of a NSNumber.

That’s why after a few month working with Swift,  I grew appreciating the Swift Team’s decision to include Optionals. I believe they made this as an answer to Objective-C’s tedious sanity check. The documentation clearly says that:

You use optionals in situations where a value may be absent. An optional says:

  • There is a value, and it equals x

or

  • There isn’t a value at all.

If I declare a variable to be a String? (read: String Optional), it would either be a String value or a nil. Not a NSNull, not other class type, and not another Apple’s private API. So, userTokenFromJSON: above could be rewritten in Swift into this:

And yes, this method will an Optional – either  String or a nil. 🙂 But the process isn’t ended here – we need to take the available String value out of the Optional. The term is usually called as unwrapping in Swift development – and there are several ways to do it!

Wait, it seems I had enough rant above… this post started to feel edgy. Let’s change the mood, shall we?

In this post, I’ll list the ways for unwrapping Swift’s Optionals that I have found so far. For the sake of the post, let’s assume we got a new function that needs a String input and an Optional variable:

Now, we need to unwrap the name (since it’s a String optional) to pass it to the createGreetings(sailorName:). There are several ways to do this:

Read More

photo-1418846531910-2b7bb1043512

Commit #5: On choosing learning materials

For us who work on the field of software engineering (and its neighbours), it is no secret that we constantly learn new things. Driven either by need or curiosity, it seems like learning is a never ending quest for us. Some of them have direct impact to our craft, like how using Xcode’s debugger could save us from headaches, or how side menu reduces user engagement with your app. Some of them are just for fun – like how TrumpScript is making Python great again (duh), or how a build engineer automates everything using bash scripts, ranging from scanning e-mails to ordering the coffee machine (!).

As a software engineering company, Ice House has a diverse learning scene. We have two main diets in our learning materials:

  1. Knowledge in our main craft, e.g. iOS or Android. To deliver the best quality, we always strive to know better about our own backyard.
  2. Specific knowledge which needed in client project’s domain,  such as geolocation or image processing. Sometimes, our client requests more than a simple mobile app to compete with current market.

Outside of that, each of us has our own preferences. Some of us love to venture outside of our comfort zone, such as playing with Arduinos, explore new programming languages / concepts, or tinkering with new game development tools. As for me, I found myself learning much more general topics, such as clean code, test-driven development, or design patterns. Sometimes I’m afraid a new platform-specific knowledge would quickly obsolete – especially on today’s tech pace.

Last week, I joined a design-and-define workshop for a new client. I had a chat with our software architect during a session’s coffee break. He has more than ten years of experience in software engineering, and had several years working as Senior Director of Engineering for Citrix’ mobile platforms. I always knew that he has a vast knowledge about a lot of things, but I witnessed it myself up close on the workshop sessions. Wondering if he’s still learning new things these days, I asked him straight away:

M (Me): So, what are you learning about these days? Got anything new?

H (Him): Hmm… nothing much. I currently playing around Kotlin and Swift.

M: Kotlin?

H: Yeah. You know, the new language from JetBrains – some people build Android app on top of it.

M: Whoa. Do you also planning to build Android app with that? Or perhaps using Swift for backend?

H: Maybe – as a software engineer, it’s always a good thing to keep up with today’s technologies. At least, I’ll learn new paradigms that might be useful later.

I found myself agreeing with his last statement, but I also start wondering how he picked his learning plan. He’s an architect, and it’s his job to keep being updated with general software growth. Why did he chose Kotlin and Swift? Why not Haskell, Node, or others? Curious, I continued our discussion with this:

How do you choose what to learn next?

Read More