Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
Let's continue our discussion of the syntactic and first-level architectural differences between the two primary languages for iOS development.
-
0:00
Now, let's pay a visit to our view controller class.
-
0:03
Which if we were to pop into the story board in either the Swift or
-
0:06
Objective C version, we would see it's the only class shown there.
-
0:10
This is a very simple app after all.
-
0:14
In the Objective C version, in our .m.
-
0:17
We see that up top, we've imported the classes that we created and
-
0:21
will wanna use.
-
0:23
In the swift version, we don't need to do that because, as we mentioned before,
-
0:26
we're using structs rather than classes.
-
0:29
Below that, we see how we're declaring our IB outlets.
-
0:32
They're similar in the two languages, though in Objective C you would often find
-
0:37
these over here, declared in the header file.
-
0:39
A couple notable differences are that here in Swift,
-
0:43
we can use the syntactic sugar for an implicitly unwrapped optional.
-
0:48
That's this little exclamation point right here.
-
0:51
By the way, the term syntactic sugar means a sweeter or
-
0:54
simpler way of writing code that is shorter or more pleasant for
-
0:57
the dev, but doesn't actually alter the functionality of a code.
-
1:01
If you need a refresher on implicitly unwrapped optionals and
-
1:04
what they're used for, check the link below.
-
1:07
Another effect of using structs instead of classes is that in the swift version,
-
1:12
we don't have to call alloc and init like we see over here.
-
1:17
Instead, we can just use a call like that.
-
1:22
It's also worth noting,
-
1:23
that in our functions in Swift, we can end with an empty set of parenthesis.
-
1:30
This is shown here and in the viewDidLoad method, and down here as well.
-
1:35
If you aren't used to seeing those, they're common to lots of C-base languages
-
1:39
like C# or Java, but they're not seen in Objective-C methods.
-
1:43
By the way, they look a little more useful and appropriate when they have parameters
-
1:46
inside, but these functions don't require them.
-
1:49
If you're making the switch from Objective-C to Swift,
-
1:52
chances are you may forget these at the beginning.
-
1:54
I know I did when I was learning C# and it caused a gray hair or maybe three.
-
1:59
More substantial than this syntactical difference I just mentioned
-
2:02
is that in Swift, functions are first class types.
-
2:06
That means that they can be passed as parameters, used as return types and
-
2:09
assigned to variables.
-
2:11
If you'd like a refresher on that, check the links below.
-
2:14
We have touched on some of these already but let's cruise through the rest of
-
2:18
the files and point out some of the other little differences that can get you
-
2:22
tripped up when moving from one language to the other.
-
2:24
For one thing, Swift is gonna save you just a little bit of time with no
-
2:29
semi-colons at the end of every line.
-
2:32
On the flip side, you will be expending a few key strokes specifying override,
-
2:37
like we do here and here.
-
2:40
And we do that when we're overriding a method found in the super class.
-
2:44
But before you get too upset about those wasted keystrokes,
-
2:47
it's actually a good trade for the safety it provides.
-
2:50
If you have a subclass in Swift, and you give it a method with a same name as one
-
2:54
found in the parent class, like for example, with viewDidLoad.
-
2:58
The check for
-
2:59
the override keyword at compile time will ensure that it was intentional.
-
3:04
Perhaps, it wouldn't happen with a famous function like viewDidLoad.
-
3:07
But it is easy to create duplicate function names in different classes
-
3:11
once you start naming them after logical functional parts of your code.
-
3:16
We can call the overridden versions found in the class like we see up here for
-
3:21
fact model, or we can call the super classes versions, like we see here,
-
3:26
and here by using super and then dot.
-
3:32
showFunFact is actually just an IB action hooked up to a button, so
-
3:36
we don't actually call it anywhere in our code.
-
3:40
In our objective C version,
-
3:42
we use the self keyword to access the properties we've declared in our class.
-
3:47
But we don't need to do that in Swift.
-
3:49
You will see self sometimes in Swift, especially in relation to closures, but
-
3:54
you wouldn't need to do it here just to get at the properties.
-
3:58
If we hop over to our app delegate,
-
4:00
we can see a couple more differences worth pointing out.
-
4:05
In the did finish launching with options method,
-
4:08
we see how what we declare a return type differently in the two languages.
-
4:12
In Swift, we use an arrow and then the return type, and
-
4:16
over here in Objective C, we do it at the beginning inside a set of parens.
-
4:21
We also see the declaration of an optional here in window.
-
4:27
We also see a declaration of an optional here for window.
-
4:31
An optional being a Swift variable that explicitly may or
-
4:35
may not have a nil value.
-
4:37
This question mark here denotes a vanilla optional,
-
4:40
as opposed to the implicitly unwrapped optionals we saw a moment ago,
-
4:43
which was declared with the exclamation point.
-
4:47
I hope this little side by side comparison was helpful in highlighting some
-
4:50
of the common differences you'll need to be comfortable with
-
4:53
when switching between Swift and Objective C.
-
4:55
Now when I say differences, I do mean the little things like semi-colons, or arrows
-
4:59
for return types, but much more important are the architectural and fundamental
-
5:03
differences, which really should drive how you craft your code in projects.
-
5:07
It's important to get comfortable with those larger concepts and
-
5:10
principals in each language so you don't find yourself trying to
-
5:13
translate your syntax without really picking the appropriate tool for the job.
-
5:17
Since we know that tool boxes are different between the two languages and
-
5:20
we wanna put those tools to use correctly.
-
5:23
Depending on how much exposure you've had to each language,
-
5:26
you might wanna spend some additional time boning up on one or the other.
-
5:30
Subsequent courses will draw on both and reviewing legacy code,
-
5:33
hacking on your own or reading other developer's perspectives or
-
5:36
just the Apple docs will be time well spent.
-
5:39
Having a firm grasp on both Swift and Objective C
-
5:42
will position you very well to work on a wide array of projects, both old and new.
-
5:47
You'll probably also find that the work you do in one,
-
5:49
will actually improve your understanding of the other as you internalize
-
5:53
the important feature differences.
-
5:55
Until next time, happy coding.
You need to sign up for Treehouse in order to download course files.
Sign up