Hi, I'm Michael Powers. I'm a Chief Technology Officer of Empower Player Incorporated. That's my company. We make solutions for consumers to easily find, try, and ultimately buy mobile applications. One important part of that equation is the try function, and that's the emulator. And it just so happens that our platform is completely built on J2SE. So we have a J2ME implementation on J2SE. The neat thing for you guys is that this is actually a full-on mid-P2 emulator that runs on the Mac, and you can use this today to build mid-P applications on your Macintosh. So what are we going to talk about? Mobile development using Xcode in the Macintosh platform. I'm going to basically cover three things. One is why you should care about mobile development. Two is, you know, what J2ME, mid-P, what that's all about. And then three, we'll talk about mobile Java applications, you know, the guts of it, so that when we get to Ted's portion, he'll show you how to develop, debug, and deploy those applications. So let's get started.

Mobile development, what is it good for? Well, I'll tell you. What are the kind of unique characteristics of mobile development versus desktop or enterprise development? A few things. I think first and foremost is the fact that it's personal. People in the mobile entertainment or mobile application industry like to talk about three screens that people have in their lives. One is your television screen. Another one is your computer screen or laptop screen. And then the third is your mobile screen, the thing you carry around with you wherever you go. When you leave the house, you typically take your keys, your wallet, and you guessed it, your phone. So it's with you all the time. And this makes it a very personal computing platform. You don't share logins on your phone. You pretty much-- it's your applications.

People like to think of their phone as a personal information device. They make it a part of their own personality. And good mobile applications can take that into account. Another and very important distinguishing platform or feature of the platform is the connectedness. That's the wireless aspect. You have a network there, and it's mostly on all the time. And a good mobile application would do well to take advantage of it. So that leads to a number of kinds of applications that are suitable for the platform. Take, for instance, web services. When I look at dashboard widgets, I think the best ones of those are the ones that pull in information off the network using web services typically.

Any of these are a great example of something that could play very well on the mobile platform because they take information and they make it easy for a person to use in a small form factor user interface. Another great example is our thin client applications. It's hard to imagine a thinner client than one you'd find in a mobile device. A great example is an application that we unfortunately can't show you today, but there's a developer that developed something that he calls MathME, and that's a thin client interface to Mathematica running over a network. So you have Mathematica running on your XServe, and then you have your handheld, and then you enter your equations or what have you, and you send it over the network, and you get back a nicely rendered graph.

This developer likes to call it the world's most powerful graphing calculator in your hand. These are great examples of using the network to your advantage in mobile application development. But let's talk about the third thing. This is really what's defining the industry today. And that's the entertaining aspect of it. People have their phones everywhere, right? So people have downtime. They're waiting in line at the grocery store or they are waiting for a doctor's appointment. And they just want to turn their phone on and find something to do. This has given rise to an amazing market for entertainment software on the handheld device. We first saw it with games like Snake, and I'm sure on your iPods you've played some of those games on your iPods.

Same idea. But now we've seen games like Bejeweled, Jamdat Bowling, and these are really, you know, it's a big money market. Jamdat Mobile is a huge company. They went public. They spent $127 million to buy the rights for mobile Tetris. It's a lot of money and they think it's an important thing. So it's a big market, this casual gaming, things you can pick up and put down.

But that's not what people have people -- that is not what has people excited about mobile entertainment. What has them excited is the size of the market and the growth and the capabilities of the platform. Three years ago we had Snake running on black and white screens. A year and a half ago we had things like Jammed App Bowling, Bejeweled. And now today you're seeing platform shooters like Tom Clancy's Splinter Cell. And now the devices that they're selling today and going into the next year have built-in 3D acceleration. So you're seeing Moore's Law with a vengeance here. And you're getting hardware accelerated 3D applications running completely on your handheld device. So it's an exciting market, and let me show you a little demonstration of that. Take a look at this graph.

This graph is half backward looking and half forward looking. And we're right in the middle, in year 2005. If you look at the blue line there, that's the line that may be familiar to most of you in this room. That's the market for desktop games. We're talking Mac, Windows, and even Linux. And those are billions of dollars. Those are revenues in the market. Look at the red line.

That's mobile entertainment. And it's not just all mobile entertainment. It's just ringtones. These aren't even real songs. They're portions of songs that people are buying for their mobile phones to personalize them. It's dwarfing the size of the entire desktop application industry. This is why you ought to be interested in this, because look at the green line.

That's mobile applications, specifically mobile games. You can see that it's growing. In the next two years, it's projected by more than one research firm to outpace both desktop applications and mobile ringtones as being the dominant factor, the dominant way people purchase entertainment software. And so that's an exciting place to be and we want to help you guys get into that market. So I talked about these kinds of applications. Let me show you a few, if we can switch to demo one, please.

I'm going to demo some of these things using our storefront technology software, which lets you see these things on the desktop, which is a great way for us to show these games to you today. And I guess, you know, I talked about web services apps and personal apps. Let me show you an example of this. And it just so happens to be an application I wrote a few years ago called "Perrona Price Check" because it neatly demonstrates both of those things. If you have a phone, actually, you can... you can actually download it from OTA.empowers.net. It's a free application.

Here it is. And it's a web service that uses Amazon's web service to let you easily browse information. And you can see that it plays like a phone user interface. You can go through and browse categories. A lot of phones prompt the user when they have a network connection. We'll just say "always" so we don't get prompted every time. And there you go. We're getting live information because the network is cooperating with us. And it's there. And these are the features of... Corona price check. This is what you can do with mid-P. This is actually a mid-P 1.0 application. And you get access to user interface with images, text.

Our implementation actually is on top of desktop UI, so we actually support things like drag and drop, but you never know. The nice thing is that you're abstracted from that. You just have to write to the form API and you get these things for free. So that's one application.

Let me show you another one. And I talked about casual games. Well, this is what I'm talking about. This application actually is written using the... If the network cooperates. We're loading these things live over the network, much like a phone would do over the air. This is a simple casual game. It's like a... It's a clone of a popular game. I can't remember which one.

But, you know, for devices that support pointing devices, like styluses, like the Sony Ericsson P800, P900. You can click on these guys. If you don't do that, Mid-P lets you have access to the keyboard as well. So you can actually go through and select these guys. This is the kind of game that somebody picks up and puts down, it's a casual game. That's, these things are selling like gangbusters. All right, so let's look at something else here.

This application, assuming it comes across the network, going very slow. I was working fine about 20 minutes ago, but maybe, you never know. This is actually from a company called Gameloft. They're split off of Ubisoft, which is a huge entertainment company that EA is trying to acquire. This is their mobile division. And this is actually-- This is actually like Sims for your mobile and this is actually very popular with a lot of people. I mentioned in an earlier slide something about the demographics. You know, currently in the mobile industry--wow, that's really trippy.

currently in the entertainment industry, you get a lot of console gamers, hardcore gamers. Well, the nice thing about the mobile space is that everyone has a phone, and if they don't, they will. So your demographics are pretty much like 50-50, male, female, young, old. It mirrors the population, generally speaking. And so you're going to get more games that are appealing to lots of different kinds of people. So this is actually like a Sims kind of clone that is actually pretty addicting, at least with our company. And you go around and you have adventures, like The Sims, and it's cool, and it's completely possible on the mobile platform. Let me show you another one.

We showed this one yesterday. So you'll see that we get the... As we're loading, we already fetched the metadata. I'll get back to that in a second. That's something about the JAD and JAR file. Remember I said this, because you'll see that things are loading. We see the name of the application, and we know the size before we downloaded it. But this is another game from Gameloft. Currently in the industry, there's a lot of... A lot of these titles are kind of migrating from the console world. This is a prime example.

I think some of you may have played Tom Clancy's Splinter Cell. It's a stealth kind of game where you sneak around and conduct missions. But this is the mobile version. And the sound is great too, right? I mean, this is just MIDI, you know? So it's good stuff.

We showed this Tuesday at the Java session, the Java kickoff session. But these are platform games. And these platform games are actually getting pretty good. And they're not afraid to show them off anymore, because the games in the mobile space don't suck anymore. And this is what gives you a lot of hope and promise for those projections I was showing you earlier. So let's wrap that up. OK, let's go back to the slides, please.

So I talked about the mobile industry, right? So the mobile space and why it's important. Let's talk about how you'd get involved in that. So Sun is pretty much actually playing a very dominant role with Java in the mobile space, where most of these games are written in Java. And it's through technologies that fall under the umbrella of the J2ME, Micro Java Framework. You're familiar with J2EE. That's the server side stuff, web services, faceless applications. J2SE is like applets, applications, and Web Start apps.

J2ME actually runs the gamut of a large array of devices. We're talking all the way from set-top media center boxes to kitchen appliances to PDAs, mobile phones, and all the way down to pagers and fax machines, things that have one line of text, very simple UIs. These are embedded systems, and J2ME is designed to address that space. Now this is kind of a complicated diagram, but I just want to draw your attention to one slice of it going down, okay? So draw a line from mobile phones going down through mid-P and CLDC. That's the technology stack we're talking about here, okay? The J2ME world is kind of split up into profiles and configurations, okay? The configurations are across the bottom. Mobile phones fall into a category called connected limited device configuration. These are kind of a subset of the capabilities of the higher end applications. And built on this kind of core foundation layer is the mobile information device profile, which has API specific to mobile phones, things like working with keypads and mobile phone screens, that kind of thing. That's the technology stack that's really-- all these games that you just saw is built on top of. So let's go into that into a little more detail. So we're drilling down.

Okay, here's the technology stack we'll be working with. A mobile Java application written to the mid-P APIs, the mobile information device profile, is affectionately referred to as a midlet, and the functionality of whatever application you're going to dream up. Starting from the bottom, that CLDC layer, that's your core layer that consists of APIs that are kind of faceless, things like accessing a network or working with collections or arrays, core language features. Mid-P on top of that gives you APIs that are specific to mobile devices, and it's built on top of CLDC. But on top of Mid-P, there are extra APIs, too, that are optional, so not all devices will have them. Things like for phones that have cameras, you might find special APIs for accessing that camera. Or for phones with Bluetooth, you might have APIs that access Bluetooth. So those are the kinds of, that's where things are categorized.

I'm simplifying a good bit, but that gives you a way of thinking about how to approach J2ME and specifically mid-P development. So I'm going to go into more detail now that you have the overview into each of these layers and explain to you specifically what you can do with these capabilities so you have an idea of what's possible and what's not.

So at the very bottom, the virtual machine layer. Okay, so you're familiar with Java virtual machines, but in the embedded space, many engineers labored to produce a Java virtual machine that runs in an embedded device. This is maybe four or five years ago now. They were laboring to get this stuff working in a very limited specification. We're talking 32 kilobytes of heap, aka persistent storage. But they ultimately did succeed. And the nice thing is that, as I said, Moore's Law is at work. And in the last year, if you look at the devices that were sold, it was hard to walk out of a phone store with anything less than a device that had hundreds of kilobytes of heap, megabytes of persistent storage, hundreds of pixels on a side, thousands of colors.

Those are very capable devices, and you can actually do interesting things with them. But even more interesting is looking forward. And that's, you know, 2005 and beyond. We're seeing quarter BGA, megabytes of heap. We're seeing 2D and 3D hardware acceleration. So it's a compelling platform for application development. I'm not sure. So how do you get at these capabilities? Well, you work with the Java APIs.

and we'll talk first about the core layer, which is CLDC. This is basically a subset of the things you find on J2SE's core libraries. You have the Java lang, Java IO, Java util packages, but in each package, each package contains a subset of the classes that you'd find on J2SE, and each of those classes has a subset of the methods you'd find on those classes on J2SE. It's a clean subset. So if you write logic or code that uses just those APIs and CLDC, it is Upworth compatible. This is the magic trick that allows these mobile Java apps to actually run on our emulation stack.

So you're probably interested in what's missing, what can't you do, 'cause that's easier to think about. So let's talk about that. First off, reflection is missing. Serialization is missing. There's no file system, so you don't get file IO. There's no collections classes, no lists, sets, or maps. You have what you always had in Java 1.1. You have vector and hash table, and that's enough. Also, you don't have floating point.

and you don't have weak references. However, those two were added to this CLDC specification in the 1.1 Rev. However, because MIDP doesn't require CLDC 1.1, not all devices require-- not all devices implement CLDC 1.1. So if you want to use those features or you need to use those features, keep in mind that you're going to be addressing a different segment of the market.

So that's the core foundation layer. Let's go up a step and actually look at the device specific, mobile phone specific APIs. That's the mid P layer, the mobile information device profile. So, MidP 1.0 is where almost all of these applications are written to, and there are a quarter billion handsets supporting MidP 1.0 in use today, active use.

People have these in their pockets and purses all over the world. What kinds of capabilities does the MidP specification give you in terms of APIs? At the low level, fundamentally, you get access to the screen. You have a canvas and you have a graphics object and you can write to the screen. For user input, you have access to the keys, the number pad, the D pad, enter or fire key, and then you have access to optional pointing, a pointer API, like a mouse style API, pointer down, pointer up, if the device supports a stylus. So with that, the world is your oyster. You can do just about anything. And most of these games you just saw were written just with those low-level APIs. weight, there's more.

On the high level, a little higher up, there's a form API. That Piranha price check application, you probably saw those were using native widgets. That's the form API. You have access. It's very high level, very simple to use, and that's how you can generate data entry applications. You get things like text fields, check boxes, lists, those kinds of things.

What's useful about that is that when you write using those APIs, it looks like it belongs on the phone. It's not a custom UI. It takes on the user interface of the phone. What else is there? Networking. Mid-P defines something called the General Connection Framework, Generic Connection Framework, GCF. And that's a real simple API. It's in one line of code. You can pass in a string URL and get back an input stream, and you're off to the races. So it couldn't be easier. The actual protocols that are supported vary from device to device, but you're guaranteed to have at least HTTP.

Persistence. That's an important part of writing an application. And what you get is access to a data store style API where you can put and get arbitrary byte arrays. So you can persist your data in that fashion. It's a very simple API. The amount of data you can store varies from device to device.

But there's a minimum-- you get at least 8K of storage. And that is enough for a lot of different things. In most cases, you get a lot more than that. Images. Built-in support is specified for PNG format. Some devices support JPEG, but GIF is right out. PNG is pretty good, and that's good enough for now.

But the audio support, unfortunately, is non-existent. There's no audio API in MidP, and this is kind of the rub, right? So you can tell by this fact alone that when they developed the mid-P APIs, they weren't thinking about games because it seems like an odd omission. Because of this, this caused some fracturing in the market because every device manufacturer, they all supported sound. They had to come up with their own APIs for accessing that sound. So you have Nokia APIs for sound, Motorola APIs for sound, Sprint PCS APIs for sound. So for that reason, people like Gameloft have to develop, when Prince of Persia: Warrior Within was released, they had to actually develop 155 different versions of that to support all of these different handsets and their own particular sound capabilities. So clearly, something had to be done.

Actually, mid-P2 was released a good while ago, and it's pretty common on the devices that are being sold today. But by 2007, projections indicate that there will be a billion mid-P2 handsets out there in the world. So it's worth thinking about targeting the mid-P2 APIs. What does mid-P2 add in addition to what was in mid-P1? Well, let's go through those categories again. Most interestingly, it's like they learned their lesson. On the low level API, you now have a built in Java ratified standardized games API. In the mid P1 world, people had to sweat blood and tears to get things to be performant on lots of different devices using just the low level APIs that were provided in mid P1. With mid P2, you get sprites, layers, blitting, direct access to image arrays, all the things the game developers wanted. So if you write to those APIs, you can rest reasonably assured that the device manufacturers have taken the time to optimize those calls. So it's a great way to actually save yourself a lot of effort and time in writing these entertainment applications.

Moving back a bit to the high-level APIs, in addition to the capabilities I described earlier, you now have the ability to write custom form widgets that give you access to the native themes and the native fonts. You can actually make customized forms that look like the native operating system. On networking, I mentioned the generic connection framework. Well, apparently it was too generic, so now they've added interfaces that you can cast your connection objects to, to get access to fine-tune the features of your connections.

Things like for HTTPS, if you have an HTTPS connection, you can cast it and then get access to the certificate and things like that. On persistence, you have access to record stores that are shared across applications, which enables you as developers to write suites of applications that interact with a common calendar or address book. And for audio, there is now audio support. And it's very simple. You can in one line of code load and play a sound. Couldn't be simpler. In fact, the specified sound behavior in MIDP2 is a subset of a larger API that's optional. We'll talk about the optional APIs right now. So that's MIDP2. On top of MIDP2, you have optional packages, one of which I just talked about is the mobile media API. a lot of these devices support media, and media is an increasingly important part of the mobile experience. There are now APIs to access it. And if you're familiar with the Java Media Framework, the mobile media API works very similarly. It's the same architecture, just slimmed down, simplified, and in my mind, improved over JMF. What can you do? You can do audio playback, audio capture, image capture if there's a camera, and video playback, as well as streaming video playback. All very interesting capabilities.

It's an optional API, but a lot of devices support it. But just keep in mind what your target audience is and what the devices are before you start using this API. And you can test for these APIs at runtime. So you can kind of keep your code base simplified. Another more specific API that isn't quite in wide distribution is the scalable 2D graphics API. This is sponsored by Nokia and adopted by Nokia and Sony Ericsson. Think of this not like Java 2D, but it's more like Flash because it has support for SVG style animations.

So you can actually interact, play back and interact with these things in code and give the user an environment where they can view SVG animations. But what's also interesting is that you can take an SVG object and render it to your low level graphics, your canvas. So that's a great way of getting images to your canvas because as you all probably know, vector graphics are much smaller than their raster counterparts and they're scalable.

So you don't have to worry about whether your graphics are the right size for the screen because in the mobile world, every device has a different screen size. So those are useful capabilities. But it's optional. Perhaps the most exciting API is the mobile 3D API because this is what's kind of fueling a lot of the current game development. Mobile 3D graphics is supported on an increasing number of handsets and it's a scene graph API, light Java 3D but again simplified and if you like simple, if you think simple is better, it's better.

It's suitable for games and it gives you access to writing 3D applications in a very simple manner. These APIs are supported by the newer handsets from Nokia, Sony Ericsson, Motorola and others. I actually want to show you support that we are actually building right now, if we can switch to demo one please, for mobile 3D graphics because we see this as a big deal. It's preliminary support and actually it's more like a proof of concept at this point, but we're rolling it out by the end of the year.

There you go. So what you get is textures. It has its own scene graph serialization format. And there's support for animation tracks, cameras, lights. It's not much of a demo, but it works and it rotates. But it's running. And this is an application written for mobile 3D. And it just works on our player. So going forward, you'll be able to write these applications with our software.

If we could switch back to the slides. Okay, so where have we been? We talked about the mobile market. We talked about the J2ME environment. So let's talk about what a midlet is and how you write one, what it feels like. So, let's see. What is a midlet? Okay, hands-on. So a midlet is basically a jar file, right?

It contains all of the classes, the resources, the images, the sounds, whatever you need. It's all in one jar file. Every class in the midlet needs to be pre-verified. I'll get to that in a minute. And then one of those classes in the jar is a subclass of JavaX micro edition midlet dot midlet.

Okay. That's your entry point, okay? That's what makes a midlet. Midlets are typically in this day and age hundreds of kilobytes in size, although some devices like the Nokia series 40 devices have an artificial limit of say 64 kilobytes. So smaller is better, but know which devices you're targeting. A midlet jar is almost never seen without its counterpart, which is the JAD file. JAD in this case stands for Java Application Descriptor. It's a properties file, it's a text file, like a manifest almost. It contains metadata for the application. It contains things like the name of the application, importantly the entry point, which of those classes in the archive is the main midlet class. It contains important things for the device, like the size of the jar. It's like a preview. In fact, phones use it as such. As you saw in the demo earlier, our player was actually accessing the JAD file first to get the preview information so it could show something to you while it was loading the jar. And in fact, it knew how big the jar was so it can give you a progress indicator. That's important on the phone devices, too, because the phones will want to get just the JAD file and then show you how big it is so you can determine whether you have space for it or whether you even want it before you click OK, and then it will bring down the JAR file. So it's important to have two. Those two files make up the midlet. So if you are a midlet, what's your life like? Well, it's real simple.

If a user launches your application, the first thing that happens is that your mid-lit main class is instantiated. At some point thereafter, you get a call to start app. At that point, you have control of the screen and the input and you can do what you will. At that point, two things can happen.

The first of which, the user can put you in the background. This happens if they have multitasking on their device or if they receive access and resources as possible so you can go into hibernation. You're still running but you should be hibernating until the point when the user brings you back.

You'll get notified because start app is called again and then again you're at the forefront. When you're active or when you're paused, the user can do that second thing which is kill your app. In either of those cases, be ready for a destroy app call. At that point, you should clean up and dispose all resources and then exit. That's the whole midlife cycle. Very simple. Very easy. Amen. So can we build it? Yes, we can. Let's talk a little bit about how to actually build these things.

So you'll build it just like you do any other project, and you'll have a series of class files. After that point-- you'll need to pre-verify those class files. What is pre-verification? In the KVM world, there's not enough resource space to include a full bytecode verifier. So there's some pre-processing done to your class files to make them easier to digest by KVM's bytecode checker. So that's what this step is. Pre-verify is actually a C program that it's available. We ported it to Mac OS X, and it's available as part of our software developer kit. And it just annotates your class files. And it's a simple process and transparent. And once that's done, once you pre-verify, then that's required, 'cause if you don't pre-verify, the app won't run on the phone, period.

The next step is optional, but it's recommended. Obfuscation. A lot of people use obfuscation to kind of hide their intellectual property, make it hard to reverse engineer their stuff. But in the mobile space, obfuscation has an unintended and useful side effect in that when you obfuscate something, typically all the class names turn into letters, like A, B, one character, method names and class names. Well, it turns out the longer your method name or class name, that stuff takes up space. So when you obfuscate something, it shrinks the size of the jar down significantly. And that's useful for getting under that 64K limit on a Nokia Series 40 device. So that's a useful step. There are free and payware applications that do obfuscation. I use ProGuard myself, but there are any number of ones. You probably are using one already, so it's just standard. Any obfuscator will work for J2ME.

So after you do those two steps, then you need to update your JAD file. I mentioned before the JAD file has to have the length of the jar file in there. Well, after obfuscation, your jar size is going to change. And so you need to update your JAD file to stay in sync with that. So after you're done with that, you're ready to run.

And you can run with our software, Empower Player. What it is, as I mentioned before, is a implementation of mid-P2.0, including mobile media API, mobile 2D graphics, mobile 3D graphics, Bluetooth support, on top of J2SE. So it just runs. It's an application. Let me tell you what it's not. It is not Sun's wireless toolkit. Sun's wireless toolkit has a number of interesting capabilities, like packet sniffing, memory profiling, speed throttling. And we don't do any of that stuff. And we're not an IDE either. We don't compile your code. We don't require you to edit your code in our player. We just do one thing and we'd like to think we do it well. So we integrate with your existing tool chain.

And that's what we like to do. It's a free download. We make it available because we want you guys to use it. To the extent that your applications are compatible with our emulator, it only helps us. We think we help you. So it's a nice relationship. I'm also pleased to announce that a number of development environments have people been integrating our support into, like things like Eclipse, IntelliJ IDEA. But the Sun's NetBeans team has actually integrated EmpowerPlayer with NetBeans. And so now we've agreed that they can distribute EmpowerPlayer with their mobility pack for Macintosh so that there will be a NetBeans mobility pack for Macintosh, which heretofore has not existed. So that's a good thing for the Mac platform. But that's what we are. And I think from this point on, Ted will take over, and we'll show you how it's done.

So we're going to get down to the nuts and bolts. But actually, let's go back to the slides real quick. And so some of the things we're going to talk about, so we're going to talk about building and debugging with Xcode, but like I said in the beginning, previous session on Java, you can use whatever tools that you like, but for this session, we're gonna show with Xcode.

To do it in Xcode, you have to set up a custom executable that will launch the emulator, pass in the JAD or JAR file and stuff. There's actually a template that's provided in Michael's SDK written by another gentleman out there that I'll have to introduce at some point. You debug it like normal with the Java debugger. You don't have to use any special debugger. You can actually debug it within the emulator using the Java debugger with an Xcode. You know, just set your breakpoints just like normal.

Conversely, it also works with Shark. It's a little bit harder to profile in Shark than with a normal Java application because in addition to your midlet, you also have the emulator and then our entire JDK running. But it is possible with Shark. What you can do is use the data mining features and exclude the Java AWT, the Java X swing classes, et cetera, et cetera, until you get down to the mid-P APIs and your APIs. You'll see a couple of unknown classes in there and stuff like that, and really what that's saying is, I tried to exclude these, but they've actually been called. Now when you're profiling in the emulator, This is not a MIP device itself. So there are realities that Michael talked about. It doesn't... Some things may be faster on the emulator or actually may be slower on the emulator. But if you run into a performance issue on your phones, running it through the emulator has a good chance of helping you figure out exactly what it is. And then additionally, let me point out the last point, is that packages really help. In the beginning of the mid-P development, people actually got rid of packages, again, because that extra namespace actually took up space in your jar and stuff. Now it's not such a big deal, but if you have a midlet that doesn't have any packages, it's a little harder to target them in Shark. So go ahead, add some packages, do your profiling, and then if you want to get rid of them, pull them out.

Deploying to the device, there's two ways. There's the Bluetooth, which is what I use for doing my development. And then there's also the HTTP, which is commonly referred to as over the air. It's closer to the real world. With the Bluetooth, all you have to do is you push over the jar, it, You don't need to update your JAD file for it, and actually, in a lot of cases, you can't take advantage of the JAD features when you're doing it with the Bluetooth deployment. But for most debugging and testing and stuff like that, that is very useful.

On Mac OS X, there's a way that you can just send a file to a Bluetooth device, and actually most mid-P phones will actually go, oh, wait a minute, this is a jar file. Let's see if we can install it and run it, and you're up and running. It's actually very simple. With HTTP, your phone is behind a firewall, and it needs to use DNS to get to your server. So you need some sort of static IP address or at least a DNS server. addressable address. And up on Sun's website, it actually details what you need to change to make it work with Apache, which of course is a first class citizen in Mac OS X.

So configuring Apache, it's actually very simple. On Mac OS X, and actually this is documented on Sun's website except for the Mac OS X part, which is just where the MIME types file is. You have to add two MIME types to the file, and you don't have to worry about writing these down. You go to Sun's website, it tells you exactly what MIME types you need to add to the MIME type file.

But the file on Mac OS X is in the etc.httpd folder. and it's just called mime.types. There's actually a backup of the original in there, which was useful for me when I accidentally deleted half of it. So if you make a change in stuff and for some reason something doesn't work, you can go back and restore it. So we're going to get into kind of our hands-on portion. We're going to build a game that's included in the mid-p SDK. It uses mid-p 2.0, the game API. And then we're gonna run it in the emulator and stuff. Put a couple breakpoints, see that you can actually do that. Shark the midlet and then deploy it via Bluetooth. Now, I'm not actually trying to teach you the mid-p APIs. Michael's actually more the expert on that one. But what we're trying to show you is how to do your development on Mac OS X. So with that, let's go over to our demo two.

And so there's one thing that you have to do before you actually can do this. Let's go to the terminal. And because of the way the SDK is distributed, you're actually going to have to chmod the pre-verified tool. So if you follow the instructions and you install it where it said it should, say to install it in developer, Java, MMP SDK. And so let's just go into the OSX, pre-verify. And so it would just be a chmod +x, and then just drag over.

And that sets it up so that you can actually execute it from your AMP build scripts and stuff like that. So, we're in the SDK, developer, Java, MMP SDK. Let's go back into the OS X folder, and the Xcode, there's a couple samples in there. Let's open up the Microtank one.

So let's just open it up and with Xcode, give it a second. This is a pretty simple sample, but it shows game APIs and such. If you look at, let's see, microtank.java, you'll see the APIs that Mike talked about, the start app, pause app, destroy app, and command connection. The command connection is where you get like keyboard pointer events and stuff like that. Let's just go ahead and actually do a build. This is an Ant build process. The nice thing about that is that Ant actually integrates pretty well with Mac OS X. And then we're using a custom executable to launch it.

in the emulator. Now this is just a sample demonstration program, but it gives you an idea of how easy it is to just build it and run it in the emulator. Let me go in and add a couple packages to this. And so for this one, Cool. Let's just add package micro tank.

It doesn't have to be very deep, just something. Let me add that to the next one real quick. Copy and paste is my friend. And the last one. So this puts them all in the same directory. I'm gonna do a clean build real quick just to make sure everything gets cleaned up. And then let's go ahead and do another build. Now, there's one thing that actually I need to update. Since I moved it into the micro tank package, we also have to go in and update the manifest.

This top line, it gives the name of the midlet. This is in the manifest. The icon for the midlet, so like when you look on your phone for the game, that's what the icon is that it would be displayed. And then the actual main midlet class. And then you can see that some of this is actually repeated down here, and then what platforms you actually target. Um, in theory, I should be doing the same thing with... with the, I'm losing myself there, with the JAD file, What you can do is just go ahead and open it up in, all right, let's just launch TextEdit.

Let's open up that JAD file. Now this JAD file is the same kind of thing, it's just a text file. So now I can go ahead and run the same game, and it should, within theory, If I made all the correct changes, all right, we got the same thing. So all we've done is put it in a package. What we need to do now to shark it is just standard Java stuff.

I should have cleaned that up before the demo. So, all you have to do is just add the X run shark. And this is just standard for all Java applications. This is just a VM parameter. It causes the JNI library shark to be loaded up and it's just a VM. and execute before the JVM really gets started. So now if I'm to go to run it, And you actually kind of saw this before. Shark for Java is enabled. So let me go into our developer applications.

performance tools, and let's go ahead and run Shark. Now, one of the things I figured out is that The way that Michael wrote this, it actually runs pretty well in the emulator. So I'm gonna have to go in and actually dumb it down a little bit. Let me just go into this Micro Take canvas, and let's force a GC in the middle of the paint. Um, dun dun dun dun.

in the render. Yeah, there you go. You got your graphics G that we're all familiar with from the Java side. So let's just do a system.gc. So let's go ahead and run it. I'm going to use a Java time trace. Shark actually goes, "Hey, you know, we got a Java process out there that's all set to be sharked." Can drive it around a little bit, use the option escape to start shark sampling. And you'll notice that the frame rates that we're getting on the bottom are a little bit less than what we originally had. And so, see, I can't drive through walls either. So let's go ahead and look at that data real quick.

So like I said, you get all these things called Java AWT and stuff like that. Let's charge Java AWT to the callers. That should get rid of a lot of stuff. Java AWT event, same thing. Java X swing. And then, let's see, Apple AWT. So I'm getting rid of all the stuff that isn't really mid-P specific. So what we're essentially doing is pulling out the J2SE stuff that's running in the background.

So unfortunately, at this point in time, that is not-- It's not saveable, but I've been talking to the Shark people and they think that would be a great feature. And then I can also charge that to the callers, and there's one more in there. - Can we have the blog there? - Oh, okay. I think I can do that in Shark.

Beauty in Macaustown. Is that a little better? Cool, thank you. So we're getting rid of all the stuff in here. And so, okay, so now we got the adapter. Let me see if I get rid of that. I should have... With any luck, I didn't get rid of my actual classes. So, where are we here? So we got SunReflect. We got our microtank classes in here. We're taking 84% in this render, or 34% in this render. And a lot of that is the system GC pulling up. There's still some stuff that we need to do to make Shark an ideal candidate for mid-P emulation, or profiling. But as you can see, there is some stuff that you can get out of it. And if you're seeing a performance issue, go ahead and run it through Shark, profile it, try and figure out if Shark can actually help you with it. And it might quite possibly point out exactly where the issue is, and then if you dig deeper into it, you could actually solve your issue. Um... So, let me see. Let's look at a couple of other SD things.

If you all downloaded the Sun Wireless Toolkit and installed the... the emulator, or the Xcode project that was referenced in our documentation for this site. In this apps directory, the wireless toolkit apps directory, there's a bunch of different demos and stuff like that. This UI demo is one we're actually gonna show. And as you can see, it doesn't really have, there's no Xcode project or anything like that. So let's go ahead and launch Xcode.

My recent item, well actually, I'm supposed to be showing you guys, so developer applications Xcode. And I've installed the template that actually comes with the SDK. So let's go to New Project. And it shows up here as this AMP-based midlet jar. Let's go ahead and the one that I'm gonna actually do is the UIDemo. I'm actually picking the same name as the sample itself because if you look in this bin directory, their JAD, their classes, all that are based on that same name. So let me just go ahead and make sure that I spell everything right.

UI demo. So this creates a project. It's essentially a Hello World project, but with the name that we want. Let's go ahead and open that up and go ahead and quit Xcode at this point. And just drag all this stuff into there. And let's replace all. So the Xcode template has the manifest and the JAD file atop folder. And so let's go ahead and actually bring these Let's see, dun dun dun, let me do it from this folder. Let's bring over their JAD file. but replace that one and the manifest from there. So we got two manifests. Let me just go ahead and copy the name of this one real quick.

copy, let's go ahead and get rid of the old one, and use the one that was included with some sample. So now we've essentially brought the sample into the Xcode project. Cool thing about this is because it's an AMP build, we don't have to add all those source files to it. They automatically just show up right here in Xcode. We have these folders that are just basically whatever's in these folders, automatically add them to Xcode and just track it as a folder itself. So in theory, I should be able to just go ahead and build and run. So right now it's doing the ant build script and it launched the emulator and brought it up. So let's go ahead and... I don't know, I'm gonna pick any one of these. These are just UI demos, so in all honesty, they're not 100% exciting, but they do show the features, and it also, in the process, what I've done is I've shown you how easy it is to take some samples, and pretty much any sample out there, or application on the web, and bring it into Xcode and the emulator, and actually start being able to run debug and stuff like that. So if I was to go ahead and, say, put a, a breakpoint right here. Let's go ahead and build in bug.

We should actually, and I think I have to bring up the alert demo portion of that, is let's go in and... Let's see, start app. Well, apparently I missed something in there. But it does work for debugging in the midlet. So the next thing we actually want to do is let's go ahead and take that JAD file that we built previously. And that's in the developer.jad.

application or Java and mid-PSDK. This is the OS 10 one and this is the microtank game. And the end results are put in the distribution directory. That's what the ANT template does. So it puts your pre-verified jar and a copy of the JAD file. It doesn't update the JAD file. You have to manually do that. In theory, you would do that after you do your obfuscation because that would make it smaller. But if we go ahead, let's take this jar file.

I'll go ahead and open up my phone. I've actually already paired my phone with the system. This is actually another sample, just a Java sample, that allows us to use the QuickTime sequence grabber from within a Java application. And if I don't make you guys too sick-- I probably should have slowed down on the coffee this morning. Let me send a file. And what I'm going to do is send this jar file directly over to the phone.

I'm gonna get rid of a couple of windows so you can see actually what's going on. Borrowed this phone from Colin. So, There you go. I love the autofocus on the eyesight. Receive this message. And so essentially it's saying that something's coming in over Bluetooth from this device, Excellent. That's the name I have for this computer. And I just said, yes, go ahead. And it should be-- yep, it got the message. I'm going to show it. It's installing the application for me. Now you notice I pushed over the jar, not the JAD file. Install Microtank, yep. Okay. Continue. Yeah, I haven't signed it or anything. It's not trusted. And in this case, I'll put this on the memory card of this phone.

So it's copying over the jar right now, it's doing its minimal security checks to make sure that I actually did I actually did pre-verify it and stuff. And so it's actually been installed. So let me go back to the main... directory of this phone and if i scroll down i'll actually see that let's see can you see that that micro tank application if i go ahead and run it here and i just clicked on it it'll actually run now one thing let me go ahead and bring it up in xcode um Next code. Michael actually pointed this out to me.

Recent projects, micro tank. I'm gonna run it in the emulator. So each device, like you said, has its own screen size. And, but each device tries to adapt them. Look there, that millisecond frame rate and stuff, is it's a little bit different place than it is on the emulator. And that's because each phone, you know, it's trying to adjust the size and move things around for you.

So even though you do your own layout, just like with layout managers in pure Java, things may get moved around slightly from what you expect. So that's pretty much it. We had hoped to actually show you some over-the-air deployment. But it turns out, in these inner rooms, cell phones don't actually have much access, as I'm sure you've all discovered. So at this point, that's essentially what we have to show you. Do you guys have any questions? Of course, there's a normal sample code and resource directory that you guys have been seeing all over this thing. I thought I had some reference slides. Looks like that's it. Thank you.