Great news folks. Forum Nokia’s Online Flash Lite Packager is live again. To be honest I was starting to fear the worst but true to their word the boys and girls at Forum Nokia have wheeled out a new version.

So if you fancy converted any of your existing Flash projects to Flash Lite and selling them on Nokia’s OVI Store then now is the time. With OVI Store available to Nokia users in over 180 countries there’s the potential to generate some serious revenue. Now I just need to think up a good idea and I’ll be driving around in that Ferrari that I’ve always wanted.

Spotted an interesting article on Scott Janousek’s blog stating that Flash Lite 4 is now available from Calsoft, one of Adobe’s partners responsible for getting the Flash Lite run-time working across various chipsets.

So why another version of Flash Lite? Isn’t Flash Player 10.1 for mobile going to make Flash Lite redundant?

Well not quite yet. Given the minimum device spec (order of a minimum of 600 Mhz ARM11) required to run 10.1 it’s going to be some time before there’s significant penetration across a wide range of devices. Plus whereas 10.1 is a browser only plug-in, Flash Lite 4 is both standalone and a browser plug-in.

So while developers can get to work straight away writing Flash Lite 4 applications and games for various distribution channels, those wishing to target Flash Player 10.1 will need to wait for AIR 2.0 to roll out across mobile.

Many may look down on Flash Lite as nothing more than a stunted version of Flash 10, but it makes a lot of sense for those wishing to write apps quickly or for those who simply want to port their existing web based games to mobile with minimum fuss. Its support for ActionScript 3 should make porting significantly easier than before where many developers would previously have had to actually re-write their code in ActionScript 2.

Outside Japan, Flash Lite doesn’t seem to have had the success Adobe would have hoped for. It’ll be interesting to see if that changes with Flash Lite 4.

Developing GamesFlash over the last few years was a great learning experience and, as I’ve said before, was something I was extremely proud of. There were times however when I felt like giving up. Although Flash Lite was a great stepping stone towards a full mobile version of the Flash player, there were terrible fragmentation issues across devices and a frustrating number of bugs introduced across various versions of the Flash Lite run-time.

When I decided to eventually add video support I came across one problem in particular that nearly lead to me having a nervous breakdown. Testing GamesFlash directly from the phone’s Flash Player application or within Device Central indicated that the Series 60 devices should each have approximately 4 Mbytes of dynamic heap available, which was enough for video support to work quite well. However, after packaging as a SIS file using various SIS packagers, I noticed that GamesFlash was suddenly only allocated 2 Mbytes of dynamic heap, which wasn’t nearly enough to comfortably run video. It resulting in the dreaded “out of memory” dialog appearing at run-time after playing a handful of videos.

Having used SWF2Go for the bulk of my SIS packaging I contacted lead developer Faisal Iqbal (AKA chall3ng3r) to see if he could shed some light on the problem. Unfortunately a workaround wasn’t forthcoming but at the time Adobe’s Distributable Player Solution came to the rescue as it packaged content without the same memory issues. With the Distributable Player Solution now cancelled I often wondered how others got round the memory problems I was having. Surely I wasn’ t the only one suffering from these memory issues.

Well I got an answer today thanks to a Tweet from chall3ng3r. Looks like it was a memory allocation bug in Flash Lite 3.0 on S60 devices, which makes memory settings in the stub launcher obsolete. Nokia have now fixed this issue and the fix is available in Flash Lite 3.1 via a firmware update. The posts made by chall3ng3r on the SWF2Go Forum indicate that the problem is specific to 5th Edition devices. I wonder if that’s a mistake as I definitely experience the same problem on 3rd edition devices such as the N95.

What the heck is going on with Forum Nokia’s Online Flash Lite packager? It must be months now since Nokia put the project on hold meaning anyone with great Flash Lite content that they’d like to package and distribute will have have to look elsewhere for an alternative.

It’s a real shame because the online packager removed the need for Flash Lite developers to have to install the Symbian S60 SDK directly on their PC. It also meant that Mac owners could package their content without having to get access to a PC. Currently Nokia’s only suggestion is to indeed install the Symbian SDK on a PC and write a Flash Stub application using Carbide c++. For some it’s probably more effort than it’s worth.

It’s just another frustration for those wishing to create Flash Lite applications for the wide range of Nokia devices out there.

All is not lost though. It certainly doesn’t look like the Online Packager solution is gone for good. In fact Forum Nokia has this statement on its site:

We are looking into providing a reliable online packaging solution for Flash… Sorry for any inconvenience caused by this action. We did get a lot of valuable feedback for our next version and wish to thank you all for your input.

It would be great if there were some more details released regarding the new packager. Is there a scheduled release date for it and what new features are we likely to see? If anyone knows then please get in touch.

And when the Online Packager does eventually re-surface let’s hope that Nokia have fixed the ridiculous signing process for Flash Lite content. I don’t really understand why Flash Lite content for Series 40 devices can be packaged in a simple NFL file and distributed without signing, whereas all S60 Flash Lite content has to be Symbian Signed and distributed as a SIS file.

Can’t we just have something similar to the NFL format on S60 devices? Currently it’s just too expensive and time consuming for those writing freeware apps to get their work onto the OVI store. I think it’s also still the case that anyone wanting to release content on the OVI store has to be VAT registered (please someone correct me if I’m wrong) before being allowed to submit content. This again just seems crazy and must surely be preventing many great creative individuals from submitting interesting and free apps to the OVI store.

I also noticed that Alessandro Pace also has similar thoughts regarding the NFL format, suggesting that Nokia push it out across all their devices.

Oh and if you are looking for an alternative packaging solution I’d suggest you take a look at SWF2Go Professional by Faisal Iqbal.

Just for fun I decided to port my audio cassette music player to mobile. A really strange thing happened though when I actually got it onto my Nokia 5800. As soon as I saw it on the phone’s screen a long forgotten memory from my childhood came back to me of something I hadn’t thought about since the day it happened.

I was playing in my room, and must have been no more than 9 years old. I was suddenly aware of another person being in the room and looked up to find a man who looked strangely familiar standing in front of me. Although I had no idea who he was I was certain he knew me. There seemed to be a bond between the two of us.

For several minutes he just stood there looking at me, seemingly fascinated. I wasn’t affraid but I was growing a tad impatient – I really wanted him to go away so I could play Super Pipeline on my Commodore 64.

Eventually he knelt down beside me and produced what looked like a thin sheet of glass with a cassette trapped behind it. The cassette’s wheels were somehow spinning and I could hear music.

He asked me what I thought. To be honest it kinda spooked me a little and I turned to shout on my Mum. When I looked back he was gone.

Recalling all this, I instantly felt quite bad for not telling the man what I thought. I think I was probably just a little too young to effectively communicate how I felt. But it has got me thinking. What would someone from the eighties think about my Flash Lite demo? Would they like it or be thoroughly unimpressed?

If I ever manage to master the art of time travel (I’m definately close) then I’m gonna make a point of going back to the eighties and asking some dudes what they think.

For anyone who’s interested, the port to Flash Lite 3 was fairly straightforward. It took around two hours and required few modifications to the actual visuals – I scaled down a handful of the clips in the library, converted some stuff to pngs, and flattened the structure somewhat to remove embedded movie clip depth. The biggest task was rewriting the code in ActionScript 2, although again, it was hardly a problem. I tend to find ActionScript 2 a fairly good prototyping language that allows you to get things done relatively quickly, which was the case with this port.

Now if I do manage to go back in time who should I show the demo to first?

This isn’t anything new but it’s an easy one to forget and something that caught me out the other day. So to be perfectly honest I’m writing this as more of a reminder to myself rather than anything else.

Firstly the problem. I was helping someone with their Flash Lite app that let the user send SMS messages to friends, but for some strange reason the device refused to launch the SMS application. Of course it was a silent failure so there were no error messages explaining why.

Now I’d simply put it down to the dude’s Nokia E90 not supporting SMS within Flash Lite but Alessandro Pace thankfully chipped in with the reason and a solution. It was of course all down to the fact that the SWF was running on a device shipped with Flash Lite 3 which, rather infuriatingly, has the exact same security sandbox as the Flash 8 player.

So why’s that such a bad thing? Well this security model effectively means that apps can either have local access or remote access but not both, which doesn’t really make much sense when dealing with mobile. If you want to make a getUrl()call, which is required to send an SMS, then you’ll need to publish your SWF with network access enabled and also copy it to a special Trusted folder on your Nokia.

Unfortunately this security model and the work-around both have a whole series of implications ranging from backwards compatibility with SWFs published for older Flash Lite players, to issues getting your applications Symbian Signed.

Adobe have addressed this with Flash Lite 3.1 but it’s something that isn’t going to go away in the short term due to Flash Lite fragmentation across the range of Nokia handsets that are already out there.

If you want to know more then I strongly suggest you read Ugur’s excellent blog entry that he posted way back when Flash Lite 3 was launched. This issue was also raised by Faisal Iqbal at the time who wrote a great follow up with additional issues and nags.

It’s the simple things that make me happy. Conditional compilation is one such thing and although it has been available since Flash CS4 those developing for mobile have been unable to take advantage of it. Why? Well to-date mobile developers have been limited to Flash Lite and ActionScript 1/2, whereas conditional compilation is only available when writing ActionScript 3.

This has been a real shame since Flash Lite developers arguably require conditional compilation more than any other Flash developer. Take my GamesFlash project as an example. I targetted over 50 different handsets and also wanted to ensure that it would run within a web browser for demonstration purposes. Considering the varying specifications across my target devices I quite often had to remove features from certain builds – streaming video being a feature that was only supported by the S60 devices. Without conditional compilation doing this can be a side-project in itself.

Sure, there are ways around it. For example, you can write multiple versions of certain classes (a feature rich version of a class for high-end handsets and a more modest version for low-end devices), store them in different folders, then using multiple profiles, point each profile’s class path to the correct folder for the version of the class that’s required. This approach works well for those going down the object oriented route, but for many Flash Lite developers this won’t be the case and including/excluding code from certain builds will suddenly become more difficult.

Thankfully developing iPhone apps using Flash CS5 won’t have these problems since it’s the first time that mobile developers using Flash will be able to take advantage of ActionScript 3. The following snippet of code illustrates just how useful conditional compilation can be:

private function setup() :void
{
    CONFIG::WEB
    {
        // Add lots of complex shapes - we've got the CPU.
        addShapes( new ComplexShape(), 1000 );
    }

    CONFIG::IPHONE_3G
    {
        // Add a modest number of simple shapes - we don't have much CPU.
        addShapes( new SimpleShape(), 50 );
    }

    CONFIG::IPHONE_3GS
    {
        // Add lots of simple shapes - we have some more CPU.
        addShapes( new SimpleShape(), 100 );
    }
}

The example above expects there to be three config constants set via the Publish Settings panel in Flash: CONFIG::IPHONE_3G, CONFIG::IPHONE_3GS and CONFIG::WEB. Depending on the build I want to make I can set certain constants to true or false, or alternatively create multiple profiles with different configurations for these constants and simply select the desired profile. This should make life so much easier.

So what about Flash Lite developers? Well if you’re developing for any of the current Flash Lite players you’re still going to run into the same frustrating problem. However there is light at the end of the tunnel. Flash Lite 4 and Flash Player 10 for mobile are on the horizon, and with both offering support for ActionScript 3, building for multiple targets will become a whole lot easier.

‘What the heck is GamesFlash?’ I hear you ask. ‘Is this another one of your hugely ambitious personal projects that never got finished Mr Caleb?’ Well yes and no. You see I did actually finish this one, although I do confess to having spent the last three years of my life on it. Strictly speaking, saying I’d finished it is actually a little white lie. You see the very nature of GamesFlash means that I suppose I could go on indefinitely working on it but I felt the time was right to move on to other things, including this blog.

So what is it? We’ll it’s a Flash Lite application that delivers the latest video game reviews, news and videos straight to your phone. Although at its heart it’s much more generic than that and can really deliver any content you like. GamesFlash was used as a test case to demonstrate the technology behind it. I ran GamesFlash over a two year period along with a few friends who helped me regularly update it with new articles. While I was producing content I was also continually adding new features and optimising the code base to squeeze it onto as many handsets as possible. As you can imagine it didn’t really leave me with much time for anything else.

When I started work on GamesFlash, browsing the web on a phone wasn’t a very satisfying experience and thanks to high data charges was also very expensive. The aim of GamesFlash was to get round this by bypassing the phone’s web browser completely and instead deliver graphically rich but bandwidth light content via the Flash Lite player. Articles delivered to the phone were template based and each template had a very small set of tags enabling me to keep data transfer to a minimum. All graphics were also optimised on the server for the device, again ensuring very fast and inexpensive downloads.

A few years down the line I also introduced streaming video for those who had a suitable data plan for their phone. Users were able to watch video trailers that accompanied many of the articles and I felt it added significantly to the experience. However by this point the iPhone was a really big deal and had revolutionised the mobile web experience. Suddenly in an attempt to catch-up, every phone manufacturer was producing pretty decent browsers for their handsets and the carriers were finally offering affordable data plans.

All this meant that GamesFlash was starting to look a little obsolete in its approach. Plus the scale of the project had started to get seriously out of hand. To be honest it had stopped being a one-developer project some time ago but I kept furiously chipping away at it determined to realise my original vision. Maintaining both the server-side and client-side code was a huge strain and I also made the decision to completely re-write the client one year into the project. It was necessary in order to get it running on mass-market devices such as Nokia’s Series 40 handsets but with very limited spare time on my hands it took around 10 months to do.

I’m very proud of GamesFlash and what I managed to achieve considering the scale of the project. In its first year alone GamesFlash was downloaded 8000 times, which I thought was pretty remarkable considering I could barely find the time to publicise it – another drawback of doing it all myself. It was also a finalist in this years Flash Lite Developer Challenge which was quite exciting and in many ways felt like a reward for all the time I’d put into it.

However with the mobile landscape having changed so much I feel there’s no longer a need for something like GamesFlash. It could perhaps survive in some capacity for low-end handsets where web browsing can still be a clunky experience but with smart phones gaining greater market penetration I think more and more people will be able to access on their handset the same content they view on their desktop.

I’ve learned a lot during this project and I’m delighted that I got everything into a more-or-less complete state and that people actually used it. But the time is right to move onto new things. If you’ve made it this far then thanks for letting me get all this off my chest, and if you fancy taking a peek at GamesFlash then you can actually play around with it via the web-based emulation below.

Use the mouse to click on the handset’s softkeys and navigation pad, or alternatively click to focus then use the cursor keys and the return key on your keyboard.

]]> http://www.yeahbutisitflash.com/?feed=rss2&p=154 0 http://www.yeahbutisitflash.com/?p=139 http://www.yeahbutisitflash.com/?p=139#comments Sat, 19 Dec 2009 15:53:05 +0000 Christopher http://www.christophercaleb.com/blog/?p=139

Well that’s the revolver code from my Russian roulette game rewritten for touchscreen. Having touch support has allowed me to make things a little more interesting, with the user now being able to tinker with individual parts of the gun, which you can see in the video below.

Considering how tricky resistive touchscreens can be to work with I’m pleased with the end result. Getting it to work with a finger rather than the Nokia 5800′s stylus wasn’t easy and there were times when I wasn’t sure it would give a satisfying experience.

There’s definitely room for improvement and I should be able to increase the frame rate by making a few tweaks here and there. I’m actually rotating the revolver graphics 90 degrees at the moment, which is obviously a huge performance hit. Once I get the user interface up and running I’ll go back and optimise things.

I usually package my mobile projects into SIS files for deployment onto S60 devices. However, Nokia in their infinite wisdom have made the whole packaging and signing process as difficult and as expensive as possible for small independent developers or those wishing to simply create some freeware. You can skip the signing process and kindly ask users to change their phone’s permission settings to allow unsigned software, but as you can appreciate not many people are willing to take the risk.

So for the touch-screen version of my russian roulette game I thought I might try Nokia’s Web Runtime (WRT) mobile widget development platform. The nice thing about WRT widgets is that, unlike native applications, they don’t need to be signed since they run within the web browser sandbox. Widgets are also installed and launched the same as native S60 applications so from a users perspective it’s all good.

So basically all I needed to do was create an HTML page to house my Flash Lite SWF, bash together a simple CSS file, sprinkle a few lines of JavaScript on top and then archive everything into a WGZ file. Pretty damn easy eh? Well the creation of the widget was indeed trivial but the final result was far from what I had hoped.

After launching it from the Applications menu I tried touching one of the game’s menu options only for a horrible border to appear around my SWF. The touch also forced the native Symbian softkeys (which I’d disabled with JavaScript) to re-appear on screen too. But the final nail in the coffin has to be the delay between user interaction with the widget and the SWF actually receiving the event. It must be somewhere close to a second before my game picks-up the events from the touch screen compared to the instantaneous response when it’s packaged as a SIS file.

Now I’m new to WRT Widgets so I’m more than open to the possibility that I’m being a silly sausage and have accidentally omitting a few lines of JavaScript, but I did stumble upon some posts from other individuals with similar problems. Perhaps it’s a bug with my Nokia 5800′s firmware, I should check that I have the latest version. If I get some time I’ll jump onto the Nokia Remote Device Access site and spend some time trying it on a few other touch screen devices, just in case the problem is specific to the 5800.

In the meantime I’ll get back to the actual development of my game. Plenty of things to iron out before it’ll be in a fit state for users to play anyway.