Welcome to session 731, Internet Application Development. My name is Ursula Ringham. I'm a partnership manager here at Apple Computers Developer Group. Today's session is going to cover Macromedia Central. It's a new product that they'll be releasing later this year. We have two people from Macromedia's development team for Central, David Calaprice and Michael Williams, and we have a third-party developer who's created some applications that work with Central, Alex Wright. So now I'll turn this over to Dave Calaprice.

Thanks Ursula. All right. So here we're gonna teach you a little bit about Macromedi Central. We're currently in beta right now. It's a new product under development. So, let's see here. So what you're going to learn about is Central. It's this new environment for Internet-enabled apps. And we're going to talk about also how Macromedia in general views Internet applications. So what we're going to learn is, we're going to get a little bit of a situation overview of kind of where the state is of apps in general, and talk about Central, and of course the process for developing apps for Central.

We're going to talk about rich Internet apps, XML, SOAP, WSDL, and Force Flash. So first of all, a little bit about the vision, Macromedias vision currently. Our vision right now is all about experiences. We feel that great experiences build great businesses. And this doesn't just pertain to application development, it pertains to pretty much anything. Whether you're going out to see a movie or drive a car or get a cup of coffee, people will pay more and expect great experiences. So Macromedia is all about helping people deliver on these experiences.

So, in order to do that, we are promoting this idea of what we call rich Internet applications, which has become very popular lately. What they attempt to do is combine the best of traditional desktop applications, so we're talking about things like the usability and user interface that you get with desktop applications, the availability of desktop applications, you can always access them regardless of whether you are connected or not, and also the integration with the operating system. As well as the best of web applications. Web applications are great at accessibility to data. They're connected, you can always have the most up-to-date information.

And also communication. We're trying to see a lot of communication used in applications lately, and this is also something that we feel is really important to improve the user experience. So we're talking about things like not just text-based chat and IM, but also two-way or N-way video and online. So all of these things sort of combine together to make what we call rich Internet apps.

What is Central and what are the issues that it addresses? Right now, most of the Internet is document-centric. Essentially, this has grown out of the history of the web, based on HTML and the web browser. Most websites are page-based and document-centric, and so most applications as well are also document-centric and page-based. You often have to click through multiple pages to perform a task.

This was a step backwards from the early '90s or even late '80s, when you had much more rich user interfaces in desktop applications. Another problem that Central is trying to address as an application platform is that the installation of applications from the Internet is often very clumsy. Typically, if you want to install an application, you have to download an executable file, find out where you downloaded it to on your desktop, double-click it, maybe run an installer, go through a few screens, and also have to worry about, "Oh, did I just download a virus?" or something like that.

So this is also a problem that we're trying to solve with Central. Additionally, applications in general don't work very well together. Unless they were designed ahead of time to cooperate, such as in a studio or suite, applications are pretty much developed as independent silos, and apart from maybe copy and paste, there's very little interaction between these applications. They have very little way of sharing data. And so that's also something that we're trying to improve with Central.

Next, offline use. Typically, web applications, if you go to a shopping application or any sort of application on the Internet, if you are disconnected, if you become disconnected from the net, that information is no longer available to you. Browser pretty much becomes useless if you're no longer connected. And so that's also something that we're trying to solve with Central. And finally, applications often have many different ways of notifying the user of events.

Some bounce the icon in the dock, other ones bring up little windows, and so there's not really very much consistency about how events are essentially communicated to the end user. And so we're trying to also provide some consistency in a framework for notification as well. So just going back to the basics of what Central is, it's an environment for collecting and managing applications. We call it United because the applications work together cooperatively, and unplugged, meaning that you can stay productive even when you don't have a web connection.

From the customer's point of view, what's good about Central? It combines the best of desktop interactivity and the availability and usability of desktop apps with web-based deployment and the ability to always have up-to-date information from the Internet. The applications in Central are cooperative and can work together and share data.

This delivers a much more efficient experience for the customer. Rather than having to go to one application and get a result from one application, for example, if you're doing some shopping and you want to look up information on a product and then have to go to another site to find a review on that product, that's an inefficient workflow. With Central, the applications can work together and actually share this data, even if they weren't designed to work together when they were built.

Fast and easy installation. I mentioned before the clumsy nature of the installation process currently for applications on desktop platforms. With Central, you can build an application and with a single click from a web page, it can be installed and running on an end user's machine. This sort of mechanism also leads into this try-buy mechanism, which I'm going to talk about here. There's a commerce system also built into Central. This is a very important aspect of the platform.

As a developer, you can create an application, post it on your website, and connect with our commerce system and sell your application and get money fed into your own merchant account without having to set up all the infrastructure, handle all the credit card, transaction processing, that kind of thing all by yourself. That's the infrastructure that Macromedia provides as part of building for Central.

Because of the trial system and the try-buy, the purchase system is built in Central, it's consistent across all of the different applications, the third-party apps and Macromedia applications that run inside of Central. The end user has sort of an expected experience. They're not going to be afraid of trying to download new applications, try them out, purchase them, and so on. They have to be afraid of different types of purchase mechanisms, something that they can trust.

Finally, you can use applications online and offline. This is, of course, up to the application developer to support both modes, but since Central is not tied to a web browser, you can actually have applications that store data for offline use and make that available when you're even not connected. And finally, applications built for Central will run on OS X as well as Windows and also in the future handheld devices. And they're all based on the Flash Player technology.

So to develop for Macromediacentral, you just use Macromediaflash MX, which is our shipping flash authoring tool, and the Central SDK, which is currently in beta right now and then later this summer or early fall will be available for public release. You use existing components that ship with Flash and also other components, UI widgets and other types of components that are available from third parties. You can use those as well as some additional components that we've built just for Central to provide a consistent look and feel across applications.

Also, you can build on top of web services and other structured data. So Central includes built-in native support for SOAP and WSDL, so you can use web services directly from the Central client to talk to a server. And the environment, as I mentioned before, it's all built on Flash technology. So if you can develop for Flash, then you can develop for Central.

So, as a developer, you have the benefits of a very widely supported development tool. There's built-in support for the transaction infrastructure, for download and installation of applications, services for exchanging data to servers, as well as between applications running locally on the client, as well as auto-updating technology. So, if you build an application for Central, and then a few months down the road you want to push out a new version, all that infrastructure is already there for you in Central, and so you don't have to do any special work to support auto-update.

and finally, Macromedias is going to provide an application finder, which is a global directory of all of the applications out there available for try and buy. And you can become listed in this application directory called the app finder, and then everybody who has Central has this directory always available on their machine as part of the Central runtime environment. So if they're out there looking for new applications, they can find them, and we'll show you a little bit of a demo of that in a screenshot in a minute. So it's a really good way to get exposure to your application.

And of course, the benefits of just being based on the Flash technology, the ubiquity of the Flash player is distributed to virtually all desktop systems over the last few years. So, people who have the current Flash 6 player already have the capability for downloading and installing Central and Central applications. And so, there's already some millions of end users out there with that capability. There's a community of 750,000 Flash developers worldwide today. So, there's a very large developer base and a support network set up for people developing for Flash.

You've got the portability across platforms that I mentioned before, as well as the ease of development of the Flash and the space-efficient file format and architecture. And finally, Flash is a multimedia player. And so, in addition to all that other good stuff, you've got support for things like video, audio, animation, you know, anti-aliased vector graphics, images, interactivity, and so on. and so on.

Here's a screenshot of the user interface of Central. What you see here in the main window is what we call the application window. This is the main area where applications inside Central run. At the very top, you'll see a toolbar with icons on it. That's the launcher area.

Each application you install has an icon and it becomes listed at the top there in that toolbar. The end user simply clicking on that icon launches the application. You can bring up multiple of these applications if you want, just like a web browser. It's a very simple, easy-to-use interface.

You get an icon, you click on it, and it runs the application. The rest of the space in that window is for the application itself to run. That's up to you as a developer to decide whatever you want to put in that space. Like I said before, we'll be providing a set of components that you can use to handle a lot of the common user interface functionality.

On the right side of the screen is what we call the console. This is a toolbar that can display optionally small, miniature versions of these applications that can be there as a persistent presence on the user's desktop as an option. For example, here we've got a traffic camera showing all the time and a weather satellite map. You can imagine other types of things like stock tickers or news information, other types of feeds, they can run as little tiles in this toolbar.

This is also where notifications appear as well. If an application wants to present a notice to the user that some event has occurred, a price of a product that they're interested in has dropped to a certain amount, then the notices can appear there in the console as well. These windows can be open or closed independently. You don't have to have any of these windows open.

It can just be running in the background, or you can be interacting in the main application space, or you can just have that console up if you just want to have a small bit of real estate used to show this information on your desktop. on your desktop. So those are the basic elements of the central UI.

So as far as the installation goes, I mentioned before, you can install directly from a website. So here's an example of, there's a company called Price Grabber, which has a shopping site that lets you compare prices for different products online. And we've been working with them to build an application for Central. And so here's an example of what their website could look like with a Central installation button on it.

So essentially, all you have to do is put a small Flash movie in your website with a button on it to install. All the user has to do is click that button. If they don't have Central installed, it's automatically downloaded and installed. Then the application itself is automatically downloaded and installed, and then it's launched. This all happens in a matter of a couple of seconds, and then they're up and running with the application outside of the browser.

So that's installing from a web page. And then the alternative is you can also install from the application finder. And this probably isn't too easy to see with this display, but it's essentially a directory of applications. And the end user can sort by different categories. There's a whole rating system where people can provide feedback to applications and rate them. You get all the information on whether it's a free application, how much it costs, what the length of the trial period is, and so on.

So there's different ways to browse through the whole directory of applications. And this is available, like I said, as a built-in component of Central for all users. And there will also be a version of this on a website, so you can access it even outside of Central if you want.

So next I'm going to bring up Alex Wright, who is an independent developer. He's been working with us since the conception of Central, helping develop applications and helping design the look and feel of our applications. And he's going to give some demonstrations of some apps running inside Central. Okay, great. Thanks Alex. Thanks Dave.

Dave already gave you a preview of the UI. I'll just let this load quickly. That's price grabber. Let me start over here. Okay. So you see here's the application window. Here's the console. And we've got a couple of applications loaded into the app finder here. So what I'm going to do first is just walk you through a couple of the applications and sort of show you how they work. So we'll come back to the app finder later maybe. But I'll start with one for price grabber, which Dave showed you sort of a snapshot of.

So, again, price grabber is one of these services that provides comparative pricing data on consumer products. So they have something like -- I think it's something like 15,000 products in their catalog. And they get prices from a lot of different retailers on a daily basis. And you can get sort of like MySignment or there's several services like that.

And their business model is they basically syndicate this data to other sites, like I think Lycos, for example. Lycos uses them. A few others do. So really while they do have a website that you can go and search for prices on, what they're really in the business of is syndicating this pricing data. So what we wanted to do was see if we could create sort of a better interface to comparative pricing data using the central environment.

And this is what we come up with. This is actually sort of a first build of it. We're actually working on a next build that will actually be a little more sophisticated and have some new features. But I'll show you some of the basics here. So one thing I can do here is just do a search. So let's say I wanted to search for an iBook.

So I'm going to click the submit button. And what's happening here is the application is parsing a request that gets sent out via HTTP to the PriceGrabber server. What happens is the PriceGrabber server responds with an XML file that we read into the application that contains all the data that you see here.

So basically what it came back with was three matches for Apple iBook. And what it's showing me is the best price for each of them. And they'll get, I think, up to like 20 different prices. But at least in our application, we'll show you the best price. And then it shows you sort of where that search result fits in this product hierarchy or taxonomy that they've got, which I can also browse around and explore here if I want to.

So for instance, we can do this. So you can see it's pretty responsive. Every time I'm clicking on something on the screen, it's sending a request off to PriceGrabber and bringing a dataset back. You can see just in the process of sort of clicking around here, This is a much more efficient interaction than it would be, say, in a web browser where you'd have to go, you know, web page to web page to web page, get a whole chunk of HTML back with every one of these requests.

Basically, with Central, we're able to put together a request and very efficiently just request the exact pieces of data that we want to get back and read into the application. A couple other things we can do with using some of the standard components that Macromedias developed. This is one called the Data Grid that lets me do sorting.

Very simple, very familiar sort of desktop OS convention. But again, if you compare this to the experience in a web browser, there's no easy way to do this in a web browser without going off to a server, whereas this is all happening locally inside the application. Oops. We didn't see that. Okay, so as I'm going through here, I'll just move on through the application a little bit.

Okay, and here we go.

Okay, so here's another feature of Central. It remembered where I was when I just shut down and came back to the application. It preserves the state, remembers exactly where you left the application when you come back. So let's see if I can pick up where I left off, okay.

So as I go through and browse through these items, you can see what's appearing down in the preview pane is sort of a thumbnail image displaying the product shot, some basic data about the product specs. We also get user reviews that are also provided by PriceGrabber. Now, if I see a product that I like, I can add it to my favorites list.

And what happens here is it gets added. You can see it switch to another tab here where I can keep sort of a short list of products. We're also creating a feature where you'll be able to set a price notification. So if the price drops, you can get a notification in Central that will tell you that the price went down.

So those are just a couple of things you can do with it. And another thing we're working on is the ability to do sort of more advanced searching based on specs and filter, you know, basically looking at different criteria or specs around a product, being able to do more advanced searching and filtering around it. So anyway, so that's PriceGrabber. I'm gonna show you another example of an app we've been working on, and this is a stock ticker app. So the first thing you'll see here when this comes up, when I run it, this is an example of the Try Buy feature.

So this basically is sort of an example of how this would work. If you're a third-party developer and you launch an app, you release an application on Central, it'll have a built-in Try Buy facility so that you can put an application out for trial for as long as you want and then put a price on it. And then the user can either try or buy. So as soon as the trial period expires, they'd be forced to buy it or they wouldn't be able to use it anymore.

Well, let's say I'm still in the trial period, so I'll hit Try. And this is basically just a, a fairly raw prototype of the application. But what this will do, let's say I wanna look up a stock quote. I'll put in about these guys. And this is going, querying a third-party web service, pulling back the stock quote data. So it gives me current quote, change date, and then some additional detail down below. Select that, okay.

So it's fairly straightforward. I mean, nothing, you know, sort of what you'd expect a stock taker to do. But again, a little more efficient than you could do with a web-based application. But what's interesting about this is I can also... The first step is to set an alert so that if I wanted to set a target price or sort of a stop price on a particular stock, I could set up a notification and it would proactively, if the stock hit that price, it would proactively notify me in the console using the notification feature. So again, a way of making the application a little smarter, a little more aware, and adding a little bit of value for the user.

I think this is a good example of, you know, since this is such a lightweight, sort of, you know, concise little application, it's a good candidate for what we're calling tiles or pods or these things that appear up in the console. So this is just a sort of boiled down version of the... of the application. So let's see how JetBlue is doing.

So again, similar sort of thing, but just gives you a very nice little, handy little utility application that you can use to do sort of quick queries like that. Let's see, so let's keep moving along here. Here's a prototype of a weather application we've been working on, and this is using AccuWeather.

So what you get here is basically, again, fairly straightforward. You can just look up whether for any location and it'll accept...

and I can have up to, I think it's up to 10 weather forecasts. You can see as I flip through these, it's fairly efficient 'cause this is all happening on the client side.

So once this data is cached in the application, all this is happening locally. Now, let's say I wanna just keep an eye on the weather. What I just did was I hit tile here, and that could launch... So I can basically just take this little weather forecast, sort of pin it to my desktop and keep an eye on it, and it'll automatically refresh, you know, on a set interval.

So you can see now I've got two things going on in my console here. I've got the AccuWeather application and the stock application. And you can have sort of an indefinite number of these things over time. So it gives you a way of creating applications that can have a little persistence on the desktop and take advantage of the runtime environment to do things like polling and notification and just create a little more of a rich experience for the user.

And I think what's really, the really interesting opportunity with these applications is the ability, because you're in this single session state in the central environment, opens up all kinds of possibilities for these applications to talk to each other and to share data with each other. You can actually permit one application to expose its data to another application. So for instance, if you were, I don't know, looking up a movie time, you could add it to your calendar very easily. So you could take, you know, the calendar being another application that might exist at some point.

And I think that's really interesting. There are all kinds of opportunities like that. For instance, let's say you're thinking of, I don't know, traveling somewhere. You know, you might be able to look up the weather and get a map to a location and, you know, add that to a shared calendar that you might send out to people.

So there's all kinds of opportunities to share data and create, and basically it gives you an environment where applications can talk to each other and be sort of aware of each other. Which is something that's just very difficult to do with traditional web-based applications where you're really in much more of a siloed mode where each application needs to exist separately. So those are just a couple of examples. We talked about the App Finder.

So I thought I'd just show you the working version of this real quick. This is just a sort of sample, a couple of applications that are in there now. This is a sort of a demo prototype for a Homeland Security application. And I don't know if this will actually see the light of day or not, but it's sort of an interesting idea.

You could just get a-- you could see Tom Ridge's vase and get a--

So that's where we're at. These are just a few of the applications. I hope this gives you just some idea of some of the things that are possible. These are all, you know, somewhat prototype-y. There's several other applications that are currently in development that should ship when the final version of Central goes out.

But hopefully this gives you some idea of some of the things that we're thinking about, and hopefully you can come up with better ideas than these. Anyway, so I think that's all I've got. I'm going to turn it over to Mike here, who's going to tell us a little more about developing in Central.

Thanks, Alex. Can I go back to the slides? Thank you. So what I'm going to do is give you a little overview of how all of this works and show you a little bit how to build a really simple application using the Central framework and environment. First of all, I want to give you an overview of what the file format of Flash is.

It's called SWIFT, which stands for Small Web Format. That is what kind of basically is the heart of Flash. And when you create something using the Flash authoring tool, you're actually creating a SWIFT file. It's basically the native format. It's a compiled binary file that contains bytecode and media that's been compiled by the authoring tool. And so there's a number of different tools that create SWIFT content.

Macromedias is kind of like the keeper of that format currently. And it's an open format that has basically become the de facto standard for doing rich media on the web. And Central is our next step to taking things outside of the web browser and more into the desktop environment. And the primary scripting language of Flash is what we call ActionScript. It's based upon ECMA 262 with extensions for the Flash document object model or DOM. And it's the same exact scripting language that you would use for JavaScript inside of a web browser.

So the Central Application Architecture is made up of four major parts. There's the application shell, the console, the central user interface components, and a number of different Swift files that kind of broker that data back and forth for you as a developer so that you don't have to do kind of a lot of the dirty work needed to make these applications and pieces work together properly. So the main central parts are the main application that you create, the tiles, and these things that we call agents. And agents are kind of like invisible background processes that allow you to kind of broker data back and forth between all these different parts.

So all of this is built, as I said before, on top of the Flash Player with some things added on top of it. And those things are, first of all, something that's very exciting to Mac users is we added a lot of performance enhancements, not only on Windows but on the Macintosh as well, to make it run a lot better. We've had AltaVec enhancements for graphics and alpha channels and things that in the past have been significantly slower on the Mac. And now we have parity between Windows and Mac for that kind of performance.

So that's something that makes Mac users very happy. We've added native web service APIs so that you can call WSDL and you can make direct SOAP calls without having to go through, as you do today, through flash remoting or some type of gateway on the server side. We've also added, because of the fact that we don't have to worry so much about the size of the Flash Player, we've added regular expression APIs so that you can do lots of more advanced string manipulation that you'd have to do when you're bringing in large data sets from the web. And we've also made it so that, because you're not in the browser, you don't have the ability to kind of cache data. We've given you APIs where you can manually cache that data.

And we've also made it so that we have a direct connection to an e-commerce system. So if you want to sell your applications or do transactional processing, we do that for you.

And then the next time the person comes up and opens the application, they immediately get back to that point. Excuse me.

So here's a quick kind of stack diagram that shows what's actually going on inside Flash. So at the most basic level is the native operating system. Mac, Windows, a device such as Pocket PC or any other device that comes along that can run the Flash player, such as Nokia handhelds, all those kind of things that we have the Flash player running on.

And the next thing up is the Flash standalone player. And it's basically taking the runtime version that you have inside the browser and it's wrapped around an executable that kind of brokers and holds this data. And sitting on top of that is something we call the controller, which is a Swift movie that then kind of, that does all of the controlling of, you know, what messages are gonna be sent between what windows, opening new windows, opening new consoles, getting data from the server side, storing preferences.

Sitting on top of that is the primary areas as a developer where you can build something. As a developer, you can build your own application that sits inside the app shell, you can build your own tiles that sit inside the console, and you can build your own agents that sit inside the agent manager. It deals with all these invisible, persistent background processes.

So, like I said, applications contain three primary parts. So there's an XML product definition. So there's an XML file called the product XML that says this is what this file, this is what this application is. It contains this size, this width, these contents. The next part of it is the actual Swift that you compiled using the authoring tool that has all of your application logic, your graphics, your video, your audio, all the things you can do in Flash. And the last thing is kind of the icon that represents that inside of the central application runtime.

It's kind of hard to see, but this is basically an example of what a product XML file is and what it presents. It kind of gives you data upon who created it, what time it was, and all the things that represent your application. So, to Central, this is your application.

This is kind of the metadata that wraps up what is an application that you've built and what the application needs to do. So, anytime we add something to the Central framework, you will define it using the product XML file, and that's how you kind of tell the system what you want to do and how you want to build it.

So, basically, a tricky thing that came along when we tried to kind of build this environment where we have multiple Flash movies all communicating to each other was people had never done that before. Typically, when you build some Flash content, you're building a single Flash movie running inside of a web browser, and that's all you're worried about.

You might be doing some animation, you might be building an ad banner, you might be building some type of, you know, simple web service application. But you're not really worried about having two different movies communicate and share persistent data. In order to solve that problem, in Flash Player 6, we added something called Local Connection, which allows separate Flash movies to then communicate to each other over kind of a global space. So, you can actually have Flash movies that are running on top of the desktop or they could be running inside the browser, and they can then send data back and forth to each other.

So, this allows us to then have multiple elements of a Flash, you know, kind of runtime that are written entirely in a scripting language rather than us having to build everything in kind of a very low-level language like C or C++. We can actually build it in our higher-level ActionScript language so that things are more portable and changeable.

So, we can write our framework once, and it will run on multiple platforms. We don't have to worry about having to report everything to Windows and Mac and a device. So, we can actually build it in a very low-level language like C or C++. So, we can actually build it in a very low-level action script language so that things are more portable and changeable. So, we can write our framework once, and it will run on multiple platforms. We don't have to worry about having to report everything to Windows and Mac and a device. Mac on a device, everything will work exactly the same way.

So basically everything that you write as an application developer, it's the same kind of framework that we have to go through at Macromedias to build this. So as we add more and more frameworks and more and more abilities, the Central framework becomes more powerful for us and also becomes more powerful for developers as we start drilling down more into the operating system.

So that drilling down is actually being done entirely by the controller. And the controller is the one that actually talks to the Flash player, and that's what talks to the operating system. So if we want to send a notice and we want to make the icon in the dock bounce, you do that through an ActionScript call.

If you want to do that, if you want to add a new application, we do that through ActionScript. Rather than you having to write that in kind of a lower level language, it's all done in our higher level language. And the controller is what does that. And as we expose more and more APIs, those get exposed through the controller and through kind of all the standard APIs that we document as part of our SDK.

So it manages what application shells are running, what is currently focused, all the kind of dirty work of what's going on and making an application behave like an application that often people have to deal with and kind of manage. We kind of do all that for you inside the controller. So all you have to worry about is building a really great experience. You don't have to worry about making sure that you have application focus and dealing with all these kind of little dirty things that you have to do to make an application work well.

So the next thing as part of the framework is agents. And agents are basically, they have no visual representation. They're background processes that allow you to make script-only connections to data services on the web and let you have persistent data for your applications. So if I'm going to build a weather application and I want to hook it up to my calendar and say, you know, we're only gonna go out on Saturday if it's sunny and warm, I can make it so that the calendar application knows, it talks to the weather application and says that the weather's over 80 degrees, book this trip and book this event with my friends and send a notice out to them. So all that kind of communication is going through agents. So each application has its own agent and each one then can communicate with others. So they can open up kind of channels of communication to each other.

And that again is managed by the controller and something called the agent manager. And when you're in your product XML, basically if you want to have an agent, you just define this line here and you say, I have an agent, it's got this name, and this is the Swift that contains that logic.

The next major part is the console. This is a screenshot. This is actually a later version of the prototype than what we showed up there. It's our current thinking of what it's going to look like. Basically, it's your persistent area where each application lives and resides in the desktop. The same way as you have any other persistent application running in your desktop, you can build that kind of environment and run it here.

If you want to give people information and the latest up-to-date data, that's what goes here. Same thing with notices. They go inside of this kind of persistent area that runs on your desktop. That's kind of fully controllable over you of where it lives and how big it is and what's inside of it.

and what we call each of those elements. The first part is called tiles, and that's basically the framework for consistent desktop presence. And for instance, you can have a weather tile that shows your local weather, and basically, or you could have any type of application, and those tiles are basically configured over what you see inside them. Could be either configured within themselves or configured by the application that created them.

So if I have a weather application and I'm looking at the weather for Chicago, and I say I want to monitor that, I can say, "Here, save a tile." It'll automatically, excuse me, add that tile to the console, and it will contain the latest information that you had for Chicago. So you're not having to go back and forth and reconfigure it. That data can be sent along and persisted across from different elements of the central framework.

The next part is notices. This is another screenshot of some current prototypes of what we think notices will look like. Basically, you'll have this kind of information about each application. I basically want to say, "Tell me when the Animatrix DVD comes out." It will come up and say, "The Animatrix DVD is out." Click on the notice.

It will open up that application and give you all the data. Maybe you could buy the DVD. You could go check it out and get all the latest information. It's really giving you up-to-date, the latest information. They can be triggered, and those are all triggered by events within an agent.

And the last part is the application shell, which is kind of your primary representation of where you build an application inside of Central. And it's where not only your application resides, but the end user, where they store their collections of applications. So if they've gone all over the web and they've found a whole bunch of applications they like, that's where they're always going to go to get them. That's where they launch their applications. That's where they find new applications.

And we provide APIs within that for changing the window size, the position of it, getting events from the user when they resize the window so you can deal with layout, getting information about when they're typing certain keyboard events so you know the index of your tab ordering. You have information over the status bar preferences, knowing when the window opens and closes. You also have notification as to when the network connection is lost or open.

So if you want to build an application, you have an application that runs both online and offline, but you want to make sure that it gives the user some notification of that. Or you start, instead of going and querying a web service, you're querying local data. You can first check and see if, am I actually connected to the web with a single call? Without having to kind of do that yourself, as you would have to do inside of a web browser. and you can also deal with setting notices, agents, and creating and removing tiles.

So after you've gone through and done all this stuff and you've built a full application, the next thing you want to do is you want to package that up so that you can distribute it on the web. And the way you do that is you build kind of what's called an installer SWIFT, and we give kind of a basic framework for how to do this. This SWIFT resides inside of your website or any website where you want to distribute your application.

Basically, it points at a product XML file which describes what your application is, where it comes from, the dimensions of it, all the kind of metadata about it. And when you click on the install button, it reads that XML file. It then kind of sends a message to the player saying, "Do they have the central runtime?" If they don't, it goes and downloads it, puts it on their machine, launches it, runs it, and all of a sudden comes up your application focused forward and, you know, if you want, immediately will be there for them to use. And that's the entire installation process. It's very straightforward and easy to do, and you can build whatever user interface you want for the installation process because all it is is a Flash movie that's triggering some native events with inside Flash.

And you can also, basically, if you don't want to do it yourself and you want to get a larger distribution, you can say, "This is my application. Put it up inside the Macromedia app finder." And everybody who comes to Macromedia.com, the millions of people every day, can go and check out your application and you don't have to worry about being the one that's distributing it. It's going to be entirely distributed by Macromedia.

The next major part is the user interface components. So this is something that's kind of been involving pretty rapidly in the last year or so with Macromedia and with Flash is people are trying to not just build animation anymore. They're not just building simple multimedia. They're trying to actually build real applications that have the kind of look and feel of an operating system and behave the way people expect. So part of that was our first initiative to build components and user interface frameworks to make that possible. And so part of that, we give you a bunch of standard user interface frameworks that you kind of expect, so you don't have to go and build them yourself.

And what we call these frameworks, the name for them is Halo. And Halo kind of gives you a consistent look and feel across not only Macromedia tools, but all the content that's built using them. And so you don't have to go and kind of do that work. And all these things are hosted by Macromedia.com in a runtime shared library. Runtime shared libraries are, rather than having all the assets inside of your Swift file, are coming from a remote location and then instantiated. So rather than you having to go and do that every time, it automatically gets it from Macromedia.

And rather than having to download those every single time, you automatically get them. And when we update them and we change them, you automatically get it. And it keeps the size of your applications much smaller. So you're not having to include the data for what a checkbox is or a radio button every single time you build an application.

So the way you consume and store data inside Central is primarily via XML, and that's something that has been in the Flash Player for several revisions, but has been focused and improved upon over the last two releases. And in Flash Player 6 and in the Central Player, we've added significant performance enhancements to make XML data retrieval and manipulation much faster, and much more the best way to do things rather than dealing with kind of native objects inside Flash, which can be cumbersome. And we also have given you native web service support so that you can take structured XML data that you're getting from a server and then do something with it that's intelligent.

And then you can take that data, store it inside of a local shared object, And then the final thing that I referred to before was that you can now cache that data locally on your machine. So it can be anything. It can be an image, a JPEG, a video, and you can store it locally. So if someone wants to download a movie and watch it, you don't have to download it every single time. You can say cache that thing once it's finished downloading. Next time they come on, if they're online or offline, it's going to give them that data.

So now I want to kind of show you, I think, I believe, yeah, I'm going to show how you actually built something for this. So I'm going to kind of step through what the basics are and then show you some code examples inside the authoring tool. So the basics of building something inside Central, and some of you may be familiar with how you build applications inside Flash, is you basically want to build inside the first frame of your movie, you're going to be putting some action scripts.

And the first thing you do is you kind of tell Central where I am, who I am, that I am a Central application, and that I expect to be getting messages from the overall Central framework rather than just me being a web application. So you kind of have to tell it via this kind of initialization operation. You say, you know, I'm inside Central. Please start giving me messages.

And once you are finished getting those messages and you are fully loaded inside of the Central environment, Central is going to call you with a function called onActivate. And that's basically going to tell you I'm fully loaded inside of Central. You can now do whatever you want. Have fun.

So for installation, what you have to do is you have to create a product XML file, or you can modify one from the development kit. You place your app Swift, your product XML, your icons, and your installer on your server, and you make sure they're all in the same directory or using relative paths. And then you basically click on that button, install it, and it gets put into the site of the Central environment, and I'll show you how that works shortly.

And another thing is, like I've discussed before, local connection is really something that you want to be able to learn how to use and become more familiar with if you're not already. And basically, it's a simple API that allows you to open up a connection to another file, to another Swift file. And this is kind of a simple example of someone having an agent that's a stock agent. You want to make a connection to it, and you want to call a function that's called getTicker. So that's what basically is here, and you're passing a basic argument.

This allows you to communicate between your application and the agent, between your application and a tile, or between the tile and the agent. All of that communication goes over local connection. You can also use this to debug. So if you want to actually have information being sent to another window, basically saying the kind of state of your application that is not something visual, you can use it for debugging as well.

So, in order to add a tile, here's some information about how you would add a tile inside of Flash. Basically, you create a new Swift that represents your tile. You set up the phone call the same way as you did inside of the first application. You say, like, basically, initialize this tile. Central goes and initializes it, calls back, saying, "Okay, you're done. You're loaded. Now do whatever you want to do on activate." Very similar to how you build an application. And you install, basically, you add a line about the fact that this tile exists inside your product XML.

and you can have as many tiles as you want for application. So tiles, so here's some examples of things you might want to use tiles for. You want to use them for live monitoring of push data, such as current stock prices, current scores, any type of persistent, constantly updating data.

And you can use it to get a subset of an application's functionality. Rather than having to go into the full application, if you want to get just a little bit of information about like my latest calendar data, that's where I can show it to you, rather than having to launch the full app.

Use agents for persistent monitoring of data. And this is the actual data set that you're getting from, that you're going to be giving to your tiles and applications. The actual tiles are more like the view, and this is kind of the model that's going back and forth, and the controller that's kind of giving you all that data, and it's pushing it into a tile, or it's pushing it into an application. And you can also use agents for communication with other apps. Not only apps inside Central, but apps inside of a web browser as well.

You don't want to use them for processor intensive tasks because these type of things, like things like iterative functions that are going over and over, because the user can't see these things. They're going to be running. You could be creating an invisible process that is slowing the entire machine down, and the user has no way to stop it without quitting Central, and you're basically going to muck up the entire environment.

So here's a little bit of code about how you actually would create a notice. And basically, you create a new notice object. And this is basically a callback from the agent manager that basically says, you know, this is basically going to say, I'm going to add a notice that says this data saying, this is really simple, it's just saying, a notice came up and it has no data in it. So this is a really simple thing. It's not actually giving you anything. It's just a kind of core framework for how you actually create a notice.

And you want to use them to notify a user. And you don't want to use them to display errors, you don't want to use them to display connection notifications like 404s, and you want to be polite with them. You don't want to be constantly coming up with notices.

You can also create custom preferences with inside of your application. So if you want to be setting certain particular information about your application and make it so people can configure notices, configure tiles, configure what all the kind of persistent things that they have no control over, you want to give them a way to visually do that and as a full kind of framework for how you do that with Inside Central.

And you don't want to use preferences to create preferences that are already done by Central, because Central already has kind of a core preferences where you can set up global things like your location and your information. And that information is then persistent and available to you. So once the user defines their name and information, you can query that and get their email address and all that kind of stuff if they've made that available to you. So offline data management, I've said this a little bit before, it's done with shared objects, and each application has a limit of 100K.

and basically that data kind of sits persistently on the hard drive and never goes away. And it's basically best for the kind of internal data that you're storing that you want to make sure that always comes up every time that application is loaded. And it's stored in a textual way.

Local Internet URLs is basically anything that you can pull off the Internet you can store. You can even pull things down that aren't even readable by Flash. So it's a very open way for you to cache data and cache information. And there's a limit of how much you can store. By default, it's 20 megabytes.

Same story with if you go over that limit, it's going to warn you, say, you know, this application is trying to request more data than you need than you currently have set, and do you want to allow that? And this is a short example, a short explanation of how that API works.

It downloads, it begins, once you call it, it immediately starts making that call. You can access it through normal ActionScript methods, saying, is this loaded, when it's done, do something with it. So it's the same way that you deal with any type of loaded data, same way you deal with loading XML, same way you deal with loading an image inside Flash.

It's the same way you deal with that inside of Central. So if you know how to do it in Flash, same exact skills. and just kind of telling you basically in the first beta, each request is a new HTTP stream. And basically in beta two, we start queuing that up like the browser does.

It's important also to show that your application is requesting data because it's not something that we automatically come up with a progress dialogue and say, you know, you're downloading a bunch of data. So your application may seem like nothing's going on. You need to make sure that you actually are showing progress of your application and giving the user feedback.

And we're actually, we do provide APIs for you to set some information in the status bar that of the current status of your application, how much is loading, what's going on. And we really encourage people to use that to give the user kind of a consistent method of feedback rather than you having to do that every single time yourself.

Offline behavior. Talked about this a little bit already. You basically will get a callback and you're going to check to see whether or not the network has gone online or offline. And you can use that to properly set up your application to make sure that when that callback gets notified that you either switch to using local data or you make sure that you're not making requests to the server side. It's fairly straightforward. And sharing data between apps, you're going to be using agents over local connections.

And updating your application is very straightforward. All you have to do on your server, where you have your product XML, increment your version number from one to two or any number above. Every week, the central environment on the person's machine will go and check that product XML. If the number is greater, it's going to go and download your new version. So all of that kind of update functionality that's fairly difficult to deal with is all handled by the environment itself. So now I'm going to switch over to the computer and show you how to build a really simple application.

First thing I'm going to do is I'm going to open up the Flash authoring tool. And I'm going to open up a simple application here. So this application here is a very, very simple application. All it does is has two text fields and two buttons. And the way that you do that inside Flash, if you want to add text fields or buttons, is basically you have... One second here. You have a text control here, and you can basically drag out and create new text fields as you please.

and then you can define them, give them instance names, everything you want to do. So I already have two created here. One is input text and one is stock info. That's right here is defined their instance name. So that's how I'm going to access it via ActionScript to know how to give it information, how to change it. And I also have two push button components here. One is going to actually make the request to get the stock information. And this one is going to like just test that I've properly created the notice.

and you can see that I've also given both of them instance names. The way you add new components is you over here, you have the Flash UI components panel and you can simply click and drag new user interface elements. And we give you a bunch of pre-made ones for Central that give you that look and feel and have all the kind of proper functionality for you to deal with remote shared libraries. So you don't have to deal with any of that work. So if I go over here into the first frame of my movie and I open it up and say Actions, I can see all of the script that makes up this movie.

And explain it to your hands. Can everybody see that all right there? So basically the first function that you're going to have here is called onActivate. And this is what gets called when your application has been fully loaded into the Central environment. Basically you get a callback that basically gives you a shell object, and that shell object contains all of the APIs that make up Central. So when you're inside this environment, you always refer to where you live as the shell.

And in this particular example, the first thing I'm going to do is I'm going to add an agent. And that agent is the stock checker. So inside of the product XML, I defined a stock checker agent, and I can refer to it now within the scripting environment and say add that agent, and that agent is another Swift file, which I'll show it to you in a second.

The first thing you'll notice is the ticker symbol, which is basically going and checking to see if there's a new ticker symbol. And I'm telling that button when it's released, it's going to make a new local connection.

So that information I'll show in a second here after I go through this.

And this is basically all of the information for displaying that data. So once I get that data back, I'm going to then take that text field and fill it with data that I got back from the local connection, which is what this is here. Stock info dot text, the text value of that stock info text field, I'm going to give it the value of the price of the stock that I got back from a web service.

And right here, this Do Test Notice button is when I click on the test notice, it's going to actually go through the process of adding a new notice and giving a really simple notice that just says New Test Notice. And this is kind of all the different properties of that notice. Whether or not it's going to show an alert in the tray, and this is basically setting the progress bar at the bottom of the shell.

And this is the same thing. If I get a notice event, I'm going to set the progress bar to be back to the way it was. And also, there's a little example here of the actual logo that I'm using inside of here. It is a little central logo.

I'm saying take that thing, the first time it loads up, add it to my local Internet cache so I can give it any type of path to a file and it'll store it locally on my machine. And then in the future, all I gotta do is refer to that same path. And if it's locally cached already, rather than fetching it from the web, it's gonna fetch it from my cache first.

So it's always, whenever you do a load movie call in Flash, rather than in the way it was in Flash, where it would always go out and fetch the data, the first thing it does is it checks the local Internet cache and then it goes out to the web.

And then the final call here is basically saying, this is the first thing that's gonna be called when the application is first loaded. It's gonna say, "Hello, I'm an application." and Call me back in a second when I'm loaded. So that's an empty application. So when you actually build an application in Flash, so now I have to actually publish this movie. So I'm going to say, export movie, which is gonna take this Swift file and export it.

and I'm going to export it. So now it created that movie. It's not going to run inside the environment. So what I want to do now is take that actual application and then I want to install it in the Central. So the way I do that is I have this saver swift that I've created. And basically inside of that saver swift, I define the path to the product XML that defines this application. So if I open up this, it shows the product XML for this very simple empty application.

It just says what the version of it is, what's the information about it, who made it, what's the name of it, where is its icons, and also where is the source of this application. The primary application is called empty_app.swift, which is what I just created. And I also have defined that I have an agent and a tile. and so basically what I have now is I open up this saver.html and I'm going to go ahead and click Save. It goes and launches Central.

And it will go and ask me, do I want to install that application? And it uses all the data from the product XML saying this is the version of it and what domain it came from. I can say, okay, it now installs it, and then immediately takes me to that application. So here's the application that I have.

So when that application first started, it actually also initiated an agent. So I can right now, I should be able to say, give me the current stock price of Macromedias. It's going to go out, talk to that agent, get some data from web service, and return it back to this text field here, assuming that I did it correctly.

So the first thing it's gonna do is, this application doesn't have the rights to do that under our security model. So it's gonna come up and say, "Do I want to allow my local machine to access this URL?" So I'm gonna say, "Yes, allow it to do that." - Where I can tell it to always allow that. And then if it's allowed, it's gonna make the request, come back, and then feed that data into this text field.

There it goes. So there's the current Macromedias stock price. So that's basically a very simple application that I built. So let me show you really quickly how the actual agent was built. So if I open up this app agent flaw, this is the one that's being called by the local connection in the other movie.

Basically, it says, you know, it's the same thing as I was showing before, the way you build it, you just say, onActivate, when this thing gets loaded, it gets a callback with the agent manager, it's going to start an interval, which is said interval, it's going to say, recursively go through and say, load some data for me from the server.

and make a local connection to the application that created it. It's going to make a web service call. So this is the APIs that have been added to Flash. Rather than in the past, you had to kind of do it yourself, you can now directly call a web service. You just say new web service, give it a WSDL file, and that will come back to you with an object that has all the callbacks of that WSDL file.

So you just say stock service dot do company info, which is the callback of that web service. You give it, and this one in particular has a user ID and password of user, any user, any password. Give it the ticker symbol that I entered in that text field.

Call it. When I get a result back, the same way as you deal with any result from an XML file, I'm then going to send that local connection back to Flash into the other movie, from the agent into the hosting application, and I'm going to say, call the function receive ticker with the current price. And that's the other function that I had inside there was called receive ticker. That then receives that data, puts it in a text field.

So that is basically a very simple stock ticker application. And if I want to also, in that application, I can say test notice. So there I just added a new notice. If I had sound, you could hear it. You could also see that the doc item bounced for a second.

And I get notification basically through the operating system as well. And right here, a notice came up saying here, new test notice. So that's the same notice information that I set up inside the application. Goes and does that, goes through the framework, uses the same data that you set in there. So there we are. I'm also having an advisory that Homeland Security has been gone to elevated.

So that's how you build the basic elements of Central. And from there, you can build a whole wide range of applications. And those are kind of the really basic things. So can I go back to the slides? So, I think given that, I basically want to give you a quick idea of where the state of the project is. Currently, like Dave said, we're in beta.

We just got beta 2 today after a lot of work, and we're undergoing a lot of usability and interface look and feel and figuring out the best way to do this. And we're going to have a public release of the SDK and the environment for all people to develop for this in the end of the summer, 2003. And we're going to launch the platform for end users towards the end of the year.

And if you want to get more information about this, you can go to the Macromediacentraldevelopmentcenter.com, which is listed up here, or you can just go to macromedia.com and look up Central. And that's where you can sign up for the SDK. And here's our contact information and for information, it's all in here. So, if you have any questions.