Photographers can’t professionally fine-tune an image of a mountainous landscape’s foreground and background on a tiny little iPhone screen. A data scientist can’t layout graphs, matrices, vectors, and spreadsheets on a tiny little iPhone screen. A customer service representative can’t troubleshoot a technology problem without searching through several device schematics, handle several different calls at once, be on the phone with one customer, be texting with another customer, and looking at a user’s guide that shows which buttons and switches do what things on a tiny little phone screen. Can you imagine trying to design, read, write, and debug code, and layout your UI with Xcode on an iPhone? (I could on a large iPad or MacBook, but not a phone).
While working on a Swift protocol-oriented and generic linked list, I got to thinking about Apple’s “improvements” to version 4.2 of their flagship language. Since a linked list is a list, I thought, “Why not add a subscript to my linked list to facilitate finding specific nodes in my list?” I did that in Swift 4.1 and got what most developers would’ve expected, e.g., used
linkedList["node4"] to get the node in the list associated with the keyword “node4.” With Swift 4.2, I can use the controversial new
@dynamicMemberLookup language attribute and implement dot/member notation, like
We’re in the middle of Apple’s annual product upgrade cycle and this article is the second in a series of tutorials, started last week, meant to highlight the most important new features of Swift 4.2. Today, we’ll look at two two new Swift 4.2 features, the
#error compiler directives.
NOTE: The second installment of this article, “Controlling chaos: Error Handling in Swift 4 with do, try, catch, defer, throw, throws, Error, and NSError,”, has just been released.
In this tutorial, the first in a series of tutorials, we’re going to discuss the arduous topic of looking for unexpected values, events, and conditions that arise during program execution, using a technique I like to call “error checking.” Today, I’ll concentrate on the reasons why you should check for errors. I’ll mention a number of techniques I use but leave detailed discussion of those techniques and sample code to subsequent articles. The purpose of this tutorial is to convince you to make use of error checking in your apps. You ignore errors at your own dire peril. This is sink or swim. If you put out a crappy app, no one’s going to use it because you’ll get a bad reputation at Internet speed, and employers/customers will be more than happy to leave you behind forever for other app developers who aren’t too lazy to write quality code.
It is my great honor and privilege to have joined the tutorials team at AppCoda.com as a freelancer. My first tutorial, “Swift 4 Generics: How to Apply Them in Your Code and iOS Apps,” was published yesterday, and was originally published here on my own site at this link. I am looking forward to publishing many more tutorials for you, my most loyal readers, at AppCoda and here on iOSBrain.com. Note: If I cross-post an article on AppCoda and here, the article will appear first on AppCoda. Thank you AppCoda!