WWDC2000 Session 128

Transcript

Kind: captions Language: en please welcome Ali ozar good afternoon ok so today's talk is Coco in depth and the the purpose of this session is to build upon the cocoa overview session which you might have attended on Tuesday to give you some what's more detail into some of the topics that Becky touched upon that day and also to give you a flavor more about how cocoa works and how it's designed so that in-depth discussions the topics that we're going to provide you are the document object scripting and undo which are three topics that go in hand the text system we're going to give you a little detail on that then we're going to give you a bit of performance tips and tools and how it impacts cocoa in the context of Mac OS 10 we're going to talk a few minutes about using carbon from cocoa and also how to use Java to program cocoa ok so for the first part of the talk documents scripting and undo I would like to invite Mike Farris who's a member of the engineering staff on stage Mike hello so I'm going to talk about 33 topics here which all have a bit in common by holding this wrong ah wrong button so the document architecture and the applescript support and the undo support in the app kit all have some stuff in common of the features in the kit a lot of stuff in the kit is basically widgets and things that you know you use in your application but don't necessarily affect the design of your application traditionally with the kit in the past you you know basically been able to structure your app however you feel you know you want to do that and it hasn't really impactive you in your ability to use the kit but as we try to add some of these higher level features we find that if your app has a particular structure it's a lot easier for us to do a lot more for you the structure that we've kind of chosen to hang all this is off of is the model view controller design pattern and I want to mention that basically all these features are separate but they work really well together and sort of with the document stuff at the center of the equation so if you're not familiar with the model-view-controller pattern i want to spend just a moment talking about that this is basically a design pattern I came from I think small talk originally and it's a way of structuring user interface applications and basically splitting up your object model now it divides models and the sort of three cat or objects into three categories there's your model objects that are basically data bearing they have behaviors that that behavior is basically concerned with you know how your model the thing that you're trying to represent in your application works and so you know have behaviors here that help ensure the consistency in the invariants that you need in your model the views are basically the things that you use to prevent data most of the objects in the kit are basically view type objects they help you to present your data to the user and then finally the controller is going to fit in the middle or denied everything controllers are a large amount of the code that you end up writing in an application so here's a little picture we can look at this two ways there's a couple of dotted lines which you actually can't see very clearly here actually they don't even look dotted anymore the little the black lines that kind of go down the middle of the box and divide everything into three spaces on the far left we have the model area in the middle where it says Dennis document and it's window controller that's the controller layer and then on the far right you've got the view layer now the two boxes that sort of span and enclose different parts of this these represent a couple of objects that are key in the document system and show where they kind of fit into this model in the document system and it's document objects tend to be the controller objects that own your model and then this window controller objects are the controller objects that own your UI so that's just a little little brief introduction to model view controller alright so let's dive right in to the document architecture basically the intent here is to provide a structure where we can provide a lot of the common behavior that all document applications need and and provide you with a place to put your behavior and easily customize for the kinds of documents that your application deals with now the the classes in the kit have a lot of sort of built-in implementation to do things like running the open and save panel loading nib files and managing the objects that come out of them and all the sorts of things you always have to do and they also provide subclassing and overriding points where you get to plug in your specific stuff now the document architecture is also heavily tied into the application packaging and in particular the same data that the finder uses to know what kind of documents your application opens the document system uses so that your application will know what kind of documents your application opens there's three main classes involved in the document system the first and most obvious one is the NS document class basically each instance of this class represents an open documents in your app it's responsible for loading and saving the document it also is responsible primarily for owning the actual contents of the document the model objects you pretty much always subclass and it's document to provide you know your specific kind of document a text document an image document whatever it is that your app is going to do and just to sort of look forward a little bit to the other two topics in this in this part of the session documents are typically the primary entry point for scripting in an application and then also each document usually has an undo manager so we'll get into those two aspects a little bit later now the next object is basically a singleton there's one and it's document controller in your application it knows about all the open documents and it also handles behaviors which are not associated with a particular document like new and open this is also where you would go if you actually needed to query the metadata that about your document types that's in your info.plist it parses all that when the application launches and provides you with some queries that you can make now you rarely have to subclass this object you can it's easy but mostly you don't need to bother the majority of the kinds of things that you're going to want to customize you can actually customize through the applications delegate object and then finally there's Dennis window controller basically this is a class which manages a window that is typically loaded out of the van in file and it usually manages the window on behalf of a document now documents can have multiple window controllers so you might have a cab application that had four windows you know that was showing a top and a left and a front view and you know maybe a preview a wireframe of the 3d or whatever you might also have an application that allowed multiple views of the same document to be open so that you could look at a different scales or whatever so documents can have multiple window controllers and although you don't have to subclass and its window controller it's very common to do so and one last point I'd like to make about the window controllers you can actually use them without and it's document you can sub class in this window controller to provide controller objects for your auxiliary panels and everything else and they provide management of the nib file content so if you were at beckys talk a couple days ago you saw this picture this is a non document-based Coco application and you may be wondering what you know the document system sort of changes this picture into basically the delegate object the window delicate objects become NS window controllers now a window controller often is the delegate of its window it doesn't have to be but if you're going to subclass it it may as well be and then there are in a document objects right and you can see that one of these document objects has a couple of window controllers and other than that everything's about the same you can see also the NS document controller object that it knows about all the open documents so that's a very brief introduction to document now an equally brief introduction scripting scripting is based on key value coding we'll talk about that in just a moment and the two main areas of the scripting support is classes that support you defining your script terminologies and then classes that support you handling script commands alright first of all let's talk a little bit about quezada coding because this is a totally crucial concept in the scripting framework we get key value coding from the enterprise objects framework and it is basically a standardized way of accessing pieces of an object what you do in your object is implement access or methods and they basically have a naming pattern you just you know you have a get method that's just the name of the key and then set method that goes along with it keys for example are things like the line width of this circle and the line color and so forth and so some of the methods might be you know line width and set line with wit and set width height and set height whatever the standardization part of this comes in in that there are two methods value for key and take value for key so value for key you just give it the name of a key like line with it figures out oh look okay this object has a line which method I'm going to go out and call this and return this the value of that and then takes value for he similarly works for settings but this allows a subsystem that there's nothing about your specific objects to nonetheless be able to you know get at the individual pieces of your object and and deal with them and so the scripting system makes heavy use of this how well we use key value coding to provide automatic evaluation of object specifiers if you're familiar with apple script you know that basically the receiver of an applescript command is usually an object that's qualified along the lines of okay well tell the the first graphic of the front document of the application sketch to do something right the first graphics of the front document of application sketch that's an object that's a fire we pretty much provide automatic resolution of these things using key value coding so if your document object has a key which is the graphics that that document contains and your application has a key which is the documents that the application has open then we can automatically find the first graphic at the front document in addition to the simple ones we can automatically do say arbitrarily complex whose clauses in this way we also use key value coding to provide default implementations for a lot of the common script commands you can see that you know satin get those are pretty easy to do with a key value coding we can also do stuff like move and create and you know count and exist so a lot of the core scripting sweet commands actually have default implementations and your objects won't have to specifically support them at all all you need to do is claim that they can support them and a lot of how to please support them all right so let's talk a little bit about terminologies in applescript your scripting terminology is usually broken up into sweets and so this is the granularity that we have for defining these things and script suites are defined in frameworks or applications or loadable bundles they are property lists that live inside of your frameworks or applications or bundles and at runtime cocoa is going to go out and find them all all of the frameworks your length against all the bundles you've loaded your app itself will find all the script sweets and then combine them all together and that produces the terminology for your app station now the contents of a script suite is basically descriptions of the classes that the suite defines and descriptions of the commands that it defines the classes are represented by NF scripting class description objects and basically classes have keys both properties or if you're used to databases sometimes those are called attributes and elements sometimes called relationships and then also a list of the commands that the classes support classes can inherit from each other just like in an object-oriented programming language and then the script command the scripting command description class is used to define commands in the script sweet and commands basically have arguments and have returned values and the things you'd probably expect there's a property list definition for all this stuff so that you just sort of describe in a property list the various classes and commands and then at runtime those will all be parsed in and these instances that these objects will be created to represent them now once the script editors say knows your terminology somebody might write a script and then tell it to run and at that point you're going to start getting script commands in your application so script commands come in if Apple events just like they do for any application in Mac OS 10 but we take them before you ever see them and turn them into any script command objects so these basically end a script command objects are the things that you'll see if you have to implement a handler for a custom command or if maybe your object knows that it can do you know counting better than the default implementation of the count command and basically the script command allows you access to all the important pieces you know of that command so it'll let you get at the receivers of the command which is basically an object specifier it'll let you actually get at the real receivers which is the result of evaluating that object specifier and subclasses of NS script command are actually where the default implementations are provided in cases where we can have a default implementation so you'll see in the framework you know NS set commands and get to man's and NS count commands and so on and so forth when you define your own command you can choose to have a subclass or not based on whether you're going to have a default implementation and possibly based on other things as well and then the other object that we have here is the ennis object reference class this basically represents one chunk of an object specifier so again graphic one of the front document of application sketch would turn into three object references that are all chained together and again object references know how to evaluate themselves using p value coding object references are found as both the receivers of a script command and also possibly as arguments to that command so this is all you know sounds pretty complicated it's actually pretty easy to get started with this we provide a lot of the behavior for you we have a lot of the core sweet and text sweet implemented in the frameworks that come with cocoa so the application applescript class is implemented by NS application the document applescript class is implemented by NS documents you know the window classes implementers window etc setter you can see where that's going the text suite is pretty much fully implemented by the end of text storage class so what that means to you is if you wanted to expose in your object model something that conforms to the text sweet you just have another text storage object and so for instance is sketch alright sketch has a text graphic type and you can you know type some text in whatever right and text graphic type exposes one of this instance variables which is a nanotech storage to Apple script and then boom automatically the text graphic in sketch will support the text week so there's a lot of the stuff built in there you can you know incrementally start exposing your own stuff you have to do a little bit of work to start exposing some of your model objects but often with just a very small amount of work you can get a lot of basic scripting functionality almost for free all right finally even briefer than the documents and the scripting stuff i'll talk a little bit about on do so first let me make the point undo should be implemented in your model okay you don't want to implement undo in your interface layer because then if something else comes along like for instance Apple scripts and starts talking directly to your model layer that's not a good thing if you're going to support multiple on do levels you know if somebody you know changes the font in through the user interface and then a script comes along and you know deletes that whole paragraph and then later the user says undo well okay what are you going to undo at that point right you kind of lost the synchronization of the undo stack of the model so it's very important that undo be implemented in your model it's also the easiest place to put it so that works out again for multiple undo every change your document has to be undoable because if not you're going to start getting out of sync again now the class and the kits actually in foundation that supports undo is called NSM do manager and it basically represents a stack of undo operations as I said before a document object typically owns an undo manager so in document based apps undo stacks or per document if you're not a document based app then by default undo stacks or per window now NSM do manager is based on another foundation class called NS invocation and that what that means is that basically to implement undo all you have to do is do exactly the opposite of what you're going to do every time you're going to do something all right clear enough alright so the code and yellow here is all you have to do in order to make set stroke color and sketch undoable now this is one of the primitive model methods and sketch right the graphic object has this method this is the way that the stroke color changes no matter who's changing it and therefore this is the appropriate place to put this on do logic we know that the stroke color is never going to change unless it goes through this code and every time it does change the first thing we're going to do is tell the undo manager to prepare a new invocation which will basically if undo is chosen end up sending the same graphic object another set stroke color message with the old stroke color that underbar stroke color that's our instance variable that you know contains the stroke color so as long as we just say oh ok well if I need to undo this just call it again with the old value everything is is going to be set up and it's going to work just fine now a lot of these undo invocations because they're implemented in the primitives in the model might happen during the vent but NSM do manager by default will group all of the invocations that get told to it during a single run of the event loop into one thing and now all undo together so let me give you a little bit of a demo mostly this will be a scripting demo and if we could switch we've switched ok good so I have here script editor and I have a little script which I've written that does very small amount of sketch stuff here so this script is targeted at the sketch application and perhaps I wonder if I can make that no bigger all right never blind it so you don't need to read this but basically this is going to this is going to tell sketch to create a new document and then put some graphics in it and so and so forth so if i run that you can see that it creates a new sketch document puts a little content in there and so forth and then the only other thing i want to show here is a sketch was implemented prior to scripting being available so the scripting was kind of put in later so nobody was thinking at the time about the fact that somebody might be coming in and changing things besides the user interface but because undo was implemented in the model that all just worse when we added scripting it's fine you know things that are done through a scrip are undoable the same as that if they were going to be live so okay that's the end of the demo and I believe have one more slide here which is just where to get some more info on this so there is a chapter of the programming topics document I think it's called app design and it basically goes just a lot more detail on exactly these three concepts document scripting and undo there's a new fur I think dp3 is an faq on NS document people have questions a lot of them tend to be commonly asked these are some answers there's pretty good scripting documentation that tells you how to do script sweets how to handle scripting in your app so on and so forth there's various release notes that you might want to look at and then of course there's the the cocoa reference documentation so okay now let's bring all the ups and he can talk about text is if you are at the cocoa overview session you saw Mike Farris actually put together the text edit demo and now we want to talk a little bit about the text system that he used in that demo the text system we have a fairly sophisticated text system in cocoa there are three major high level teachers first of all it's international it was designed with being international in mind it's Unicode base it supports in line input methods it doesn't support every aspect of internationalisation yet for instance you cannot type bi-directional text or vertical text in there however because it's Unicode based and because the API encourages use of Unicode and other proper methodologies if you use it the text system it's highly likely that your application will just work with bi-directional and even vertical text it's also flexible it's got multiple replaceable classes in there and we'll just talk about the major ones and it has a wide range of intended uses all the text you see in Cocoa applications ranging from a text field all the way up to a large text view for instance the text area of project builder which has colored text and has a lot of specialized behavior or the text area in HTML edit which has even the totally different object model behind it is built using the text system it's also powerful even if you don't want to subclass and add stuff you're on your own it has a lot of features out of the box as Mike showed during the demo so there are 22 even though you can approach the text system casually and just use it in your application without doing anything else than just a simple usage I'll just talk about two of these one of them is NS text field this is a class that represents in all of those elements in that little window the editable field the password field the non-edible field those are all text fields it's usually one line could be multiple but usually one it's usually non-rich but could be rich and it's read only at are editable you see both examples there and these are subclasses of an ex-con troll what it means is when the user enters data and hit return a target action that's the scent so you can take action based on what the user changed so it's obvious what the uses its for text fields and stuff but you know little fields that appear the other use is text view the other class this is for more sophisticated editing typically they're rich you know that rulers they have color panels on panels you can drop graphics in there and so on it's got a lot of lot of the additional powerful features of the text system accessible directly in there the good news about both of these cases is they're both available in interface builder now you can say new application draga text field drag a text view and you can check a few boxes and most of the features are available now so that's the text view class let's look at what's beyond text view we have the layout manager class the layout manager is the piece of the text system that coordinates the layout of text and so on and we have the text storage which might talked about earlier which is basically the back end of text where the text is actually stored and in fact these three pieces form the Model View and controller which is what Mike just talked about the text storage stores the text the the layout manager lays text out and text you displays it ok so the NS text storage class which is the model the back end it basically stores the text as an attributed string there is a class in in foundation called NS attributed string and just actually a subclass of that and as attributed string is basically aced NS string meaning it has unicode characters in it that you talked about this on Tuesday and then it's got on every character in an S dictionary of attributes and for efficiency we put these on ranges of characters let me show you a picture here is a string which contains I believe eight characters now because this is unicode we can say there's just eight characters in there in here if you're not talking unicode and you're talking classic one or two by top and coatings you know this could be maybe 10 bytes or whatever you know i don't know the exact byte count but would depend on what characters are being displayed for their eight characters here now the first one is an H with an underline so its attributes for that range of one character is that it's got a color of light blue it's got a font of courier 72 and it's got an underline style that's solid now if you look at the next five characters the color there is light blue and the fastest courier 72 we don't have an underlying attribute in that case by default if there's an underlying attributes means there's no underlined finally the last two characters they don't have a color attribute which would mean that we're using the default which means white actually probably black ops team it's reverse and the font there is Sokka 72 now so there are three Rangers here three bags of attributes and they apply to these ranges now the one other thing to say about attributes is you can have your own attributes in these dictionaries for instance if you want to have a special indexing attribute you add on to text you can just add them into these dictionaries call to actually whatever you want and you can add any value you want these actress will be maintained at the Texas edited pushed around etc and so forth so it's you know you can overload these things and add your own information on any range of character you want so the layout manager is the middle piece the controller it coordinates pipe fitting of text it reads text from the text storage it lays it out into lines and then it gives it to text view to display so it's the middle coordinator guy the other interesting thing about layout managers it also stores information about the laid out text so if you want to ask where is line 1 or where is the you know where are the characters 1 through 20 displayed on the screen and so forth or what's the bounding box that this text to cup this is the place to go just has API to give you that one thing to note about layout manager in fact the whole text system is you'll note that there AP is that are in terms of characters in api's that are in terms of glyphs most of the time people use the term characters to mean both but once the distinction the important distinction in our API is where we sort of have to be exact is that characters refer to the elements in the text storage each unicode character is a character and when we say character range we're talking about the rain unitech storage glyphs are to display a displayable elements the glyphs are usually elements of fonts and they are computed as a result of laying the text out and the characters and glyphs are distinct and in fact one character might lead two to three glyphs or maybe several characters can be combined to show one glyph and which glyphs get shown display which goods are shown basically depends on the font let me give you an example most good text systems would take an S and an I the two characters and put them together to display the ligature fi so the ligature is really just one glyph for the character range that contains two characters corresponds to a glyph range that only contains one good so you know if you look at the NSA opmanager API keep this distinction in mind because it's important finally a little more detail about the text view the view part of the whole whole picture it's the user interaction layer it displays the glyph it also handles all the events key aapki down etc all go to text view it also deals with the ruler the font and all the other color panels and all these all the other users are elements that's basically the user is doing it also turns out that if you want to have multiple columns multiple pages multiple weird areas you just have multiple text views that are attached to the same layout manager now one thing to note here is that NS text view is a subclass of a classical and as text which in turn the subclass of NS view and NS text is a sort of a legacy class that's in there and as text view is the class you should use but for the whole picture the whole API you should really look at both text view and text and you know think of those as the combined API for text view it turns out you can do most things with the text system using text view but for more sophisticated usages you would go beyond text you and talk to the layout manager or or text storage so just to recap text storage stores the text layout manager lays it out and text view displays it and two other interesting tech system components are the texts contain your class text containers display they basically described the areas that text should flow into in fact you can use a text content to describe a doughnut-shaped area or whatever you want you know it's it's basically describes the area it turns out there is one picks container per text view and in fact it turns out that you can rip alpha text view from this equation and just leave the text container and have a text system that doesn't display but instead can be used to lay out a newspaper for instance in the back end without ever displaying it's because it's going to the printers or whatever so text content is the part of text view that describes the area and finally we have typesetter there's usually one instance of this types of their purpose is to get the glyphs and put them on a line and basically do all the justification so typesetter is invoked by layout manager as a part of laying out the text okay so so much for text now I want to talk a bit about performance it turns out there is a performance session going on right now which you're all missing so we figured we would give you some of the interesting aspects of that talk here especially how it relates to cocoa so in the context of cocoa application and in general actually Mac OS 10 as well there certain causes for performance issues memory or the lack thereof network or disk operations or too much of them too much drawing and pulling so these turn out to be major concerns it turns out that pure CPU usage is rarely the problem I mean typically if your application is slow you're rarely going to find that it's because of lack of CPU power but of course it happens you know that algorithms can strike anywhere so let's talk about memory 11 cause for problem is maybe one problem that you might not have on Mac OS is window backing stores both carbon and Coco apps all have backing stores corresponding to every window that's on the screen in fact everyone know that's even not on the screen so if you're a 1k by 1k window that's 32 bit steep that's I think four megabytes of memory right there for that window and of course this window backing store is something that's used to give you a really nice display flicker-free and so on another reason is the custom heat management a lot of applications might be doing their own heat management especially on Mac OS and this turns out the cause this turns out to be a potential problem for apps running on Mac OS 10 finally failure to release memory you're just leaking it or holding on through too much turns out to be a potential problem so window backing stores as I said windows are by default buffered also NS images which is the image displaying component on cocoa in ass image will sometimes use caches which are basically window backing stores to cash images in and again you know you load hundreds of images that could add up to a few megabytes in your application now there are there are tools to look at these and I'll mention these in a few minutes but there are few solutions in this area you can make your windows one shot which means when the window is no longer in the display its memory is released and every time the window comes back on the display and memory region is created for it and then the window is displayed and you can assure that NS images are not creating caches and there are several ways to do this so one other solution that you might think about is why why use the buffering at all and it turns out that using buffering allows windows 3 flicker-free if we don't have buffering when you do that lovely window moving on top of other windows all the exposed regions would have to constantly be drawing themselves to keep up with you know keep up with the users moving and you know that's a bit windows like maybe and it's a bit you know not not in the spirit of aqua custom heap management again a lot of apps you know in order to assure that they have enough memory to complete an operation might be allocating large blocks of memory which they carve themselves maybe the memory that they used before in Mac OS 9 was not quite enough for them it doesn't do the right interrupt handling whatever it turns out that this is bad because it's just causes fragmentation if every subsystem allocated want megabytes per node news and carved out there all these little pieces of memory that are not being used in the system and perhaps be there being kept hot because the customer memory management ends up touching all of those bites and another disadvantage here is that standard tools to track memory which will show you one of you know it won't work it doesn't know how this memory is allocated so the solution here is just to use Android's memory system the standard mal lock that comes with the system it's pretty powerful it covers a wide range of uses it should be good enough for almost all uses on Mac OS 10 finally failure to release memories the last point here the beck you mentioned Coco introduces reference counting where objects can retain each other and so on so one problem is that you know you simply retain something or you have a copy of it and you don't release it well that's an obvious memory leak you know you have to release it another problem is sometimes one object can retain another object and that object in return retains me so these two objects are retaining each other they might be totally useless but they're just sitting around not getting freed and to solve that you really need to be consistent in how you do retains and releases 11 guideline we use is if you have parents child type things you know where you have a hierarchy of objects typically the top level objects retain the lower level objects and the lower level objects even if they point to the higher level object do not retain the higher level objects another case is loose connections for instance of cocoa we have delegates outlets targets those are typically entities pointing at each other typically those loose connections do not involve retains meaning an object does not retain its delegates or its targets because those are all entities of our objects in their own regard so the performance tools to track malik's memories there is object a lock and malik debug i believe will show you object alec in a few minutes to track all memory meaning everything a nap might be touching that includes all the shared frameworks etc there is tools like tops and PS which you run on the command line now if you run leaves and you see these sides which means virtual sighs you might at first be shocked you'll see numbers like 80 megabytes that includes all of the shared frameworks and all the other things that are shared across the system so that's not really the number that's you know what your app is actually occupying but looking that number and seeing whether it's growing or getting smaller and looking at trends that that number is still interesting finally the track window backing stores there is no tool on DP for no obvious no easy way to do it but Chris will show you a tool that I think going to be released pretty soon so quickly the other reasons network or disk operations please take a long time relatively speaking and you probably I mean all know you've had to deal with these things these might have an unpredictable effect on performance because sometimes the disk is slow sometimes network is slow one thing to watch out for is on Mac OS and user directories can be either on a local machine or they can be in a network and we go to the user directory to read stuff like preferences or you might put caches there or other documents if you always test in the context of a local user and then you might find out on the network user case where the network access is much slower you might find that things are just way slower and you weren't prepared for network accesses so and the thing here is obviously you should avoid or delay or call us operations that touch the disk for instance if you're writing preferences out don't write them out every time something gets changed maybe wait to write them out at the end cocoa applications actually write out the preferences when they're quitting so you could just let the cocoa system do it for you when you update preferences there are tools sampler I believe Chris might show that in FS usage SS usage is a command-line tool which will show you all file system calls that a process or the whole system is doing it's pretty entertaining if you haven't seen it an interesting a sad sort of way ok and drawing too many times is another common problem sometimes in object-oriented environments because multiple subsystems might be doing drawing you know to sub different subsystems might cause update of an element and you just might not notice it might not be obvious NS view the abstract drawing class actually provides the facilities for managing and coalescing dirty regions so instead of causing a display immediately you should call fit needs display which recorded in its view that this region updated and eventually it will display at the appropriate time we have various tools and again I think Chris might show one of them i mentioned that show you displaying as it happens so it gives you an idea of what on finally pulling pulling is bad sometimes pulling is used i think sometimes mac OS 9 applications use pulling more than say on mac OS 10 polling is bad because it keeps applications awake the colonel has to schedule them in the applications memory is kept hot and it also interferes with power management and with scheduling I mean the colonel was trying to schedule applications in there's an application of every tenth of a second says anything happening anything happening anything happening you know you eventually United you can see how to be a problem so the solutions are there are pretty good solutions in the system there are event mechanisms both in carbon and cocoa that lets you catch event when interesting things happen milestone happened mouse will happen etc rather than you sitting there pulling the mouse location and there are also notifications that will tell you that certain things change another thing is even if you can't avoid polling maybe you can do polling at key points for instance when your application becomes active you could update the state of some certain thing that you're displaying perhaps when your app is active the chance that it's being the split change behind you are very small so it's not interesting to update and sampler and tops will again show you the cases for polling ok so i will now invite chris cain on stage for a demo of some of these tools [Applause] mo 1 let's see in the short time we have I don't have nearly enough time to go into any detail on these apps as far as how you go about to use them to solve particular problems I just want to show that the apps exist and you know generally what they're about the first staff here I've launched a sampler and I'm going to choose text edit I'm going to sample the launch of texted and so what I've done is I have just hit the button that's a launch and sample and all it's done and what we have is a call graph on the left to the center of the of the center of the window and this is showing the call stack that sampler found the app in if you will what samplers doing is every in my case 50 millisecond it's going out to the other app it's stopping it it's going and plundering around in the application finding out where all the threads are what they're doing and it's recording that information and so what it's displaying in the call graph is the sort of coalesced call tree view of that of what was going on over in the call stack lift over on the far right what's going on is sampler has chosen the hottest frame it hottest node at every frame in this coalesced call graph to show you you know what what's the hottest thing going on what we're seeing here in this case is the app spent most of its time while it was sampling it launched very quickly and then I let it run a little bit and spent most of its time just blocked waiting so that's what this is what this is doing we see and its application run it's looking for a next event and you know a lot of internal routines here we see CF run loop is being run you know so we're going down into the layers of the system and eventually we trap into the kernel and we're blocked in the kernel waiting for an event to come on user input event now I haven't clicked over here so no user input events have come into the app certainly not while I was sampling so one thing I just wanted to point out while I was here is that it's very normal very normal to see this sort of vac trace that if you find your app in the situation where mock message over right trap is you know stuck yet essentially that is normal and that is good and we want apps to be very quiet not doing anything while they're in the background like Texas Texas in the background if I sample again here let me we crank this down to one millisecond so every one millisecond stopping the app and sampling now one thing to note is that I I have not built a special text edit here this is just the text edit that comes on the system I don't know if there's any way for me to prove that I guess you'll just have to trust me there but to sample a nap you do not need to especially build a profile version the app or anything like that and so what we see is while I was sampling all the samples all 5439 of them are stuck in mock message overwrite trap waiting for events to come in you know so that would wake up for example when I click the window there and go and do some drawing and stuff like that so that's sampler that's just a very quick look the best way to find out more about these applications is to go in and play with them and see what they do the next step I'm going to show you is object Alex object alec is a way of looking at the memory usage of an application I'm going to choose text edit again and I'm going to choose the binary so here we see the object Alex window the first button over here is start button I'm going to start to start up the task now it's launching texted at what we see here is the histogram of various categories of allocations object alex is seeing all the allocations that are done by the applications and if categorizing them as best I can in some ways it's more sophisticated and in some ways in some places that you know it really doesn't know what how to category is an allocation so it just gives it a generic moniker now the fun is probably too small for you to see there but the first column is a category and the category name in the first row here is zone malik 22 and what that means is just a generic allocation occurred of size 22 we have a current column that's the number of blocks which are 22 bytes in length that are currently still allocated and the other interesting caught most interesting column is the total column which I selected here and we're sorting on and that shows that 2075 of these blocks blocks of length 22 were allocated while the program was running one interesting feature we've added since dp3 to object alice is that we understand some of the CF types so in the second row you see CF strings collected and it identifies these particular strings as the immutable ones and I'm going to go over it in the second tab here and if i click on CF string immutable here it's showing me a list of all the CF strings that are currently allocated in the application so if I click on one it's showing me the contents of the string down here for example there's a string without global preferences there's a string with a path in it thank you so that also works for very other types of objects of CF array the mutable variable kind of CF array here it's showing the debug description this is an empty array the count is 0 is there one with something interesting a lot of empty arrays are pretty common there's an array with one thing in it which looks like a string a path to the application i launched in fact and and so on of those so here's see a set and here's a description of an assisi upset with a bunch of stuff in it so that's object Alex the last thing and then there are other things you can do with object outlook yeah I suggest you know running it playing around with a little bit here I'm going to demonstrate this in a moment what's going on when this happens but you can scale the view for example sort by the different columns and so on the last thing I want to show and we stop that is let's move it over here this new tool Holly alluded to called quartz debug it might not be called quartz debug when we release it but hopefully it'll be released soon it's not in DP for but it goes in and talks to the core graphics server the windows server window manager and tells it to you know turn on various graphical debugging features so I'm going to let's see what let's turn on all of these so what we see at what we saw briefly there is the bits of the window that are being redrawn our first drawn in yellow and then they're drawn with their true content so if I click on a button for example we see it is hard to see that the button is actually being redrawn sense is so quick let me turn on the delay if we turn on the delay we see the very labor-intensive process that graphical drawing goes through to produce a window as complicated as object Alex window so here we see the text you know the table tab view being drawn there that background patterns being flatted onto the screen here come the tabs on the other the outline view every row and so on so turning on the delay allows you to see where you have redundant drawing I'm going to turn that off that's just too painful ok so we've recovered but I turned off the delay and now we're just you know every time the window has to become inactive of course we have to redraw all the controls because they're now gray into the blue and things like that one thing I've noticed as far as debugging here is that if I choose a different column you can see if you look closely that the whole outline view is being redrawn and that's probably correct and okay if I you know change the view around the outline view is just drawn once but if i change the slider here do you see that it's being redrawn twice so yeah really obviously i do it out here nope there oh yeah twice and in fact the slider is also being drawn twice with us a little more subtle and you might not be able to see that going on up in the screen so i probably have a bug hear that when I'm readjusting the scaling I'm over over you know displaying the system I might have a direct call to the display method in there for example rather than doing set needs display and letting the app kit display system take care of that for me like to call Ali back where do you go and if you could have the slide set thank you Chris okay so we still have a few minutes and I'm going to talk a little about using carbon from cocoa now as you know cocoa and carbon are actually two separate programming environments and there they don't share the same windowing structures the responder chains events and so on but our goal is to you be four developers to be able to use carbon features from cocoa and cocoa features from carbon and that's the ultimate goal we have and I'll just talk about where we are in debt now much of the plumbing under carbon and cocoa apps is the same calling conventions we use the same compiler it's C so no problem there the application packaging you've probably heard about NS bundle CF bundled application packaging exactly the same between the two apps the low-level API is POSIX etc the same and basic data types an int isn't in both worlds so that's all very good so fundamentally there is no problem calling carbon between carbon and cocoa you can call a carbon function from cocoa no problem but there are some restrictions as to what you can do now if you look at the umbrella framework picture which you've seen about 40 times I bet you see that we have the various levels below the two I think in general we can say that you can involve carbon services from application services and core services frameworks without any problem so examples of carbon api's you can use from cocoa include quick draw apple event file manager resource manager text encoding converters speech I'm anything else that comes from low-level carbon our application services and of course core foundation now high-level toolbox API is the high-level toolbox is the fundamental drawing stuff that is in carbon it sits in the carbon framework bucket those in general are currently not available you can try to call them but in general events might not work the drawing might not be right so at this point this is not something you can do in the context of a cocoa app now aight also said that you could pass basic data types back and forth so obviously see types and structures no problem those are all the same between the two environment now their api is to convert other types some of the more fundamental types you might be using in your app are file paths or FS traps or URLs and for instance file manager a carbon manager in CF URL which is in corisande shin both provide ways to convert urls and tasks back to fsr and FS specs and so on so you could actually intermix those two api's by doing these conversions and also in some carbon API still take Pascal strings in the context of a core Coco app you might have NF strings or CF strings and then you can use CF string or nsstring conversion facilities to call down to those api's now I'm saying NS string or CF string this brings us to toll-free bridging which enables passing which enables treating those two is the same what toll-free bridging does is some CF types are the same as their cocoa counterparts CF string is the exact same as an NF string array dictionary data URL the same thing and there are few other classes this is true for what this means is if you have some cocoa API and it gave you an enough string and you have to call a carbonate gala takes a CF string just cast away it's the same thing no problem ok so this is thank you so you can just pass these back and forth ok so so much for carbon now I mean as I said our intent over time is to improve the bridging and currently you might find that some areas are not properly bridge yet and if you hit upon a wall and she hits something unique definitely please a lot of snow and finally the last topic for today is programming cocoa with Java as you know Objective C and Java are both the languages with which you can program cocoa and here I'm going to talk about some of the design philosophy of what happens when you use Java to program cocoa you can access most cocoa api's using the Java language and I'll explain why it's not everything Coco objects can be subclassed in Java so if you have an NS view which is a cocoa object with an objective-c and you want to have a subclass of it in Java you can do that you can also pass objects back and forth between Java and Objective C so NSU is an objective c class it once you know some objects it once have a window pass to it you can pass the java version of it back and forth it's all automatic and your applications can either be one hundred percent Java or you can make them hybrid meaning parts of them can be objective c parts of them can be java so the philosophy we have in the Java API is is that we want developers to be able to use the Java language to program in to create cochlea applications however we want to preserve and expose the cocoa programming model because you know we have these this cocoa application model it's you know one way and you should be able to use that in the application but we also want you to be able to use Java paradigms and objects there possible and where it makes sense one example is the java string class it's very it's all over the place in java and in the java side you might you might it might be a better idea to use the java string rather than use the NS string class and functioning functionally they're pretty much equivalent the other goal we have is that you want to be able to integrate and use java libraries as much as possible java network libraries well whatever else you might have java utility libraries you should be able to use them in the context of your app and this is pretty much confined to the lower levels meaning it's DUI layer it might not work so good but lower levels networking etc those api's are all available to you so I talked earlier that I said earlier that most api's were exposed it turns out almost all of the apt-get is exposed using this name com that Apple that beep that application okay and then we have some of foundation exposed when I say some it turns out to be adding at least half of it combat Apple yellow ducks foundation now the areas that are not exposed as basically areas where you know we decided that Java has a link coolant and finally there additional frameworks combat Apple that yellow that scripting has the scripting functionality that adds is added on to the cloak of frameworks now we will rename these things at some point soon okay so most objects are exposed directly we call these rafts so NS view in Objective C is the class combat Apple yellow that application of NS view in Java now I talked about the string class which is not exposed those are more meaning any time it goes to the other side it goes to run change it basically changes into an object of the other language so nsstring instances are converted to the string class in Java and there are a few other classes to which this happens and we repackage some functionality for instance categories as an objective-c feature which lets you add methods on top of an existing class it's not available in Java so in those cases we either take the methods that are in a category and fold it into the base class or repackage them into a separate object in c functions which cocoa has some of are not exposed will directly in Java so we've usually package them into a utility class much like the math class in Java and cocoa also has a bunch of structs and selectors and java does have a concept of structs and selectors and those are converts to java objects as well and as far as method name mapping in objective-c method names can have arguments keyword arguments or keywords for each argument for instance post-event it starts there are two arguments there one between each colon in Java we convert that to post event meaning we drop the other argument names because often the main part of the name is good enough and Java also allows overloading which means you can have various versions of that sometimes when the name would be not very obvious or sometimes when the second argument is important is the first one we tend to keep the whole thing so set object for TV becomes said object for key finally init method which are the Constructors in objective-c in Java are just converted to construct your methods for instance the NS view in it with frame method which is how you create a nice view in Java is simply NS view which is how you create objects in Java so those of you who are familiar with job will probably have tools to inspect and look at Java api's like Java p and so on one tool we provide on the system is this app called Java browser it's really handy it just shows you a browser up there of all the classes it knows about which includes the cocoa classes plus all the other classes including the Sun classes and you can choose any class and down below it will show you a nicely formatted API for that class so it's a fairly handy tool if you're if you want to browse through the API ok so I think that you answer the documentation there's documentation on vp for release notes and so on the release notes are really quite handy there's documentation and system developer documentation cocoa you can also go to the website to see if there's updated documentation any of these areas with example code in both system to vote for example zap kids and in system developer examples java app kits for java applications written with cocoa and here's the roadmap some of these talks have passed but you know if you have a chance if they're the facilities will provide to review them you can choose to do so let's see the localization talk is happening right after this i think that's like talking about how to localize cocoa and carbon applications the courts talk is tomorrow where it talks about courts AP is that you can use directly from cocoa applications if you want to and performance talk that is pretty much wrapping up right now i believe so okay let's see so i think we have about 10 minutes i would like to invite mike and chris back on stage for some QA and becky i think i see her there too now one one thing we have a brand new address coco feedback at Bluford apple com it works so if you have comments and feedback on the API new features you'd like to see added to Abaddon foundation such please send send us mail thank you