So in iOS Swift we can do optional chaining to simplify the nil checking like in the official documentation
let johnsAddress = Address()
johnsAddress.buildingName = "The Larches"
johnsAddress.street = "Laurel Street"
john.residence!.address = johnsAddress
if let johnsStreet = john.residence?.address?.street {
println("John's street name is \(johnsStreet).")
} else {
println("Unable to retrieve the address.")
}
// prints "John's street name is Laurel Street."
I understand about the usage of the optional chaining in john.residence?.address?.street but how can we know where is actually the chain is breaking (if either residence or address is nil). Can we determine if residence or address is nil, or we need to check it again with if-else?
Don't do the chain then. The chain is only interesting if you don't intend to stop. If you do, break it up at interesting spots - otherwise, where would you put in the code for the bad cases?
if let residence = john.residence {
if let address = residence.address {
...
} else {
println("missing address")
}
} else {
println("missing residence")
}
I don't think so. Optional chaining is a convenient shortcut syntax and you are giving up a bit of control along with a couple of keypresses.
If you really need to know where exactly the chain breaks, you have to go link by link into multiple variables.
There is no way to tell where optional chaining stopped. However you can use:
if let johnsStreet = john.residence?.address?.street {
println("John's street name is \(johnsStreet).")
} else if let johnAddress = john.residence?.address {
println("Unable to retreive street, but John's address is \(johnAddress).")
} else {
println("Unable to retrieve the address.")
}
Related
I have the following implementation, but I need break down the statements do not combine them using ,. What is the best approach to refactor the existing code?
do {
let school = try schoolManager.currentSchool(), schoolName = school.name
return schoolName
} catch {
return nil
}
Since you don’t really do anything with school other than grabbing its name, you might just do:
do {
return try schoolManager.currentSchool().name
} catch {
return nil
}
Or, even even more concise, since you’re not doing anything with the error thrown by try, you can instead use try? and optional chaining, e.g.:
let school = try? schoolManager.currentSchool()
return school?.name
Or
return (try? schoolManager.currentSchool())?.name
It's really hard to find a proper title for this question. Please be easy on me.
The first part is a check to see if an account exists:
Auth.auth().fetchSignInMethods(forEmail: userEmail, completion: {
(providers, error) in
if error != nil {
self.displayAlertMessage(alertTitle: "Unhandled error", alertMessage: "Undefined error #SignUpViewController_0001");
return;
} else if providers != nil {
self.displayAlertMessage(alertTitle: "Error", alertMessage: "This account is not exist.");
return;
}
})
As you can see, I have something named Unhandled error with message Undefined error. I don't know how to name it properly. Can somebody explain that part to me?
The second one is about getting a localized string - any ideas to make it fancy?
Auth.auth().createUser(withEmail: userEmail, password: userPassword) { user, error in if error == nil && user != nil {
self.displayAlertMessage(alertTitle: "Success", alertMessage: "Your account created successfully. We send you a verification email.", dismiss: true);
} else {
self.displayAlertMessage(alertTitle: "Firebase error", alertMessage: "(error!.localizedDescription)");
}
}
Thanks for tips :)
You can handle the Errors this way:
Auth.auth().fetchSignInMethods(forEmail: email, completion: { (response, error) in
if let error = error, let errCode = AuthErrorCode(rawValue: error._code)
{
switch errCode {
case .emailAlreadyInUse:
GeneralHelper.sharedInstance.displayAlertMessage(titleStr: LocalizeConstant.CommonTitles.Alert.rawValue.localizedStr(), messageStr: LocalizeConstant.CommonTitles.Continue.rawValue.localizedStr())
case .accountExistsWithDifferentCredential:
GeneralHelper.sharedInstance.displayAlertMessage(titleStr: LocalizeConstant.CommonTitles.Alert.rawValue.localizedStr(), messageStr: LocalizeConstant.CommonTitles.Continue.rawValue.localizedStr())
default:
break
}
return
}
}
Here I am getting the errCode using AuthErrorCode provided by Firebase itself and then, I am passing in the received error code using error._code. So, now I can get the type of AuthErrorCode. Using this I am making cases like .emailAlreadyInUser, .accountExistsWithDifferentCredential etc. You can just type . and it will show you all the AuthErrorCodes. So, you can simply handle the error codes in this way.
Now, coming to the second part of the question, i.e. getting localized string. You can add localization to Firebase, for that you have to select the language code. Auth.auth().languageCode = "en" //For English. But, I do not think that it gives localized errors as there are many more languages than what Firebase supports. This mainly for sending localized emails.
To handle the localization, you have to create your own method as I did. You can see that I have called a function displayAlertMessage in which I am passing thetitleStr: LocalizeConstant.CommonTitles.Alert.rawValue.localizedStr(), which is a part of localization.
struct LocalizeConstant {
enum CommonTitles: String
{
case Alert = "common_alert"
}
}
This value designates to the key given by me in the localization file. If you do not know about localization, you have to do a Google search on it. Let's say I have two Localizable.strings one is in English and the other one is in French. In Localizable.strings(English), I've written Alert like this:
"common_alert" = "Alert";
And, In French:
"common_alert" = "Alerte!";
So, this is how I have manually added localization in my app. But, to achieve this you have to do two things. 1) You have to set up your appLanguage. 2) You have to call a method which will fetch the values from these keys defined in the Localizable.strings file.
To do this, I have created a method localizedStr(). It is an extension to String and you can use it as follows.
extension String{
func localizedStr() -> String
{
var finalRes = ""
if let path = Bundle.main.path(forResource: Constants.appLang, ofType: "lproj") //Constants.appLang is "en" here for "English", but you can set accordingly.
{
if let bundle = Bundle(path: path)
{
finalRes = NSLocalizedString(self, tableName: nil, bundle: bundle, value: " ", comment: " ")
}
}
return finalRes
}
}
Now, this method localizedStr() will give you a localized string according to your app language. Even, if Firebase provides localized error codes(which I think it does not), it is impossible to get the error description in each language. So this is the best way I came up with. It may not be the best method out there in the world, but it does the task.
P.S.: To optimize this throughout the app, either you can create an extension to AuthErrorCode or you can create a Helper function where you will just pass the error._code and it will return the localized string. I've added the long way so that you can understand everything in the best way.
Some of my users have been sent me logs identifying a EXC_BREAKPOINT (SIGTRAP) Error on this line of code. I've been been trying to make it safe but all of the properties of EKParticipant are non optional so comparing to nil just gives me a warning saying it will always be true. If something is nil here how should I handle it?
Error Line
let participantEmail : String? = participant.url.absoluteString.lowercased().replacingOccurrences(of: "mailto:", with: "")
Apple Error Description
Trace Trap [EXC_BREAKPOINT // SIGTRAP]
Similar to an Abnormal Exit, this exception is intended to give an
attached debugger the chance to interrupt the process at a specific
point in its execution. You can trigger this exception from your own
code using the __builtin_trap() function. If no debugger is attached,
the process is terminated and a crash report is generated. Lower-level
libraries (e.g, libdispatch) will trap the process upon encountering a
fatal error. Additional information about the error can be found in
the Additional Diagnostic Information section of the crash report, or
in the device's console. Swift code will terminate with this exception
type if an unexpected condition is encountered at runtime such as:
a non-optional type with a nil value
a failed forced type conversion Look at the Backtraces to determine where the unexpected condition was encountered. Additional
information may have also been logged to the device's console. You
should modify the code at the crashing location to gracefully handle
the runtime failure. For example, use Optional Binding instead of
force unwrapping an optional."
Full Method
/**
Parses participants for a given event.
Goes through the EKEvents attendees array to build Attendee objects used to model a participant.
- parameter event: The calendar event we'll be finding the participants for.
- returns: An array of Attendee objects with the participants name, email, required/optional status and whether they've accepted their invitation to the event.
*/
private static func parseParticipantsIn(event: EKEvent) -> [Attendee] {
var participants = [Attendee]()
if let attendees = event.attendees, event.attendees?.isEmpty == false {
for participant in attendees {
let participantName : String? = parse(EKParticipantName: participant)
let participantEmail : String? = participant.url.absoluteString.lowercased().replacingOccurrences(of: "mailto:", with: "")
let isRequiredParticipant : Bool = participant.participantRole == EKParticipantRole.required
let hasAccepted : Bool = participant.participantStatus == EKParticipantStatus.accepted
guard (participantName != nil && participantEmail != nil)
else
{
log.error("Participant could not be parsed")
continue
}
let attendee = Attendee(name: participantName!, email: participantEmail!, required: isRequiredParticipant, hasAccepted: hasAccepted)
participants.append(attendee)
}
}
return participants
}
This appears to be a problem with the EKParticipant.url property. Any attempted access of EKParticipant.url causes a crash if you have a participant with the following email field within it.
"Bill Gates" <billgates#google.com>
I'd guess the quotation marks end the String prematurely. It is fine when accessed from EKParticipant.description so I intend to parse it from there.
This is a ridiculous issue, and Deco pinpointed it exactly. I used a different approach to get around it though: Since I'm already working in a mixed code base (obj-c and Swift), I created a class method on one of my obj-c classes that takes an EKParticipant and returns its URL as a string. Then, in Swift, I call that class method to get the URL instead of directly accessing the property (and crashing). It's hacky, but better than crashing and saved me from parsing the description.
This is rather old question but yet I hit this issue myself. My solution is to fallback to ObjC in order to workaround it.
Just add this ObjC functions to swift bridging header file and you are good to use them in swift.
static inline BOOL
participantHasNonNilURL (EKParticipant* _Nonnull participant) {
return participant.URL != nil;
}
static inline NSURL* _Nullable
participantURL(EKParticipant* _Nonnull participant) {
if (participant.URL != nil) {
return participant.URL;
}else {
return nil;
}
}
Example of usage:
extension EKParticipant {
var optionalURL: URL? {
return participantURL(self)
}
var hasURL: Bool {
return participantHasNonNilURL(self)
}
}
This is still an issue on macOS 11.2... I have reported it to Apple. I encourage anyone else hitting this issue to do the same.
The only Swift-only workaround that worked for me is:
extension EKParticipant {
public var safeURL: URL? {
perform(#selector(getter: EKParticipant.url))?.takeUnretainedValue() as? NSURL? as? URL
}
}
Validations are added incorrectly, please check the below response about how the guard could be used.
if let attendees = event.attendees, event.attendees?.isEmpty == false {
for participant in attendees {
guard let participantName : String? = parse(EKParticipantName: participant) else{
log.error("error in participant name")
return
}
guard let participantEmail : String? = participant.url.absoluteString.lowercased().replacingOccurrences(of: "mailto:", with: "") else{
log.error("error in participant email")
return
}
let isRequiredParticipant : Bool = participant.participantRole == EKParticipantRole.required
let hasAccepted : Bool = participant.participantStatus == EKParticipantStatus.accepted
/* guard validation is not required here */
if (participantName != nil && participantEmail != nil){
let attendee = Attendee(name: participantName!, email: participantEmail!, required: isRequiredParticipant, hasAccepted: hasAccepted)
participants.append(attendee)
}
}
}
return participants
I'm parsing an NSDictionary. I don't want to go thru item by item to make sure everything is really there and nothing is unexpectedly nil. I figured I'd just do-try-catch. But I'm getting a compiler warning. Here's my code: saying:
do {
try adminMsg = NSDictionary(objects: [rawMsg["msg"]!["Title"]!!,
rawMsg["msg"]!["Text"]!!,
rawMsg["msg"]!["Time"]!!],
forKeys: ["Title", "Text", "Time"])
} catch {
adminMsg = nil
}
But I get this warning:
"no calls to throwing function occur within 'try' expression"
Does this mean I have no choice but to crash if an item is missing from the dictionary? I can't trap it and let my code gracefully tell the sender they sent me an invalid NSDictionary (unless I check it all out item-by-item in code)?
I can't trap it and let my code gracefully tell the sender they sent me an invalid NSDictionary
You cannot trap a fatal error, no. What you can do is catch the missing elements by using optional binding.
guard let title = message["Title"],
let text = message["Text"],
let time = message["Time"]
else {
// Missing data; inform caller
}
This is how you gracefully tell the client that there's something wrong with the data. You could return nil, an empty dictionary, or throw an error: whichever suits you best.
To make this properly Swifty, you should first define your data:
typealias RawMessage = Dictionary<String, [String : AnyObject]>
/** Important keys in a `RawMessage` */
enum RawMessageKey : String
{
case message = "msg"
case title = "Title"
case text = "Text"
case time = "Time"
}
enum RawMessageError : ErrorType
{
/** The `RawMessage` has no "message" key */
case NoMessage
/** The `RawMessage` is missing an expected inner key */
case MissingKey
}
Then your extraction function. This uses optional binding, not force unwrapping, to check that the key "msg" is present. Force unwrapping failure cannot be "caught"; that's not what it's for.
If the key is not present, you signal that to the caller by throwing your own error. Then use further optional binding to get the rest of the items. If any are missing, again throw an error.
/** Pull important values from `RawMessage` and repackage as `NSDictionary` */
func extractAdminMessage(rawMsg: RawMessage) throws -> NSDictionary
{
guard let message = rawMsg[String(RawMessageKey.message)] else {
throw RawMessageError.NoMessage
}
let keys = [String(RawMessageKey.title),
String(RawMessageKey.text),
String(RawMessageKey.time)]
guard let title = message[String(RawMessageKey.title)],
let text = message[String(RawMessageKey.text)],
let time = message[String(RawMessageKey.time)]
else {
throw RawMessageError.MissingKey
}
return NSDictionary(objects: [title, text, time],
forKeys: keys)
}
If you prefer, using flatMap could be an alternative to the stacked unbind:
let keys = [String(RawMessageKey.title),
String(RawMessageKey.text),
String(RawMessageKey.time)]
let objects = keys.flatMap { message[$0] }
guard objects.count == keys.count else {
throw RawMessageError.MissingKey
}
Here, any missing value will be dropped by flatMap; then if there aren't the same number of keys as objects, signal your caller.
I came up with this:
let rawMsg : NSDictionary =
["msg":["Title":"sometitle", "Text":"sometext", "Time":"sometime"]]
let adminMsg = NSMutableDictionary()
if let msg = rawMsg["msg"] as? NSDictionary {
for key in ["Title", "Text", "Time"] {
adminMsg[key] = msg[key]
}
}
That works even if a key is missing from the "msg" dictionary. You won't crash at any point during that, not matter how malformed rawMsg may be.
(It would be better if adminMsg were a Swift dictionary rather than a Cocoa NSDictionary, but at least this seems to cover the original problem domain.)
A few suggestions
Stop using NSDictionary and use Swift dictionary instead
Don't use exceptions to manage control flow
The force unwrap ! produce a fatal error, you cannot catch it
What you should do instead
if let
msg = rawMsg["msg"],
title = msg["Title"],
text = msg["Text"],
time = msg["Time"] {
let adminMsg:[String:Any] = ["Title": title, "Text": text, "Time": time]
}
I have been reading about Optionals in Swift, and I have seen examples where if let is used to check if an Optional holds a value, and in case it does – do something with the unwrapped value.
However, I have seen that in Swift 2.0 the keyword guard let is used mostly. I wonder whether if let has been removed from Swift 2.0 or if it still possible to be used.
Should I change my programs that contain if let to guard let?
if let and guard let serve similar, but distinct purposes.
The "else" case of guard must exit the current scope. Generally that means it must call return or abort the program. guard is used to provide early return without requiring nesting of the rest of the function.
if let nests its scope, and does not require anything special of it. It can return or not.
In general, if the if-let block was going to be the rest of the function, or its else clause would have a return or abort in it, then you should be using guard instead. This often means (at least in my experience), when in doubt, guard is usually the better answer. But there are plenty of situations where if let still is appropriate.
Guard can improve clarity
When you use guard you have a much higher expectancy for the guard to succeed and it's somewhat important that if it doesn't succeed, then you just want to exit scope early. Like you guard to see if a file/image exists, if an array isEmpty or not.
func icon() -> UIImage {
guard let image = UIImage(named: "Photo") else {
return UIImage(named: "Default")! //This is your fallback
}
return image //-----------------you're always expecting/hoping this to happen
}
If you write the above code with if-let it conveys to the reading developer that it's more of a 50-50. But if you use guard you add clarity to your code and it implies I expect this to work 95% of the time...if it ever failed, I don't know why it would; it's very unlikely...but then just use this default image instead or perhaps just assert with a meaningful message describing what went wrong!
Avoid guards when they create side effects, guards are to be used as a natural flow. Avoid guards when else clauses introduce side effects.
Guards establish required conditions for code to execute properly,
offering early exit
When you perform significant computation in the positive branch, refactor from if to a guard statement and returns the fallback value
in the else clause
From: Erica Sadun's Swift Style book
Also as a result of the above suggestions and clean code, it's more likely you will want/need to add assertions into failed guard statements, it just improves readability and makes it clear to other developers what you were expecting.
guard let image = UIImage(named: selectedImageName) else { // YESSSSSS
assertionFailure("Missing \(selectedImageName) asset")
return
}
guard let image = UIImage(named: selectedImageName) else { // NOOOOOOO
return
}
From: Erica Sadun's Swift Style book + some modifications
(you won't use asserts/preconditions for if-lets. It just doesn't seem right)
Using guards also help you improve clarity by avoiding pyramid of doom. See Nitin's answer.
Guard keeps code that handles a violated requirement next to the requirement
To be clear, guard isn't always about success vs failure. The more generic way to see it is about handling a violated requirement vs process code that isn't violated.
example:
func getImage(completion: (image: Image)? -> Void) {
guard cache["image1"] == false else {
completion(cache["image1"]!)
}
downloadAndStore("image1") { image in
completion(image)
}
}
In the above the requirement is for the image to not be present in cache. If the image is present then our requirement is violated. We return early. As you can see we also handle the violated code path, right next to its requirement i.e. the structure is not:
if requirement {
.
.
ten lines of code
.
.
} else {
handle requirement
}
The Swift Docs on Control Flow explain the idea behind that:
Using a guard statement for requirements improves the readability of
your code, compared to doing the same check with an if statement.
It lets you write the code that’s typically executed without wrapping it in an else block
it lets you keep the code that handles a violated requirement next to the requirement.
Guard avoids nesting by creating a new variable in the current scope
There is one important difference that I believe no one has explained well.
Both guard let and if let unwrap the variable however
With guard let you are creating a new variable that will exist in the current scope.
With if let you’re only creating a new variable inside the code block.
guard let:
func someFunc(blog: String?) {
guard let blogName = blog else {
print("some ErrorMessage")
print(blogName) // will create an error Because blogName isn't defined yet
return
}
print(blogName) // You can access it here ie AFTER the guard statement!!
//And if I decided to do 'another' guard let with the same name ie 'blogName' then I would create an error!
guard let blogName = blog else { // errorLine: Definition Conflicts with previous value.
print(" Some errorMessage")
return
}
print(blogName)
}
if-let:
func someFunc(blog: String?) {
if let blogName1 = blog {
print(blogName1) // You can only access it inside the code block. Outside code block it doesn't exist!
}
if let blogName1 = blog { // No Error at this line! Because blogName only exists inside the code block ie {}
print(blogName1)
}
}
For more info on if let do see: Why redeclaration of optional binding doesn't create an error
Guard requires scope exiting
(Also mentioned in Rob Napier's answer) :
You MUST have guard defined inside a func. It's major purpose is to abort/return/exit scope, if a condition isn't met:
var str : String?
guard let blogName1 = str else {
print("some error")
return // Error: Return invalid outside of a func
}
print (blogName1)
For if let you don't need to have it inside any func:
var str : String?
if let blogName1 = str {
print(blogName1) // You don't get any errors!
}
guard vs if
It's worth noting that it's more appropriate to see this question as guard let vs if let and guard vs if.
A standalone if doesn't do any unwrapping, neither does a standalone guard. See example below. It doesn't exit early if a value is nil. There are NO optional values. It just exits early if a condition isn't met.
let array = ["a", "b", "c"]
func subscript(at index: Int) -> String?{
guard index > 0, index < array.count else { return nil} // exit early with bad index
return array[index]
}
When to use if-let and when to use guard is often a question of style.
Say you have func collectionView(collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int and an optional array of items (var optionalArray: [SomeType]?), and you need to return either 0 if the array is nil (not-set) or the count if the array has a value (is set).
You could implement it like this using if-let:
func collectionView(collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int
{
if let array = optionalArray {
return array.count
}
return 0
}
or like this using guard:
func collectionView(collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int
{
guard let array = optionalArray else {
return 0
}
return array.count
}
The examples are functionally identical.
Where guard really shines is when you have a task like validating data, and you want the function to fail early if anything is wrong.
Instead of nesting a bunch of if-lets as you get closer to finishing validation, the "success path" and the now successfully bound optionals are all in the main scope of the method, because the failure paths have all returned already.
I'll try to explain the usefulness of guard statements with some (unoptimized) code.
You have a UI where you are validating text fields for user registration with first name, last name, email, phone and password.
If any textField is not containing valid text, it should make that field firstResponder.
here is the unoptimized code:
//pyramid of doom
func validateFieldsAndContinueRegistration() {
if let firstNameString = firstName.text where firstNameString.characters.count > 0{
if let lastNameString = lastName.text where lastNameString.characters.count > 0{
if let emailString = email.text where emailString.characters.count > 3 && emailString.containsString("#") && emailString.containsString(".") {
if let passwordString = password.text where passwordString.characters.count > 7{
// all text fields have valid text
let accountModel = AccountModel()
accountModel.firstName = firstNameString
accountModel.lastName = lastNameString
accountModel.email = emailString
accountModel.password = passwordString
APIHandler.sharedInstance.registerUser(accountModel)
} else {
password.becomeFirstResponder()
}
} else {
email.becomeFirstResponder()
}
} else {
lastName.becomeFirstResponder()
}
} else {
firstName.becomeFirstResponder()
}
}
You can see above, that all the strings (firstNameString, lastNameString etc) are accessible only within the scope of the if statement. so it creates this "pyramid of doom" and has many issues with it, including readability and ease of moving things around (if the fields' order is altered, you have to rewrite most of this code)
With the guard statement (in the code below), you can see that these strings are available outside the {} and are made use of, if all fields are valid.
// guard let no pyramid of doom
func validateFieldsAndContinueRegistration() {
guard let firstNameString = firstName.text where firstNameString.characters.count > 0 else {
firstName.becomeFirstResponder()
return
}
guard let lastNameString = lastName.text where lastNameString.characters.count > 0 else {
lastName.becomeFirstResponder()
return
}
guard let emailString = email.text where
emailString.characters.count > 3 &&
emailString.containsString("#") &&
emailString.containsString(".") else {
email.becomeFirstResponder()
return
}
guard let passwordString = password.text where passwordString.characters.count > 7 else {
password.becomeFirstResponder()
return
}
// all text fields have valid text
let accountModel = AccountModel()
accountModel.firstName = firstNameString
accountModel.lastName = lastNameString
accountModel.email = emailString
accountModel.password = passwordString
APIHandler.sharedInstance.registerUser(accountModel)
}
If the order of the fields changes, just move respective lines of code up or down, and you are good to go.
This is a very simple explanation and a use case. Hope this helps!
Basic Difference
Guard let
Early exist process from the scope
Require scope existing like return, throw etc.
Create a new variable that can be accessed outside the scope.
if let
Can not access outside the scope.
no need for return statement. But we can write
NOTE: Both are used to unwrap the Optional variable.
guard let vs if let
func anyValue(_ value:String?) -> String {
guard let string = value else {
return ""
}
return string
}
func anyValue(_ value:String?) -> String {
if let string = value {
return string
}
return ""
}
The clearest explanation I saw was in the Github Swift Style Guide:
if adds a level of depth:
if n.isNumber {
// Use n here
} else {
return
}
guard doesn't:
guard n.isNumber else {
return
}
// Use n here
guard
A guard statement is used to transfer program control out of a scope
if one or more conditions aren’t met.
The value of any condition in a guard statement must be of type Bool
or a type bridged to Bool. The condition can also be an optional
binding declaration.
A guard statement has the following form:
guard condition else {
//Generally return
}
if let
Also popular as optional binding.
For accessing optional object we use if let.
if let roomCount = optionalValue {
print("roomCount available")
} else {
print("roomCount is nil")
}
I learnt this from swift with Bob..
Typical Else-If
func checkDrinkingAge() {
let canDrink = true
if canDrink {
print("You may enter")
// More Code
// More Code
// More Code
} else {
// More Code
// More Code
// More Code
print("Let me take you to the jail")
}
}
Issues with Else-If
Nested brackets
Have to read every line to spot the error message
Guard Statement
A guard block only runs if the condition is false, and it will exit out of the function through return. If the condition is true, Swift ignores the guard block. It provides an early exit and fewer brackets.+
func checkDrinkProgram() {
let iCanDrink = true
guard iCanDrink else {
// if iCanDrink == false, run this block
print("Let's me take you to the jail")
return
}
print("You may drink")
// You may move on
// Come on.
// You may leave
// You don't need to read this.
// Only one bracket on the bottom: feeling zen.
}
Unwrap Optionals with Else-If
A guard statement is not only useful for replacing a typical conditional block with an else-if statement, but also great for unwrapping optionals by minimizing the number of brackets. To compare, let's first begin how to unwrap multiple optionals with else-if.
First, let us create three optionals that will be unwrapped.
var publicName: String? = "Bob Lee"
var publicPhoto: String? = "Bob's Face"
var publicAge: Int? = nil
The Worst Nightmare
func unwrapOneByOne() {
if let name = publicName {
if let photo = publicPhoto {
if let age = publicAge {
print("Bob: \(name), \(photo), \(age)")
} else {
print("age is mising")
}
} else {
print("photo is missing")
}
} else {
print("name is missing")
}
}
The code above certainly works but violates the DRY principle. It's atrocious. Let us break it down.+
Slightly Better
The code below is more readable than above.+
func unwrapBetter() {
if let name = publicName {
print("Yes name")
} else {
print("No name")
return
}
if let photo = publicPhoto {
print("Yes photo")
} else {
print("No photo")
return
}
if let age = publicAge {
print("Yes age")
} else {
print("No age")
return
}
}
Unwrap with Guard
The else-if statements can be replaced with guard.+
func unwrapOneByOneWithGuard() {
guard let name = publicName else {
print("Name missing")
return
}
guard let photo = publicPhoto else {
print("Photo missing")
return
}
guard let age = publicAge else {
print("Age missing")
return
}
print(name)
print(photo)
print(age)
}
Unwrap Multiple Optionals with Else-If
So far, you've been unwrapping optionals one by one. Swift allows us to unwrap multiple optionals at once. If one of them contains nil, it will execute the else block.
func unwrap() {
if let name = publicName, let photo = publicPhoto, let age = publicAge {
print("Your name is \(name). I see your face right here, \(photo), you are \(age)")
} else {
// if any one of those is missing
print("Something is missing")
}
}
Be aware that when you unwrap multiple optionals at once, you can't identify which contains nil
Unwrap Multiple Optionals with Guard
Of course, we should use guard over else-if.+
func unwrapWithGuard() {
guard let name = publicName, let photo = publicPhoto, let age = publicAge else {
// if one or two of the variables contain "nil"
print("Something is missing")
return
}
print("Your name is \(name). I see your, \(photo). You are \(age).")
// Animation Logic
// Networking
// More Code, but still zen
}
The main difference between guard and if statements in swift are:
The if statement is used to run code when a condition is met.
The guard statement is used to run code when a condition is not met.