iOS App Development with Swift

Structs, Protocols & Errors

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
iOS App Development with Swift

Check out a free preview of the full iOS App Development with Swift course

The "Structs, Protocols & Errors" Lesson is part of the full, iOS App Development with Swift course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano answers student questions regarding having structures instead of tuples and if classes are more efficient than structs. A walkthrough of error management using do, try, and catch is also provided in this segment.


Transcript from the "Structs, Protocols & Errors" Lesson

>> Do you have any questions? At this point, yep?
>> Yeah, so earlier you had, didn't you have types that were you could have like-
>> Tuples?
>> Yeah, tuples, so Is it better to have the structures or tuples?
>> So let's say that the human has a name and let's say an age.

Now, you can see that they will get an error in line 14, because the age is not optional I need to add the age, okay? And let's say I'm 15, right? I look like 15, so what's the difference between this and defining a type like, let's say I have Anna instead of using a human, a structure, I define an string integer tuple, that I can even set a name for each segment of the tuple, right?

So and then I say, Anna, is 20, what's the difference? Well first, in this case,oh, because it's an integer, no a string. So I cannot have functions in tuples, so no methods. And also no protocol compliance that we didn't see that yet. But those are the main differences, okay?

So you use tuples for very simple data. Again, coordinates something that you don't wanna mess with that just instead of having x and y, you create coordinate with x and y inside and nothing else. But if you wanna add behavior, it's better to create a structure, but in memory, there are kind of similar, in terms of the memory used, it's kind of similar.

>> Confused, because I thought he said structures were of no methods, but they have methods.
>> Yeah, structures, they can have methods, they can have initializers.
>> So with objects is it just reference, no reference, that's the only difference?
>> With classes.
>> That's the only difference, with classes?

>> Yeah.
>> Okay.
>> And also, you don't have a super class.
>> Okay, you can hear it.
>> So you don't have the part of OOP.
>> Okay, okay.
>> So it's a kind of a half baked class but more efficient.
>> Okay, so it's created to have more efficiency in it.

>> Yeah, exactly, but on a normal IOS application you prefer efficiency over what OOP is offering you. And most of the time you have a lot of situations that you're using classes when other languages because you don't have our other option and maybe extracts are a better fit.

>> So whenever you don't need to have full objects then this is better.
>> Yeah, in most cases you don't need full option from classes. Be careful because sometimes we call instances of abstract and instances of classes. The option term sometimes can be applied to both. It's more typically two classes, so you have an option of a class.

But sometimes you will see people saying you have an option to find a structure because it's also an instance in memory. We prefer instances.
>> In Swift you cannot initialize the structures.
>> Yeah, I mean, you don't yeah I mean you don't need to create an initializer but you can, so I can have here, So now in this case, this is a default initializer.

So without arguments, now it's complaining here because if you set an initializer, you're removing the default initializer. So now if you want to receive name and age, you need to create another one manually that receives the name and the age. If you don't set an initializer, you have one by default.

But if not you need to manually create it.
>> Okay.
>> Okay? Well, on their match we have already seen the quickly the gar, things that we're not going to use later. And actually something that I can quickly show you, because most of you are expecting this to happen.

But I wanna tell you that try catch here works completely different from what you're used to. And most of the framework is not using exceptions. There are libraries and parts of the framework that may be using exceptions. So this is more from your own code, okay? So you cannot catch some exception from the system because there are not exceptions, they're using other ways to manage error.

The exception system exists here If and if not try catch it's do catch. And then there is a time that you need to use as a prefix to the function that throws. So if you have a function that throws it says here throws, you can throw an exception.

How do you call that function that throws with a try, prefix, okay? It's more similar to how a weight works cane in other languages what also here. So use do these code and some of this code will throw exceptions, some other code will not throw exceptions. But I wanna emphasize that you will see later that we are not going to use this.

And an standard iOS application that talks to the UI will never use this. Because the framework in the basics is not using exceptions, you can use exceptions in your own model, okay? In your business logic if you want. And for that you have an exception framework and you have, do try catch.

But let's say for now is part of advanced swift and not part of basic swift because you don't need to use it by default, okay? So at this point, I think that you're ready to start doing something with what we've seen. And I know that there are more to see about swift, but also we need to create an app.

And you will see that every single we've seen in swift it's enough to understand how to make an app, okay? And we're going to reemphasize these concepts as long as we are coding our app.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now