In the Apple platform we have a lot of different frameworks.
So someone from that we have.
You've heard of is the UI kit and we have foundation and so many others but now we have been talking
about safety y as another framework in the Apple platform.
Now what is a framework framework is just a bunch of libraries that allow users.
In this case developers to leverage the underlying operating system.
In this case of the Apple platform that's what it is.
You like heat has all of these libraries classes and so forth that let developers invoke or leverage
the user interface and then many add properties they need to create applications on that platform.
In this case Apple platform foundation framework is another framework that its use in conjunction with
UI kit and so forth.
That gives us more capability more classes more libraries perhaps to deal with more low level and primitive
properties and classes and so forth.
Now Swifty y as you know by now allows us to create user interface much much easier.
Now deal here is that Swifty y as its own framework needs a way in which it can communicate with the
UI kit meaning because swift UI is quote unquote I would say is limited in so many ways.
At this point at least for now there are things that we may want to place inside of a swifty Y from
UI kit.
So the idea here is that we can borrow certain views or certain classes or certain things that you could
provide into our safety y.
In this process here at this point here.
So the process of taking placing views from UI kit into Swifty Y is what we call its what we call UI
view.
Re presentable protocol.
So in order for this transaction to happen we need to embed a protocol called UI view represent all.
Now the next question you may ask is what is indeed a protocol because you may have heard of protocols.
Maybe I have mentioned in passing and you may be confused.
Protocol What is that.
Let's talk about that.
Well a protocol is some sort of a blueprint that defines methods properties and other requirements that
suit a particular task or piece of functionality.
What that means is when we look at inheritance in object oriented programming we may have for instance
a person class.
And then at the bottom we have a developer while a developer is a person which means will then inherit
from person.
In this case here you can see there is a hierarchy of the top superclass and at the bottom subclasses
right the children glasses.
So a developer inherits from person.
However for more flexibility we could create some sort of a different class a blueprint of methods properties
and other requirements that can be adopted by a class or a struct or a num whatever structure that we
are creating.
So that those classes it's actually required to implement those properties methods and so forth.
In this case here a developer would say well in order for you to be a developer because you understand
you inherit from person that's that's established.
But in order for you to be developer you also have to be instructing all meaning that you have to conform
to the instructional protocol which also means that in order for you to be a developer you have to be
indestructible.
Otherwise that's not going to work.
What that means in code is that whenever we creating a developer in this case and we come farm to protocol
that just means then that I have to satisfy a certain requirement or certain requirements that our protocol
may have for us because remember the protocol is just a blueprint of what needs to be done.
It's like a contract that says OK if you confirm to me if you want to be me then you have to do these
things.
A developer in order for him or she to become a developer it has been structural indestructible as a
protocol as a blueprint will have properties methods and so forth that anybody who conforms to it must
abide by almost like a law.
That's what a protocol is.
So this now gives us a lot of flexibility because a developer could inherited from one person of course
but a developer can also implement or conform to many different protocols.
That is the beauty.
So it gives us this flexibility and notice that the protocol here has nothing to do with person or developer.
In many ways.
Right.
A developer in this case could go and confirm to many other protocol likable or whatever else.
And the protocol that may make sense for a developer.
So how does this all make sense to what we are trying to do with the UI viewer were presentable.
Well this concept is the same if we look here do you why if you were presentable protocol allows us
to put together for instance we can have a class map view and we want this map view to confirm to the
UI you represent of a protocol.
So in this case here do you I view represent a rule which has a protocol will have for instance to make
you eye view method and update you are viewed method in many others method.
And it could also have properties.
Right.
So now our map view here because we want to take this map view and put in so if you why we have to confirm
to that UI view presentable because then we have to go confirm to.
Do you have your presentable because we want to be able to take advantage of the make you eye view and
update your eye view.
In fact we have no choice.
The moment we confirmed we.
That means we are signing the contract so that we can do what is split.
What are we supposed to do which in this case has to be make you eye view and update to eye view.
What that means then is that the map view would have those methods must have those methods or must implement
those methods to actually have or add code inside of to make you eye view and empty white view.
And that's where we are able then to put the code that will then create the view and to make you eye
view and update anything inside of you.
So that then we able to embed that into a swift UI.
So any view that we may not have directly within Swifty y we can actually get all of those views from
the from the UI kit because it has everything.
Right.
And for that to happen we have to take that class we created with struct.
And it has to confirm to the UI viewer presentable because that will allow us to represent what's when
we like it into swift UI.
So whenever you hear about me saying about a protocol conform to a protocol and so forth that's what
it means.
It just means we are taking from a defined blueprint of methods property and other requirements that
suit a certain task or piece of functionality.
Right.
We're putting it all there laid out.
No implementation so that anybody who wants to use or confirmed to us or be like us they have to for
him to ask me.
Meaning that they have to implement those methods that we are making available for them.
All right.
So that's it.
So what are we gonna do now we're going to create a map view struct which will confirm to you viewer
presentable so that we can then do that then we can create the view the actual map and then update that
view instead of the Swift UI view.
Let's go ahead and do that.