WWDC2004 Session 317

Transcript

Kind: captions Language: en so at the end of the week your your brains are probably filled with lots of ideas about how you might use some of the new api's that have been discussed a lot of the new technology that's been demo'd and what i'd like to do today is talk about the tool that hopefully you'll be using one of the tools anyway that hopefully you'll be using to implement some of your new ideas interface builder since this is announced it sort of an advanced session I'm assuming you you're comfortable with interface builder what I want to do though is focus on part of interface builder that I think up until recently has been fairly unutilized or underutilized until recently because if you went to the quartz composer session today or the QT kit session the other day you saw some great interface builder palettes that have been created also if you look in flash developer / extras / pallets on your DVD you'll see a number of new palettes that have been created by teams outside of the interface builder team and what that means is basically well to some extent i didn't know that these other teams were working on these pallets but more importantly it means that these other teams did this without the help of interface builder team and in particular they'll be using basically the same process that we're going to be talking about today so again if you have an opportunity to see or look at the slides from those previous two sessions or say one of the cocoa binding sessions you'll see some interesting new palettes that have been created and as well as look on your disk so John was going to introduce me but I'm Chuck Fleming manager new manager of the IB team and again what we want to talk about today is interface builder and how to extend it make it more powerful and extend it by creating your own pallets so you should I guess first of all I ask why would you want to write an interface builder palette what does it do for what does that do for you and first of all it gives you a very convenient way to get your objects in the hands of your developers in a way that they can use those objects to build applications and customize those objects to fit the application that they're building you can have of course two different sets of developers your internal developers developers in your company or your colleagues here in a university setting but if your objects that you're creating our innovative enough or interesting enough or useful enough you may actually consider number two which is go ahead and sell these things as object where and I think I've listed on the screen one company that's doing that producing some very nice pallets so you might take a peek at the website and check out what some other folks are doing and the third reason if you if you've gone to any of the cocoa binding sessions you know Coco bindings is introduced was introduced last year and is very exciting technology that's been displayed this year as well particular in the quartz composer session this morning terrific use of bindings was as shown in the setting of interface builder palette so third reason why you might want to write appellate is to take full advantage of cocoa bindings for your custom views with in interface builder the only way really to expose your bindings at this point is to implement a pallid so very quickly topics we're hoping cover number one building and debugging palettes sort of getting things going quickly step 2 some additional pallet task that's we're going to talk about how to make things a little bit more fully functional add some features that you would expect to have your inspectors fully working maybe undo support tooltips things like that third and fourth topics a little bit miscellaneous collection of topics here are some tips not entirely related to palettes but they touch on topics that you should know as you're writing palace or playing with nibs in general and then very quickly i'll just give some performance suggestions okay so how do you make a pallet you use the two tools that two of the tools apple provides Xcode we are going to provide you with an enhanced template project template for specifically for making pallets it's a significantly improved over the one that's currently shipping that's in the disk image that will be available for download at the end of this session and then interface builder itself because you're going to assemble the pallet graphically and also assemble the inspector graphically and that's what interface builder is all about assembling you eyes graphically so the first thing we're going to take the very simplest case how many of you guys have built a palette before okay a smattering but not overwhelming which is good because even though this is advanced topics i'm going to start with the real basic stuff and it's very easy to do so hopefully i won't bore the advanced users here too much so we're going to start with the template that we're going to provide and then we're going to make some modifications to the three classes that get generated with the template which is the palette inspector and view class itself so i'm going to bring John Hef whose newest member of the IB team he's just joined us recently and he's going to help me do some real quick demo so we're going to do a lot of switching back and forth and just try to focus on a few things as we go so the first thing John's just going to show us you know sort of a very basic process of getting started with the new template and John one thing that I don't think we mentioned was could you just tell folks where that template live that temple is going to be on a disk image that we're going to provide to you at the end of the day it will be available for download and also in the file system well we're going to actually get the template to work with interface builder you're going to need to put it in your home folder in the library okay let me just go ahead and show you in the finder we're going to step through the the template lives in home library application support apple developer tools project templates standard apple plugins in here we have our IV palace wewt 2012's that's a long path but it's also the place where the standard xcode templates live so if you're familiar with that it's the same place except starting in your home directory so i'd like to go ahead and introduce you guys to the wwc 2004 template for building interface builder pallets so i'm gonna go ahead and launch xcode and create a new project now since we have that template living in that folder will be able to see it here in the standard apple plugins so i'm going to select the IV palette WT 2004 and create a new project named widget so our new project here on the screen it's going to include everything we need to do to get started building an interface builder palette the most important thing to notice about the the project is that it's been divided into two targets we have a widget target in a framework target the widget target is going to hold our interface builder palette which is going to be everything we need to configure our our object that we're exposing through interface graphically where while the widget framework is everything that application needs to consume the widget at runtime so let's go ahead and take a look first at the widget framework I'm gonna go ahead and expose the target membership here so you can see exactly which files belong to which groups so in our framework folders all the files that by default belong to the widget framework and here we have a view object that subclasses from nfcu so we're going to use this to provide a new view accusers and also in our palates and our pilot folder we have two interesting classes of nodes we have an inspector that we're going to use to configure the pallet graphically to configure the view graphically and a palette it's going to hold the view so that users can drag and drop it into their projects so with this I'd like to give it back the Chuck to continue the presentation okay can we get the flies again okay so very quickly what was generated for us three classes the widget class which is a view that's going to pier on your palette the inspector which is going to be the files owner for the inspector nib file and the palette which is sort of a controller object is also the files owner for the palette nib that got created for us we'll look at those in details in a second so again widget that's the view object that's going to go on the palette and by by default it's the subclass of ennis view when we switch over to looking at non view based palette objects you're going to have to change that yourself to make it whatever class you want it to be in we did them again that's the view that you're going to put on your palette it has the template creates a skeleton implementation of three methods for you that you do need to fully implement and it with frames and it with coder and encode with coder and it with frame you need because that gets called when your view first appears on the pallet ni b and that gets loaded lazily so it doesn't happen automatically it will happen say for example the first time you click on the tab that represents your palette in the palace window and I be and it with frame will get called so any initialization you'll do there the nitwit coder encode with coder are needed because for example when you drag your widget off the pallet in ib into your design window we're going to archive that object and put it on the pasteboard so in code with coder will get called there and then we drop it in the design window it'll get unarchive and so a nitwit coder will get called and finally for example when you save your nib file with the new object in it that object will get freeze-dried again or archived and so in code with coder will get called so you need to implement those three methods and again since this is an advanced or advanced session I'm assuming you guys know about coding and some of the standard app kid and foundation techniques what else was created would you palette that's a subclass of IV palette and basically the most important to take home point on this one is it should be the files owner of the widget pallid nib in there again skeleton implementations of a couple of methods finish instantiate this guy is primarily used when you have the non view case when you have an object that you're going to put on the palette which is a subclass of ennis view but you need to associate a visual proxy for that object so that you can graphically manipulate it even though it's not of you normally you do that association in finish instantiate and we'll show you the teeny bit of code you need to make that happen and then also the inspector class name by default a reasonable choice is given there that isn't what you need then you can certainly modify that the inspector class is created for you that's the subclass of ib inspector it's the attributes inspector for your widget and again it should be the files owner of the inspector nib okay again here's the stub implementations that are created for you in it okay in revert and it is probably where you want to load the bundle that contains your inspector nib file in co or sorry okay and revert mirror each other revert is going to be called by ID and give you the opportunity to pull information from the inspected object and insert it into the UI your inspector and okay does the opposite when you get when you trigger the okay action you'll be responsible for pulling information out of the UI and pushing it into the object that you're being expected so these guys are trying to keep things in sync and so in the back here heads you should be thinking cocoa bindings so this is the old style it works fine think in terms of cocoa bindings as you go forward because this is a synchronization issue based let's see what else couple of nib John's going to show us those in just a second basically the palette is where you assemble what's going to appear in IV in its pallet window files owner you're going to have to change that because we couldn't do that for you in the template and the inspector knit itself that's where you're going to inspect or assemble the widgets that will get extracted and then put in the inspector in interface builder is running and again the files owner i'll mention this several times files owner needs to be a setup set appropriately right so John I think you were going to just give us a quick look at those nib file okay so let's go ahead and try to make this a sample project run a bowl with interface builder and the first thing we're going to do is we're going to fix those files owners like Chuck mentioned so I'm going to open up through the files that i'm going to show you now which are the widget pallet nib and interface folder and next we'll do the widget inspector so in the widget palette viously we have the files owner in one window is very important that the files owner has this custom class set to be a widget palette also the files owner needs to be connected to the to this palette view right here and we can see it's connected this palette view is what's going to be loaded into the interview they spill their palates section over here and we'll be modifying that later let's also open up the widget inspector and make sure that it's files owner is set to be an instance of widget inspector also we need to make sure the files owner is bound to the widget fitted to the widget inspectors window so now we have our nip set up and will be ready to move on shortly Chuck exercise okay so that's sort of the the minimal setup and now we just want to add a tiny bit of code so you can see that well we have a functioning pallet at this point so John's going to do a real quick modification to the code build it load the pallet and see that it really is sort of functional so back to the demo okay so we have our palette here and on our palate we'd like to place a widget view so what we're going to do to do this is put in an NS custom view they were to change the custom views custom class to be a widget now at this point we have everything that's needed to get a widget loaded into interface builder but unfortunately our widget doesn't paint itself so we wouldn't be able to see it so we're going to modify the widget scales and it was generated for us by the template and we're going to include a draw rect method so in the draw method we just want to make it visible for now so I'm going to go ahead and choose the blue color and go ahead and fill our clip rectangle with blue now from here we can build a project and we wind up we want to go ahead and make sure it gets installed in the correct location so I'm going to go to my to go to our home folder move to libraries frameworks library framework going to framework frameworks and here's our widget framework and then also we go two pallets will see that we have our widget palette so let's go ahead and go back to interface builder and let's go ahead and load up our widget palette so in interface shoulders preferences its last tab is the palette tab we can choose to include our our palette here here's our widget palette i'm going to select it and it's going to load up in interface builder at this point we can create a new nib and our widget is fully functional and ready to be dragged and dropped into new applications so that's all we have to do to get a view on to a pallet chef and also the inspector looks like he did command one yep so we can see in the inspector that interface builder is aware that this inspector is expecting a widget object and if we were to have edited our inspector nib the properties would appear that ok back to the client please okay so I want to kind of move on to the non view case which is really not much different from the view case just a slight modifications but before leaving the view example I wanted to point out that on the shipping panther and i'm not sure if it was earlier but certainly panther and tiger if you look at on your hard disk ian flash developer / examples / interface builder you'll find a nice fully featured sample project called progress view pallet that illustrates in some more detail the process of getting a view based object on a pallet ok so again heading towards the non view based object case before i get to their what i want to do is just mention something that's probably obvious but when you assemble an application and you're bringing things off the pallet that say your palette objects into the application and building it designing it and then you save and build at runtime of course your application needs to have access to the code for those pallet objects so clearly one way to do that would be you've got the source code to m and H for your custom views you could distribute those but that would get pretty tedious probably a better approach is to make sure that the classes for objects on your palette and associated objects that may be needed are wrapped up in a library or sorry a framework and so one of the things our new palette does is it make that job easy for you certainly customizable but it will create the framework for you and install it in convenient location as well as the same for the palette as John showed so what we do with the framework is it will end up installed until the library frameworks and the palette gets installed in till the library palette okay so back to getting an object on a pallet where that object may not be a view based object or a subclass of NS view so it requires a small change to the nibs and some small code monkey asians so the templates going to make that easy John's going to show us again in detail some of these things but what the palette project does for us the new project is it sets up three different targets one for the framework one for the palette and an aggregate target ten sets of several new groups to organize your code in a reasonable way establishes build dependencies for you exposes the headers that you might need it provided create some files to support undo implements the or gives you a palette table in which you can store some other information like tooltips things like that so John I guess you're going to show us some more of the details then about what we actually give you in this template and by the way I should mention I'm old goswami from universe filter team helped us out in designing and building this this project so this is a big help it's much superior to the shipping one so here we have another Xcode project generated from our template this is we're going to use we're gonna use this project to put a non view based palette object onto a palette and we will see that again where art project is divided into two targets a palette for interface builder in a framework the framework includes the object that we're going to place on to the interface builder Palace which is here a random number generator and the palette folder a group contains all the stuff we need for interface builder to let us edit our graduate or objects graphically so it's like the previous project we have an inspector and we have a palette and we also have the niche generated for both the the inspector and the palette again we also have Bill dependency set up in this so there's a palette requires the framework to build this way the random number generator only lives in one library and interface builders women need both the palette and the actual random number generator in order to include those anger projects whereas application developers will only need your framework to use your random number generator so you want to show the command so we show that we could we can see those projects those dependencies here by looking at one of our targets in the inspector and we can see that the random number palette requires the random number framework I also showed the dependencies on which which files belong to which target if you would fetch sure so in the the framework is all the coke like that like I said all the files that belong to the framework which applications are going to need we can see these two files belong to that and if we look at the interface builder palette will see that all the rest of files belong to the individual or cosmic Center facial they will need this code in these nibs in order to edit the object graphically in its runtime and also if you could disclose the undo support as well so we will provide birth sorry couldn't ok so when an object is being edited in interface builder we're going to take snapshots that object when you tell us to when we know that you're that your inspector is about to head its object and these IV class description files expose the property for the object you want to have snapshot at runtime so for example for a random number generator we're going to take a snapshot of the men value the max value and the frequency attributes which are the instance variables of the random number generator and so when the user presses undo we'll be able to swap back to old values and swap in as the user modify things and presses on do so these classes are key to implementing I do support and interface builder okay that could define please okay so as we mentioned earlier you've got a non view-based object like a random number generator you want it on the palate you need to graphically manipulate it so you need to assign a proxy view to it very simple process you're going to instantiate to the object and then you're going to associate a view with that object so John's going to quickly show us where we do that in the code so it's interesting to think of how we can put a non view-based object into an interface color palette since the palette contains a few objects so we go out to look at our random number palette which I'm opening interface shoulder now we see that we have this are here representing a random number generator this is what we want the user to see in the interface builder palette when they're using our palette that we're generating for them however we inspect this we'll see this in NS image you not a random number generator so what's going on behind the scenes is in our palate up in our palate classes finish instantiate method we're telling our base class to associate a random number object with that image view so the so our base class which is the IV palette is going to know that when the user drags one of these images that when he deposits the image onto his object browser he really means to deposit a random number generator and not the NSM HBO that he initially dragged so that's how we're able to put non view-based objects into palettes and have the IV runtime manage that for us ok next two slides ok so before going any farther there is a very nice example again that shipped with answer a little and tiger that you might want to take a look at that shows you in addition to the tips and tricks will show you today some additional features that we won't have time to get into for example some supporting drag and drop onto your objects that in fact gives you a nice example where you might need something done before the instantiate object which is where we just did that mapping between the view object and the non view object or the view proxy and the non view objects sometimes you need to do stuff before finishing fancy eight and one of the things is for drag and drop support so you will implement your and knit method and do that there so a place to look for some some other very good tips is / developer sample interface builder and look at the busy pallet example okay so at this point we we have the bare minimal functionality and we want to go on in and show what's involved in making your inspector fully functional I'm sure you have a pretty good idea what we need to do supporting undo and redo which hopefully John's given us an indication that that's pretty trivial and then what about working with cocoa bindings hey John ok so we've already seen putting an object on to a pallet twice now let's go ahead and take a look and see how the inspectors work I'm going to go ahead and open the inspector nib that was genitive was generated for us and we had modified and in the inspector you'll see that we have properties reflecting what was in on do support we have a text field for setting the maximum and minimum value along with the frequency of a random number generator will see that each of these has an action that's bound to the files owner through his o each of these three text fields has its ok method bound to the targets owner so when you finish editing either the text boxes the files owner which is the inspector is going to get the ok message and no to push the properties that are reflected in the inspector to the object that is representing you'll also notice that each of these texts feels is connected to the files owner via outlets so the files owner knows where to read the values from let's go ahead and build our project now like we did with the previous project and make sure that it gets installed in the correct location quickly we can note while it's building that in the random number inspector in the ok and in in ok and revert methods where we're pushing the properties from the view to the object and from the object to the view we can see it it into ok method we're telling interface builder to the object will change this is the point when interface folder is going to use that IV class description that you generated to take a snapshot of your object for an archiving the future to implement undo so now that our projects built let's go make sure it's in the correct location which again is in your library frameworks folder there's our random number generator and let's also make sure we've got the talent and our palette so back in interface builder we can go to the preferences we can choose palettes we can press add and select our random number palette so in the random number pal let's go ahead and actually utilize this in Xcode i'm going to create a new project and we'll make it a sample will use the cocoa template for an application and we'll call it random harness so since I random harness is going to want to use our random number generator we need to import the framework that we generated with the random number project so we're gonna add that to our project so in a hour library in library frameworks we're going to grab random number framework we're going depend on that and let's go ahead and put a random number generator into our nib file so in our resources we're going to go to the main menu did okay we should start that back up so in our main menu so we got to grab the random number generator again so here we go and in our nip that we just generated were going to grab one of these random numbers and like we said we associated random number generator with the Senate image view and when we drop it we're going to get a random number generator okay so to utilize this let's go ahead and put some graphical elements on our window to expose what's going on with the random number generator I'm gonna put a text tool here and two buttons put a start button and a stop button and let's go ahead and configure our random number generator with the inspector that was shown earlier so let's say it will have a min value between 0 100 and let's go ahead and make it fast so we'll have the frequency 2.2 so if we set the stop buttons action to be stopped on the random number generator and do the equivalent for start and we're going to go head and use cocoa bindings tell the text field to bind to the value that's exported by the random number generator so tell us actually able to get its value now it looks like we have a bug yeah we should be able to see random number generator here and choose random number here are we running tiger I don't think so no that's probably our problem that is our problem so the latest release of interface builder you can choose other optics besides NS controllers the bound 2 for cocoa bindings so when you go ahead and use your latest copy of Tiger that you'll provide with you'll be able to bind to over this random numbers random number I bar for your text field display the value is automatically but with the older version we're not allowed to do that so that's yeah we should have been kind of surprising that there's no object controller here so we've added preliminary support so that you can bind directly to model objects and not just controllers so unfortunately though it looks like we're running a version of Panther here so okay go back to the slide okay so what did we just do well we really didn't do anything we had this all pre can but basically the steps that you would need to do as John pointed out you've got the inspector you're going to drag some text fields or graphical widgets in there you'll take the inspector which is the files owner and hook up and set up outlets to point to those widgets so that when the revert method gets called i should say when the revert message gets sent otherwise John will scold me so when that message gets set the revert message that we can get to those objects in the inspector and pull the values out and insert them into the inspected object and then you also want to set up your actions your okay actions so that when say you do something in the inspector you trig enact trigger an action which will then get sent to your inspector object and the result is your inspector object and wants to take the values from the UI and push those into the inspected object that's basically what what you'll need to do okay undo support is very easy on you make slight change to your ok mess and add a IV class description file now the template that we provided has done that for you in fact here's John actually showed us this as he was looking at the inspector implementation but the highlighted text shows you how basically to support undo you'll want to call that second line or have that second line implemented for every object that happens to get changed when you're doing the inspection and then the class description file again you just list the instance variables the names of the instance variables that you want to participate in undo if you have a class that has a bunch of I bars and only a small subset and obviously you want to a little performance enhancement is just a list of ones that need to participate okay inspectors and cocoa bindings so as I mentioned earlier we've got this okay and revert method thing going on that keep things in sync and that's precisely what Coco bindings is good at doing for you without writing those those those methods implementing those methods so it works very well with on on Tiger with you sorry nan view based objects interface builder is have been around for a long time it much earlier than Coco bindings so that means there are pots impossible edge cases when you're working with view based objects in particular we do some caching of the images that might make you work a little bit harder to get things to refresh when you implement undo and redo but basically it should work there might be a few edge cases so you might have to do a little tweaking so I think John you were just going to show us the example what's involved what's what's left in your project after you use the cocoa bindings approach for an inspector so like Chuck said bindings are a great thing to use in inspectors because all you have is one to get set mappings keeping the objects in sync so here instead of having an ok and revert method in slightly different instance of the random number generator project instead we just have set value we're overwriting the key value coding for our class to push the values from the inspector back to the object and we have on do support here by telling like just like we said in okay we're telling IV this object is about to change so we can take a snapshot and save it for later so really now has eliminated all that getting set code and both the okay and revert methods more inspector and instead we just have this one set value method which is a short three lines okay so normally you see the people bring up the project with the file merge so you know the okay and revert methods are now gone there were no instance variables left and you're down to a minimal amount of code okay that's fine okay just a few additional details where does ib look for pallets where should you put the pallets it looks in a bunch of places but the places we recommend till the library pallets till the developer pallets classes that you want to expose you know the main class that you've put on the pallet plus maybe some auxiliary classes make sure those are mentioned in the palette table file tool tips when you're in the palette window in ID itself and your mousing over objects in your palette you can specify tooltips you do that also in your palate table one thing I did mention on the slide is the image that represents your objects on the palette that you click on you can specify that in the palette table file okay very quickly I just want to mention a couple approaches to debugging your palettes and then a couple of topics that may be useful while you're debugging palettes but also may be useful in general to let you modify how things look depending on whether you're running in ib or whether or not you're running in ivs test mode so first of all debugging well if you're from the old UNIX world then you're old friends you know terminal Emacs GDB still work great okay so you always a fallback but if you want to do at the xcode way xcode now provides a very nice way to debug your palettes you've got your palate project you're working in i sorry xcode has a facility for assigning a custom executable to your project and basically the custom executable you want is interface builder so when you launch the application your custom application will be interface builder you're in your palate project you set breakpoints in the appropriate places or reasonable places for example in your inspector class name finish instantiate ok revert any reasonable places you want to see this code being executed or not something's going wrong why then simply start gdb in Xcode your and load the palette so that makes gives you a nice graphical environment in which to actually debug your palate ok the other two questions can you determine if you're actually running in ib or not well you can just basically ask does your widget class for example responded selector is in interface builder I be defines that in a category on nsobject so you can simply see if and the implementation is highlighted here so you can just test do your respond to that and if you're in interface builder but maybe you want to know whether you're in test mode or not maybe you want to do some drawing differently so you can see you know what what state you're in you can simply ask in its application are you in test interface mode so that's a method that's made available through IV application editions which is a public header ok so you're going to switch gears just a little bit now and talk about some things that are perhaps not entirely late it related to pallets but good things to know they do help you if you understood so in your understanding of how pallets work good things to keep in mind but also for nib loading in general and some of these we see a lot of questions on the mailing list especially from beginning pallet programmers about what methods get called messages get sent and when in particular an it or an it with frame depending whether your view or non view object awake from the other net with coder and so on so the first case is you've just clicked on your palette in the palette window and I be what happens first well that's where your net with frame will get called on your view class let's take the example again this is a view based object so in it with frame gets called there then the next thing you drag that view into your design window again it gets archived when it gets put on the pasteboard when you drop it it gets an archived so in it with coder gets called first and then I'm sorry in code with coder when we archive it and then in it with coder when we drop it then you save the nib and then in your running application that nib gets loaded so what happens when the nib gets loaded this freeze-dried object mysteries freeze-dried view that you had in your nib file gets unarchive so an it with coder gets called some folks expect so this is a view mine it with frame will get called but no it's the anit with coder that gets called because again it's a freeze draw and we're following this object when the application runs so this slide just basically summarizes what we saw in the previous slides so a nitwit coder the second side I think is a little bit more important than it with coder is going to get called not your knit with frame and then of course after that awake from nib will get called a couple of caveats to keep in mind you count on your connections have all having been formed in the in it with coder you have to wait until away from nib to make sure all your connections are formed so again this was a case of you in the case of a non view object on the palette instead of basically everything is the same except in it with frame gets called are sorry admit gets called instead of an it with frame and it's important to note if your non view object has an initializer other than in it that's not going to get called so this only works well if your view and it would frame or if your non view it needs an init to work in an IV pally here's another case suppose the time you take a custom view which is one of the system provided on one of the system provided palettes and you drop that into your design window but you want to make that view a special subclass some subclass that you've provided either you've dragged in the header or you pick another class subclass of view that's available in ib itself so you have a new view here now called my view so what happens when that gets saved well the custom view is the thing that actually gets encoded okay and it keeps track of the fact that oh by the way I really wanted my subclass of view to be used at runtime so the next step say at runtime when that maybe gets loaded the custom view is the thing that gets on archived and then it realizes oh we really didn't want to cut the custom view we wanted that subclass of view so basically the custom view kills itself off and allows for your subclass of view to get created so in this case and it with frame does get called your subclass didn't get unarchive it actually got created the normal way so in this case and it with frame gets called okay and then that previous slide was just a summary of what we saw on screen let me skip that for save us some time here the final and probably the most confusing case that we run into is suppose you dragged off a system view not a custom view not a palette but some sort of system view from ib palette typical case might be an in its button even more typical a lot of people taken GL view which we provide on the pallet you drag that off into your design window and then you want to change what class it is so instead of say in its button you've got your subclass of button and so you use the classes tab in IV or the class inspector and you switch what class it is so again you might have a subclass of button or subclass of OpenGL view so again there's two ways you can come up with a subclass of OpenGL view you could bring a custom view in and change it or you could bring in an OpenGL view in and then change it so we're in the second case where we've taken a system view we're changing its class what happens in that case well this is a little bit strange but what happens is the NS button in this case gets archived so it's in code with coder gets called when we save the nib and then when the mid gets loaded at runtime well something gets unarchive in fact the emit with coder to your sub class gets called even though what got encoded was the NS button so you have to be careful if you do implement some encode with coder on your sub class that's not going to get called and furthermore you probably shouldn't be pulling out especially for type stream the old type stream version of archiving you don't want to be pulling things out of the stream assuming that those are things that you put in there for your sub class because it's actually the superclass that got encoded ok so the behaviors a little bit strange there so because of that strangest you should be asking well why would you ever want to do that why would want to bring in a button and then change its class well one answer is say button or some widget that the system provided may have a lot of attributes that and state that needs to be set and that state can easily be set in the inspector for that object so you can take advantage of setting up all that state by using the inspector that you inherit okay all right so looks like we're in pretty good shape for time the final topics that I want to talk about basically are related to performance and some some tips on on designing your nibs so for example one way to get some nice performance in certain cases is used in a snit which is reasonably new if you use NF nib you can get enhanced speed improvements at possibly a cost of memory you get to load the nib from the disk just one time and then once it's in memory you can instantiate it as often as you want very quickly and again the trade-off is between loading speed in the memory footprint okay so here's a little bit of sample code about if you haven't used in its need before something like this give you a start so for example if I wake from nib I'm going to get a hold of the main bundle for my application and the next line is basically setting up a dictionary which is used to set the files owner on the nib file and then I have an action method here which basically if I haven't already allocated the NS nib I'm going to go ahead and call Alex and it was me obtain colon bundle colon that's going to load it from the disk but it doesn't instantiates that objects are not created they're not in memory and then the next line is how you actually instantiate the nib and then the final line is say that if had some window in it so you could do making order for so you see it come on screen so a possible use for something like this is say i chat where you have incoming requests from people to start a conversation you might want to get those chat windows up as fast as possible you might not want to hit the hit the disk okay something like that a couple of pointers system documentation on loading resources okay good for some more detail okay the mid content strategies that are related to this nibs are fairly cheap if you load them into memory you can get them on screen fast if you load them from disk as long as they're not too heavy weight that that's really not shouldn't be a problem but remember that every object in your nib is going to get instantiated so excuse me so they're cheap as long as they're skinny don't try not to put a bunch of windows in your nib file don't put a lot of objects that perhaps could be lazily loaded stored in other nibs and loaded or other bundles and loaded when needed okay and the other thing when you're finished with a nib file make sure you free the top-level objects okay and against more details on where you can get information on those topics slides will be available