RC Flex 4.5 Hits and Misses – Part 2

In the previous post I mentioned that Farata developed View-based application running from exactly the same code in the desktop, web and mobile. Does it mean that we take portability above all? Not at all. We are simply pragmatic. And from the same point of view let me disagree with the portability when it stay in the way of the functionality.

Here my background story for that. Back in 90s, when PowerBuilder and VisualBasic ruled application development, not a single VB or PB application was “pure” one (ie written only in that language/VM) – they all utilized native C code packaged as DLLs or VBX. Today, AIR provides great UI engine, but all universe of capabilities – quality camera, audio, telephony, notifications, great 3rd party native libraries are out of reach. If I do not use them for the sake of portability – I will loose to applications written for particular platform. During my demo I saw peopled wowed when AIR boundaries disappeared and Android based voice recognition did data entry for the Desktop application. Yes, I know that this will force me to pack the iOS version with the different extensions (when iOS support for Flex comes along in June). I am also waiting on C extensibility toolkit from RIM in May.

So, how does Adobe position itself in reference to integration with the native tools? Air application can be “invoked” from the native Android code, but not the other way around. The only integration approach is mentioned by James Ward, but it is not a part of the RC for Flex 4.5. The availability of Extensibility Toolkit based on that approach promissed, but no date was given. I think support of integration is a matter of survival. The same goes for “remoting” within personal network boundaries? Not supported either. I think it is another gap that Adobe has to fill.

Anatole Tartakovsky

5 thoughts on “RC Flex 4.5 Hits and Misses – Part 2

  1. I think there were lots of opportunities Adobe missed, lost or hasn’t foreseen down the road. Just a small part of them:
    – there should had been a way to export into native code from AIR as a second option
    – completing above case, Air package should have been extended additionally to support multi-threading, directx and opengl
    – if they are reluctant to provide an improve version of AS 3 (enums, lists, generics, hello?), then allow other languages in flex/air development – and I am not implying Javascript here
    – there should had been a way to export into html/js. I mean come on, lots of Java tools allow java to html/js. I am not saying it would be easy, but it’s Adobe we are talking about

    In my opinion Adobe is fighting a lost battle. Don’t need to convince or offend anybody and you can just totally ignore what I am trying to say here. I used Flex since it’s V1 Alpha 1 and Flash years before it and jeez, I missed it so much sometimes. But from a big head start Adobe had buying Macromedia with its flash/flex tools, they are now on the last wagon and even worse, they stay in denial.
    They have been always slow on developer requests and new features, it took years sometimes to fix some critical bugs. Sometimes it was more of a battle between developers and Adobe than a mutual understanding :-) And since there are similar issues for any company offering development tools, what Adobe needed to keep was the innovation, excitement and interest with new versions.

    But it simply didn’t happen. Where is opengl support in Air for Android??? We had to ditch a framework here we were investing and developing for 2 years (on flex and air) just because air for android was/is/will be buggy, slow, limited and frankly – annoying and pointless. If you can’t make it happen – then just export into native code. What, is it so hard? So ask Unity3d or Appcelerator then.

    For mobile development especially, with webgl and new browsers coming with better and faster rendering and javascript engines and ECMAScript 5 as a Javascript successor (thanks God) – I have my own doubts anything will be changed.

    You may say, wait, It’s easy to bitch about, why don’t you do something? My answer is: “Do I care if Adobe keep screwing things up?”

    Flex is a great product and its mxml engine is superior but again, Adobe needed (or may need in future) to offer at least an option to export in native code (for air) and into html/js (for web) since clearly there are obvious problems with flash player and air engines – this may change the tides.

    Poeple DON’T want plugins. Is it so hard to get it? Take a look at Firefox for example. I actually needed to install a Flash block extension to stop loading any swfs when browsing pages. And since it’s not Flash Player engine at all but sloppy developer code all over the place in all these annoying flash ads and even worse Plugin Container of Mozilla – no one blames Mozilla but “Flash” (as our designers and testers call anything which renders swfs :)

    And as much I would say Delphi and PowerBuilder were top-notch products back then, although I still miss them, I will never use them again. So better Adobe do something drastic or many developers will remember and miss, but not using Flex 15 years from now.

    Anyway, didn’t want to offend anyone – just my thoughts having my coffee before jumping on java and android.

    Dimitar G.

  2. Dimitar,

    Adobe has their issues, but converting the byte code into a native version doesn’t have to be done by them. Since you’re from Java camp, you might know about the company called Excelsior that created a converter from Java to exe. This was not done by Sun Microsystems.
    Yes, Adobe is slow, but for now they are the only company that offers a complete solution for the cross-platform development of the rich UI. But I get a feeling that Adobe is turning toward HTML 5.

    Because of the stupid and stubborn pricing policy with LCDS, Adobe will soon will lose their market share in the networking layer to WebSockets (the only concrete artifact from the HTML5 offering so far). Adobe lives in a dream world where software can be sold $100K+ a piece. The rest of the world is learning how to become profitable selling software for $1.99, $9.99, $19.99 or similar price ranges.

  3. Dimitar,
    I have seen environments similar to flex allowing native code generation, etc. – it had limited impact – please recall impact of PowerBuilder buying and wasting 3 years on Watcom C++ code generation at the time when they had to build on new Internet platform. The same here – we moving from mouse desktop platform to touch/human interfaces and it is not a time for cleaning up small pieces – it is time to allow wider integration with new platform – otherwise moronic html/js will hold as the only common denominator for mobile platform.
    1. Adobe has to provide the same code running across desktop and mobile or become niche product like Delphi or PB.
    2. They have to provide bridge to native platform that is simple and transparent
    3. Nothing else matters much

  4. @Yakov
    There are always other options but since Adobe wants to (and does) execute quite a control over their runtime engines (air and flash player), they should offer their own abc to native code. And by native code export – not a mere transition to whatever they have as of now, but extended native support, emphasizing on multithreading and full gpu rendering. If they could achieve all this in their runtime engines, good but obviously they are struggling providing that. Yes, Molehill is on its way but as I mentioned, from a clear leader flex/flash is now on the last wagon. They needed to provided this last year, not somewhere at the end of this year.

    And reading in some Adobe posts how hard multi-threading support will be for air and flash player and all this – many developers don’t see such info as valid points but excuses (or lack of any will) to deliver such no matter what.

    To achieve any of these goals, Adobe may need to expand their language support. Clearly AS core developers are a drop in the bucket alongside endless Java, .NET and script-alike developers. .NET for example is quite a complicated framework.engine/tools and can bring quite a pain sometime just wrapping your head around it. But because of the extended language support it has an ever-growing expansion. Not a big leap but still.
    Actionscript is not that popular and for Adobe to provide a well-rounded and complete solution may need other language support too.

    Of course any of these points may be not valid from other people’s point of view but just because of all these mentioned I for example HAD to switch myself from Flex and as3 to Java (although I am not that happy or proud of this). I just blame Adobe :-)

  5. Dimitar,
    I am not sure the language matters that much. What matters is the ability to coexist in the eco system of the target environment. I am coding mostly within OSX and target mostly windows (client /flex), linux (servers/Java/Frameworks) and mobile platforms(Flash/Native/????). It only matters in iOS world and I would probably take a 2 man month project to integrate compiled Flash apps in the natve apps with complete access to iOS SDK/provide integration layer for corporate apps that do not need iStore for distribution.

    Crossplatform and microprocessors are inevitable. Adobe has upper hand in it (over fragmented Java or disparate c kernels or ARM frameworks) as long as they provide modular approach and ability to integrate with native platform.

    I expect first release of cross tools not from Adobe but from RIM – we will see what they have to offer in May once SDK is out. If acceptance and success are observable Adobe will follow. It is sad so that success will depend on very late and somewhat skewed device and non-existing community over real ones.


Comments are closed.