Xcode Libraries & Frameworks: The Don't Call David Ortiz Episode

In the latter innings of a baseball game, there is no confusion over who calls who: The manager calls the bullpen. Question is, which pitcher(s) in the bullpen is the manager calling for and how quickly do the relievers need to get ready? 

It's questions like this that get developers thinking about new apps and what steps to take to build them. In our manager's case, he needs an app that calls the phone number of the bullpen phone, an app that displays on the bullpen phone screen images of the pitchers he wants to get ready, and indicates how quickly he wants them to get warmed up (maybe on a scale from next inning to next batter).  

If we were to build out this bullpen app we would have to navigate Xcode appropriately.  

Oh, and if David Ortiz calls the bullpen he's not much of a conversationalist. He prefers to let his bat do the talking.

Xcode may be most well-known for its ability to write software for Apple's iPhone OS (Operating System), but that's not all Xcode can create software for. In fact, with Xcode you can write software for iOS, watchOS, tvOS, OS X, and the always popular "Other". Not only can you create applications for each of these operating systems (OS), but you can also write frameworks, libraries, and system plug-ins for OS X. 

That's all great, but what does it all mean, why are libraries and frameworks important, and when do we use which? That's what we'll cover in this post as we dig a little deeper into Xcode.

Getting Started with iOS

When it comes time to start a new project Xcode gives you some options. Do you want to create something for the iPhone (iOS), for the Apple watch (watchOS), Apple TV (tvOS), for a Mac laptop or desktop (OS X), or something else? These options appear on the left hand side of this window:

In the above case, we see our iPhone application options. In the same way that a baseball clubhouse manager makes sure that all the uniforms are cleaned and hanging in each player's locker ready for the game, Xcode lays out some pre-existing software formatting for each format before we even write a line of code. If you're familiar with Ruby on Rails, it's akin to Rails scaffolding. Do you need it all? Maybe. Maybe not. Either way, it's there if you do. Specifically, Xcode comes with established code for apps that are Master-Detail, Page-Based, Single View, Tabbed, or in Game formats. 

What are frameworks and libraries? And how are they different?

A good question with, apparently, no single answer as this Stack Overflow page notes. Seeing how this is our first time with this subject, let's take a broad view for now. This visual representation of frameworks and libraries may help:



So what's going on here? Let's walk through it. Say that you're a manager building an iOS app that wants to keep track of your bullpen (the green "Your Code" rectangle above).

A framework is made up of one or more libraries. Libraries are pre-existing code that you call to use their functionality instead of building out that functionality yourself. A manager can go out and try to pitch the ninth or he can pick up the bullpen phone and call for the closer who already knows what he's doing and does it much better than the manager.

In the same way, your code calls a library when it needs to use that library's code. Here are some of the most popular Swift libraries currently found on the online code repository, GitHub:



A framework, on the other hand, calls your code (the way that Zack Britton probably tried to call Buck Showalter during the 2016 AL Wild Card game; that phone may still, in fact, be ringing...). Why, or more importantly, when would a framework want to call your code?

Broadly speaking, a framework calls your code when it needs to know what to do with what it has. Here are a few examples:



Those all sound great, but what are they talking about? Good question. In general, what Ben's talking about is this: The user of your app, in this case, the manager, chooses a reliever from the bullpen and calls him. Then what? Then the framework takes that information - that the app needs to call a specific reliever in the bullpen - and calls your code to find out what to do with the manager's action. In our case, the framework learns from your code that the headshot of the chosen reliever should appear on the screen of the bullpen phone.

That's the big picture of what it means for a framework to call you. In other words, the framework's not calling you, it's calling the code you wrote so the framework knows how to properly respond to an event in your app. The Hollywood paraphrasing that some software bloggers and teachers have adopted to explain frameworks ("Don't call us, we'll call you.") is cool, but potentially confusing. Hopefully this explanation clears things up.

Here is a long list of frameworks that come with iOS-based devices.  The list includes frameworks that allow users to access their address books, for determining a user's location, and for accessing a user's calendar for event data among others.

Our manager can even create his own frameworks and distribute them if he wants so teams from Rookie ball to the majors can use the technology.

On Deck: We'll continue to delve into Xcode.

Yankee Stadium is to Ballparks As Xcode Is to IDEs

Before we jump into enumerations' cousins, structures and classes, let's discuss the ballpark where all the Swift games are played: Xcode.

To this point, all the code that I've written for this blog I wrote in an Xcode playground. A playground, as the playground likes to tell people when they first open it, looks like this:



In other words, a playground is a place where you can play with or practice writing some code to make sure if it works before writing it into your final project.

Why can't we just play around with stuff in our final project? Oh, you can and you will. But sometimes you'd rather practice that Jeter jump-throw on the playground behind an abandoned building than during Game 1 of the ALCS on national television.

So what is Xcode? Xcode is Yankee Stadium, Wrigley Field, Fenway Park. It's where you code the apps that will one day exist in the App Store. Unlike playgrounds which exist as is, Xcode has the ability to include files from your hard drive, to reach out to the web, and more. Playgrounds are games of pepper: Xcode is a full nine and extras if necessary.

If Wrigley is a ballpark, Xcode is an IDE. What is an IDE?  It is an Integrated Development Environment which is a fancy way of saying it's where you code software. Here's Wikipedia's definition:

And to give you a visual, here is Sublime Text 3, a popular text editor, where a developer would normally write code:

What you see here is code written in Python. And here is Swift code written in Xcode:

What similarities and differences do you see? Let's start with similarities. Both have examples of code written in them. In Sublime Text, all you see is code. In Xcode, you see code in the second panel from the right. 

And the differences? The biggest difference is what the other three panels in Xcode can do for you that regular text editors do not. 

On the far left panel there is a list of all the different files created for this project, these include assets such as images, videos, and sound files, it includes the storyboard which is what you see in the panel second from the left which acts as a visual of what you are building. It includes the actual files where you write code like what you see in the panel second from the right. And that just covers the highlighted blue folder in the upper lefthand corner of Xcode. To the right of that highlighted blue folder are seven more icons adding even more functionality from what errors or warnings there are and what they have to say, to a search function to find whatever it is you may be looking for, to the break point navigator that details where you have installed specific areas where the code should stop running so you can identify bugs. 

In short, text editors are like pitchers that strike out or walk everyone and IDEs like Xcode are pitchers that make use of their fielders to save their arms. Or what Crash Davis told Nuke here:

So relax. This game is fun goddammit. It's fun.

Going forward we are going to dig deeper into Xcode before returning to structures and classes.

You Make The Call: Bat or Pull Kyle Seager

Baseball has no shortage of statistics, stats that allow us to draw comparisons between players, their performances, and the likelihood of this outcome or that outcome. These stats also help managers make decisions in the course of a game.


Take Seattle Mariners' third baseman Kyle Seager for instance. This year Seager has a 1.053 OPS versus right-handed pitching. Impressive. And against lefties? His OPS is only .613. Less impressive. Chances are if Seager comes up in the late innings, that the opposing skipper is going to bring in a lefty to face him at which point Seager's manager has a decision to make: Stay with Seager or go to the bench.

To help us make decisions based on numbers (whether they are integers, floats, or doubles), Swift offers a series of comparison operators for us to use. What are comparison operators? Good question. Here they are from Apple's own documentation:




The first two aside, the rest look a lot like what we learned in school, right? Here are some baseball examples:



Now back to those first two. What is the difference between the "=" assignment operator and the "==" comparison operator?

There's a big difference. Let's take a look.

As we discussed in an earlier post about assigning values to constants, when using the assignment operator (=) what we are saying is that we are attaching a certain value to a variable or constant. In the case of Miggy, we are assigning 426 to the variable miggyHRs. We are not saying that miggyHRs are equal to 426.

It's normal to think of the assignment operator (=) in mathematical terms because that's how many of us first came to know it. But here, it's more like saying, Miggy is with the Tigers. He's not equal to the Tigers. He's with them because we've assigned him to them. But that could change, especially if Miggy is a variable.

On the other hand, when we use "==" comparison operator we are saying that whatever is on the left-hand side of the "==" is equal to whatever is on the right-hand side. This is more like the equal sign we used in math class.

More so, when you use the "==" comparison operator Xcode will either return true or false. True, those items are equal or false, those items are not equal. Xcode does not return true or false when you use the assignment operator.

Similarly, we can say that these two statements are not true as we use the "does not equal" comparison operator: (!=). Here's an example comparing the career ERAs of Ed Walsh and Addie Joss:



Now let's put these comparison operators to work with conditionals. Back to Kyle Seager. If you're Seager's manager you probably have a certain cutoff at which point you prefer to pinch hit for a player. Let's say that cutoff for Seager against lefties is an OPS of 0.725 and that Seager's cutoff against righties is an OPS of 0.800.



Challenge 1: Re-create the Kyle Seager code above using the player and cutoff figures of your choice and then take a screenshot and tweet it to me (@randallmardus).

Challenge 2: Flip the script on the Seager code and write code for a pitcher and how that pitcher deals with left or right-handed batters. Then take a screenshot and tweet it to me (@randallmardus).

On Deck: Logical operators!