Tuesday, July 31, 2007
Eclipse 3.3: New and Improved
source :here
The highlights are:
* Label coloring for Java elements (enable it in Java > Appearance).
* Quick Access (Ctrl+3) for navigating around to a view or preference page.
* Triple click on a line to select the complete line, drag and drop text. This is very handy when using the mouse, but I am not using the mouse that often in Eclipse though.
* The new Java 6 debugging features rock. Introspecting references is really handy when trying to analyze memory leaks or weird object interactions.
* The Plug-in Development Environment is a lot more advanced. Code completion has become something people expect in Eclipse (it's everywhere), and the new user interface looks very nice.
* Specialized downloads for new users. This makes it a lot easier to try out the new Web Tools or C++ development environment. Just download and unzip, and you are good to go.
* No more mucking around in eclipse.ini to prevent perm space memory errors on Sun JVMs. This is now done automatically on Windows.
* Improved maximizing and minimizing (tiling editors is preserved when maximized) improves reduces the amount of useless whitespace.
The highlights are:
* Label coloring for Java elements (enable it in Java > Appearance).
* Quick Access (Ctrl+3) for navigating around to a view or preference page.
* Triple click on a line to select the complete line, drag and drop text. This is very handy when using the mouse, but I am not using the mouse that often in Eclipse though.
* The new Java 6 debugging features rock. Introspecting references is really handy when trying to analyze memory leaks or weird object interactions.
* The Plug-in Development Environment is a lot more advanced. Code completion has become something people expect in Eclipse (it's everywhere), and the new user interface looks very nice.
* Specialized downloads for new users. This makes it a lot easier to try out the new Web Tools or C++ development environment. Just download and unzip, and you are good to go.
* No more mucking around in eclipse.ini to prevent perm space memory errors on Sun JVMs. This is now done automatically on Windows.
* Improved maximizing and minimizing (tiling editors is preserved when maximized) improves reduces the amount of useless whitespace.
Monday, July 30, 2007
Embedding fonts in Flash CS3/AS3
source:http://maohao.wordpress.com/2007/07/29/embedding-fonts-in-flash-cs3as3/
package
{
import flash.display.Sprite;
import flash.text.TextField;import flash.text.Font;
import flash.utils.getDefinitionByName;public class SimpleTextPaneTestDrive01 extends Sprite
{
private static var embeddedFont:Font = null;
public function SimpleTextPaneTestDrive01()
{
var embeddedFontClass:Class = getDefinitionByName(”Font1″) as Class;
Font.registerFont(embeddedFontClass);
var embeddedFontsArray:Array = Font.enumerateFonts(false);
embeddedFont = embeddedFontsArray[0];var fmt:TextFormat = new TextFormat();
//fmt.bold = true;
fmt.color =0xffffff;
fmt.size = 16;//Old day fashion: If you embed it in a textfield on stage
// fmt.font = “Helvetica”;
fmt.font = embeddedFont.fontName;
var tf:TextField = new TextField();
tf.text = “hello world!”;
tf.setTextFormat(fmt);
}
}
}
package
{
import flash.display.Sprite;
import flash.text.TextField;import flash.text.Font;
import flash.utils.getDefinitionByName;public class SimpleTextPaneTestDrive01 extends Sprite
{
private static var embeddedFont:Font = null;
public function SimpleTextPaneTestDrive01()
{
var embeddedFontClass:Class = getDefinitionByName(”Font1″) as Class;
Font.registerFont(embeddedFontClass);
var embeddedFontsArray:Array = Font.enumerateFonts(false);
embeddedFont = embeddedFontsArray[0];var fmt:TextFormat = new TextFormat();
//fmt.bold = true;
fmt.color =0xffffff;
fmt.size = 16;//Old day fashion: If you embed it in a textfield on stage
// fmt.font = “Helvetica”;
fmt.font = embeddedFont.fontName;
var tf:TextField = new TextField();
tf.text = “hello world!”;
tf.setTextFormat(fmt);
}
}
}
Sunday, July 29, 2007
Saturday, July 28, 2007
composition vs inheritance for Sprite and MovieClip
source
composition vs inheritance for Sprite and MovieClip
a reader recently wrote me with some questions he posted to a newsgroup about inheriting from Sprite in ActionScript 3.0 vs inheriting from MovieClip in ActionScript 2.0. it's an important topic, so i figured i'd post the exchange here, starting with the reader's newsgroup posting:
====
I have been until now a fervent disciple of compositing a graphic instance into a class in every case, rather than making my class extend MovieClip. Admittedly I was a piker at AS2 and only now that I am cranking on AS3 do I consider myself worthy to call myself a beginner OOP programmer. But I bought into all the reasons, and if I were still making AS2 apps, I might remain in that camp.
But lately my devotion has been shaken and now I am seriously considering extending (and then subclassing from) MovieClip or Sprite when making any class which has a visual component. Whereas before I would always compose in a MC instance, almost never make my class inherit from anything but my own superclass, and implement interfaces for polymorphism, now I think I will extend, although still implement interfaces for the usual other reasons. I also still plan to be a composition devotee in all other ways-- I like composition more than inheritance. Also I would not extend MC for classes which have no graphical component, such as game logic components. (I am making games and other interactive entertainment apps, for in-browser distribution.)
Here are a few reasons why my mind is changing; please feel free to refute or support any of these:
--Changes between AS2 and AS3 make the downside of subclassing MC/Sprite smaller than before. I'll let far more informed people come up with good examples, but one seems to be the explicit nature of adding an object to the display list-- the overhead hit of being an MC is small (nonexistent?) if it is not on the list.
"Essential ActionScript 2" advocates composition-- see the large MVC example in which a view class, although nearly entirely visual in function, did not extend MC but rather composited MC. However, in Moock's equally impressive AS3 book, all his examples now seem to use extension. This gives me a new perspective.
--All the Adobe best practices and examples use extension, as do nearly all code samples I see in other helpful forums. I am not one to blindly run with the crowd but I think I'd get better feedback on my code from my peers if I follow suit.
--All the AS3 Flash components seem to use extension, and indeed, AS3 itself is heavily inheritance-based rather than composition-based, for understandable reasons.
I am probably missing a lot and mis-stating much of what is there but hopefully you get the idea.
So once again I ask my better peers: what are now the arguments for and against extending MC or Sprite for one's visually represented classes in AS3? Any observations would be much appreciated.
Also, in Essential ActionScript 2.0 there is an extensive example of the MVC pattern involving, what else, a clock. In his code his Clock view does *not* extend MovieClip (Sprite not having been available in AS2), which is in keeping with his general admonition to compose a graphic element into a class rather than extend one. His view's constructor takes an MC as an argument, and the view attaches its MC instance (which contains all the clock visuals) to the passed MC. The view object is not itself attached, because it is not an MC. The view class contains an MC which ends up getting attached. To change the XY of the view would be to ask the view to change its MC instance's XY. Pure composition.
In Essential ActionScript 3.0 there's an extensive "Virtual Zoo" example which among other things uses an MVC-ish structure, in which the view and controller are the same class. If anything, this would make composing in the view's root graphic element even more sensible than his AS2 example. The View does not really fit the definition "is-a Sprite"; it also is a view manager and controller. But, contrary to his AS2 stance and in keeping with all the other examples in his AS3 book, Moock's view class *extends* Sprite, and is added as a child by the main class. Though the view does happen to contain objects which are also made from Sprite-extending classes (pictures of the zoo animal and the like), the view class does not contain its root sprite the way the AS2 example contained its root MC. The view *is* a Sprite. To change the XY of the view would be to simply set its inherited XY properties from the outside, as any Sprite would be positioned. So though Moock still is a devotee of composition in every other way, on this one point he seems to have decided to use inheritance and take a path different from his AS2 book.
And I have seen most other AS3 code examples follow suit. The Lott AS3 book does, and all the Adobe examples do. So forgive me for having my faith shaken a wee bit.
Though I remain convinced of the rule to favour composition, in this particular set of cases I am considering routinely using inheritance, even though I easily *could* use composition. It just seems to be messier, denser, and longer to use composition *in this set of cases*. So is my reasoning good, faulty, or does it simply betray deep cluelessness about OOP?
====
hi matthew,
as with all design choices in programming, the question of composition vs inheritance comes down to a cost/benefit analysis. in ActionScript 2.0, the only way you could create a logical "type" of display asset was to subclass MovieClip. the cost of implementing MovieClip subclasses was quite high because:
-you had to link a class to a particular .fla
-you had to use arcane syntaxt to create objects (attachMovie())
-the initialization process was messy (no constructor arguments)
i preferred composition over inheritance for MovieClip objects in ActionScript 2.0 partly because the cost of implementing inheritance was so high. the composition alternative sheltered users of my code from those costs.
in ActionScript 3.0, the system for creating a logical "type" of display asset is much cleaner. you simply extend Sprite, and use the subclass like any other class in your program. there's no need to link your class to a movie clip symbol in a .fla (though that's still possible), and you can use normal "new" syntax to create instances, complete with constructor arguments.
so in ActionScript 3.0, the composition approach actually has a higher cost than the inheritance approach because composition requires more code. hence, the cost/benefit question in ActionScript 3.0 is: are the benefits of composition worth the extra code? recall that the benefits of composition are: 1) a more logical class hierarchy, and 2) the ability to extend a logically appropriate class while still using the composed class's functionality.
in simple programs, such as the VirtualZoo, I think composition can be overkill, particularly in the case of the Sprite class. in fact, I would argue that the VirtualPetView can legitimately be thought of as a specialized type of Sprite. conceptually, what is a Sprite? it's a displayable graphic that supports interactivity. what is a VirtualPetView? it's a specific graphic (a pet) that supports a specific type of interactivity (feeding). in other words, VirtualPetView is a specialized type of Sprite, much as a Automobile is a specialized type of Vehicle.
now let's turn to the question of separating the controller from the view in the virtual zoo program. as you point out, VirtualPetView contains both the controller and the view. does that make sense? is the VirtualPetView class becoming bloated and difficult to read? probably a little. if the pet had more interactivity (grooming the pet, teaching it tricks, etc), I think it would be wise to separate input from display. in fact, i even wanted to write a chapter showing the benefits of full mvc by breaking the VirtualPetView into two classes. but at 900 pages and 2 years of writing, a full discussion of mvc was one of the things that got cut from the book.
nevertheless, it's perfectly natural to start with a class that combines the controller and the view, and then later refactor the class to separate the controller from the view. again, for a small program, combining the controller and the view into a single class is less work. as i often say, if the program runs and does what you want it's "right". later, if the program scope increases, you can pay the cost of writing a little more code in exchange for the benefits of greater flexibility and readability.
there are no right answers with this stuff. you have to decide what makes sense for your program. the fact that you are asking these questions means that you are programming the "right" way.
thanks for the interesting question!
colin
Posted by moock at July 28, 2007 08:53 PM
composition vs inheritance for Sprite and MovieClip
a reader recently wrote me with some questions he posted to a newsgroup about inheriting from Sprite in ActionScript 3.0 vs inheriting from MovieClip in ActionScript 2.0. it's an important topic, so i figured i'd post the exchange here, starting with the reader's newsgroup posting:
====
I have been until now a fervent disciple of compositing a graphic instance into a class in every case, rather than making my class extend MovieClip. Admittedly I was a piker at AS2 and only now that I am cranking on AS3 do I consider myself worthy to call myself a beginner OOP programmer. But I bought into all the reasons, and if I were still making AS2 apps, I might remain in that camp.
But lately my devotion has been shaken and now I am seriously considering extending (and then subclassing from) MovieClip or Sprite when making any class which has a visual component. Whereas before I would always compose in a MC instance, almost never make my class inherit from anything but my own superclass, and implement interfaces for polymorphism, now I think I will extend, although still implement interfaces for the usual other reasons. I also still plan to be a composition devotee in all other ways-- I like composition more than inheritance. Also I would not extend MC for classes which have no graphical component, such as game logic components. (I am making games and other interactive entertainment apps, for in-browser distribution.)
Here are a few reasons why my mind is changing; please feel free to refute or support any of these:
--Changes between AS2 and AS3 make the downside of subclassing MC/Sprite smaller than before. I'll let far more informed people come up with good examples, but one seems to be the explicit nature of adding an object to the display list-- the overhead hit of being an MC is small (nonexistent?) if it is not on the list.
"Essential ActionScript 2" advocates composition-- see the large MVC example in which a view class, although nearly entirely visual in function, did not extend MC but rather composited MC. However, in Moock's equally impressive AS3 book, all his examples now seem to use extension. This gives me a new perspective.
--All the Adobe best practices and examples use extension, as do nearly all code samples I see in other helpful forums. I am not one to blindly run with the crowd but I think I'd get better feedback on my code from my peers if I follow suit.
--All the AS3 Flash components seem to use extension, and indeed, AS3 itself is heavily inheritance-based rather than composition-based, for understandable reasons.
I am probably missing a lot and mis-stating much of what is there but hopefully you get the idea.
So once again I ask my better peers: what are now the arguments for and against extending MC or Sprite for one's visually represented classes in AS3? Any observations would be much appreciated.
Also, in Essential ActionScript 2.0 there is an extensive example of the MVC pattern involving, what else, a clock. In his code his Clock view does *not* extend MovieClip (Sprite not having been available in AS2), which is in keeping with his general admonition to compose a graphic element into a class rather than extend one. His view's constructor takes an MC as an argument, and the view attaches its MC instance (which contains all the clock visuals) to the passed MC. The view object is not itself attached, because it is not an MC. The view class contains an MC which ends up getting attached. To change the XY of the view would be to ask the view to change its MC instance's XY. Pure composition.
In Essential ActionScript 3.0 there's an extensive "Virtual Zoo" example which among other things uses an MVC-ish structure, in which the view and controller are the same class. If anything, this would make composing in the view's root graphic element even more sensible than his AS2 example. The View does not really fit the definition "is-a Sprite"; it also is a view manager and controller. But, contrary to his AS2 stance and in keeping with all the other examples in his AS3 book, Moock's view class *extends* Sprite, and is added as a child by the main class. Though the view does happen to contain objects which are also made from Sprite-extending classes (pictures of the zoo animal and the like), the view class does not contain its root sprite the way the AS2 example contained its root MC. The view *is* a Sprite. To change the XY of the view would be to simply set its inherited XY properties from the outside, as any Sprite would be positioned. So though Moock still is a devotee of composition in every other way, on this one point he seems to have decided to use inheritance and take a path different from his AS2 book.
And I have seen most other AS3 code examples follow suit. The Lott AS3 book does, and all the Adobe examples do. So forgive me for having my faith shaken a wee bit.
Though I remain convinced of the rule to favour composition, in this particular set of cases I am considering routinely using inheritance, even though I easily *could* use composition. It just seems to be messier, denser, and longer to use composition *in this set of cases*. So is my reasoning good, faulty, or does it simply betray deep cluelessness about OOP?
====
hi matthew,
as with all design choices in programming, the question of composition vs inheritance comes down to a cost/benefit analysis. in ActionScript 2.0, the only way you could create a logical "type" of display asset was to subclass MovieClip. the cost of implementing MovieClip subclasses was quite high because:
-you had to link a class to a particular .fla
-you had to use arcane syntaxt to create objects (attachMovie())
-the initialization process was messy (no constructor arguments)
i preferred composition over inheritance for MovieClip objects in ActionScript 2.0 partly because the cost of implementing inheritance was so high. the composition alternative sheltered users of my code from those costs.
in ActionScript 3.0, the system for creating a logical "type" of display asset is much cleaner. you simply extend Sprite, and use the subclass like any other class in your program. there's no need to link your class to a movie clip symbol in a .fla (though that's still possible), and you can use normal "new" syntax to create instances, complete with constructor arguments.
so in ActionScript 3.0, the composition approach actually has a higher cost than the inheritance approach because composition requires more code. hence, the cost/benefit question in ActionScript 3.0 is: are the benefits of composition worth the extra code? recall that the benefits of composition are: 1) a more logical class hierarchy, and 2) the ability to extend a logically appropriate class while still using the composed class's functionality.
in simple programs, such as the VirtualZoo, I think composition can be overkill, particularly in the case of the Sprite class. in fact, I would argue that the VirtualPetView can legitimately be thought of as a specialized type of Sprite. conceptually, what is a Sprite? it's a displayable graphic that supports interactivity. what is a VirtualPetView? it's a specific graphic (a pet) that supports a specific type of interactivity (feeding). in other words, VirtualPetView is a specialized type of Sprite, much as a Automobile is a specialized type of Vehicle.
now let's turn to the question of separating the controller from the view in the virtual zoo program. as you point out, VirtualPetView contains both the controller and the view. does that make sense? is the VirtualPetView class becoming bloated and difficult to read? probably a little. if the pet had more interactivity (grooming the pet, teaching it tricks, etc), I think it would be wise to separate input from display. in fact, i even wanted to write a chapter showing the benefits of full mvc by breaking the VirtualPetView into two classes. but at 900 pages and 2 years of writing, a full discussion of mvc was one of the things that got cut from the book.
nevertheless, it's perfectly natural to start with a class that combines the controller and the view, and then later refactor the class to separate the controller from the view. again, for a small program, combining the controller and the view into a single class is less work. as i often say, if the program runs and does what you want it's "right". later, if the program scope increases, you can pay the cost of writing a little more code in exchange for the benefits of greater flexibility and readability.
there are no right answers with this stuff. you have to decide what makes sense for your program. the fact that you are asking these questions means that you are programming the "right" way.
thanks for the interesting question!
colin
Posted by moock at July 28, 2007 08:53 PM
Loading name/value pairs using the mx:HTTPService tag
original author : Peter deHaan
source: Peter deHaan's blog
== quote from his blog ==
Again, I’m sure there is a nicer way of handling the ResultEvent and converting to a data provider, so you may want to play around with it a bit.
Of course, if you know the names of the parameters in the file that you’re loading, you could also just do something like this:
Oh, and remember, since the params.txt file is being loaded at run-time and embedded during compile-time, the params.txt file needs to be relative to the SWF file and not the MXML file.
source: Peter deHaan's blog
== quote from his blog ==
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="horizontal" verticalAlign="middle" backgroundColor="white" creationComplete="httpParams.send()">
<mx:HTTPService resultFormat="flashvars" url="{VARIABLES_URL}" id="httpParams" result="onResult(event)" />
<mx:Script>
<![CDATA[
import mx.rpc.events.ResultEvent;
import mx.collections.ArrayCollection;
[Bindable]
private var VARIABLES_URL:String = "params.txt";
[Bindable]
private var paramColl:ArrayCollection = new ArrayCollection();
private function onResult(evt:ResultEvent):void {
var vars:Object = evt.result;
var key:String;
for (key in vars) {
paramColl.addItem({key:key, value:vars[key]});
}
params.visible = true;
}
]]>
</mx:Script>
<mx:VBox>
<mx:Label text="Parameters:" />
<mx:DataGrid id="params" dataProvider="{paramColl}" rowCount="5" visible="false">
<mx:columns>
<mx:DataGridColumn dataField="key" headerText="Key" />
<mx:DataGridColumn dataField="value" headerText="Value" />
</mx:columns>
</mx:DataGrid>
</mx:VBox>
</mx:Application>
Again, I’m sure there is a nicer way of handling the ResultEvent and converting to a data provider, so you may want to play around with it a bit.
Of course, if you know the names of the parameters in the file that you’re loading, you could also just do something like this:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" verticalAlign="middle" backgroundColor="white" creationComplete="httpService.send()">
<mx:HTTPService id="httpService" resultFormat="flashvars" url="params.txt" />
<mx:VBox>
<mx:Label text="name: {httpService.lastResult.name}" />
<mx:Label text="product: {httpService.lastResult.product}" />
<mx:Label text="powermove: {httpService.lastResult.powermove}" />
<mx:Label text="skill: {httpService.lastResult.skill}" />
</mx:VBox>
</mx:Application>
Oh, and remember, since the params.txt file is being loaded at run-time and embedded during compile-time, the params.txt file needs to be relative to the SWF file and not the MXML file.
Subscribe to:
Comments (Atom)