If you send headers to a domain that does not match the domain where the SWF is hosted, you need update your crossdomain.xml file to allow them to continue to work with Flash Player 9.0.124.0. While this is discussed in the ADC pre-announcement, it could use a bit more detail. Flash Player support wrote a great technote on details of how to set up <allow-http-request-headers-from>.

http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403185

One of the examples from the article is:

<?xml version=”1.0″?>
<!DOCTYPE cross-domain-policy SYSTEM “http://www.adobe.com/xml/dtds/cross-domain-policy.dtd”>
<cross-domain-policy>

<!– This domain can accept a MyHeader header from a SWF file on www.example.com –>
<allow-http-request-headers-from domain=”www.example.com” headers=”MyHeader”/>

</cross-domain-policy>

Also, it is worth reiterating that the new header crossdomain syntax is required for both send and sendAndLoad network APIs. For network requests without additional headers, traditional crossdomain syntax and behavior continues.

While in Hong Kong for Macromedia MAX, Greater China, I picked up one of the Nokia N90s. The new line of Nokia’s cost a pretty penny, but are not just another small increment on the 6000 series. There are many, many new elements, that I have not seen previously on a Nokia phone. Some are great, others have left me a bit annoyed (well, more than a bit).I have had six Nokia phones and over the years I have collected more than my fair share of Nokia chargers. This has been one of the things I have liked best about Nokia, consistency. On the flip side consistency has also surfaced as slow product evolution and lack of innovation. With the N90, they have gone in directions like the clam-shell design, hi-res screen, and pivoting everything, but at the same time they have violated some of their key consistent points like a new charger tip, and a different screen size.

Deltas:

The most notable difference on the phone is immediate. It is a clam-shell/flip design. There are certainly other Nokia clam-shells including the Nokia 6260 (remarkably similar), but they are rare enough to be worth mentioning anyways ;).

The camera is 2MP, and is on a pivoting section at the hinge of the clam-shell pointing off to the side of the camera, not pointing out the back like every other camera. The camera uses Zeiss optics, and has some nice new features like aperture speed controls.

There is a second LCD screen that is for info display on the outside. This is fairly common now for clam-shells, but is all part of the new clam-shell model. On the external screen you can get caller info, apply profiles and go into camera mode. You can also set a screensaver and control the brightness for this screen.

There is a second joystick and a new Action Button on the side that are primarily used when the phone is closed or in camera mode. When the phone is not in camera mode, the action button activates voice commands (a good features I’ve missed from other phone brands). In camera mode you use the action key to focus by pressing down halfway and to shoot by fully pressing.

The power connector is new, and a bit smaller. You either have to buy a handful of dongles for all of your old chargers ($7-$10USD each), or new chargers ($20 each). Also, if you use a USB charger, the tip is also not going to fit. While this tip is new, you will pretty much be stuck with the dongle :(. Luckily you do get one dongle in addition to your charger in the box.

The USB port has a cover now. I passionately hate the Nokia USB PC software, so that port is meaningless to me anyways. After a week though, the cover has ridden up a bit and I have found my self re-seating it a couple of times.

Once you open the phone, the changes continue. The main screen is occupies the same real estate as the other series 60 phones, but the screen resolution has been increased by doubling the pixels on each axis (previous 176×208, now 352×416. New applications and vector Flash files look amazing in hi-res, but old icons, and old applications look blurry when pixel doubled. if you have ever run an LCD screen at not optimal resolution, you know what the experience looks like.

The upper portion of the clam-shell can also pivot, much like the camera section. When pivoted, the screen goes into landscape mode, and there are even new soft key that are only usable when in this mode (the regular soft keys are on the bottom portion of the clam and are often inaccessible when in the pivoted mode. This mode is only used for images and video though. pivoting the upper clam-shell will take you into the camera by default unless you are in the gallery application. If you are in on a call, going into this mode will automatically shift the audio from the earpiece to the main speaker.

Under the various covers there have also been some interesting changes. The N90, like the 6680 has a door on the right side for swapping the MMC card (half-size SD Cards. available up to 1GB right now). For the 6680,opening that door immediately disengaged the card and all applications on the phone were shut down. On the N90, you can choose to swap memory cards through the profile manager. Opening and closing that door have no software effect any more.

In the Battery area, the major difference is that the sim card does not sit under the battery any more. It is now inserted at an angle into a slot right next to the battery. I guess theoretically you could now swap sim cards without powering down the device, though I don’t know how recommended that is. The battery seems the same as before, but strangely, I got two batteries with my phone this time.

my opinions of these changes

Good

The hi-res screen is large and beautiful, and really makes the partnership with Macromedia all the more valuable. My Flash content built for the low-res screens overall transitioned beautifully, with only some suffering in the bitmaps.

The camera takes lovely pictures that are much richer than my previous cell phone picts. The auto Flash seems to trigger more intelligently than on my 6680 which almost never fired. I also get some on-phone image manipulation tools like cropping and filters.

When everything is pivoted, the phone feels more like a camcorder. It is pretty slick to experience. You hold the base of the phone sideways almost like a gun handle with the action button now faced towards you. The upper part of the clam can now pivot to let you move the phone anywhere and angle the screen to your comfort. And lastly, you can then vertically pivot the camera to pan up or down.

When open the phone feels enormous (in a good way) but when closed is almost exactly the size of my 6680. I’m a big person, so generally when I hold a cell phone to my ear, the bottom of the phone is still several inches up my cheek from my mouth. With the N90, I have the earpiece at my ear and the microphone is actually an inch directly out in front of my mouth. I have to imagine that this should allow for a microphone that can be less sensitive and not pick up as much sound from the surroundings. I still need to ask people I call as I call from noisier spots.

Bad:

That twisty pivot camera is cool, but it is a major mixed blessing. Both of the pivots swivel very easily–too easily. No matter if the camera is closed and the keys are locked, if the thing pivots, the camera is on and sucking battery power :(. Since I keep my phone in my pocket, it happens all too frequently. It is awkward to constantly pat down my pocket to “close my camera.” *cough*

Anyhoo, the more awkward element is when I am talking on the phone. If the top part of the clam-shell pivots, the phone goes into hands-free mode. I think it is trying to go to a video call, but strangely, pivoting back does not put the audio back to the earpiece though! To switch back to the earpiece you have to press one of the softkeys. However, if you have another call on the line, the switch between the lines softkey is the same key and overrides the switch back to the earpiece.

I discovered this when I called someone, got their voicemail, then had them call back mid-voicemail recording, knocked the earpiece while looking at the caller ID and got the whole thing on the external speaker. By the time I was done, it was only a miracle I hadn’t hung up on my friend and had a bit of a hissy fit ;).

Thinking though of the earpiece, it is actually strangely positioned. I love the fact that the phone when open is huge, but the earpiece is positioned as high up as possible. When I hold the phone naturally to my ear I can’t hear anything. I have to drop the phone about half an inch. This is a whiny gripe I realize, but I do keep answering the phone and hearing nothing until I remember.

Ugly:

The ugly category is for the bugs that are already starting to rear their ugly heads.

I seem to be getting the exact reverse battery issue from my 6680. Now my battery is overly optimistic. Last night my phone registered full battery strength before the beginning of the Harry Potter movie. Like magic two and a half hours later my phone was completely depleted. Not quite ready to believe that my phone was affected by the evil of the deatheaters, I was at a bit of a loss. No warnings, no nothing. When I got home and hooked it up to the charger we were back in business. The phone also reported back in about an hour that it was fully charged. I’m sooo not convinced.

Trying to configure my phone, I discovered that my phone has been prone to crashing and re-starting as I navigate the options of some of the system configuration applications. Not much more to say about it. Just crash :).

Truthfully I think there is more, but man, this is a loooong post and I want to hear your stories

Ok, I am a died in the wool gameCuber, but the fact that you can DIY Flashify your X-Box 360 is very cool. That nagging voice that says “it can run flash, you must buy it” is becoming louder. Also Engadget’s X-Box meets Flash meets the borg logo is also fun.

Microsoft has released a patch to the 360 that among other things closes the ability to run Flash. This is about as useful as that windows update that just lets you (and your Redmond-based overlord) verify that your copy of windows is legal. Even though the epic battle of Adobe V. Microsoft seem to be really gearing up, I hope that Flash will be a legitimate reality on all consoles at some point.

UI development in commercial games is generally lame, hard to do, and often has a different “feel” from the game itself. My understanding of the process is that the UI always ends up being a crunch time project and a fairly complex one when you aren’t using a tool so perfectly suited to the task as Flash. For any application, Flash is an excellent tool for adding great visuals, good capabilities and for going from .

A couple of years ago I went to a great presentation at Flash Forward NYC about how Orange Design had dramatically improved the UI development and design process for Lucas Arts by making the UI for several of their PS2 games run in Flash. I’ve never been clear if the player is on PS2’s or if it is software running on the specific discs (For more information, click on the Lucas Arts in Orange Design’s “Applications” section).

There was also an interesting article on GameSpot about how Flash may make its way onto the PSP and that it hasn’t been “intentionally ignored.”

Now if Nintendo would see the light, all would be well with the world.

I’ll be up in Seattle from Monday through Thursday for the west coast Flash Forward. I can’t wait to see the new venue.

My presentation on mobile design and Flash Lite 2.0 is Tuesday morning at 10:30AM. I hope some of you have a chance to drop in. While I always prepare way too much content for fear of running out with time to go, I do hope this will be an interactive sessions full of questions and feedback.

I’m just putting some finishing touches on my PPT and one of the FLAs, but the session materials will be posted here before the session. The plan is to make the examples show contrasts. I will have the same application running on different devices or in different versions of the player so we can really have a discussion about the many different simultaneously moving targets that is mobile development.

The examples will be a maze game for the U10 in Flash Lite 1.1 that was ported from Flash 7, a couple of games for Flash Lite 1.1 on Nokia devices, and my Flickr application in Flash Lite 1.1 and 2.o.

If you are at the conference and want to meet up, write a comment and hopefully we will see each other there.

I was officially invited to join the hordes yesterday in the Sprint Ambassador program. Sprint has taken to searching for blogs discussing mobile phones and consumer electronics and giving them a free phone and unlimited call and data plan for six months.

Doing a quick search suggests that this is more about guerrilla marketing than about market research. Going after bloggers, the assumption is that they will give us a phone and we will probably blog about them. Very smartly, they didn’t ask the participants to blog or anything, they just figure it will come naturally (a point I am proving now).

Of course I am accepting the phone and am grateful for it as a chance to try Sprint out again after 5 years on Cellular One/AT&T Wireless/Cingular Blue. I can’t imagine that there is anything that they can do though that would make me want to switch to them. The fact that they aren’t on GSM is a complete deal breaker for me.

Now if the Samsung A920 that they are sending me is one of those MMI Samsungs, I may have spoken too soon.

Sorry for the rather speedy post a bit ago, I was getting knocked off the network by the folks coming into the room right before the session. I was getting ready to start and I realized I had forgotten one thing. Having the files up before the session does seem an important point though.

Thanks to everyone that attended. I was really pleasantly surprised by the turnout. There were also some really good questions after the session. If you would like to see the PPT file and the related Flash files, please download the source here.

The major points of the session focused on one of two topics. The first part of the presentation was focused on what designers can do to optimize Flash Lite 1.1 performance. I used a couple of my old files like Pellet Pop and Aces High plus a maze game I made for the iRiver U10 to demonstrate some of the design techniques:

• Smoothly animate small elements the eye is focused on and roughly animate (or not at all) large elements. This gives user the perception of smooth moving content without the hit to performance.
• Use simple animations (scripted or tweened) to cover over processor intensive task. If you need to run a harsh loop over several items, animate a transition and run the the loop as a frame loop rather than a while loop. The example of this was using an explosion animation in Pellet Pop. The trig for digging out each column of a dynamically created terrain that has been exploded is run at one column per frame during each from of the explosion animation. The cumulative effect of the script is applied visually when the animation is finished.
• Consider whether to use vectors or bitmaps in your application. Scaling and rotation really require vectors, but otherwise you should use bitmaps for the performance benefits.
• Interaction differences in the devices make all the difference. Target specific devices, or classes of devices with your SWF. Flash does a great job of staying functional anywhere, but with varying screen sizes and pixel density, not to mention interaction patterns, each device is pretty unique. By tying your layout to variables that can easily be changed, it is pretty easy to create a base file then make some documented design changes to target a new device. I showed how by changing two variables, the stage size and one button event handler I was able to make a specific port of my U10 game for my Nokia that is consistent with the Nokia interactions.

From there I moved on toSWF 2.0 to show how much better life is about to get. My original maze game was coded for Flash 6, and with only changing the stage size I was able to run the original game on my phone with only a very slight loss in performance. I also showed how using Flash Lite keeps you from having to implement server solutions for XML and loading JPGs. This ability really makes Flash Lite accessible to people that are purely focused on the client side.

I wrapped up my presentation by talking about how Flash Lite 2.0 is actually moving ahead of the desktop player in certain cases. In Flash Lite 2.0 you can use right to left languages and can support any media type that your phone supports. I showed an example from Adobe on how Flash can composite 3GP video straight into the Flash movie. I desperately wish Flash for the desktop had this capability.

Making games for the U10 is fun, but I also want to be able to customize the Flash Lite UI that runs the rest of the device. I’ve gotten pretty far, so I thought I’d share what I learned in hopes that others are looking into this and can share what they have learned.

The Problem
The Iriver does a really good job of protecting its UI SWF. When you hook the device up to your computer you can see some directories, but there must be some that are simply not exposed. There are two main directories on the device, media which holds the DRM audio/video and can’t be modified except through Windows media player. The other directory is Data that can be modified as you wish.

The Vulnerable Spot
When I got my U10, one of the first features that made me raise an eyebrow was picture viewing. You use a tool to transfer JPGs from your desktop to the device where they can magically be loaded. The thing is that as I have really good cause to know from my traffic cam viewer and Flickr tool, Flash Lite 1.1 can’t load JPGs. Looking at the files on the device (/data/system/pictures/) The files are .JFU and .JTH, which I assume stand for “JPG Full” and “JPG Thumbnail.”

If you transfer any of these files to your desktop and change the file extension to .SWF, the Flash Player can run the file. The image viewer works in a very similar way to my traffic cam viewer. Instead of loading a JPG, it relies on an external solution to wrap the JPG as a SWF. This isn’t a server solution like mine though. The transfer tool does the conversion as part of the transfer process.

Knowing that, it is pretty easy to make your own Flash Lite 1.1 files and start loading Flash files into the UI. The easiest way I’ve found is to export your file and take a screen shot and save it as a JPG. Move that file over using the transfer tool to make the placeholder (and thumbnail file), then replace the JFU with your SWF remembering to alter the file extension. When you disconnect your U10 and it re-boots, go to Settings>Extra>Background>Pictures>(your image directory) and select the thumbnail for your SWF.

Introspecting the UI
With a Flash background you can do some pretty cool design things, but not a whole lot technically. To do more, it is a matter of finding out more about the Flash file that loaded the background. In Flash 5 and higher, there are a lot of tools that let you introspect into a parent SWF that another is loaded into. With for...in you can find everything you could ever need to know.

Back in the reality of Flash Lite 1.1, we have a much more limited set of tools. The best tool in our small arsenal is _target. For the background it is /bgImg/photo/photoDown. It doesn’t get us as far as I’d like since you can’t find out what else is in each of the timelines. Luckily there are other places that the images appears. Some of these other locations are a bit more revealing.

Full SWF as the Background:
/bgImg/photo/photoDown

Thumb SWF in the Background Selector:
UI in landscape:
/all/currentMenu/setupPhotoList/listBox/list2/photo
UI in portrait:
/all/currentMenu/setupPhotoList/listBox/list3/photo

Full SWF viewed in the Photo Viewer:
/all/nextMenu/photo/photo/photoDown

Thumb SWF in the Photo Selector menu:
UI in landscape:
/all/currentMenu/PhotoList/listBox/list2/photo
UI in portrait:
/all/currentMenu/PhotoList/listBox/list3/photo

Also using _currentframe and _totalframes can reveal a little, but I haven’t had much chance to play with sending the various movie clips to different frames. The root does have 70 frames though, so there could be some interesting things there.

I’ve been spending my time exploring the other timelines, specifically the menu timelines. Strangely, every time I try to modify /all’s properties, it really screws things up. I have no idea how, but setting the _y of the movie clip, often makes the buttons non-functional and can even shift the UI into portrait mode. No clue why. There are however some elements off-stage if you want to take a look.

Just be careful, you can seriously screw up your ability to interact with the device. If you mess things up you can still generally connect up to your PC and replace your malfunctioning file. When it asks you whether to do power only or power and data, you may have to try a variety of buttons. If you get seriously screwed up, you can always download the firmware update tool from iRiver and reformat the device (eep!).

In my previous post I talked about how to make the background of your U10 a Flash movie, so I thought I would post the source for my first background, a random generating background. It looks fairly plain on the desktop, but when you add in all of the menu items from the device, it looks a little more interesting.

In addition to adding the circle elements, I am altering the alpha level of the non-highlighted elements of the menu. To make the menu work with any background color, the text elements are set at about 30% opacity. The Flash background I’ve been working on is a bit bold color-wise and the menu items are getting lost. By bumping the _alpha of /all/currentMenu up to 300%, you can make the text opaque.

Prior to doing a little more introspection I had previously been changing the alpha of the root, but that affects other UI elements like the translucent black overlay for system notifications like volume adjustments and connectivity. By more narrowly targeting the alpha setting, I can boost just menu text and arrows.

Another interesting thing that you can see when you start doing dynamic backgrounds is that the SWF is reloaded several times. If the backlight turns off, the background will redraw when the light comes back on. The same holds for when you change from portrait to landscape or launch and exit a game. The strange thing is that right before it redraws, you still see the old state. It isn’t that the background was ever unloaded; it was just reloaded.

I am on a bit of a U10 kick recently after doing a U10 game for my presentation at Flash Forward. Craig Babcock wrote a comment on my previous entry and as I started to rant I thought it would be better to respond as a post rather than a comment. The U10 breaks every notion of key events that I have had and manages to be internally inconsistent with itself.

In Flash 4 player world, you don’t have Key.isDown to poll a key position to do smooth interactions. Instead you rely heavily on the accessibility feature of key repetition. You hold down a key and it fires once, pauses, and then fires repeatedly and rapidly. It doesn’t make for the best experience, but with some ingenuity, you can make pretty fluid movement.

On the U1o, when you add your SWF to the device, you quickly find that the key never fires. Since we are using an accessibility feature, I wasn’t all that pissed that key repeat didn’t work for a device like this, even though I was disappointed since this narrows the types of games I can make. What did frustrate me though is that the key repeat does happen on the device UI. In menus, holding down the side of the player (the key) will continuously scroll (and even accelerate and optimize the display) until you let go. In media player and radio settings, there is functionality that relies on your holding down the button for a longer period of time.

Clearly something strange is going on. I have a few guesses of what could be going on (I have no evidence to support any of these ideas):

• FScommand2 - Perhaps there is a custom fscommand2 that can poll the key like Key.isDown. This would be essentially impossible to detect as long as it is only implemented in the protected UI.
• Different Player - The Flash games are running in a separate instance of the Flash player from the UI. You can tell this because you can set the frame rate of your game without it being slaved to a master SWF frame rate. You can also use background color and the _target for your file’s main timeline is just /. You can also tell that the UI player is not destroyed since randomized backgrounds still show their original pattern for a moment before being re-loaded. Since they are separate player instances, it has gotten me wondering if they are separate player versions. The player isn’t huge for a storage device like an MP3 Player. If I wanted to add functionality like the ability to launch the video or other broader actions and didn’t want this functionality exposed to the developer API, having a custom player for the trusted content would certainly be a route I would want to explore. None of the device identification elements seem specific enough to provide useful information on this theory.
• on() event shenanigans - I have the most negative evidence for this one. I thought that they might have mapped another key on the keyboard for for the purpose of a keyUp action so I created a button that maps every key that I could think of that was mappable in Flash 4. None returned anything unexpected. The only other things I can think of is a custom event like a keyUp (though that precise name didn’t seem to work) or there is a key that I am not thinking of to listen for.

Since I am pretty well thwarted I only have one possible test left. Some of my experiments with the UI have ended up screwing up the buttons. If I can find where they sit and unload the parent of the buttons, any buttons I add in my custom SWFs should start firing.

IMPORTANT NOTE: If you decide to give this a try, put your actions in something like a thumbnail file, NOT the background. If you screw up your UI in a thumbnail, you can restart the device and go back to the main menu. If you screw up your background, you could make it very challenging to get the device able to sync to your computer to overwrite the bad SWF. Since the device uses Flash buttons to give permission to the Power & Data selector, you need this to remain functional. Luckily, the power button seems to be a device control, not a Flash UI control, so you shouldn’t be able to break that.

The Popular Science of the 21st century, Oreilly’s Make magazine and blog are must reads for geeks. After perusing the site, I generally feel inspired and really really slow (though I’m still not sure why I should be wanting to give a roach an exoskeleton no matter how cool it is).

So I’m geekily excited to see that Philip Torrone at Make has linked to my post on “hacking” into the U10 interface.