PDA

View Full Version : Flex Project vs Actionscript Project


ASWC
09-06-2010, 06:58 PM
For the sake of it I was looking myself into using Flex components in Actionscript projects but then it came to me, why would I need Flex components in an Actionscript project anyway?

1. If I want an Actionscript project then I'm looking to get an advantage out of it which should be most likely file size. So using Flex components wouldn't make sense since they would add a lot to the file size anyway.

2. If what I want is writing AS3 code instead of using mxml then better would be to just create a Flex project, then create a manager type of .as class, then in my mxml script tag creationComplete handler I simply pass "this" to my manager class and now I can forget about mxml and work my whole project with actionscript.

So what is your way of handling those situations?

bowljoman
09-06-2010, 09:04 PM
I use these in the case of number 2...


<mx:Script>
<![CDATA[

//CODE

]]>
</mx:Script>




<mx:Script source="file.as"/>




<mx:Script>
<![CDATA[
//some code
include "file.as";

]]>
</mx:Script>



<fx:Script>
<![CDATA[
]]>
</fx:Script>

ASWC
09-06-2010, 09:16 PM
yes of course include/source does the job just fine. I just like to wrap my code into a class while include/source is just part of a class. I like to have a little constructor and package path and so on. ;) Just silly me...

maskedMan
09-07-2010, 12:10 AM
My experience with Flex is limited, but the main reasons I would choose it over straight AS3 :

Meta data, including (maybe even especially) Bindable.

Making the app skinnable a bit more easily.

The opportunity to completely separate gui asset swfs from the code that drives the application. Graphics are often the largest bandwidth hog in a Flash project, so just grabbing all the code first and graphics on demand should theoretically help with people who want a faster load time.

ASWC
09-07-2010, 12:24 AM
yes bindable is cool but expensive. I remember seeing the actionscript code generated for each bindable (like around 20 lines). So using a lot of bindable adds up rapidly in the .swf size.

maskedMan
09-07-2010, 12:30 AM
yes bindable is cool but expensive. I remember seeing the actionscript code generated for each bindable (like around 20 lines). So using a lot of bindable adds up rapidly in the .swf size.

Oh, no doubt about that.

I've also seen mentioned in the haXe mailing list that the Flex Complier will do some silly things like create get/set functions for public variables even if you yourself don't. I'm thinking this is also a side effect of bindable.

bowljoman
09-07-2010, 02:44 AM
yes of course include/source does the job just fine. I just like to wrap my code into a class while include/source is just part of a class. I like to have a little constructor and package path and so on. ;) Just silly me...
Well, yes silly you, I guess.

Then if the mxml component class does not fit in your idea of a class library, then you would override function set data, and use your key class there, or add additional vars as needed for specific types. I prefer to have a pure as3 lib when possible, but if flex is required in the app, I create the mxml component renderer.

Its really not too difficult to integrate packages and components.

If your class requires an fx of mx component base class, use some mxml where appropriate.

drkstr
09-19-2010, 01:31 AM
The advantage to Flex is development speed. If you have heavy performance or file size requirements then best to stick with a purse AS3 project (no Flex components).

If however you recognize that for most purposes, a small degradation in performance is negligible for 95% of end users, then you may begin to love Flex, and even the "cursed" MXML.


You could certainly use purse AS3 in a Flex project (minus the top level Application tag). However, I encourage you to play around with MXML a bit more. You may find it to be a huge time saver for defining displays. This is even more so with the new Flex 4 spark skinning concept.

Of course, when it comes to application control nothing beets good ol' fashion AS. For those purposes, use the same tried and true methods you're used to. The key is finding what MXML is better at than AS, and finding a good balance between the two.

Personally, I gag whenever I have to define display layout using AS...

ASWC
09-19-2010, 04:52 AM
The advantage to Flex is development speed. If you have heavy performance or file size requirements then best to stick with a purse AS3 project (no Flex components).

If however you recognize that for most purposes, a small degradation in performance is negligible for 95% of end users, then you may begin to love Flex, and even the "cursed" MXML.


You could certainly use purse AS3 in a Flex project (minus the top level Application tag). However, I encourage you to play around with MXML a bit more. You may find it to be a huge time saver for defining displays. This is even more so with the new Flex 4 spark skinning concept.

Of course, when it comes to application control nothing beets good ol' fashion AS. For those purposes, use the same tried and true methods you're used to. The key is finding what MXML is better at than AS, and finding a good balance between the two.

Personally, I gag whenever I have to define display layout using AS...
I totally get what you say and agree. I understand that laying out components/elements is easier with mxml and I'm going there. Still I like to keep my logic in pure actionscript code, but just the logic. I'll give a try to pretty much everything in mxml anyway but for example implementing in mxml the system of tween, transition, sequences and so on between states seems to me rather confusing and hard to read (if it gets pretty complex of course). I can imagine myself going back to a project after a few month and get stuck trying to understand the whole transition system between states that I created in mxml.