Java mobile apps today - a technology/weapon misunderstood

When you look at the present landscape of available mobile technologies to develop apps with, you'll see an abundant offering. Depending on what platform you're developing for, you'll see a mix of native applications, web technologies and similar. These are all cool and powerful, but what is not often talked about is the scope of the applications written and how choice of these technologies is linked with business models. What am I talking about here ? People working with J2ME will be eager to point out that there are several hundred million phones capable of running such apps and that phones that have that as the primary application platform are still going strong (for example Nokia's S40 phones). Others will say that means nothing  as owners of such phones are unlikely to pay for apps and that their hardware is so limited that you couldn't make something impressive anyway. Both are right in a way, but the story doesn't end here. What is often overlooked that shiny, flashy apps, sold as a product are not the only business model here even though originally most of the J2ME offering were just that - games. Think about SMS for a moment here. It is a super simple service, basically a specialized application, that earns huge amounts of money. But is the money in selling this 'SMS application' as it would be in selling 'Angry Birds' ? No, it's in the services it supports. It's somewhat similar to the problem that some people first encountering Open Source business models have - if you give your app away, how do you make money ? And this is why Java mobile app programming of today is misunderstood - it should not be viewed as a competitor to the write-app-sell-app-...-profit business models of iOS, Android or Symbian, but as a gateway that allows addressing a huge user base otherwise currently unreachable with other technologies. You don't need super-high technologies and sophisticated devices to check for a public transport schedule, arrange reservations, inventory/availability checks, etc. In that light, it's far from dead and/or useless. It's just about realizing that you have a business that CAN benefit from such a userbase.

Flash versioning gone wrong, or, should the abusers be abused ?

A painful fact is that Flash 10.1 is not currently available for the Nokia N900 (well, at least painful for N900 owners). If we look at the bigger picture, applications (like my version-forging TweakFlashVer) uncover a few non-N900 specific problems with the way things are done in Flash land.

TweakFlashVer is an awful hack - it just makes the Flash plugin report a faked version string (much like browsers in the old times forged their agent strings). Seasoned Flash developers are naturally very displeased with such an approach, as the plugin itself does not gain any additional functionality or acceleration, it's still the same Flash it was prior to the intervention. I can hear you ask - well, what good is it, then ?

And here is the problem - cludgy as it is, it DOES work, as seen on the N900, Facebook videos work again and many sites came back to life. How is that possible ? Sadly, often the real requirements of the content presented by Flash do NOT match the requested version in the loader/web page. But why do people declare wrong versions and make lives of their own users miserable ? Because Flash is doing it wrong in the first place, and then it gets abused by webmasters and flash devs further (making TweakFlashVer an abuse of an abuse). What are the reasons for this abuse in the first place ?

• Using version detection as an upgrade mechanism. The assumption is that if someone does not have the latest version, it is simply because they simply have never been nudged into upgrading it. The developers doing this think they are making users a favor since they will be upgrading to a version which is faster, safe, but are forgetting that different platforms have different upgrade cycles, and that latest version might not be available just yet.
• Using the wrong loader. This can be caused by copy-pasting flash loader code from other projects or on-line tutorials, without matching the version requirements in the loader with the actual content. In other words - plain sloppiness.

Both of these, however, only go to show that Flash is doing it wrong in the first place, for the following reasons

• The queries should be for *features*, not versions. This important as we will be seeing Flash players with different preferred feature sets. For example, a platform with hardware video acceleration might prefer a different codec to a platform that has no such thing (currently this role is done - again, in a wrong way - by checking for Flash Lite). Not to mention the pipe dream that one day Flash becomes a real Open industry standard with multiple content player plugins, which would obviously have different, partially overlapping feature sets.
• The version requirement should not be a statically coded thing in HTML that is unrelated to the actual content. If there is (any) Flash version available,  the versioning requirement/handshake should be done *inside* Flash.
• If possible, the server should present multiple versions. Sure, Flash 10 has new features, but there is no fallback, meaning there is no systematic way of saying 'hey, give me a Flash 9 version of that content'. As it is now, the server acts as a bouncer, asks 'whatcha got' and the client says 'errr.. 9.0.260 ?' and then the server just says "you're too old for this" and slams the door.

The question in the end thus remains. There is no doubt TweakFlashVer is a super-hacky solution to frankenstein Flash in order to allow users to access the content they want, but the Flash powers that be will have to come up with two solutions before this approach becomes widespread and turns from a hack into a modus operandi of abandoned Flash platforms, like Maemo 5 and 64-bit Linux:

• A system that can address the sloppiness of it's users and their (mis)use of HTML loaders
• Change the upgrade-upgrade-upgrade mantra. Sooner or later the range of devices that will (try to) run Flash will get so wide that a version number will not guarantee anything, and the Open Screen Project changed nothing in that aspect - users of particular platform are still at the mercy of Adobe and/or their vendor if they will get Flash player in a firmware without any guarantee that a sloppy coder won't render their device obsolete in a couple of months.