For the rest of this book I’ll be referencing four different types of projects when describing the various problems and solutions that we need to solve. I’ve purposefully kept these projects as small and self-contained as possible in order to focus on just those elements we need to address.
Our goal with these is not to provide an all-encompassing solution for this or that problem, but rather to provide a working code reference for our needs. To talk about source control, we don’t require several tens of thousands of lines of Swift. We don’t need a massive database application to cover building deployment targets or using schemes. What we want—no, what we need—is a very basic set of projects with code we can readily understand so we don’t spend time unnecessarily worried about this or that syntax item, but rather can direct our attention solely to the task at hand.
Our projects address four key areas:
Code conversion from Objective-C to Swift
Using the Apple Watch
Working with Apple’s HomeKit iOS feature and framework
Interfacing with external devices
Remembering that our goal is not to learn to write Swift, but rather to prepare your iOS experience for the real world, I chose projects that you’re likely to encounter as you take your skills out into the real world. There’ll always be the boring “Build a Table View” this or “Convert to Core Data” that you will have to deal with, but here, while we can, let’s have some fun while learning. Of course, what I think of as fun might significantly differ from your ideals, so we’ll just see how it goes.
Code Conversion
As the popularity and proliferation of Swift continue to grow (despite some holdouts who believe it’s not ready for prime time), you’re likely as an entry-level developer to be assigned projects where the main goal is to convert an old project into Swift. There are many reasons why this is a good idea. First, as Swift grows and more features are added to support the latest Apple devices, using Swift might be the only way to do things. That is, a desired feature may only be supported in Swift and not in Objective-C. For the short term, I suspect this to be unlikely, but if you make the conversions now you won’t be caught off guard if such a time does arrive.
Another reason for converting to the new language is to take advantage of the many safety features built into Swift. The requirement to initialize variables could save you dozens of hours you would have spent tracking down an unnecessary bug because you failed to initialize a property in Objective-C. Like anything else, there are ways around this; optionals allow you to circumvent this restriction by enabling you to indicate an absence of value for any type. Typically, when using existing framework method calls the indiscriminate use of optionals can quickly get you into trouble. First, a returned optional is an optional, not a value. A value is “wrapped” inside an optional, and thus you must unwrap it.
Note
We won’t be going into the details of the Swift language, so familiarity with the syntax is assumed.
You get into trouble when you try to unwrap an optional for which there is no value; that is, there is an absence of value. Attempting to use an optional for which no value exists by forcing an unwrap causes your app to crash at runtime. This functions just the same as trying to use a nil value with Objective-C .
Figure 4-1 illustrates the basic concept of the app that we will be converting. The code generates a simple three-wheel slot machine where the user is provided with a starting amount of credits and can place bets prior to spinning. The app produces three random positions for where the wheels will land after the spin button is pressed. A method inside the app determines the amount of the win, or that the player loses the spin. The winnings are added or the losses are deducted from the player’s bank. If the player uses all her credits, then the game can be reset.
Figure 4-1. Our first project will convert a simple slot machine game from Objective-C to Swift
Originally written in the very early days of iOS when it was still called iPhone OS, the app builds its UI programmatically. On top of the three wheels, which are in reality image strips, lies the graphic image of the slot’s faceplate. When originally written, there existed only two iPhone types: the original iPhone and the iPhone 3G. The screens were both the same size, so only one image file was required. Because several devices of different sizes and resolutions are in play now, part of the conversion process requires new image files. In order to address this concern, as would be typical in most conversions from Objective-C to Swift, I’ve included a few, but not all, of the current device sizes.
On top of the front panel image, the app stacks the three buttons and the three labels for credits, current bet, and amount won. While I would not use the same design today if I were creating this app from scratch, the use of Image Views within code should be understood by anyone looking to become proficient in iOS development projects.
Coin Toss
For our second project, we dive into working with Apple Watch. We’ll create a simple coin-flipping game called Coin Toss (Figure 4-2). As you can see, I haven’t spent a great deal of time on the graphics. That’s not what this exercise is about. Our goal is simply to create an app for the watch. That’s it. Everything else we can learn from extending our use of the libraries or adding features or even attempting to make it more of a game. We could add more intelligence or use the onboard sensors to skew the probabilities depending on the angle of the watch face relative to the horizontal plane, essentially creating a “weighted” coin.
Figure 4-2. Coin Toss game for the Apple Watch
But again, those enhancements are left up to you. My goal in writing this book in the first place is to inspire to you. I want to push you off the virtual cliff, so to speak, and let you fly on your own.
Home Automation
I call our third sample project Disco Ball because we will remotely, using an iPhone and Apple’s HomeKit framework , start our party (Figure 4-3). In reality, we can control power to any device that uses AC power, but turning on or off the table lamp would just be so boring. As with all other projects, I keep this very simple. I want to show you how to access, load, and use HomeKit to create a simple, single-element database and then do nothing more than turn that device on or off. With that simple goal, we’ll have the basic operating knowledge to start down the path of a complete home automation system.
Figure 4-3. Our third sample project controls a disco ball, which could be any AC-powered device, using Apple’s iOS home automation feature, HomeKit
External Sensor Interface
Our last project will address the use of external devices, typically called accessories, for information input and output. We’ll start with a simple, two-part logic board of my own design (Figure 4-4).
Figure 4-4. Our final project will retrieve orientation information from a remote Bluetooth Low Energy sensor board
The sensor logic board consists of two sections. First, a small MEMS (microelectromechanical systems ) integrated circuit measures movement and orientation using accelerometer and magnetometer logic. That information gets passed to a Bluetooth Low Energy (BTLE) module that sends the data out wirelessly.
For our project we assume the sensor will be placed on a human subject’s shoe, either externally or internally, using an orthotic type of enclosure. Thus, the data sent by the sensor reflects the orientation of the subject’s foot in two dimensions. The foot’s pitch refers to the amount above and below the horizontal plane of the toe; that is, how much the toe is up or down relative to the heel. The roll parameter measures the inside or outside roll of the foot, such as when you might twist your ankle when playing sports.
Our app will collect this data and visually display these two parameters of the foot onto an iPad display as shown in Figure 4-5.
Figure 4-5. Our app project graphically displays the orientation information from the sensor as the pitch and roll parameters of the foot
Sensor data will be read using Apple’s Core Bluetooth framework . The raw data will be normalized to reflect a positive or negative angle deviation, which will then be passed to a transform function to rotate the appropriate image in Figure 4-5. While we won’t go into detail on angular computations, our visualization of the information will reflect an approximate angle of the foot along either of the two axes.