July 31, 2003

Unity 2 Contest

Come one, come all! Win a copy of Unity 2!

1st Prize
A Single-Domain Unity Professional Licence

Goes To:
The first developer that posts a live demonstration of a Unity 2 Beta application that includes client registration and attribute persistence using the supplied Unity MySQL implementation.


2nd Prize
A Single-Domain Unity Express Licence

Goes To:
The first developer that posts a live, working version of the supplied example Unity application "uSimpleChat v4 with Client Login". The example app is located in the uClient2.0.0_b1.zip file, in the folder /uClient/uSimpleChatMX/clientlogin. Note that you don't have to do any development work to make the app run, you just have to install Unity, set up attribute persistence (as described in the new server docs), and run the client app on a live site. To see the app in action on moock.org, visit:
http://moock.org/unity/clients/uSimpleChat/clientlogin/


3rd Prize
One of three Single-Domain Unity Express Licences

Goes To:
The first three developers that post a live, working version of the uMiniChat application seen in action here:
http://moock.org/unity/uchat/
The uMiniChat app must be posted on the homepage of an existing site, and must be customized in at least two ways (e.g., colors, fonts) via the uChatMiniSettings.xml file. The uMiniChat app is located in the uClient2.0.0_b1.zip file, in the folder /uClient/uChatMini.

Additional Rules:
1) To submit your entry, email your application's URL to unity@moock.org.
2) Contestants are eligible to win one prize only.
3) The winning applications must be hosted for the entire Unity 2 beta period. Prizes will be delivered after the beta period ends. If the winning application is offline for more than 1 consecutive 48 hour period during the beta period, the prize is forfeit (unless that offline period is the direct result of a technical problem caused by Unity 2 Beta 1).

More information:
To get started, visit http://moock.org/unity/harmony
That page will provide you with the downloads and documentation you need to participate in the contest.

Good luck everyone!!

Posted by moock at 10:01 AM | Comments (0)

July 30, 2003

Unity 2 Beta 1 Now Available

Unity 2, moock.org's multiuser application development kit, is now in public beta. This latest version features database hooks for storing per-client and per-room information across sessions. Easily register users, log in users, and store their information across sessions. Download the latest beta here | Read about Unity 2 and view samples here | View Unity 2 client and server documentation here.

Posted by moock at 11:11 PM | Comments (2)

July 25, 2003

good, concise intro to flash programming

you know, i was just re-reading a copy of my actionscript pocket reference. i think the first 60 pages are a really nice little intro to the language and flash programming, and i don't think i ever publicized that aspect of the book much. in a way, i'd kinda like to include the material in asdg. i always felt the urge to do an overview for asdg given that its like 1100 pages.

anyway, for $10.36 on amazon, i'd say the pocket reference is a great way for someone coming from another language to get their feet wet with actionscript and flash programming. the book's so small, somehow i had almost forgotten about the little guy ;)

do you have the pocket reference? if so, what do you like about it? what do you think i should change next time around?

if you know of other good "ActionScript Primer" style books or online tutorials, post 'em here.

Posted by moock at 02:56 PM | Comments (8)

July 24, 2003

reader mail: call function from link in html text field

josh writes:
========================
Imagine a string of htmlText, let's have it say "Click here to jump around." Now, on the word “here” there needs to be an anchor tag that…wait for it…runs a piece of Actionscript that's within the same .swf. Perhaps a simple function that just launches a trace message. I've tried everything I can think of and this is such a specific topic it's difficult to find information on it. Do you have any ideas on the topic?

colin answers:
========================
hey josh,
it goes a little something like this:

this.createTextField("tf", 0, 100, 100, 200, 20);
tf.html = true;
tf.htmlText = "Click <A HREF='asfunction:displayMsg,hello world'>here</A> to jump around";

function displayMsg (msg) {
trace(msg);
}

more info on page 1001 of your copy of asdg2. (it's actually listed in the index under "hypertext links, calling ActionScript functions from).

Posted by moock at 10:43 PM

new product puts Flash on the desktop

A few months ago, ScreenTime (creators of the well-known screensaver authoring tool by the same name) released SWF Desktop, an authoring tool for creating Flash-based desktops. On a Flash desktop, you can place animated effects, live information updates, and interactive content, as shown in the examples posted here.

This is definitely an interesting use of Flash, but do you like the idea of an interactive desktop? Is it something a web agency's clients might want? What's a killer app for the Flash desktop? Multiplayer games like bridge or chess?

Posted by moock at 10:20 PM | Comments (8)

July 23, 2003

components article followups

here are two responses to questions about the flash components article i wrote for the o'reilly network.

==================
QUESTION 1

Why are components large in size?

I started using drop down, push button, and radion button on one of my application and noticed the size of my swf file increase from 10K to 32K. Please note that I am publishing my project using the compress option. Any ideas why this is happening?


==================
ANSWER 1

This is a common debate on most flash programming boards. The two biggest reasons for the size of the components are:

1) they're designed to be used as a group, so you take a big hit for the first one you use, and much less for each one thereafter. e.g., if you just use a listbox, you'll notice a big jump in filesize as the core libraries for components are added to your app. if you then add a radio button, you'll notice that the additional size is less than the cost of using the radio button on its own. and if you need a scrollbar, you get it for free (there's already a scrollbar in the listbox).

2) the components have a much richer featureset than you might think. they respond to keyboard control, and accessible input devices, have their own focus model, work with dataproviders, etc, etc. macromedia's goal is to make them behave like real operating system controls, so that online flash apps feel like traditional desktop apps. to paraphrase macromedia's mike chambers (www.markme.com): if you can build an equivalent feature set in less code, macromedia has a job for you.

it seems to me that it might make sense to ship "lite" versions of the components, that have a stripped down feature set. however, if everyone used those, then flash content would be much less usable and completely inaccessible.

for a long discussion about file size and component quality involving several macromedia employees (including nigel pegg, who developed most of the original mx components), see: http://chattyfig.figleaf.com/ezmlm/ezmlm-cgi?1:sss:27250#b

==================
QUESTION 2

I'm speaking from a coder point of view, and here all the things that I dislike in components:
- Macromedia doesn't provide any guideline, standards, rules or internal documentation of their components.

- I didn't like smartclips in flash5 too, and I'm happy not to have waisted my time to use or build them, because now they are obsolete, detroned by flashMX components, is it gonna be the same things with components when flash 7 will go out and promote a new way of doing things ?

- the way components work and how they are structured, sorry but that's bad coding practice ...
http://c2.com/cgi/wiki?CodeSmell

I will not be a dummy programmer following blindly Macromedia components bad OO coding style.


==================
ANSWER 2

components are here to stay, trust me. if you develop windows apps, you don't write a Menu or DialogBox class yourself, you use the corresponding MFC class. if you're developing java apps, you likely don't write a Tree class yourself, you use JTree. if you're developing flash apps, you use components. after all, you're developing apps, not UI widgets. of course, in some situations you'll produce your own specialized UI widgets for any platform, but for standard apps, you use the built in UI libraries.

the mx components are not perfect. they are version 1 of flash's UI library. but they are quite usable, and lay a good foundation upon which macromedia will certainly build. i agree that the flash mx component authoring process needs improvement, and in some cases so do the components themselves...but that's why software companies release new versions of products, right? merging an animation tool with an app development IDE isn't something that happens overnight. it takes years to evolve. and along the way i think we're all learning to create better, more engaging content.

Posted by moock at 11:04 AM | Comments (3)

July 22, 2003

grow with yugo

flash art pioneer yugo nakamura's latest project is now live. here's the description:

"ecotonoha is a project - to nurture a virtual tree collaboratively, and at the same time contribute to the actual environment to cope with global warming. as you make ecotonoha's leaves, the virtual tree will grow, and as ecotonoha grows, real trees will be planted by nec."

Posted by moock at 10:16 AM | Comments (4)

July 21, 2003

new vector park exhibit

vectorpark has new work up: a morphing sequence of 3d walking things. nice to look at and play with (it responds to your mouse). thanks to veronique for the link.

Posted by moock at 04:30 PM | Comments (2)

July 17, 2003

reader mail: Button name follow up

sanjay had a follow up question:
One of the things in my original query was to find out whether it is normal that the instance name of the button ("theButton") when used as a var/param will contain its target path.

For example, on the theButton, inside a mc mc1:
on (release) {
SomeFunction(theButton);
}

SomeFunction is on a frame in the mc (mc1) containing the button.

function SomeFunction(param1) {
trace(param1);
}

The trace is:
_level0.mc1.theButton

Is this to be expected?

colin answers:
=======================
hi again sanjay,
yes, that's the expected and normal output. here's why:

in your example, you have a button with an instance name "theButton" on a frame of a movie clip named "mc1". you attach the following code to your button:

on (release) {
SomeFunction(theButton);
}

as you can read on page 234-235 of asdg2, the scope of statements in an on() handler attached to a button is the movie clip that contains the button. you already intuitively knew that in your code because you referred to SomeFunction() directly by name, as though your code were on a frame of mc1. by extension, you also knew that you could refer to theButton directly when you passed it as an argument to SomeFunction().

your example statement:

SomeFunction(theButton);

passes a reference to the "theButton" object to the function "SomeFunction". inside that function, you display the reference in the Output panel:

trace(param1);

values passed to trace() are converted to the String datatype before being displayed in the Output panel. converting a Button object to a string yields the Button's target path (same as doing targetPath(theButton)). hence, the Output panel displays:

_level0.mc1.theButton

colin

ps. i know it's just an example, but you shouldn't start your function names with a capital letter. normally a leading capital letter is used only for class names.

Posted by moock at 10:33 AM | Comments (0)

July 16, 2003

reader mail: accessing Button._name from an on() handler

sanjay asks:
How do i reference the name of a button (p 463 of ASDG2e) from an on() handler.

Can't get it to work...

===================
colin answers:
===================
hi sanjay,
if you use on() handlers, you don't have an easy way to get at the Button class's _name property. to access _name you need a reference to the button object to which the on() handler is attached. however, from an on() handler attached to a button, the keyword 'this' refers the the movieclip on whose timeline the button resides. that's not what you want. from inside the on() handler, you could refer to the button object as this.yourButtonName, but i'm guessing that's not possible because you're trying to get the button's name dynamically.

so, if you need access to the button when it's clicked, try assigning the button event handler as a property rather than with "on()", as in:

theButton.onRelease = function {
// do stuff here...

// in this style of event handler, the following
// statement will display the name of the button
// in the output window
trace(this._name);
}

you could also use an on() handler attached to a movie clip. in that case, the keyword 'this' refers to the clip with the on() handler, so you would be able to use 'this._name'. for info on using movie clips as buttons, see page 364 of asdg2.

for much more info on on() handlers, see the section on event handler scope for on(). p234-p237 of asdg2. see also the table describing the values of the 'this' keyword in event handlers.

colin

Posted by moock at 01:19 PM | Comments (0)

July 09, 2003

reader mail: dynamic variable names

stefan asks:
*********************
I wanna use a kind of dynamic variable on the left side of "=".

Something like:
var iname = "myobjectinstancename";
var eval(iname) = new myClass();

To say it frankly I do not exspect to get this working.

Or a compiler (AS -> SWF) on the server-side would solve this problem.

Do you have any idea?


colin answers:
*********************
if your code is on a frame in a timeline, you can use the [] operator to create the variable name from a string. as in:

function MyClass () {
}
MyClass.prototype.hello = function () {
trace("hello world");
}

var iname = "myobjectinstancename";
this["iname"] = new myClass();

iname.hello(); // Displays "hello world"

as for a server-side compiler, you could investigate Ming:
http://ming.sourceforge.net/

Posted by moock at 11:15 AM | Comments (3)

July 08, 2003

reader mail: loading XML

i figure i'll start posting some of the responses i send to readers here for posterity. the first comes from josh, a java developer.

josh writes:
**********************
I have searched for hours and hours.. and no one seems to know the answer to this question.. I come from a java background so this is just mind boggling to me.. I have one simple function..

getData = function(xmldata) {
dReader = new DataReader();
gXML = new XML();
gXML.ignoreWhite = true;
gXML.onLoad = function(loaded){ trace(this.hasChildNodes()); };
gXML.load(xmldata);
trace(gXML.hasChildNodes());
}

rs = getData("../reports/salesreturned.oml");

of course the trace inside the onLoad function has children.. the one after gXML.load doesn't (I'm guessing because it hasn't been loaded yet.. I want to actually return a data from the getData function.. how are you supposed to get out of the gXML.onLoad portion.. It seems like once you want to parse the XML your'e pretty much stuck in a timeline of chaining functions from onLoad.. This is probably a more general question than just this.. it applies for all event handlers and how to "get out" of them.. I couldn't figure out how to assign a variable in the getData function data from inside the handler.. even if I did.. how would I return the function because the data isn't loaded before it would return.. it blows my mind how actionscript wouldn't process something like this sequentially since it doesn't have blocking functions.


colin answers:
**********************
hi josh,
coming from a multithreaded environment like java to a singlethreaded environment from flash is indeed a little disorienting. part of the key to understanding your situation is knowing that the actionscript interpreter does things automatically behind the scenes for you that you might not expect from a Java perspective.

first a few fundamentals:
1) all code in a flash documents executes according to either events or to frames.
2) code on a frame generally executes sequentially *unless* it involves an HTTP load operation, in which case the HTTP request isn't sent until the end of the frame on which the code occurs. the load request doesn't block the execution of code; it's just put off until the end of the frame, after all code has been executed.
3) when an HTTP request occurs, the results take some time to return. they arrive asynchronously, and must be handled by event handlers that may actually fire perhaps 10, 100, or even 1000 frames later (assuming you're not stopped on a frame).
4) unless you use 'var' to create a local variable, variable declarations in functions defined on frames create "timeline variables" which are available to any other code on frames in that timeline. (think of timeline variables as instance variables of the MovieClip object on whose timeline your code resides.)

now let's take a look at your original function. i'll add comments to explain what's happening behind the scenes.

===========
getData = function(xmldata) {
// this doesn't seem to be used(?)
dReader = new DataReader();

// create a new XML instance, store it in gXML, which
// is defined on the timeline of this function declaration.
// probably not what you want. this should likely be a
// local variable.
gXML = new XML();
gXML.ignoreWhite = true;

// assign the onLoad callback function. it will execute
// automatically when your data has loaded.
gXML.onLoad = function(loaded){ trace(this.hasChildNodes()); };

// now ask Flash to load the xml file. this actually doesn't occur
// right away. it occurs at the end of the current frame.
gXML.load(xmldata);

// the load hasn't started yet, so there are no child nodes.
trace(gXML.hasChildNodes());
}

// this is an impossible idiom in actionscript.
// data won't be returned until it loads.
rs = getData("../reports/salesreturned.oml");
===========

ok, now let's rewrite your function so it works more the way you want it to. note that i'd normally do what you're doing within a class. however, you seem to be using code on a timeline, so i'll stick with that convention for this example. i'll also try not to completely replace your current approach. i'll just adapt it a little to the Flash world.

here's the source for our sample XML file:
===========
<?xml version="1.0"?>
<P>Hello</P>
<P>There</P>
<P>World</P>
===========

here's the code on a frame in your .fla file:
===========
getData("doc.xml");

function getData (url) {

// "But wait!," you think, "the local variable will expire
// at the end of the function, before data loads!"
// Not true. ActionScript will keep it around for you internally
// until the load completes, even after the function exits.

var gXML = new XML();
gXML.ignoreWhite = true;
gXML.onLoad = handleLoadedData;
gXML.load(url);
}

function handleLoadedData (loaded) {
if (loaded) {
// extract what you want from the loaded data
var data1 = this.childNodes[0].firstChild.nodeValue;
var data2 = this.childNodes[1].firstChild.nodeValue;
var data3 = this.childNodes[2].firstChild.nodeValue;
// then do something with it.
// (i'm assuming you're updating a UI, but you
// could just set a timeline variable here.)
updateUI(data1, data2, data3);
} else {
trace("load error");
}
}

function updateUI (value1, value2, value3) {
// you'll use the values to update your ui,
// but we'll just display them in the Output
// panel for this example.
trace("Received values: ");
trace(value1); // Displays: Hello
trace(value2); // Displays: There
trace(value3); // Displays: World
}
===========

if you're using the Macromedia FUI components, you might also want to investigate the setDataProvider() method and databinding options. that lets you define an XML instance and wire a UI component to it. when the instance loads new values, the component updates automatically.

good luck!
colin

Posted by moock at 10:46 PM | Comments (6)

July 04, 2003

flash mx actionscript lecture video

moock.org's first lecture video is now available for purchase. entitled "Flash MX ActionScript Power Tour," the lecture ships on CD and costs US$19.99. here's a description of the lecture:

"Join Colin Moock, author of O'Reilly's "ActionScript: The Definitive Guide" for a power tour of the programming features first introduced in Flash MX. This session gets down and dirty into code, with a practical demonstration of dozens of ActionScript features. Perfect for intermediate to advanced developers who need a crash course on ActionScript's MX tools and capabilities. Beginners will find the content stimulating, but probably a little overwhelming."

Lecture notes are posted online here.

Note that the lecture was taped shortly after the release of Flash MX, so it refers to features in MX as "new" even though they've now been around for a while.

If you have any questions, let me know by posting comments here.

Posted by moock at 10:42 AM | Comments (4)