Ideally, errors should never occur. File we need should always be available and networks should always be present and reliable. Unfortunately this reality is not ideal and we have to deal with the consequences. Thankfully the Swift team included a great way to handle these deviations from the ideal in Swift 2. Swift Error Handling lets us quickly and easily warn the compiler whether a function can throw an error, actually throw it, and handle it in whatever way seems appropriate.
[Read more…]
API Availability Checking in Swift
With all of the new and awesome APIs that come out every year for each successive iOS version, it can be tempting to just drop support for the previous versions of iOS, and just go completely to the new stuff. Of course though, we usually can’t do that for many reasons. As such, we need to support older versions of iOS, and maybe dropping the oldest ones after they just become too difficult to support, or when active users on that platform drop to a certain amount.
There have been ways to check for API availability for some time, by checking if something responds to a selector, or just checking the iOS version ourselves and using that in a normal Swift “if” statement. With the arrival of Swift though, we have an even nicer version of API checking, that is even helped by Xcode itself. This allows Xcode to actually warn you if you try to use something that is unavailable on one of the deployment targets for your Swift app.
[Read more…]
Protocol Extensions in Swift
So, if you’re using a class, structure, or enumeration which did not provide a method that would be very helpful for your app, you could simply add it via an extension (which you can read more about in the posts Swift Extensions Part 1, and Swift Extensions Part 2). With extensions, you can easily add methods to a type that builds upon the existing types. One of my favorites is writing my own UIColor convenience initializer (shown in the post How to Create a UIColor in Swift), that takes a value between 0 and 255, and hardcodes the alpha to 100% opacity. I definitely understand why the authors did it the way they did, it is general so you can do many things with it, but I didn’t want the boilerplate required to convert my 0-255 based RGB values, and I CERTAINLY didn’t want to set the alpha to 100% each time when it would never be anything else in my app.
Well, that’s great and all for classes, structures, and enumerations…. but what about protocols? In Swift 1, you could write your own protocol and have methods in it that would then have to be implemented by those types that adopt the protocol… but if it doesn’t have a method you need, the only thing you could do was either write an extension for each type that adopted the protocol, or write it as a global function. That’s exactly what Apple did for a lot of functions in Swift 1, particularly many that worked with several CollectionTypes like Arrays, Dictionaries, and Sets.
With the coming of Swift 2 though, we now have a recourse that no longer requires global functions. Now you CAN extend protocols with Protocol Extensions. You can even provide default implementations for these methods defined in those protocol extensions!
Println Is Now Print, and Do-while Is Now Repeat-While in Swift
There are a few differences from Swift 2 that probably don’t need their own post, but should be mentioned nonetheless because they do have significant implications. This post will cover a few of those changes: Print replacing Println and the Repeat-While loop replacing the Do-While loop.
[Read more…]
The Guard Statement in Swift
Often when working with Swift Optionals, we will want to perform an action if the Optional contains a value, or do something else if it does not. This is done with Optional Binding with the “if let” syntax, which lets us test for wether it contains a value, and if it does, binds it to a constant that can be used later in the if statement. This works great for many cases, but it does put the emphasis on the positive case. If there is a value, do this, otherwise do that. Now if the code to run when there is a value is short, you can easily see what the “else” clause is tied to. However, if the code to run when there is a value is long, then you might need to do some scrolling to see the associated else clause.
This is where the guard statement comes in handy, introduced with Swift 2. The guard statement puts the emphasis on the error condition. In this case, if there is no value, you can clearly see what will be done to deal with it.
What happens if there is a value? The rest of the current scope continues running like normal. Let’s go into an example of how the guard statement can be helpful.
[Read more…]
- 1
- 2
- 3
- …
- 5
- Next Page »