This workshop will be retired on May 31, 2020.
Compare Fun Facts in Swift and Objective-C: Part 18:38 with Gabe Nadel
Let's work through two versions of a very simple iOS app. We will highlight some of the differences to help begin building fluency in both languages.
[MUSIC] 0:00 Hello again. 0:04 By this point in your journey you should be at least somewhat familiar with both 0:05 Objective-C and Swift. 0:09 Apple development is now living in a duel language era and we at Treehouse believe 0:11 to prepare you for success you're best getting comfortable with both. 0:15 In this short workshop we'll take the same fun facts app 0:19 written in both Objective-C and Swift and we'll highlight the differences. 0:21 If you haven't been introduced to both languages yet please check the teacher's 0:25 notes for the courses or workshops which are right for you. 0:29 They vary considerably in length and detail so 0:31 take a moment to pick the right path before you devote too much time. 0:34 As you'll see this is a very simple app so 0:38 many of the language differences will be more syntactic than architectural. 0:40 If the differences we discuss in this lesson seem painfully simple, don't fret. 0:44 We go into greater depths in the links provided below as well as the other 0:48 bridging content further down the iOS track. 0:52 Before we go poking around the code, let's run both apps and 0:56 see that they do indeed they do the same thing. 0:59 First we'll try the Objective-C code. 1:02 I'm going to use Command R here. 1:04 And I'll tell you why we don't have a run button in just a minute. 1:07 Okay, we see a fact displayed. 1:10 We can show a new fact, another fact. 1:12 Okay, great. 1:15 We'll home that. 1:16 Now we're going over to the Swift code. 1:17 We'll run that And here we see some other facts, 1:21 new colors and it behaves just the same as we hoped. 1:28 By the way this app is serving up facts at random so 1:33 that's why we did not display the exact same text and colors. 1:35 As you'll see, the functionality and logic is essentially identical. 1:39 Okay, let's stretch out the two projects here so we can see as much as possible. 1:43 And if you've ever tried to put two projects side by side, 1:48 you may have encountered a problem making them as narrow as I've made them here. 1:51 The trick to doing that Is that you need to hide your toolbar. 1:55 So if the toolbar was showing it would say hide the toolbar here. 1:58 When you hide it, then it allows you to make the window nice and narrow. 2:02 Otherwise it would have a minimum size of about out to here an that wouldn't work 2:05 for the kind of side-by-side kind of display we wanna do today. 2:09 So one thing that you probably will notice right off the bat is that 2:13 we've got a lot more files over here on the right in our Objective-C code. 2:17 In fact, the names of the files are almost all the same, but here in Objective-C, 2:22 we have a .h and a .m as opposed to just one file over here in Swift. 2:27 Well in case you don't recall, 2:35 In Objective-C a class is divided into two files. 2:36 A header file denoted with the .h, and an implementation file denoted with a .m. 2:40 Now this project is so 2:46 small there isn't a whole lot to look at in most of the headers. 2:47 But if we open up ColorModel.h, 2:51 we can see just a few examples of what you are likely to find in a .h. 2:53 So starting from the top, first we see two import statements and we need to 2:57 include these here so we can utilize all the good stuff contained in foundation and 3:02 UIKit in the meat of our class. 3:06 Speaking of our class, below that we see our ColorModel and 3:08 it inherits from NSObject and that's what that little colon here means. 3:13 Below that we've got a property declaration with some memory directives. 3:18 And this here property is an NSArray of UIColors. 3:23 Below that we see a method called getRandomColor, 3:28 which is gonna return a UIColor, and it all ends with the @end. 3:32 Now for a more complex class, often there are a dozen or more properties and 3:38 methods declared, 3:42 which is why it can be nice mentally to have your .h segregated from your .m. 3:43 From a technical perspective it's nice because your code usually needs to import 3:49 the .h to the other classes, 3:52 rather than the .h and the .m, and the .m is usually much, much larger. 3:54 If we compare this to our Swift color model file 3:58 we're greeted with several syntactical differences. 4:03 And we'll talk about those in a moment. 4:07 But there's also a telling architectural difference. 4:08 Can you spot what that is? 4:11 Well, we see here in the Swift version that the entity, 4:13 ColorModel isn't a class at all. 4:16 It's a struct. 4:19 Now, in Objective-C, folks are permitted to use C structs. 4:21 But almost always, developers just make the jump to creating a simple, 4:24 custom class like we did over here. 4:28 So it seems like now would be as good a time as any 4:32 to highlight this important feature of Swift. 4:34 That is, more robust structs. 4:37 As opposed to the lightweight C structs available in Objective-C, 4:40 structs in Swift have much more in common with classes. 4:44 Both can define properties and methods. 4:48 Both can utilize subscripts and custom initializers. 4:50 They can also both be extended beyond the default implementation and 4:53 conform to protocols. 4:57 This is a lot more functionality then you get with a c struct, 4:59 which is why you see structs used so much more often in Swift. 5:02 That said, 5:05 classes come with their own unique capabilities not offered by structs. 5:06 Some of the most important ones of those are Swift 5:11 classes offer inheritance when you subclass one from another. 5:14 Swift classes offer reference counting, so 5:17 you can have multiple references to an instance. 5:19 Swift classes have deinitializers, and Swift classes offer typecasting so 5:22 you can check types at runtime. 5:27 One other important thing to remember is that structs are value types, so 5:29 they're copied, rather than referenced, like classes which are reference types. 5:33 If you'd like to read more about classes and structs in Swift, I've linked a very 5:38 useful Apple doc below that's almost sure to quench your curiosity. 5:42 To highlight some of the syntactic differences, let's hope into FactModel.m. 5:46 In our .m, we see that we have a custom init method. 5:52 Init means initializer, by the way. 5:56 Inside of which we call init on our superclass, which we can check in the .h, 5:58 this is NSObject. 6:03 And now, once self is initialized. 6:06 We see that we're assigning the initial value to our facts property 6:08 using a literal syntax. 6:12 We see the literal syntax used here to create the array. 6:14 That's the at square bracket. 6:18 And then again for each string, 6:20 a literal syntax which is our @", @", @", and so on. 6:23 Swift uses literals as well as can see over here, but those literals 6:29 don't have an at, just the quote and in this case just the square bracket. 6:35 Back in our Objective-C file, We scroll down, 6:40 we see we have a method implementation for our getRandomFact method. 6:45 Note in our Swift version how we specify that we're creating a constant, 6:50 containing the output of our random function, whereas in Objective-C, 6:55 it's simply an int variable. 7:00 Of course in Swift that type in inferred as the output of this is gonna be an int. 7:02 One thing underlined that might now be second nature to an experience Swift dev 7:09 though perhaps less so to an Objective-C dev is that this constant 7:13 isn't really the analog to the kind of constant we usually see in Objective-C. 7:18 Not always, but often, the constants we create and 7:23 use in Objective-C persist for quite some time. 7:26 We might use a constant like fixed price or preferred frame rate or 7:30 a limit on the number of results we want from queries. 7:34 Essentially, they would usually have a fixed value once our program is running. 7:37 More or less how we think of constants when we do a physics or 7:41 a chemistry problem but here in Swift a new constant 7:44 called randomNumber will be created each time we call this function. 7:48 It could be called a million times within one run of this app. 7:52 It will only be relevant to our program for a very short time though 7:56 during that time will not be permitted to change, it's still a constant. 8:00 So this constant is still a constant, though it serves a very different purpose, 8:04 architecturally, than most Objective-C constants do. 8:08 Below that we see the syntax for getting a value from a particular index of an array 8:12 and that's a bit more concise than the version we see over in Objective-C and 8:17 being concise is pretty much how Swift rolls. 8:22 The last tidbit to point out within this file is that our .m ends with the @end but 8:25 that's not going to be here over in Swift because this is all contain 8:30 within a struct. 8:35
You need to sign up for Treehouse in order to download course files.Sign up