« July 2005 | Main | September 2005 »
August 12, 2005
File Upload is Here!
At long last, it is now easy to upload files from Flash and Flex applications. Thanks to a new feature of Flash Player 8, you can abandon your clunky, quirky, javascript and invisible HTML forms.
Follow this link to learn more about file upload as well as new features in Flash Player 8 that benefit Flex.
I have to tell you, as a vetern of adding file upload capability to Flash applications, this is truely a godsend. The Flash engineers have listened and really came through.
Oh yeah, your Flex apps run much faster and use less memory, too!
Posted by pent at 09:15 AM | Comments (6)
August 09, 2005
Dialing for Components
A while ago I wrote a DevNote article and a blog entry describing how you can build a component. What started out as a simple component, got increasingly more complex. To the basic component I showed how you can style and skin it and add events. All in all, it wasn't a bad bit of writing. I hope it was helpful.
I want to offer you another look at building components. This time using Flash to make the graphic skins and MXML for the structure. This technique does use ActionScript, but it is kept to a minimum and does not use ActionScript classes.
The Dial Component
Click here to download the components and examples: Download file
The component up for inspection is the Dial component: a round disk with a programmatically positioned needle. See the first figure. The Dial is very plain, but that is a result of my lack as an artist. I created the visual elements of the Dial - the skins - in Flash. I chose Flash for two reasons: all of the assets are stored in 1 file; the assets are scalable since they are vector graphics and not bitmaps. You can however, use any image editor and make PNGs, JPEGs, or GIFs as your assets.
To begin, I created a new Flash document and made three symbols: the Dial face, the needle, and the cap which covers the base of the needle. You could do away with the cap or even make the cap part of the needle. I made my symbols to specific sizes: the Dial face is 150x150 pixels. The cap is 25x25 pixels. The needle is 63x3 pixels and was drawn pointing to the right, so it can easily be rotated (this is the 0 degree position).
Once the assets were drawn and saved as symbols within the Flash document, I published the document to a SWF file and placed it into the same directory as the Flex component source code.
The Dial component is an MXML file. The root tag is a Canvas. I chose Canvas because I can position its children using (x,y) coordinates and because I can easily position one child on top of another; the cap has to be above the needle which is above the face.
You can make the Dial component by creating a new MXML file and set the root to be a Canvas. For its children, add the following controls:
<mx:Image id="face" x="0" y="0" source="{dialFaceSkin}" />
<mx:Image id="needle" x="75" y="75" source="{dialNeedleSkin}" />
<mx:Image id="cap" x="62.5" y="62.5" source="{dialCapSkin}" />
<mx:Text />
Notice how I explicity position the components based on their sizes. The cap for example, is at (62.5,62.5) - the center of the dial is at (75,75) and the cap is 25x25 with its center being (12.5,12.5). So the position of the cap's upper left corner is (75-12.5,75-12.5) or (62.5,62.5). Notice that the source property for the Image tags are data bindings to the skins. You bring in the skins with a Script block:
[Embed(source="DialAssets.swf",symbol="dialFace")] public var dialFaceSkin:String;The Embed compile directive will cause the compiler to locate the symbol in the asset file and bring it into the final SWF. The variable below the Embed directive will be associated with the asset. Since the asset is dynamically bound to the Image, you see the dial face in the canvas.
Now you can save the Dial.mxml file and use it in a test application.
<mx:Application xmlns:mx="" xmlns:local="*">
<local:Dial id="myDial" />
</mx:Application>
Now you can write the code to position the needle. We want the Dial to have a minimum and maximum value just like other similar Flex controls (sliders and NumericStepper, for example). I wrote set and get methods for these properties. This follows the design pattern for Flex components and allows the properties to work with data binding since they will emit ChangeEvents when set.
This is the code snippet for the minimum property; the maximum and value properties are similar.
[ChangeEvent("minimumChanged")]
private var _minimum:Number;
public function set minimum(n:Number) : Void
{
_minimum = n;
dispatchEvent({type:"minimumChanged"});
invalidate();
}
public function get minimum() : Number
{
return _minimum;
}
The metadata ChangeEvent tells the compiler that this value can be used with data binding. Internally, we use _minimum to hold the minimum value as "minimum" is the name of the set function. This means you can do:
<local:Dial id="myDial" minimum="32" />
When that happens, the minimum set function is called, _minimum is set, and the change event is dispatched. So
<mx:Text text="{myDial.minimum}" />
will change with the new value.
The invalidate() call tells the Flex framework to re-draw the control. This may result in the position of the needle changing. For instance, if the previous value of minimum was 0 and is now 32, the needle will need move further clockwise.
function positionNeedle() : Void
{
var n:Number = (_value - _minimum)/(_maximum - _minimum);
var pos:Number = 135 + n*270;
needle._rotation = pos;
}
The positionNeedle method handles the draw event. Make sure you change the
This method uses the current values of _minimum, _maximum, and _value to position the needle. You can see that since these values contribute to the rotation of the needle skin, you need to invoke invalidate() whenever any of these properties are changed.
That's all there is to making this component: you create your graphic skins in Flash, use a Canvas to position the elements of the component, and use a little ActionScript to set the properties and initialize the component.
Going Further
To liven things up a little, I created a couple more skins in another Flash document (I could have used the same Flash document, but I wanted to keep the assets for different components separate).
In your test application, add another instance of the Dial, but this time change the skins:
[Embed(source="TempAssets.swf",symbol="dialFaceSkin")]
var tempFace:String;
[Embed(source="TempAssets.swf",symbol="dialNeedleSkin")]
var tempNeedle:String;<local:Dial id="tempDial" dialFaceSkin="{tempFace}" dialNeedleSkin="{tempNeedle}" />
When you run the application, you'll see this more colorful dial in addition to the original dial. If you think you would use these skins more than once, create a new component (see TemperatureDial.mxml), but use Dial as its root tag. You will find that all you need to do is embed the skin assets and assign them properly. By basing your new component on an existing component, you get all of that component's features and code, plus your extensions.
One thing you should have noticed right away is that I hard-coded the positions of the children (Images and Text) based on my knowledge of the size of the graphic skins. That's perfectly OK. But if you want real flexibility, you'll have to calculate those values.
Conclusion
Writing specialized components for Flex does not have to be difficult. You also do not have to follow the rules precisely, but use the framework as intended and make it work for you and use as much of it as you need. While I did not make my component so it can be any size, I did make it do what I wanted and I allowed it to be customized further.
Using a graphic editor, such as Flash, allowed me to concentrate on the function of the component, rather than on its looks.
Posted by pent at 01:29 PM | Comments (4)
August 02, 2005
I AM ORANGE: 1976-1980
Like many seniors in high school I thought about going to college and which college that would be. By now I was very sure I wanted to work with computers and write software. So the college I would go to would have to offer a degree in computer science. Back in 1976 this was not common. Even Princeton University, so close to home, did not offer a degree in computer science and in fact, offered very few computer software courses. As fate would have it, the very first college brochure I received was from Syracuse University.
Syracuse University, I would find out, was very unique for its time. It not only offered a B.S. in Computer Science, it also had the School of Computer and Information Science. Not only that, S.U. had SULIRS - Syracuse University Library Information Retrieval System. The entire card catalog was computerized. I knew these people had their act together and it was the place for me. In September 1976 my mother, sister, and I packed me up and went off to S.U. where the Goon Squad moved me into my dorm with my soon-to-be horrible roommate (but that's a whole other series of articles).
Keywords: Network, DEC, IBM, LISP, Computer Science
Going to S.U. was more fortuidous than I could have imagined. Now remember this was 1976. Computers were mainframes. Keypunches were the norm and very few people used computers. There was no Internet.
In 1976 Syracuse University was a wired campus. There were DECwriter IIs everywhere (white and black machines that used paper and a dot-matrix printer; made a racket but were reliable). In dorms and in academic buildings. Not only that, every student, regardless of degree program, was given several hours of computer time each semester. They could use the time for whatever they wanted: write papers, write programs, learn. The entire operation was run by the Academic Computing Center located in, appropriately enough, Machinery Hall, tucked away just off the north east corner of the Quad.
S.U. had two mainframes: An IBM 360 with a modified operating system: SUOS (Syracuse University Operating System) which was the envy of IBM since SUOS did things IBM said were not possible on a 360. The ACC also had a Digital Equipment DEC-10. Both machines had a couple of megs of memory.
The IBM system supported SULIRS as well as APL. If you are unfamiliar with APL, it was (and may be still is) a marvelously quirky lanaguage of strange symbols, and read right to left. APL required a special keyboard and the DECwriters had the APL symbols printed on them in yellow. You would write entire programs on a single line if you wanted to. The IBM system also supported the more academic research software like SAS.
The DEC system supported mostly the CIS department and was our favored machine. You could do LISP, ALGOL, Snobol, SAIL, Prolog, Fortran, and a slew of other languages that are just fond memories. The CIS department was my Gryffndor.
The 'network' at S.U. was pretty unique, almost entirely home grown. All of the DECwriter II terminals around campus were connected via serial line to a DEC-11. When you approached a machine and hit the return key you were given a login prompt. You had two accounts: one for APL and one for the DEC-10. Depending on which account you entered the DEC-11 directed you to that computer and then made the connection for you. Marvelous system. It even switched the DECwriters to APL mode if you signed into your APL account.
One of my first classes in computer science was LISP (List Processing Language) given by the much-loved Dr. Ed Storm (who has sadly passed away). Can you imagine that the first language you were to learn was LISP? Most people learned BASIC. Not us. We learned LISP. LISP is a beautiful, if impractical, lanaguage. It is entirely recursive and wonderful to teach Computer Science, not computer programming. Learning LISP was like having a light bulb switched on and illuminating a landscape filled with algorithms.
(FUNCTION FACTORIAL N) ( (IF N EQ 1 (RETURN N) (RETURN (MULT N (FACTORIAL (MINUS N 1)))) )
I actually never learned BASIC, nor FORTRAN, nor COBOL. Over my four years we used Pascal, APL, SAIL, and others. The point of the languages was to teach the science behind the software, not the software itself. Our artifical intelligence classes used LISP, Prolog, or PASCAL. The Math department was heavy into APL because multi-dimensional matrix multiplication was easy to do in APL. One of the hardest classes I ever had was Semi-numerical Algorithms (based on Don Knuth's book) given by the much-loved Dr. Pardee (who also has passed away). We used APL to figure out algorithms in different bases, such as base -3. Why? To understand how to express irrational numbers, logic, sorting, fractals, and much more.
I've only begun to tell you of the wonderland that was the S.U. campus, in terms of computing. Bleeding edge, that's what it was. We had some of the best professors in the world come teach there. And S.U. embraced computers in ways that other places were only beginning to understand.
I have never regretted going to Syracuse University (except for the snow) and cannot recommend it enough. My love affair with S.U. lasted longer than my four undergraduate years. I'll tell you about that next time.
Posted by pent at 01:24 PM | Comments (7)
August 01, 2005
Government Work - Things Sure Have Come Along Way
When I was going to high school, a career in computer science wasn't on the top of everyone's list. At least not at my high school. One fellow was going off to West Point, another off to Stanford, and so forth. My own plan was to go to Syracuse University. I think the slacker generation started with mine as most of the student body ridiculed anyone with plans for their future.
But I digress. When I was a senior an opportunity presented itself. The Forrestal Reseach campus at Princeton, N.J. had an opening for an intern in the General Fluid Dynamics Laboratory, part of NOAA (National Oceanic and Atmospheric Administration). The internship included summer and winter breaks from college. I applied and was accepted. I knew Fortran which they were keen on back then.
Keywords: Fortran, vector graphics, raster graphics, modelling
My summer after graduating high school was spent in a black and glass office building on the Forrestal campus. The GFDL was tasked with using computers to model the earth's atmospheres and oceans. Please remember this is my memory of it when I was 18 years old.
The GFDL used a 'super computer', a Texas Instruments ASC1000. I'll never forget it. The memory banks filled a room with another glass-enclosed room being the operations center. The ASC1000 had 1 megabyte of water-cooled magnetic core memory! Can you believe that? 1 whole megabyte and it took up a room. I have a 10 gigabyte flash-memory stick in my desk drawer that's the size of a pack of gum! 1000x the capacity of the ASC1000. Amazing.
I was awestruck of course. I was assigned to work in the vector graphics department where I was tutored by a kind man, Tom, and his biker assistant, Jimmy. The graphics machine was a Stromberg-Carlson 4020. The thing looked like it came from a WWII submarine. It was gray and at least 6 feet long. The images were projected up onto a screen using a single cathod-ray beam in a housing that was 4 feet tall. Above this was a film camera which recorded the images.
Basically, the process went like this: you wrote a Fortran program and keypunched it onto a deck of cards. This took many days to get right and was filled with vector graphic calculations. You handed the deck over to the operators of the ASC1000. The job ran and if successful, produced a magnetic tape. The tape was reel-to-reel and about 24 inches in diameter.
The tape was then brought to the SC4020. The instructions told the SC4020 to draw pictures on its tube which were recorded onto 35mm B&W fim.
The film was taken from the SC4020 and run through a developer (much like the machines at CVS) and a roll of negatives was produced. You then viewed the film either on a projector, or more likely, with a loop to look at it frame-by-frame. I probably have some of those at my Mom's house.
I remember producing 3-D images of the earth (oceans removed) and of weather patterns. I remember how I wanted to blow them up and use them for art work.
But can you imagine this today? What I was doing in 1976 was positively archaic by today's standards.
By the next summer some new technology had made its way to the ASC1000 - CRT terminals. I remember there being about 3 of these terminals, blue cases with white flickering letters on a black background. I was in Sci-Fi heaven. I could actually write programs and make corrections right there without touching a keypunch. I was one of the few avid users ('never catch on" one of the scientists said).
The thing about the techology then was the programmer-operator relationship. You just didn't sit down at a computer and write programs. You had to also go to the computer center and hand over your work to someone else. The computer operation scheduled the jobs. For an expensive machine like the ASC1000, the operators made sure it ran 20/7. Your job might not be run for several hours. There were bins for your printouts and you checked them periodically. Programs with infinite loops or that crashed the machine were a no-no to say the least.
The ASC1000 came with its own team of engineers from Austin that were on site to keep it running. I shared an office for a bit with one of those engineers who spent most of the time talking to his wife and calling her 'punkin'.
The idea that people would have computers in their own homes, hundreds of times more powerful than the ASC1000 was really science fiction. Computers were expensive. Using them was difficult. Programming them was science. Perhaps all of these are still true, but they were not something for everyone. They were not ubiquitous.
I don't know what happened to the GFDL lab. I worked two summers and two winter breaks. As the summer between my sophomore and junior year approached, I called and told them I would not be returning. I was staying at university and working there. It was also the last time I would live at home.
Tune in next time for a peak at the technology of Syracuse University, 1976-1984.
Posted by pent at 07:23 AM | Comments (1)