design-nation.blog/en

Guess the race is on to see adoption rates of Flash Lite and JSR-226... but...

This is still J2ME we are talking about, Flash Lite is still going to be quicker to write/produce things in (which is really one of it's strongest, if not THE strongest selling point). So really, not as much of a hit as it might first seem :)

Well that's one implementation of JSR-226 - and I'll bet that every other company will have a slightly different one.

J2ME is great in theory, but the more I look into it the more I'm horrified by the fragmentation across the industry. As a content developer forking different versions of my content just for compatability makes absolutely no sense - and as Richard pointed out, things are so much faster to develop with Flash Lite.

I don't have specifics on that spec yet, much less its eventual implementations and use, but I do understand that most modern clientside engines do acknowledge the need for vectors now. (Put another way, if a clientside engine couldn't offer drawing abilities in 2005, then that would be increasingly strange.)

jd/mm

Well, I agree with John. Obviously, a client side engine must offer some graphical abilities. And I also agree with Richard and Bryan, things can be done faster in flash.

But I was just wondering. "They" want to render vector images. "We" know how to do it. I'm not sure if I see this specification as something to fear of or not. Maybe, it's just that I feel as if an opportunity has gone. I mean, wouldn't it be great if we could just integrate a swf into a J2ME application?. I don't even know if it could be possible from a technical point of view, if it's just a dream, but it's something I would like to do.

Cesar that's something I'd love to see! I've not been able to look at this the past couple of weeks but I had a couple of ideas for integrating Flash/Java, please feel free to add any you have, that would be great. (sorry put this page together in a hurry)
http://www.richardleggett.co.uk/misc/FlashLiteJ2ME.html

As to physically integrating to the two, do you mean embedding a Flash player in a Java app? It might become too platform specific as found with SWTFlash, especially on mobile devices:
http://www.darronschall.com/weblog/archives/000070.cfm

Then there's Animoi which took a different route concerning Flash/J2ME:
http://www.macromedia.com/macromedia/proom/pr/2004/animoi/index.html

Emailing the address on there you get a "customer support request" automated response.

Hi, Richard, I remember your post in the FlashLite mailing list.

I don't mean just embedding the flash player into a java app, maybe I'd love to see some kind of tight integration between them, maybe some kind of intercommunication, maybe the ability to switch the focus from a J2ME application to a flash application, I'm not sure.

I've read your ideas about integrating a swf with a midlet acting as a socket server. Maybe, that could be the best path to follow....

What type of inter-op are you guys seeing in terms of Flash Lite - J2ME?

Personally, I'd rather have a C++ app providing more integration with the specific device hardware that used Flash Lite as an interface engine. Sort of like a Central for the mobile space - that could be utilized by Flash and other applications using sockets and either xml and/or a simple scripting language.

Let the C++ app worry about available features, security, Bluetooth integration, IR, wifi (if supported), interop with other apps and data on the phone.

Granted, this is a bit of a best-case scenario - but it J2ME just always feels like hack after hack.

Hi, Bryan

That's a good idea also. There are some things that flash can't do right now, maybe because it shouldn't, maybe because it's not possible, I don't know.

But it will be great to have an API to access the phone's hardware and software ( bluetooth, PIM, local persistant data, and so on ).

Personally, I don't care if it can be achieved trough J2ME, C++, but that's definitely something I'd like to see.

By the way, maybe it's out of the scope of this discussion, but I'd prefer a J2ME solution. I know that the "write once, deploy many" mantra is, well, let's say "not too accurate", but maybe a C++ solution will be only valid for Symbian devices.

Personally I don't care whether it's J2ME, C++, Assembly or Python - however, any runtime that runs at arms length from the hardware is probably going to suffer from limitations on camera use, bluetooth, ir, file i/o, etc. The idea here is to provide an interface that is tied to the hardware and would provide apps created with higher level technologies (Flash Lite, Python, even J2ME) to take full advantage of the hardware.

It also wouldn't have to be limited to just the Symbian OS - there's no reason the same application couldn't be ported to Windows Mobile, Palm OS or Linux.

Ideal solution would be to have all device manufacturers agree and actually implement a common specification. For an example of how well that works, look no further than the current state of J2ME.

I'm not going to hold my breath. ;-)

Great blog by the way - some fantastic conversations start here.

>>Ideal solution would be to have all device manufacturers agree and actually implement a common specification<<

Sure!. That would be the perfect solution. To have some kind of "phone hardware" API, that we could rely on, no matter what techonology we use to create our application.

Now, could we expect something like that? I'm afraid not. At least not now. Should we ask for it, beg for it, do whatever we can to make it real?. Sure.

And thanks for your kind comment about this blog. I wait for your comments in the next discussion ;)