Thank you for coming. My name is Ted Jucevic, and I'm one of the DTS engineers at Apple that does Java support. So today we're going to talk about J2ME, Java 2 Micro Edition. And to get things started, I'm actually going to introduce the gentleman here who, he ported the MIDP 1.0 emulator over to Mac OS X. And we demoed that lightly last year when we were showing cross-compiling with Ant. And then he's brought an SDK for MIDP 2.0 to the platform also. Let me introduce Mike Powers from MPower Player Incorporated. And here he is, Mike Powers. Thanks.

Hi, I'm Michael Powers. I'm a Chief Technology Officer of Empower Player, Inc. 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 MIDP2 emulator that runs on the Mac, and you can use this today to build MIDP applications on your Macintosh. So what are we going to talk about? Mobile development using Xcode and 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, MIDP, what that's all about.

And then the third thing is, you know, what is the best way to build mobile applications? 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.

This graph is half backward-looking and half forward-looking. 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. Those are billions of dollars. Those are revenues in the market. Look at the red line.

That's mobile entertainment. 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 billion people. We're going to be the number one research firm to outpace both desktop applications and mobile ringtones as being the dominant factor, the dominant way people purchase entertainment software. That's an exciting place to be. 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 Michael Powers, 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 Piranha Price Check because it neatly demonstrates both of those things. If you have a phone, actually, you can--you 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 Toronto Price Check. This is what you can do with MIDP. This is actually a MIDP 1.0 application. 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. That's one application.

Let me show you another one. I talked about casual games. 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 a clone of a popular game. I can't remember which one. 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. 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. These things are selling like gangbusters. All right. 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 know, 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.

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. Okay. or 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. You're 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 kickoff session.

These are platform games. These platform games are actually getting pretty good. They're not afraid to show them off anymore because the games in the mobile space don't suck anymore. This is what gives you a lot of hope and promise for those projections I was showing you earlier. Let's wrap that up. 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, you know, actually playing a very dominant role in the -- 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. Okay, 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, you know, array of devices. We're talking all the way from like set-top media center boxes to kitchen appliances to PDAs, mobile phones, and all the way down to, you know, pagers and fax machines, things that have one line of text, you know, very simple, you know, UIs. Okay, 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

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 VGA, megabytes of heap. We're seeing 2D and 3D hardware acceleration. So it's a compelling platform for application development.

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 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? 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 I/O. 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.

You And you don't have weak references. However, those two were added to the 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 MIDP layer, 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.

But wait, 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. Okay? You have access. It's very high level, very simple to use, and that's how you can generate data entry applications. And 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. MIDP 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.

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 nonexistent. 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 MIDP 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.

MIDP 2.0. Actually, MIDP 2.0 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 MIDP 2.0 handsets out there in the world. So it's worth thinking about targeting the MIDP 2.0 APIs. What does MIDP 2.0 add in addition to what was in MIDP 1.0? 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 MIDP 1.0 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. With MIDP 2.0, you get sprites, layers, blitting, direct access to image arrays, all the things that 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. It couldn't be simpler. And in fact, the specified sound behavior in MIDP2 is a subset of a larger API that's optional. And 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. And since a lot of these devices support media, and media is an increasingly important part of the mobile experience, you can use it to create a mobile experience. You can use it to create a mobile experience. You can use it to create a mobile experience. 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 actually adopted by Nokia and Sony Ericsson. Think about it. It's not like Java 2D, but it's more like Flash because it has support for SVG-style animations. So you can actually interact, playback 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 a lot more complex than a simple, simple, simple, simple their 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. I'm going to 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. 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. We'll get to that in a minute. And then one of those classes in the jar is a subclass of JavaX Micro Edition midlet.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. And 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 jar file, and it was actually using the jar file. 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 jar file, and it was actually accessing the jar file. I'm sorry, 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 okay, 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 midlet 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. 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. 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. Then exit. That's the whole midlet lifecycle. Very simple. Very easy. 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, like, letters, like A, B, one character, like, you know, 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, like, 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 an implementation of MIDP 2.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 toolchain.

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 they are, 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. Some of the things we're going to talk about. We're going to talk about building and debugging with Xcode, but like I said in In the previous session on Java, you can use whatever tools that you like, but for this session we're going to 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 within Xcode. 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, etc., etc., until you get down to the MIDP 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." But now when you're... Profiling in the emulator.

This is not a MIDP device itself. There are realities that Michael talked about. 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 MIDP 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 MIDP 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. 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, and 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 MIDP SDK. It uses MIDP 2.0, the game API. And then we're going to run it in the emulator and stuff. Put a couple breakpoints, see that you can actually do that.

Shark the MIDLIT, and then deploy it via Bluetooth. Now, I'm not actually trying to teach you the MIDP 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. Because of the way the SDK is distributed, you're actually going to have to chmod the pre-verified tool. 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 OS X 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. and Michael Powers, the founder of the J2ME JVM team, will be presenting the demo on the Let me go in and add a couple packages to this. And so for this one,

This 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 going to 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 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. In theory, I should be doing the same thing with

What you can do is just go ahead and open it up and, 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 the rest of the team will be joined by the team members of the J2ME JVM team. 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 going to have to go in and actually dumb it down a little bit. Let me just go into this MicroTake canvas and let's force a GC in the middle of the paint.

Dun dun dun dun.

So let's go ahead and run it. I'm going to use a Java time trace. Shark actually goes, "Hey, you know, we've got a Java process out there that's all set up to be sharked." You 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 like 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 MIDP 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. Oh, okay. I think I can do that in Shark.

Beauty in Mac OS X. Was 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... 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. We're still, there's still some stuff that we need to do to make Shark an ideal candidate for MIDP 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.

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 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 going to show. 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.

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 going to actually do is the UI demo. 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. and Michael Powers, the founder of the J2ME JVM team, will be joining us for the session.

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. The 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

I don't know. I'm going to 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 Let's say 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.

application or Java and Mid-PSDK. This is the OS 10 one and this is the micro tank game. The end results are put in the distribution directory. That's what the ANT template does. 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. Let's take this jar file.

I'll go ahead and launch, 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 going to get rid of a couple of windows so you can see actually what's going on. I 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 and Michael Powers, and then the rest of the team. and Michael Powers, and then developing the latest and most advanced applications for J2ME JVMs. Ted Jucevic, Michael Powers, and then deploying them to embedded J2ME JVMs.

Ted Jucevic, Michael Powers, and then deploying them to embedded J2ME JVMs. Xcode. Michael actually pointed this out to me. "Recent projects, micro tank. I'm going to run it in the emulator. So each device, like you said, has its own screen size. But each device tries to adapt them. Look there, that millisecond frame rate and stuff. The main reason why I'm talking about the J2ME JVMs is because it's a little bit different place than it is on the emulator. That's because each phone is trying to adjust the size and move things around for you.

So, you know, even though you do your own layout, just like with layout managers in pure Java, you know, 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? There's a normal sample code and resource directory that you guys have been seeing all over this thing. And I thought I had some reference slides. Looks like that's it.