RIM on Adobe Abandoning Mobile Flash

Adobe announced today that they're stopping development of their mobile Flash player as soon as they release Flash Player 11.1 for Android and BlackBerry Playbook. Both of which are mobile devices, but don't run the mobile flash player.

Hopefully an OS update isn't required for those devices to get the new version of Flash Player, otherwise the majority of Android users are screwed. The PlayBook is currently running Flash 10.2.

A few hours later RIM posted a trademark-filled statement on their blog:

Earlier today, Adobe announced plans to stop investing in Flash® for mobile browsing, and focus more efforts on HTML5. As an Adobe source code licensee, we will continue to work on and release our own implementations, and are looking forward to including Flash 11.1 for the BlackBerry PlayBook.

The strategic direction announced by Adobe today further validates RIM’s decision to launch the BlackBerry PlayBook with a full-powered and uncompromised desktop class browser supporting both Flash and HTML5. We are pleased that Adobe will focus its efforts on next generation Flash-based apps delivered via AIR and BlackBerry AppWorld as well as the great opportunities that HTML5 presents for our developers as we discussed at DevCon Americas.

In essence they're saying:

Adobe just blindsided us with that announcement and even though we pay them an outrageous licensing fee for access to their source code, we don't have a copy of this mythical Flash 11.1 to test on the PlayBook. Luckily we support HTML 5, because we're probably going to be dicked-over by Adobe again in the near future.

I wonder how long until RIM changes direction again and begins to downplay the PlayBook's Flash support?

Wishlist for the ColdFusion Advisory Committee

I only recently learned about the CFML Advisory Committee, but I was impressed that such a thing would even exist. I suppose with two open source CFML engines (Open BlueDragon and Railo) it was only a matter of time, but without buy-in from Adobe the utility of such an organization is seriously limited. Fortunately Adobe has bought in and has members on the committee.

I'm not sure what percentage of my time I spend working with ColdFusion, but whenever I do I always run into arbitrary limitations or inconsistencies that are incredibly obnoxious. It gives ColdFusion the feeling of a language that was started by one group of people, picked up half-finished by another group with many features are implemented very shallowly in order to meet a ship date. And all too often Adobe never looks back to address those flaws. Hopefully the CFML Advisory Committee will address these flaws.

A great example blatantly rushing a feature is the implicit creation of structs and arrays. With the initial release of ColdFusion 8.0 you could use { } and [ ] notation to create both inside of a CFSCRIPT block, but you couldn't nest them until the release of ColdFusion 8.0.1

<cfscript>
// This only works in Adobe ColdFusion 8.0.1+
someStruct = {
 key1 = {
  subKey1 = 'xyz'
 }
};
</cfscript>

I'm hesitant to email my entire wishlist the Committee as Sean suggested, but I did want to write it out and solicit some feedback. Some of these are specific to Adobe ColdFusion (such as var declaration positions), and there is the possibility that some of the issues are fixed or under consideration to be fixed in the upcoming release of CF 9 Centaur.

ColdFusion/CFML Wishlist (or gripes)

  • Consistency between cfscript, cfml functions. cfquery, cfdump, and all of the other functions missing from CFSCRIPT
  • Allow var declarations anywhere (Note: Supported in OpenBD)
  • Fully document CFQUERYPARAM type mapping (cf_sqltype_* to actual SQL type)
  • Fully document the SQL commands/functions available for CFQUERY Query-of-Queries
  • Ordered structs – I can't think of a good reason not to preserve the order of items.
  • Implicit creation of structs with case sensitive names and names containing spaces
    <cfscript>
    struct = {
     'one key' = 'abc',
     'mixedCase' = 'def'
    };
    </cfscript>
  • Support a more standard struct declaration format.
    <cfscript>
    struct = {
    	key: 'val',
    	orKey =&gt; 'val'
    };
    </cfscript>
  • Pass implicitly created objects as function arguments.
  • Allow [] notation to append to arrays.
    <cfscript>
    someArr = [ 'one, 'two', 'three' ];
    someArr[] = 'four';
    // someArr is now [ 'one, 'two', 'three', 'four' ]
    </cfscript>
  • NO WHITESPACE RESIDUE FROM ANY CFML CODE – Seriously, don't leave a mess when you're parsing. Every byte counts.
  • Defined way to pass any variable by reference
  • Allow optional args and default values in cfscript function declarations
  • True eval() function. I want to be able to dynamically parse code. DE and EVALUATE are about as healthy as cigarettes.
  • Public/private key encryption added to cfencrypt w/o needing Bouncy Castle. OK, this one is probably just for me :)
  • Zero-based arrays. I bet people that like 1-based arrays also hang their toilet paper under instead of over. Savages.
  • A better way to handle caching, such as named caches so that you can expire individual caches easier if/when they need to change. (Note: Supported in OpenBD and Railo)
  • Dynamic function calls. Also check out the PHP call_user_func_array function.
    <cfscript>
    function printPrefix(str) {
    	writeoutput("PREFIX: #str#\n");
    }
    func = "printPrefix";
    #func#("test");
    // Outputs:
    //  PREFIX:TEST
    </cfscript>
  • Ternary operator. WTF? Anyone who is thinking about suggesting IIF should stop right now. IIF doesn't even come close to being true ternary operator.
  • Improved For-In loops – Loop through structs with keys/values, like foreach in PHP
    <cfscript>
    for( key =&gt; val IN someStruct ) {
    	writeoutput("someStruct[#key#] = #val#\n");
    }
    </cfscript>
  • StructValueArray – Return an array of all the values from a struct (just as StructKeyArray returns an array of all the keys). (Note: Matt has requested this for OpenBD.)

In a perfect world things like zero-based array indexes and ordered structs could be set at the application level to maintain backwards compatibility, but I'd even settle for server-wide.

Leave a comment if I'm missing compatibility for one of the CFML engines and I'll update the post accordingly.


© 2007-2012, Corey Gilmore | Posts RSS Feed | Comments RSS Feed | Contact

 

The views expressed on these pages are mine alone and not those of any past or present employer. All information presented on this site was obtained lawfully and not through disclosure under the terms of an NDA.