A co-worker stopped by today to ask if I knew of an AC adapter for the Iriver U10. While IRiver doesn’t sell an AC adapter. You can pick one up pretty cheaply (at least for today). Since the U10 does everything through a cable that is proprietary at one end and a standard large-size USB at the other end, you can always just pick up a USB to AC adapter.

If you already have the IPod USB power adapter, you are good to go.

While on Iriver’s site, I noticed that there is a wallpaper creation contest that is in the voting phase right now. Take a second to vote; it is always a good idea to encourage these sorts of interactions with the community!

EDIT: The woot for the U10 has ended

For those of you that want to work with Flash Lite 1.1, but don’t want to get a new phone, the Iriver U10 is a great device to get. You can upload your own content, or start hacking the main UI which is also done in Flash Lite 1.1.

Normally the U10 512MB is $200. Woot.com has it for $99! I’ve bought several things from them and all the transactions have gone well. The only trick is to buy one before they sell out. good luck! it is a fun device.

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.

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.

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.

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!).