Quitting Capuchin Flash Lite apps

January 13th, 2009

I’m fairly sure that there is no way to use SWF2JAR to bundle a Flash Lite SWF into a JAR package and be able to exit cleanly from the SWF. So this means using Eclipse (or your JME editor-of-choice) to do your packaging.

I’ve created a simple JME project that shows how to do this. In a nutshell, you need to use the DataRequest API in Capuchin to send a request to Java to quit the app. The files in the project show how this can be done; it’s all pretty simple, if you read through the DataRequest example in the Project Capuchin docs. I did not include the DataRequest.as file from the Capuchin examples/tutorials package since I’m not using classes in the example; so, depending on how your app is set up, you may need to include this when publishing your SWF.

At minimum, if you want to use this to just create a quittable Flash Lite app that uses no other Capuchin APIs, then:

  1. replace your fscommand2("Quit") with the appropriate code from the sample FLA;
  2. drop your swf in the res/ directory of the project
  3. find this line of code in src/FLClose.java:
    InputStream inp = getClass().getResourceAsStream("/FLTest.swf");
    and change FLTest.swf to the name of your SWF;
  4. build the project and package it.

That’s the minimum required to get this working. Bear in mind that you will need to edit the JAD file to change the name of the app in the menu, if you want to use a custom icon, etc.

(Also bear in mind that I’m new to JME, make no guarantees that this will immediately work for you, etc., etc. I think it’s pretty risk-free, but use at your own risk.)


SWF2JAR: I Can't Quit You

December 3rd, 2008

One of the most exciting parts of Project Capuchin is the ability to bundle up a SWF into a JAR package and be able to install Flash Lite content just as you would any JME content. Building content for mobile devices using Flash Lite is a piece of cake compared to actually distributing it, so this is a welcome step. An indication of how important this is, I think, can be found in the SWF2JAR tool that SE has made available.

The sole purpose of SWF2JAR is to take your SWF and create that JAR file. You can add a custom icon and set other parameters, click the button and you get a nice little installable file. You don’t have to install Eclipse or know anything about Java. You can’t use SWF2JAR if you’re transferring data between Flash Lite and Java (i.e., you’re using Capuchin to access data/features on the phone, like the accelerometer); if you’re doing that, you need to use Eclipse to package your content.

Given that, my assumption has been that the main target for SWF2JAR are the Flash Lite developers who have simply developed a piece of “stand-alone” content and want to bundle it for distribution. So I figured I’d take Poker Solitaire, run it through SWF2JAR, and have a nicely installable game on my hands.

Which I did, but only one problem: it seems that my in-game ‘quit’ button no longer works, so I have to force quit the game using the “Running apps” window. My guess is that by default fscommand2("Quit") isn’t transmitted to the Java wrapper. I wonder if this sort of thing would constitute “transferring data” (i.e. the request to quit) from Flash Lite to Java, which implies that you’d be required to use Eclipse for packaging.

Perhaps I’m just missing something obvious. But if I’m right, I think this significantly limits the usefulness of SWF2JAR, in my mind, which you’d think would account for Flash Lite’s method of quitting an application. Further research is required.

(Anybody had success with SWF2JAR? Anybody recommend a good JME book or two?)

Flash Lite on the C905

November 28th, 2008

By way of initial test of the Flash Lite implementation on the C905, I just copied over all of the stuff I’d been working on on my W910i to see how it would run on the C905. The Flash Lite player is still a browser plug-in – there is a stand-alone player accessible via the Capuchin framework, but we’re not talking about that just yet. Opening content via the browser works much the same, but the browser itself is slightly different, which has an impact on how FL content works. FL via the browser on the C905 does not support going full-screen via fscommand2(), and the browser can no longer be put into full-screen mode. So the upshot of this is that your content will always be scaled down to leave room for the softkey text and the signal/battery icons.

Since it’s unlikely that anybody will be delivering stand-alone content via the browser to these phones – because that’s part of the point of Capuchin – it’s not a big deal for content that’s actually shipping. But it introduces an extra step into the workflow during testing. If you’re using Capuchin simply to wrap your swf into an installable file, and want to be able to test your content in full-screen mode during development, you’ll have to go through the swf2jar process with every iteration. Good thing I kept my Windows PC when I made the jump to the Mac!

That’s probably the most significant difference that I’ve found that will have an impact on developers. Two other little items of note:

  • If you rotate the phone, the browser will switch to landscape mode, so any Flash content that might do the same will get rotated twice (once by the browser, once from within Flash). Again, not a big deal for shipping content, but another speed bump in the dev process;
  • The loadVariables APIs for accessing accelerometer values and mp3 information are still supported, so if you want to take advantage of these things for wallpaper content, you can (no idea if they’ll continue to be supported so ultimately using Capuchin to access this data might be the most future-friendly way forward).

SE C905: First Impressions

November 26th, 2008

The Sony Ericsson C905 is the first of the Project Capuchin phones, which is an API to bridge Java ME and Flash Lite – you can use FL as the presentation layer and JME for the application logic, or access device APIs previously inaccessible from within Flash Lite (GPS, calender and contact data, and so on).

The phone itself is very nice – it’s a slider form factor, and overall very much like my other SE phone, the W910i, since the UI seems to be essentially unchanged (which is fine; I like the SE UI). The C905 is a little bit thicker than the 910, but not enough to be an encumbrance. I guess this isn’t surprising seeing how the C905 has Wi-Fi, GPS, and an 8.1 megapixel camera with flash. All in all, I’ve been sufficiently pleased with the C905 to make it my primary phone (goodbye iPhone! You and your crappy little camera had your two months in the sun).

I’ll have some follow-up posts shortly on my first thoughts on the Flash Lite implementation on the C905 and my initial experiments with Project Capuchin.

SetFullScreen (and other fscommands)

May 27th, 2008

Hayden asked about the ability to go fullscreen when launching a swf from within the browser. I don’t know about Javascript-based methods to do this, but here’s what I’ve figured out about that in terms of Flash Lite. I thought I’d also tack on some interesting bits about a couple of fscommands, namely SetSoftKeys and ExtendBacklightDuration.

The swf cannot access fullscreen mode itself, so this sounds like the same situation as with SE FL 1.1 phones. If the browser is in fullscreen mode to begin with, then the swf will run in fullscreen mode. Any calls to SetFullScreen in the swf are ignored.

SetSoftKeys exhibits behaviour that I can only describe as wacky: there appears to be a delay of approximately five seconds before the command is actually executed. If you start a swf that has a SetSoftKey call in the first frame, it does not take effect right away, so for a brief period of time you can still access the regular browser functions with the soft keys (menu for the left button, back for the right). But then, once the SetSoftKey ‘takes effect’, it effectively locks up the browser. I tried one swf and, until I realized that the ‘end call’ button acts as a sort of kill command to the browser, had to keep restarting the phone to be able to get out of that swf. Perhaps this is the standard behaviour for SE phones, but if so, it seems an unfortunate decision. It would seem better to not allow the remapping of the keys at all than to create a situation where it seems impossible to exit a swf.

Lastly, ExtendBacklightDuration. This works as expected, although it appears that interacting with the accelerometer will reset the backlight duration to the default. If you’re creating a game/app where the only means of interaction is via the accelerometer – and so there is an extended period of time where the user is not pressing any buttons on the phone – the backlight will turn off. This, obviously, is not the optimal user experience.

Luckily, there’s a dead simple way around this. Just throw the following code into your movie, and you won’t have to worry about the problem:

function keepBacklightOn() {
     fscommand2("ExtendBacklightDuration", 5);
}
var lightInterval:Number = new Number();
lightInterval = setInterval(keepBacklightOn, 5000);

This just creates an interval that will set the backlight duration to 5 seconds; the interval is run every 5 seconds, so the effect is to keep the light on all the time. You just have to remember to turn this off if/when you don’t need it – if the user is interacting with a menu, or if the game is paused, for example – to avoid draining the battery unnecessarily.

Accelerometer notes, Part 1

May 26th, 2008

Having had a few days to play around with the accelerometer on the W910i, I have to say that it’s a lot of fun. It’s not without its idiosyncrasies, though. The first one that I’ve discovered makes me wonder if there needs to be another category for Flash Lite implementation, in addition to the usual standalone, browser, wallpaper, etc. modes. Perhaps it could be called ‘pseudo-standalone’.

I think the W910i could be described as having a pseudo-standalone implementation of Flash Lite, because of how the accelerometer is handled – or not – by Flash Lite files, depending on the context in which they’re started. If a swf is loaded from a web server, it will not be able to load accelerometer data; the vars into which the data gets passed (accX, accY, accZ) remain as empty strings. If the same swf is copied to the phone memory and started via the file manager, it will work as intended. When you start a swf in that manner, and hit the left soft key, you get the standard web browser menu choices. So the swf is clearly loading via the browser, but the browser ‘knows’ that it didn’t get loaded via an http connection. (I’m assuming that the browser is allowing or denying the loadVariables call to the accelerometer data.)

W910i font bug

May 25th, 2008

Just posting this in case anybody else runs into this problem: device fonts in Flash Lite 1.1 files do not display on the SE W910i (a FL 2.1 phone). The fonts do display if the same swf is opened on a Nokia E65 (FL 1.1 pre-installed). If the FL 1.1 fla is published as a FL 2.x file, the fonts will show up on the W910i. Anybody else encountering this on other SE phones with FL 2+ installed?

SE W910i: First Impressions

May 22nd, 2008

A new phone has been added to the Ludicrous Software stable, the Sony Ericsson W910i. It’s the first SE phone I’ve obtained for testing and development, so as a person whose been using Nokias almost exclusively, the last day or so has been kind of interesting. When I first took the phone out of the package, it seemed kind of light and insubstantial, at least in comparison to the phone I’ve been using day-to-day lately, the Nokia E65. (These two phones aren’t targeted at the same demographic – the E-series phones are meant for businesspeople, while the W910i is a Walkman-branded phone – but they’re both red slider phones, so the comparison , at least for me, was inevitable).

In any event, after an initial period of adjustment, I have to say that I’m pretty pleased with and impressed by the phone. While it lacks the Wi-Fi capabilities of the E65, setting up the phone to use a PC’s internet connection is almost painfully easy, which is nice. Setting up the wireless services on the phone wasn’t the most pleasant experience, since the Sony Ericsson service that will send you the configurations you need seems to send the wrong settings for Rogers here in Canada. But that’s pretty much all ready to go now. Otherwise, the O/S is really nice, and strikes me as a nice combination of S60 and S40: pretty much all of the flexibility of S60, but the menus are as responsive as a Series 40 phone (I’ve always found navigating around the S60 menus to be pretty slow).

In terms of Flash Lite, it has Flash Lite 2.0 in the browser (although it feels like it’s a standalone player, as you can launch swf files right from the file browser). The phone also has a bit of a twist: an accelerometer that can be easily accessed from with Flash Lite, as Hayden mentioned a while back. I’ve had quite a bit of fun playing around with this feature, and will have some follow-up posts about it over the next little while, so stay tuned for that.

Flash Lite 2.0 for Sony-Ericsson

October 10th, 2007

Sony-Ericsson Developer World has released Flash Lite 2.0 Developers’ Guidelines. (more info)