[MUSIC] Welcome back. In this lecture, we're going to go through the architecture of a watch app and sort of the basic concepts, so you can sort of understand what you need to do and how things work before we get started actually coding anything. So again, we from last time, after we added the target, you have a watch app and a watch app extension. And these are very different as you can see the watch app doesn't hold code and extension does. The watch app only basically only has a storyboard and some images that you use inside the storyboard. Watch app is very, very different from iOS app. You sort of have to think of it like start from a clean slate when thinking about it. The story board is mandatory and you must define your UI using this story board. Every screen you're going to show, you have to have a story board scene for it. And also have a controller for it and extension. And so, even though these are not in the same target, your storyboard scene still connects to the controller's, interface controllers of the extension and they get. And the storyboard basically is a true storyboard for the watch app. From the storyboard you should be able to see every scene and pretty much and every interface component like button and label in the story board. And just this code can control it and the system will call your code, like the life cycle methods, as you go. So, to sort of get a better understanding of these rules, I'm going to borrow this very useful image from Apple's development watch OS guide, which you can find online, and in the supplementary material for our course as well, you'll find the link to this. So, in watchOS 2 which is up here, you see that we have the iOS app running on iOS on the phone, and on the watch we have watchOS which is the system, and you have your watch app sort of encapsulating the watch kit extension. And that's our extension, that's our app. And the reason why the two are separate is really because of watchOS 1, where the watch app was on the watch, and the watch extension actually lived on the phone. As you can see this is very interesting. The code was always executing on the phone, while the assets like the resources or storyboard was only on the watch. And every time you had to update the UI or anything, you would actually have to wirelessly. So, the connection here is bluetooth. It's not, like it's very, very slow compared to, like connection between chips on a device. So, watchOS would have to talk to iOS, tell it that you need a new interface update, your code would run on a iPhone, and then send back the update to update on the watch. On watchOS 2, that works way better now. You can still communicate between your watch app extension, through to OS to your atlas app, but that's now only to sort of send data back and forth, which can still do or pass notifications, pass triggers or any events, and no longer just do execute, like interface related code. All right, so if you sort of understand this, so both of these are living in the watch, which means that access between this code runs quickly and can update the interface quickly. And we can go back to the story board. So, again the basic concepts are that the story board defines the scene. Lots of similarities to iOS, there's also definitely a lot of similarities to iOS. One of these scenes is controlled by a interface controller. But again, everything is a lot more simplified. Is a lot more simplified and just a lot more strict. In this default interface controller, you have the life cycle of an interface controller. And that is you awake. And then you will activate or did deactivate. On the watch, you only have one interface active, like active, at any moment. And that's the one on top. Unlike iOS, there's practically no background stuff running. You can do some networking stuff, you can do some backgrounding stuff but generally speaking, there's only one interface controller active. So, what that means is that you want to be strict if you have multiple interface. It will tell you when you've deactivated. And when you're deactived, you can sort of stop doing some stuff and you're done. You don't get to write anymore code. When you're interfaced will appear again will activated will be called. Sort of like view will appear and view will disappear and view did disappear. But much more important, like its much more strict set of methods. And awake with context is basically an initialization method and this gets called as when the app launches. And that is very interesting. So that is very important. So, when the watch app launches, it actually instantiates every single interface control you have in your storyboard. And we'll call awakeWithContext on all of them. And what that means is that the performance of this method is very important. You don't want to do any big calculations, you just want to set up your interface elements to sort of the initial state here. And with that, you'll allow the watch app to start up. And then it will activate when this controller will actually be shown. That's when you set up due to calculations and actually say, put in the data, etc. Do the computations you need to display the actual data. And that will be, so it doesn't have to get run for all of the interface controllers upon starting which is a very big overhead. All right, so there's one more class or a file in the beginning. By default, and its ExtensionDelegate. So, this is sort of parallel to the app delegate. It handles a lot like the application level, web cycle methods, and as you can see there's a lot less. There's only three. Unlike iOS, which gives you a bunch. DidFinishLaunching, DidBecomeActive and WillResignActive. It's very much like DidFaceControl. Now in this delegate, you would also implement talking to the iOS app, etc. Those are generally, if you look into the extension delegate, which is always a good idea to look at, the definitions, you notice that it can handle actions, which are notifications, and you can handle user activity. You can launch for a notification, these just handle those actions and you got all this stuff. You also have methods, you can call on it on the [INAUDIBLE] kit extension. To access like the root stuff and you can open system URLs and get shared extension and de-delegate itself. So this is sort of like the UI application. And this is the UI application delegate, except on the watch. Okay, so one more point before we end this lecture. So, there's two assets and that's very interesting because they're both under watch now. They used to be different because one would live on the phone, one would live on the watch. But they behave as if it was like that. So, the storyboard only accesses its assets. When you have interface elements that are in the storyboard from the start, you put them in this access.xcassets along with the app icon. So, then the storyboard can only grab images from this assets, whereas this code when you click [INAUDIBLE] image and you want to say set it to a new face component or sent to the phone, whatever you want, you would put them in signed assets here. So, you want to make sure that, so assets here are basically data or like UI elements that are not set here. Sort of set in the storyboard by default and need to be created from code. So, there's another quick difference, where in code, it doesn't work really the same as LS. Often you set things by their name. You reference things directly by their name, so you can set interface augments with like an image name, and that actually looks for the image inside this asset. So, you're telling the interface, is telling the system to look for an existing image on the watch app, which is here inside that two interface. So, that's sort of the different there, between the extension and the watch app itself. And in the next lecture, we'll start building out our interface.
