Thinking in Code » compiler

Flex Roadmap Session

Michel Boudreau — Mon, 25 Oct 2010 23:35:30 +0000

Here at another session with Deepa Subramariam, the product manager for Flex, where she will talk of things they are thinking about and hopefully will carry out in future Flex builds. They are really looking for feedback, so please comment on what’s being said and make yourself heard.

Deepa started the conversation straight away with mentioning that Flex 4.5 (hero) preview was released to the public yesterday night. Go ahead and download/try it now!

In an overview of her presentation, she placed a lot of emphasis on the performance of this new build. This is real good since one of my earlier post mentioned that Flex 4′s performance decreased by about 3 times less than Flex 3. Everyone from now on will be built around performance in mind (she even repeated it 3 times, a la Ballmer).

The new SDK will include both desktop and mobile components in one, and will include touchscreen functionality automatically. It will all be built it and will know which one to target when compiling. This is a real good idea since it increases code reuse without really thinking about it.

She goes on to mention that the Datagrid is also a very big part of the new SDK, but she won’t go too much into it since there’s a talk just about the Datagrid (which I will be attending). But as a quick reminded, performance and a lot of extra features are being added since this will replace both the MX Datagrid and AdvandedDatagrid.

Another feature is the improvement of the RSLs. Essentially, RSLs are no longer just one massive swz, but it will be separated in several smaller swz and your application will only load the RSLs it needs. The RSLs will also be cached so that you don’t have to reload your RSL over and over. This will greatly reduce startup time and load time of your application. Awesome.

Deepa also mentioned that the compiler is also being revamped. The incremental compilation time and memory usage will be reduced by 20%. Good news for people who are big on compiling often.

Another big part of Flex is that Adobe is now changing the development process of the product. They are now going to do a 6 month release calendar for Flex. They are also releasing test units for the Flex code and will let the users submit patches for the SDK after they pass these tests and then be reviewed by the development team. This is great news since now expert Flex developers can send things that they can fix and Adobe will include it in a later build. Great use of the community on this.

She goes on to talk about ‘Enterprise Enablement’. These are enterprise solutions that can be very useful for large application, like a better printing and accessibility support, better internationalization that does automatic language detection and better component extensibility across all components to make it easier to change and reuse the SDK code.

She finishes with saying that they are concentrating hard on speed. Improving not just the components, but the core itself, like the language (which could definitely use a revamp), RPC (including the network layer and full REST) and native Flash Player features that can be leveraged in Flex.

Now introducing Falcon, a brand new compiler made for Flex from scratch to fix a lot of problems that are now there. It also has deep integration with Flash Builder which will make it a lot more like a Java style of coding (live problem displaying, analytic, etc). This is the first talk of it in public and hoping to share this amazingness with us within a year. This will definitely change the landscape of the development cycle and hopefully entice more developers to use Flex.

The next announcement is huge. Adobe is working on Flash Player to include threading, but make it simple enough for people to use without thinking too much about locks. They will offload work to a thread (serialization, calculations, etc) and keep the UI running smooth as silk. It’s about damn time! I’m extremely ecstatic at this announcement since this will be a new era for Flex development. I actually did mention of threading being a problem with Flex in a earlier post (which an Adobe employee mentioned that it actually went around the office when I wrote it). Wow, just wow. Exciting time to be a Flex developer.

That’s all for now folks. There’s a ‘meet the team’ tonight that will listen in on our feedback. If there’s anything you want me to ask, just comment on this post.

Prepping Flash for War

Michel Boudreau — Mon, 22 Mar 2010 15:44:41 +0000

Flash vs Silverlight vs HTML5; a no-holds barred grudge match is brewing in this industry. It will divide developers and companies where there was little contention in the past. I doubt that this will end in a fatality, but the injuries will most likely fall to Adobe because of its current dominance in the field. Each technology has its pros and cons, and multiple providers can co-exist, but companies need a reason to choose one over another. I predict most of the debate will be based around the development process; ease of development, quick prototyping, effectiveness of tools offered, development environments, unit testing, system integration, as well as application design and planning. If a company can make great applications in less time, it means that they can make more money.

I’m a fan of Flash, but like most things in life, it isn’t perfect. Flex and Actionscript have been an integral part of my career and I would like them to continue to be so. I would like to touch on certain concepts that I think would add more value to the current software offerings and in turn give Adobe an edge over the competition.

Time is an important asset for a company, which is why increasing development efficiency will be a key factor in winning this war. I’m talking about reducing the compiler time, making it smarter and bug free, and adding 64bit support to utilise workstation performance. This improvement can save valuable minutes or even hours depending on the developer.

Speaking of development efficiency, I also suggest that Flash Builder starts supporting Linux. Adobe doesn’t even have to officially support it, just make sure the eclipse plug-in can work in a Linux environment with or without design view (I personally never use it). The feature request for having Flash Builder on Linux is one of the most popular requests on the Adobe bug tracker.

Irritations while using Flash products also need to be eliminated. I personally enjoy development work (geek alert!), but when something doesn’t work like expected, it frustrates me to no end. The Flex framework is fairly good at doing exactly that; it’s supposed to save time, and it does, but there are some components that have been buggy ever since its inception and they aren’t being fixed.

The next point is cause for debate between developers, in the end it comes down to preference, but it needs to be addressed. Of course, I’m talking about Cairngorm – or more specifically your decision to support it. I personally don’t think MVC is the pattern to use when handling a Flex application, and other developers in the community agree; hence the creation of several new open- source frameworks. It seems to me that Adobe is playing favorites with Cairngorm and could instead use that development effort in a more productive way. Adobe should work on enhancing the Flash API and opening up doors to allow third party frameworks to improve their usability.

With complex applications come crucial new ways to design the flow and interaction within the system. For that, a developer needs tools to show this visually. Tools like wireframe UI timeline or UML round-trip engineering can combine both design and functionality in a uniform way that all developers can understand. A lot could be learned from Java and their tools: e.g. offering code hot-swapping to greatly reduce debugging time.

If Adobe is serious about creating a developer language, then a more complex language needs to be their goal. Multiple-inheritance, polymorphism, overloading, enumerators, abstract classes, destructors, private constructors, decimal data type, threading support – these are only a few of the things that Actionscript is lacking. Some would argue that there are a lot more. I’m not saying it’s a bad language, after all, it does do what it’s supposed to do, but with bigger systems come more architectural complexities that the current language cannot support.

A common topic when debating Silverlight vs Flex is the lack of multi-threading. I really do hope that this will be implemented in the next iteration of the language because the possibilities it would open would be mind-blowing. Imagine a system that can execute complex algorithms and computations without disrupting the user experience; that would be a major improvement! Heck, even if the language doesn’t give developers access to threads, just allowing the player to run different threads for visual components and for computations would be a great improvement.

Let me leave you with this: I’ve been a fan of Adobe since I was a kid, and I still am. If any business is capable of surmounting the upcoming challenge, it will be Adobe. I believe that the community surrounding this product will be a key factor in this war; if Adobe listens and responds to our suggestions, only great things can happen.

Speaking of community, I invite all developers and designers to debate and comment on this topic. I think it is one that will be talked about for quite some time to come. I’d also like to thank Joe Morrison, a Director at Lab49, for letting me bounce ideas off of him.

Repeater Scope – Flex Silently Failing

Michel Boudreau — Fri, 11 Dec 2009 20:13:41 +0000

This specific problem has been annoying me for a while. I personally don’t like using Repeaters, they aren’t the best way to handle the repetition of a specific element and also, they can cause memory leaks if not used properly. When I do use them, it’s because I’m creating a prototype or in a time crunch.

I use the ‘this’ keyword a good amount in my code. I like it because it differentiates in a quick and effective matter that the current variable being referenced is a class variable and not a function variable. However, if you have the following:

In this example, we have a Repeater using ‘this._repeaterData’, that is repeating a ‘SomeComponent’ component that binds the ‘this._data’ variable. Most of you would think that this works since the variable in your class is available and that the compiler is not giving any errors. However, when you try this example, you will notice that what you set in the ‘this._data’ isn’t binding properly to the component. Why is that?

This would be the work of the Repeater. Flex doesn’t let you know about this flaw, but whatever is within the Repeater tag changes the scope of the ‘this’ keyword. In this case, the ‘this’ keyword points to the Repeater itself and no errors actually occur even though there should be one. You are left debugging this small piece of code for the longest time until you notice that removing the ‘this’ keyword within the Repeater actually fixes this problem. In fact, this bit of code actually works:

It works because of the way Flash looks for variables within a scope (which is another subject altogether). This is a pretty big flaw in the compiler which can cause a lot of grief and hopefully will be fixed in the future.