This is session 6 11. AJAX methodologies for QuickTime development in which you will also coincidentally

QuickTime methodologies for AJAX development. My name is Kevin Calhoon and by preference and profession, I'm a software engineer. In this session we are going to be harkening back to what Peter Graffagnino said on Monday in the Graphics and Media State of the Union. In which he recommended that you use web technologies for interactivity, and for media such as audio and video and even time text you use QuickTime. In this session we are going to be talking about how you can combine those powerful things together.

The bridge between the two is the Java script API of the QuickTime plug-in. In this session we'll be going over its scope, we'll give you some handy usage tips, we'll tell you what's new in the JavaScript API of the QuickTime plug-in in the Leopard time frame, and we'll give you some demonstrations of some really cool things that are under development now and what you may already have and not know it of the plug-in and web technologies.

Ok. Specifically you will learn how to detect the presence of the plug-in on the users machine for the use of the browser and how to do a check of the version of QuickTime so you're sure that the features of QuickTime that your media requires are present. We will give you our best practice recommendation for how to use the plug-in to embed content in your document or in your web app.

We will go over the basics of controlling time based media via the JavaScript API. Also how to query state of media if you want to display the state or to respond to the state. In fact, how to respond to state changes in the media without polling in JavaScript, we'll cover in this session.

Further, how to register for time notifications if you want to synchronize other things happening in your document with time media, and you'll also learn about as I already mentioned, some usage in the real world of how this media stuff and web technology can be married for interesting results.

Ok. What technology frame works are we dealing with? If you are a web developer, if you're developing web pages, if you're a web app developer and you want to integrate time media such as audio and video into it, this session is for you. If you are a QuickTime developer and you are interested in following our recommendation for how to add interactivity to your QuickTime media via the use of web technologies, this session is for you. Also if you are a classicist, this session may be for you. You'll have to tell us afterwards.

Alright, let's jump right into the nuts and bolts of the usage of the plug-in. How to detect that it's present and how to check the version of QuickTime. Well this whole process is very straight-forward if the browser that your user happens to be using the Netscape plug-in API, and I'll show you the straight forward code for this in just a moment, but there is a little bit of a wrinkle if that browser that the user is using happens to use the ActiveX API for browser plug-ins.

The reason that there is a wrinkle, is that Apple's recommendation up until now has been for you to use the QuickTime check object ActiveX control to do the version check of QuickTime. Unfortunately when Microsoft revamped its security policies for IE7, it did not bless the QuickTime check object ActiveX control for use with IE7.

So if you use it your user may get a warning that the plug-in that the page uses may be unstable, may have diseases, and the user may wish to run away and this of course is not something that you want your users to do when they navigate to your pages.

So you will want to follow this new recommendation for how to do the version check of QuickTime. First of all, you would want to include in your object tag that you wish for the page to use the sufficient version of the QuickTime ActiveX control that has this feature.

We'll be adding the feature essentially of the QuickTime check object control to the QuickTime dot QuickTime control, which is the one that you have been using in order to embed content in web pages in IE, or other browsers that use the ActiveX API. If any. And what you'll want to do when we ship you this new version of the QuickTime dot QuickTime control, once you've included in your object tag that version number, of course IE will help the user to download that version and to install that technology that it requires, and once the page is loaded you can instantiate that control and call its get QuickTime version method in order to determine the version of QuickTime that is being used.

Alright, if any of this check fails, the code for which I will show you in just a moment, or if the version of QuickTime is insufficient, our recommendation is that you navigate the user to the QuickTime download page. Here's the URL for that. So that the user can download the sufficient version of QuickTime that's required for your documents. Ok so here's the code; first of all the first clause is, the first if clause is going to run any browser that supports the Netscape plug-in API.

What this code essentially does is to iterate through the installed navigator plug-ins, search for a match among those plug-ins of the name QuickTime and a number. The name of our plug-in has a name in that form. QuickTime and the version number of QuickTime that's installed and you can use that version number as the version number of QuickTime that you can compare against the version that you require.

This else clause will run in browsers that do not support the Netscape plug-in API, and here is the code for the recommendation that I just walked through a moment ago. Instantiate the QuickTime dot QuickTime control, invoke its get QuickTime version method, and that will be the version of Quick Time that you would compare against. So there you go. That will guarantee that your page has the appropriate version of QuickTime. Of course if it's not available, navigate to the QuickTime download page, alert the user. Of course it's up to you to determine what to do.

Once the appropriate version of the plug-in and QuickTime is available, how do you embed audio and video media in your page? Well there are a number of differences among browsers as you probably know, in the way that certain things such as objects and bed tags are treated. So we have a very specific recommendation on how to construct those tags in HTML for the broadest possible compatibility with the browsers and the browser versions that our plug-in supports.

It's a little bit finicky. So what we've done is to supply a JavaScript library for your use that you can invoke in order to create those tags appropriately. The JavaScript library that Apple provides for embedding, I'll give you the URL for that a little later in the session. You can download and use on your site and invoke via the QT right object function, and that function will formulate the appropriate tags so that your content can be embedded and displayed by the QuickTime plug-in.

The first parameter to the function is the URL of the media you wish to plug-in to display. The next two parameters control its width and height, and other parameters map to embed in object tags on the plug-in and they are all documented in the library that you can download. But that's the easy way to do it.

If you have a need to construct these tags yourself, we also document what they look like. That example will expand to this construct in HTML. You'll note that there is an outer object tag and an inner embed tag and this is what works best across the universe of browsers.

And you'll see that the attributes of the object element and those of the embed element mirror each other. Well it depends on what browser happens to running, which one it actually picks up. That leads to an interesting question, which element is going to turn out to be live for scripting once it's inserted into the DOM? Well it's a bit of a difficult problem that Mike has got a solution to, and I have a more modern solution to in just a moment, but there you go. That's the raw stuff. Once you've got the thing embedded and you want to control it.

You want it to start to play or you want the user to start it to play, what do you do? Well you have two options, in one the first option is the simple one for you if you have no need to mediate the control of the playback. You can use the plug-ins controller attribute, set it to true in order to tell QuickTime to display it's standard 16 pixel tall user interface for media control, and the user can interact with that to stop and start the movie and so forth.

However, most web pages these days have their own look and feel and you will certainly want to have your own controller that matches that look for control of media. You can design that anyway you like, and control the media via the plug-ins JavaScript API. Here are some of the methods that you might want to use in order to do that. High level methods for playback, play stop, rewind and step.

Or intermediate level methods such as set rate. Let me walk through these. The rate of a movie in QuickTime par less is the rate in which it's playing. 1.0 corresponds to the movie's intrinsic rate, its natural rate. The rate at which it would typically play for normal viewing.

Zero corresponds to stopping, so you stop or pause a movie by setting its rate to zero, and you can detect whether a movie is playing by checking whether its rate is zero or some other number. You can make it fast-forward for example by setting its rate to 2.

You can also seek through time through the movies duration for zero to it's duration by means of the set time method. In the QuickTime plug-in time is an integer, and that integer represents the number of increments that you want to advance in time The number of increments per second is given by the movies time scale. In order to get that you invoke the plug-in method get movie time scale.

So for example, if you want to navigate to 2 seconds from the movies start, you would set the time to 2 times the movies times scale. Alright so we have other control there about the sound volume, whether the movies loops. You can use these last two methods, set start time and end time in order to give the movie in and out points to play only a segment of its full duration, and so forth. You can also use these methods in order to fetch information about the movie.

Now for those of you that have a background in object oriented design, or perhaps just opinions about object orientated design may be asking the question "Why have you exposed methods in order to control and to query these things? Why haven't you exposed attributes?" Well the answer to that question is that in the QuickTime engineering group we are not "Johnny come latelys" to the JavaScript world.

We designed this API to work with the very first scriptable browser Netscape 4, and with Netscape 4 was the most natural for a plug-in that wanted to advertise a JavaScript API to expose methods. If it was natural for it to expose attributes, we never quite found out how to do it. So we designed our API to work in this way.

Ok. What happens if you want to respond to state changes? If you are implementing a custom controller and you want it to reflect whether the movie is currently playing or whether the movie has reached its full duration. Well if you have been implementing such a thing up until now, as you know it would be necessary to poll the state of the movie. You would instantiate a JavaScript timer and then as that timer fires at an increment of your choice you would have to use the methods I just showed you in order to query the state of the movie.

Well that's inefficient, and it's not very AJAX like either. So what would you prefer to use? Naturally it would be better if the plug-in were to emit DOM events that you can register listeners for, and then when your listeners were invoked you could do whatever you needed to do. Well we agree with that.

And so in the version of the plug-in that we will be shipping concurrently with Leopard for both Mac OS X and Windows, the QuickTime plug-in for the first time will be admitting DOM events to indicate state changes in the movie. And here is a list of the DOM events that we are implementing.

We haven't chosen these completely independently in fact, these DOM events are modeled very closely after the current W3C draft specifications for HTML5. As you may know HTML5 for the first time includes HTML time media elements of which one instance is the audio element and another is the video. Well where did all that come from? We've actually been participating with the working groups that have contributed to the HTML5 draft specifications.

Based on our experience with media in web pages all the years we've been doing the QuickTime plug-in. We went to them with the model of how we thought media would naturally behave inside of the HTML DOMain and we even proposed a set of events that those plug-ins should emit. And together with other members of the working group the current draft specifications have been formulated and we're taking that draft and implementing this portion of it back into our plug-in.

First of all we want to validate the design of HTML5 and also we want to provide this functionality to you in the plug-in in the form in which we already provide embedding with media. So here are the events. What do they mean? Begin is an interesting one. Its and event that the plug-in will emit when an instance of it has been inserted in the DOM and it becomes live for scripting. Begin is an event that you can listen to, to determine whether the outer object or the inner embed element is the one that is live for scripting.

Loaded is emitted when the media resource has been completely loaded. You can listen to that if you don't want to play for a really long time. However, any media technology worth a nickel is going to allow you to play back however much media has already been transferred and the QuickTime plug-in certainly is worth at least that. and when there is some media that is available for playing we will emit the can play event. That's the one that you listen for to determine that you want to enable for example a play control.

However it may not be exactly one you want to initiate playback because what you really want to do is wait for sufficient amount of media to be transferred and you also want to have some assurance that the transfer rate is high enough that you can start playing and continue playing all through to the end of the duration of the media without having to wait for more media to be transferred. The can play through event is emitted when plug-in judges, according to current network status that it's safe to start playback right now.

But network states can change and if for some reason the transfer slows down while you are playing and we have to stop playback because you run out of media, we will first emit a pause event to tell you that we stopped playback and then we will emit a waving event to tell you that the reason we stopped is we need more media.

If after a while because you yanked the cord out of the wall, we discover that no media is being transferred after what I think is 3 seconds we will issue a stall event so that you can advise your users on the best recovery options. These other events, whether they mean you can go to the W3C draft of HTML5 and they're defined there.

You'll note that we're emitting loaded and not the standard load event. Why are we doing that? Well we are currently in the testing phase, making sure that all this works across the full range of browsers that we support, and we discovered then that in at least one browser when a plug-in tries to emit a standard event that the browser already knows about, and may emit itself under other circumstances. These events are suppressed, they don't bubble, listeners aren't invoked. Though I won't tell you which browser does that, although I'll mention that its name or the technology that under lies it includes one of the last of the 3 letters of the English alphabet.

Ok. One last feature and then I'll turn this over to some web developers that are getting some interesting stuff with it. What if you want to synchronize with media all the things that that are happening on the page? For example, make images pop up as you play through certain portions of the media or whatever else you may want to do.

For the first time in the version of plug-in that will shift with Leopard and concurrently with Leopard for windows, you can register for time notifications by the actupoint function. You tell us what time you want to be invoked, the name of the function that you want called, or the function object that you want invoked, and you could also tell us by the third parameter pause whether or not you want the movie automatically to pause at that time. And when the movie plays through that time either to that time or traversing that time, that function or that function object will be invoked. You know that it will be invoked only when that time is reached or traversed during a normal playback.

It will not be invoked if a time is skipped over by seeking. Now we realize that there is value for that kind of notification too. We will be working with the W3C working group in order to propose that kind of notification as well and if you have an interest in helping to craft that specification please by all means join the W3C and let your input be known about time media or any other aspect of that specification.

OK. This slide is only here to tell me that I'm running over, I'd better get over there to the demo machine where some guy, oh wait that's me, will be showing you an example of these DOM events and these notifications at work. Now you solve this page if you came to the Graphics and Media State of the Union on Monday.

Where you saw a really nice web page which has its own controller. ( music playing ) And you'll see at the bottom of the page is well, that the content below the movie is updating automatically as the movie plays that displays sycronize the movie playback. There are some custom controls to the left that allow you to navigate from a segment to sub chapters if you will of this movie.

I can play and pause.

Control. There's also some very nice stuff on the bottom which I wish I could scroll to, but you can get the idea as I mouse over this portion of the controller, a thumbnail of the segment or chapter of the movie that's associated is displayed. I can click on the thumbnail in order to navigate to that chapter. So all of this control is achieved via standard web technologies together with the QuickTime plug-in that manages playback.

Let me show you a bit of a simpler example to illustrate how this can be done. ( movie plays ) This is a scaled down version of the same thing and the control here is a lot simpler. I mentioned the standard 16 pixel tall QuickTime controller, that's what this is. It's just here for the demonstrator to have something to hand on to.

The page itself implements only a simple button for playback control and you'll see that.

It changes its name as the movie plays and pauses. Events that are generated let me reload the page and show you the sequence

of events that are generated.

I can really get used to that. This events are generated as the movie is loaded. I mentioned some of these before begin as an emitted when the incidence of the plug-in is inserted in the DOM and you can begin to talk with it. These other events that I didn't talk through as I mentioned you can read about in the W3C draft. Let me do one more thing here; let me navigate back to the beginning. I'll play and then I'll add a queue point by clicking this button at whatever time the movie happens to be playing.

Now I'll navigate back to the beginning. Let me clear that display for you. Then as I play again,

you see the queue for the time I registered for was hit and if I wish to I could do whatever I wanted in my scripts in order to synchronize something else happening on the page with the media. So that's a simple demonstration of how it all works. For some richer demonstrations and a lot more information about plug-in in real world use.

I'm going to turn the podium over to Mike Seeple who is a web developer who did a lot of the work on the new Apple dot com pages that you've been enjoying since the Keynote on Monday morning. Mike's going to come up and he's going to tell you the real truth about the QuickTime plug-in. Mike

Thanks Kevin. I wish I could say I have more exciting examples but honestly I am dying to get my hands on the new stuff he's been talking about showing off.

I'm Mike Czepiel. I'm a web developer on the Apple dot com team and if you're in the session before this, I'm going to be talking about pretty much the same thing. If you weren't great cuz you're going to be getting the best part of the section, right here right now.

As a web developer on the Apple dot com team, I get to work with some really amazing designers on a daily basis. I'll bring their prototypes to life. I'm on the web using HTML, CSS, and JavaScript, full gambit of web scan technologies we've all come to know and love. In create and some of the create some really seamless video experiences in with their work, and I'll share with you how we actually helped them do that today. Right now without all the great DOM events on Apple dot com.

There's a we use standards but you don't have to. There's actually a lot of or several closed proprietary scores options that we want to get video on the web. But we were born and raised on view source we really embrace the open web. We want to be able to use whatever video we want. We don't want to have to invest in particular tools, particular methodology. So it's great about being able to use HTML,CSS and JavaScript is we can choose the highest quality video for displaying our products online. Of course this means this video you immediately start thinking of QuickTime.

Unfortunately QuickTime is not typically something you will see a lot online in an interactive environment. Usually the page that your loading is just going to be a page with the QuickTime movie loaded. Its sole purpose of that page is just to show QuickTime movie with standard control. This is really isn't what our designers are going for though, they want something that looks like it's a native part of the page and really integrates correctly. Thankfully the QuickTime team was created seven years ago around 2000 QuickTime 4.1. They were really forward thinking and added the JavaScript API. I could have been back here 7 years ago talking about this and it pretty much would have been the same presentation honestly.

Fortunately no one was really doing anything with the JavaScript API back then. Honestly it's just probably more trouble to get Java script working across browsers reliably back then. Now the first thing from your mind was integrate. How am I going to integrate rich media into my applications? Thankfully, thanks to increased browser...advances in browsers development tools and tireless efforts of the open source community in developing JavaScript libraries. We really come a long way and it's a lot easier now to work with JavaScript. Which now lets us turn our attention to actually doing some cool stuff with JavaScript and this is where QuickTime comes in.

Unfortunately the QuickTime API itself does look like it was ran in 2000 and it really hasn't changed yet. It's going to change obviously as Kevin pointed out. Unfortunately for today we really don't want to be coding like its 2000. We want to be able to integrate QuickTime as another native part of our actual libraries that we're using to just prototype scriptaculus on Apple dot com.

So we decided to actually go off the beaten path here. We're not using the official AC QuickTime. We actually wanted to you know create a more modern indication of it. You know pending the QuickTime elements to the page. So we didn't want to be inline doc and writing with QuickTime, only then turn around and when we're working with our modern libraries be document pending (inaudible). Like I said, we created our own and the differences are pretty clear that one looks a bit more familiar to you at this point. Additionally gives us the flexibility of being able to call it within our script without having to put it inline with the page.

You, but you can go with either one and really the great thing about the JavaScript API just being raw JavaScript is you can kinda take and do what you want with it. You can create this node in any fashion you want. So if you don't like how we're doing it on Apple dot com or the way that the its officially provided by the QuickTime team, you can go in and make your own theoretically. You're going to be off the beaten path. You're going to have to kind of do it yourself.

Fortunately on Apple dot com really wants to just get a really nice experience going and the designers aren't going to be thrilled with us having spent all this time on creating a nice interface. When they think interfaces, they obviously want a really nice graphical user interface. This code really hasn't impressed them. We just want to get to this point where we can work with QuickTime live, in the real world today, without having to revert back to document writing content.

Once that's actually set though, we can actually turn our attention to the plug-in API itself. Again we want to be able to integrate this into our own components without too much fuss. We want to really feel like a part of our library. So we on Apple dot com created a QuickTime controller class that we use to help communicate with the plug-in. This helps us get around some issues, as Kevin mentioned.

Helps us abstract the plug-in itself and get around some issues as Kevin mentioned. Right off the bat when you go insert one of the QuickTime movies in the page, you're going to end up with 2 objects. The object and the embed depending on the script your using. Different browsers are going to look at different objects.

We don't want to have to every time we write a script, figure out which one we are talking to. So the custom control we created is a great place to do this. You've read this code once and the control is going to be able to, from then on, be the expert on which element it needs to talk to. Now its we want to be able to do that really easily, we exposed this API within the custom control that simply attached to a movie.

So we just give it the movie we just created in the previous step and it's able to figure out the rest and then from now on we can use it as a proxy to the plug-in. Whenever we want to send events, it just delegates and send it right...and then it passes the message right along to the plug-in.

Plugging can take some time to get be responsive and actually respond to events depending on the browser. Just in general can take some time but we don't have the benefit of being able to wait for it to actually report that it's available and ready to begin. So we need somebody to stand in there and look at it. Now the controller knows which movie to look at. Its the obvious choice to just sit there and monitor. So we will set up a loop to just sit there and ping it.

While it's doing that we can also have it emit events. So we've if your using a prototype..if you're using DoJo or YUI or Mood tools or something allows your to fire custom events, you can do that but we use the prototype Scriptaculus and we've exposed these function call backs. Which you can register call back functions to.

So when the custom controller, monitoring the movie, hits one of these events its a legit call we'll just call one of our call backs and we're able to execute code. This is really important point I'll make later, but really the loss of the QT next pointing at the JavaScript protocol is security concerns fairly recently. This is actually one of the few ways that you're going to be able to tell when a movie is finished right now and do some activity.

Also because we have the custom controller, we really want to be able to talk to the movie in plain English. While it's great that we can actually the rate if it's equal to zero, find out if it's playing or not. We really want to in our own components being able to work at a much higher level, so it just feels again that we really need it. We want to be able to talk to this in English, create our own vocabulary.

Where working with QuickTime feels very native and very non special. We really don't want it to be this foreign object in our pages We might also want to time custom behaviors when we send events, so for instance if we're caching the state of the movie. When we change the state of the movie directly we might want to do something.

This also allows us when certain events occur, when errors are thrown at a lower level and communicating with the plug-in. We're able to capture those events and respond in a way that we might want to make assumptions about. So for instance if we're asking a movie that's played if we get a failure right now, we might just want to assume that the movie is not playing. You know this would be a place where that's not the assumption you want to make, you have the ability now to change that. So if you'd rather cash the state of the movie and just return that, you have a place to do that really easily.

We can also use this to make estimations so if we're keeping track where the movie is for instance to update a custom controller, and draw progress for. This would be where we're able to keep track of where was the last time; if we get a failure on the plug-in we can guess where it should be just by just by figuring out where it was and how long we waited until we checked. This helps just keep things looking really smooth even if the plug-in underneath is not responding as much as we'd like.

So anyways we just want to be able to extract to the plug-in itself so it's not dealing with circuit 2000 technology. And we're going to use this to talk to the plug-in. Of course one of the things that we really want to do on Apple dot com, its really one of the most requested things is to use custom controllers. And so we've actually allowed the custom controller in code to be represented and rendered in pages as DOM elements and update using the scriptaculus slider.

I'd like to show you right now the demo of the Apple dot com web site and its use of the custom controller and some of the QuickTime stuff today. So this is live today. If you go to Apple dot com, you'll see this. Down at the bottom we have a movie player.

With the poster frame, it's actually really not a poster frame, it's not a movie its just a jpeg which you use to click to play. We're actually not going to play that one right now, we're just grab one of these other guys ( movie start and plays ) starts playing the movie.

You'll notice that there is a custom controller which allows us to pause the movie

play the movie

it also responds because it's polling

to us actually interacting with the plug-in itself. ( movie starts again ) and it reflects in the correct state.

( movie stops again ) I'm not sure if you saw it flash by, but there is actually is a loading status in the queue. We get just by querying the progress of the movie itself. In addition because it's just a slider, we're able to actually drag and send change events off to the plug-in through our custom controller and have it update the state of the movie.

Additionally like I said we're able to change the movie,

because we have that whole set URL API already baked in there. So we're able to progressively advance our content of the page. All these are really just links directly to the movie.

We extract the URL we're able to attach them to the movie and send that off of to the custom controller and tell it to just update the movie that its attached to. We also have, like I said, custom events kind of baked into this such that when the movie ends, we're actually going to throw an end state up.

So there's an example of that. Really that is the only way you are going to be able to do this at this point because we don't have the QT next to rely on. Lets see. Another example, and this is probably one of the most impressive ones I think on Apple dot com right now. It's a lot of hard work by some really great developers that builds upon the QuickTime library that we already have.

This is our Leopard site. There we go. And these actually pop up the movie, video window and I think it's still loading but the movie ( movie plays ) actually load in the pop-up and you're allowed to navigate throughout them. It's a really nice seamless integrate experience that our designers are going for. One of the best things about this was, as I was looking at around the web at some of the comments.

People were defiantly mistaking this for some other technology. Assuming we used something else to get this going. So I'm taking this as a compliment that they really didn't understand that this was just QuickTime and the JavaScript. You know we all have access to really easily. So back to the slides, I have some information about how we actually work around some of the issues we run into in doing this.

For instance when you are working with Firefox, the plug-in..Actually I think this actually occurs in Safari too now that I after some experience before these files are finalized to work in the last minutes for the redesign. Plug-ins are only available while they are visible in the view port, so you really can't talk to the plug-in while it's off screen. You can't talk to it while it's hidden while it's visible. So these are just some of the things that you need to keep in mind while you're working with it. That just..yeah.

Firefox also kind of bogs down a bit so if your actually pinging it quite a bit its plug-in seems to fail a bit more often. So this makes the custom controller all the more important because now you have a place to handle those appropriately and not expose them to higher level component that really don't care most of the time.

Internet Explorer, Internet explorer because of the obviously the garbage collection issue of the circular references between the DOM and the JavaScript objects. You have to be really careful that when you create a movie and you maintain a reference. The DOM object that you eventually do clear it. Otherwise you can actually with the movie persisting across pages. So you can browse to another persons web site and your movie will still be playing. Which you know might be great from a marketing start point, 'cause now you've branded other peoples web sites.

Your visitors really really aren't going to appreciate that. Additionally you're leaking memory at that point, which can be an issue. So you just need to be really careful about that. So just tying the movie usually works pretty well honestly, but you can still have audio playing. So just make sure that you keep track of the references as you're doing this.

Additionally if your trying to position a movie, absolutely somewhere within the page you'll sometimes see a kind of drawn in from the top left and one of the solutions to that is prior to you showing just tip the visibility of it hidden until it gets into place and the movie is already situated. You won't see it.

As your working with Opera, well it doesn't have a JavaScript API as of now. So I'd advise that you play really nicely with Opera because it does handle QuickTime very well, but you're going to have to you know keep it in mind that you can't do all the fancy set URL stuff for monitor, custom controllers. So it's just a matter or progressively enhancing what you already have. For instance all the links on the bottom of the Apple dot com movie switch.

Again they start as movie links, so if you don't have JavaScript at all they link right to the movies. If you're in Opera and you don't have the Java script API we actually rewrite the URL to point back to the page with that movie initially loaded. So you still get that functionality in Opera that when you click the bottom, you'll actually load the page with the movie that you're expecting. It's not going to be as nice but its going to work and people are going to appreciate the effort. So just some obtrusive JavaScripting and progressive enhancement, all the stuff that you're already used to makes life a lot easier.

Fire works pretty damned well actually, surprisingly, perhaps not. So you shouldn't have too many issues with that. And some really useful parameters I found in working with the object and the embed tags are the show logo false because people don't need to see the queue. They are going to know when you're use it that the quality of the video is there and it's QuickTime and if they don't that's fine. They'll still appreciate the high quality video.

Additionally the save embed tags, if you're going to start doing movie swapping it becomes really important that probably want to save the embed tags. 'Cause other wise you wipe them away. So if you set the controller false initially, and then you switch the movie without saving embed tags, you're going to get the controller back and you probably don't want that. So you probably want to save the embed tags you originally set on it.

So in general in working with QuickTime within JavaScript and HTML TSS without relying on proprietary solutions, you really want to be able to course JavaScript to kind of fit in with everything that you're doing and make it feel like a part of your own library. You don't want it to be a special case you're working on.

It's just good design, object orientation, oriented methodologies really help make it easy to work with and your able to really build some spectacular components just by compositing with all the other stuff your working on. I think that's pretty much it. I'd like to bring up Todd up on stage to talk about some of his usage. Thank you

Hi.

I think we all saw Steve demoed the widget during his Keynote so you're probably with that. What were going to look at here. And one thing that I want to say up front so I'm just going to talk about a couple of implementation details for the movie widget and also talk about how the movie widget uses the QuickTime plug-in to display movie trailers. Something that's really interesting about the movie widget is that it does not use a widget plug-in. It does everything that it does to once again standard web technologies, HTML, JavaScript and CSS.

So what's a widget plug-in? If you've done widget development in the past, you're probably familiar with the concept of widget plug-in. Its a plug-in type specific to Dashboard widget development. It allows you to access native services of the platform that may not normally be available to you through JavaScript or other web technologies in the widget.

So widget developers often use widget plug-ins if they're doing something maybe really sophisticated in the user interface, or they're accessing some kind of API on the system that's not available to JavaScript. And once again the movies that widget doesn't have to resort to this. Everything once again is like a broken record here but everything is HTML, JavaScript and CSS so it's a good example of the kind of sophisticated user interfaces in rich media interfaces that you can get through web technologies in the QuickTime plug-in.

In a lot of the Apple widgets and also the third party widget used AJAX to communicate with the remote web services and fetch XML resources and then display that information in the user interface and the movie widget is another one of those widget's obviously. When you first launched the widget, obviously it communicated with a fandango remote web service and fetches the movies that are playing in your area. And then it displays this for obtaining animation of the movie posters.

It actually uses a couple of JavaScript classes that we've released as OS XTiger10 dot four dot three. We released a collection of JavaScript classes that you can reuse in your Dashboard widgets. These classes actually work across all the modern browsers, so you can reuse these classes in your web applications as well and they can be really useful So let's kind of point out the reusable Dashboard JavaScript classes that the widget uses as I see them in the user interface but you can see right away that it uses a class called Apple animator that does handles this animation for the movie posters of the beginning here.

So many go ahead to click the widget to expand it and you notice that whatever poster I click on comes preselect in the user interface when the movies widget expands. So it's got 2 states here I can click at the top again and it will shrink back down to the to the small state and if I click it again it expands to the expanded state.

So the first feature we should probably talk about its really obvious is there's this calm view. This is obviously happily inspired by the OS X finder column view and in the finder there's a coco objective C class called AS browser, and in the movies widget there is kind of a JavaScript equivalent of that class. It's heavily inspired by the API MNS browser that we call the Apple browser for this widget. It's a reusable JavaScript classic it can create this user interface, and it also has an associated JavaScript delegated API that you can implement in your application or widget.

And the use that to fill up the user interface with custom data for your application. So be curious how we did the code for this calm browser up to, you can just take it that the Java to the widget and even copy paste your own applications. We don't mind if you look in there so..

As you can see that this is fully operational column view done in HTML, JavaScript and CSS. Can also be clicked theaters or movies the browser view will resort currently we have movies on the left side in the first column. Click theaters, now it's sorted by theaters and then the movies for each theater displayed in the second column.

And this is just 3 HTML UL elements, and each movie item reached, time item reached, theater item is just HTML list item elements. These are just standard HTML. So obviously the center piece of this widget is really about the trailer playback with the QuickTime plug-in. So I'm going to go see "Fantastic Four" tomorrow so let's take a quick look at the trailer here.

So once again this actually uses a lot of features you've already heard about in this session today. Obviously we've got a custom dHTML controller here at the bottom. So using the same controller equals false attribute on the embed or object HTML element. To remove the standard QuickTime controller so that we can add our own custom to HTML controller and then of course we're using the Java API you've heard Kevin and Mike talk about today to control the widget.

Very similar to what you see in Apple dot com. A couple of the other Apple classes are being used in the interface here. There's actually an Apple class called Apple slider, and we're using that for the controller progress meter down here and we're obviously we've customized with some custom CSS and HTML.

But it's just for using another standard class you've got available since OS X, 10.4.3. You'll notice as we load any theater, you'll also get a progress indicator sliding across behind the slider. It's kind of subtle to. I'm not sure how well you can see on the screen here, but again we're just using the same APIs that Kevin talked about earlier. He mentioned there is an older polling style if usage of the API to get that kind of progress indicator in your user interface.

Versus the newer DOM media events. The DOM media events API is so new we actually didn't even have time to implement the movies widget using that new API, for today but we're definitely looking forward to using that before Leopard shifts because the movies widget will really significantly benefit from that simplified API but you can kind of see the progress meter going across the bottom. ( movie plays ) and the QuickTime plug-in, I mean it's really great. You can abuse the slider as much as you want, and the movie keeps up and everything works.

Works extremely well again just web technology. It's really great now what you can do with the QuickTime plug-in. A couple of things that I wanted to mention about the browsers that I forgot to mention was it actually has full keyboard navigate abilities. So also I'm going to use just the up and down arrows here to switch to the com view as I'm not using the mouse.

Just the kind of interactivity you'd expect from a native user interface like Coco or Aqua. And also you can use the right and left keys to switch between columns. Then also I can hold down and get the kind of auto repeat action. But those are some of the features of the movies widget. I hope you guys really enjoy. I think it's going to be pretty exciting widget for Leopard and that's all I've got.

Thanks

Stay turned for the sequel movies widget rounded corners. How did he do that? Oh well where's the...there you go. Ok. So to wrap this part of the session before we get to some questions. If I could invite Eric Carlson to come up on stage, who knows the one more thing even better than I do. If we could get the podium mike up for Eric. He's going to walk us through the one more one more thing.

Eric: One more thing. Anybody who has been to the sessions in this track has probably seen this slide, but it's really important as your designing web pages and web applications. Keep the keep the Phone in mind. Because you want your content to work there are well. Remember best design practices You want column lay out, size matters. Remember that band width available on phone can fluxuate and you want your you want your content to deal to it well with that. Use media queries, they can help you adapt your content to the settings that it's running one.

Optimize for the iPhone. Remember the viewport code for double tap. Make sure that your content deals with text size adjustments. Deal with DOM events and remember when you have media and to in code appropriate appropriately for the Phone. Use reference movies so that phone can pick the content that most appropriate for the conditions on the Phone.

And...why don't we go to the next one.

Alright. So if you're looking for more information on these topics or places to research on the stuff we've been talking about there are some URLs that are useful to you. For example the object detection URL. What did we add this one? That's for the Phone.

ahhh this is for the Phone. You want to talk to these? Sure Mark Malone is the Internet technologies evangelist. Contact him for more information or help on things either for the Phone or for the Apple's other Internet technologies. And here we have some useful URLs for finding out more about coding for the Phone and also for the standard groups. The W3C media query and the HTML5 HTML5 spec that that's currently being developed.

Unknown speaker: Ok. These are the URLs that I was prepared to talk about. The first URL there the tutorial on the embed tells you all you need to know about formulating the embed tags for the QuickTime plug-in on your own. The second URL there, the scripting dash title URL gives you complete documentation on the current JavaScript API of the QuickTime plug-in. And we'll be updating that document to cover the new features that we are adding the the Leopard time frame.

Eric also mentioned that to cover multiple devises, you'll want to use QuickTime reference movies to allow the run time installed version of Quick Time to choose the appropriate movie for the device under the conditions that are currently pertain. In order to create those reference movies and learn more about them, go to the that make movie 2 URL at the bottom.

If you are interested in the QuickTime seating program, you want to get your hands on this technology. The enhancements to the plug-in that we've talked about today are not in your WWDC Leopard seed, unfortunately. But you can participate in the QuickTime seating program and get these things to try out before they go final, contact the Apple representative at that email address. CQT@Apple dot com to get involved in that program.