Si trabajas con Flex, ActionScript, Flash, Air, BlazeDS, AMF, Cairngorm, PureMVC u otras lenguas de programación de Adobe Systems o tecnologías relacionadas quizá te interese pasarte por el nuevo grupo/tema que hemos creado en Utoi: Profesionales de Adobe Flex.

Se trata de un grupo dedicado a todos aquellos que trabajan con Flex, o que quieren aprender más sobre la plataforma. Se admitirán preguntas sobre programación, discusiones acerca de cualquier aspecto relacionado con Flex, recomendaciones de herramientas, avisos de eventos y, por supuesto, ofertas y demandas de empleo relacionadas con el tema.

Utoi está aún un poco en pañales y de momento somos cuatro gatos (y muchos ya nos conocíamos entre nosotros; somos los de siempre :) De hecho, este tema está entre los nueve primeros que se han propuesto (y aprobado) en Utoi.

Por lo que me ha dicho la gente de Utoi, hoy es el lanzamiento «oficial» de Utoi en Soitu y, efectivamente, desde hoy están enlazando a la nueva red social y de microblogging desde la portada de Soitu (vaya nombres). A ver si eso le da un empujón al grupo de Flex…

Categories: Adobe Flex, Computers, Spain; Tags: ActionScript, Adobe, Adobe Flex, Adobe Systems, Air, AMF, BlazeDS, Cairngorm, Flash, group, grupo, profesional, professional, PureMVC, social, Soitu, tema, topic, Utoi

No comments yet        © 2006-2010 tripu        

I finally managed to get the Flex 3 IDE and version 3.0.0 of the AIR SDK to run with Eclipse 3.3.2, and to launch both the AIR runtime and the Flash plug-in for Firefox from within Eclipse as needed (run and debug modes).

The process is no apt-get install, and is not well documented. At the end I combined instructions and tips from Adobe Labs, one or two comments from forums and the workaround for a bug filed in Jira. This recipe summarises the process in detail and, following it step by step, in a few minutes you will be running Flex Builder 3 in Ubuntu 9.04 Jaunty Jackalope. This recipe might be applicable to other versions of Ubuntu, and even to other Debian-based distros.

There are six main steps:

1. Install a JRE
2. Install the Eclipse SDK
3. Install the FB3 plug-in for Eclipse
4. Back up one SWC library
5. Upgrade the AIR SDK
6. Repair the offending SWC library from the backup

A few notes before going into details. First of all, bear in mind that the Linux version of FB3 is an unsupported alpha, and that some key features are (still) missing in it. The most important one is the design view, but also the states view, the profiler and four other features. If these are important limitations for you, you might need to consider virtualisation instead (or a different base OS altogether).

Second, there is no stand-alone FB3 for Linux. Flex developers running Windows or Mac OS are used to installing either the FB3 plug-in on top of an existing Eclipse installation or the FB3 stand-alone bundle provided by Adobe. In Linux, on the other hand, there is no option but to install the Eclipse SDK first, and then the FB3 plug-in on top of it.

Third, Java is a dependency: the FB3 plug-in needs Eclipse, and Eclipse needs a JRE.

Fourth, if you plan to build AIR applications for the desktop (as opposed to Flash applications for the web) you might need to install the AIR runtime separately, in addition to the steps listed here.

Finally, here I use Bash commands to illustrate these steps in detail and without ambiguity; but most of these steps, if not all of them, you can accomplish using your file manager and visual tools of choice instead.

1. Install a JRE

   $ sudo apt-get install sun-java6-jre

   This will also install sun-java6-bin.
   You can now check that Java has been installed successfully, the usual way:

   $ java -version

2. Install the Eclipse SDK
   From all the bundles that Eclipse.org provides, pick and download a minimal Eclipse SDK (you won’t need all those fancy plug-ins, and they can be added after the installation anyway).
   Whatever the bundle, it needs to be version 3.3.x, codename Europa.
   The IDE “for Java developers” [Europa] is the best option:

   $ wget "http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/europa/winter/eclipse-java-europa-winter-linux-gtk.tar.gz"

   Extract the files from the archive and then move the base eclipse/ directory to, for example, /usr/local/:

   $ tar -xzf eclipse-java-europa-winter-linux-gtk.tar.gz
   $ sudo mv eclipse /usr/local/

   Create a permanent workspace for Eclipse:

   $ mkdir ~/eclipse-workspace/

   Launch Eclipse:

   $ /usr/local/eclipse/eclipse &

During the first initialisation it will prompt for a workspace. Browse to the directory that you just created (~/eclipse-workspace/).
Check that Eclipse works (you can write and run a helloworld in Java).
Close Eclipse.

3. Install the FB3 plug-in for Eclipse
   Download Flex Builder for Linux and give yourself permission to run the file:

   $ wget "http://download.macromedia.com/pub/labs/flex/flexbuilder_linux/flexbuilder_linux_install_a4_081408.bin"
   $ chmod u+x flexbuilder_linux_install_a4_081408.bin

   Create a new directory for FB3 and make it your own:

   $ sudo mkdir /usr/local/flex-builder/
   $ sudo chown $USER:$USER /usr/local/flex-builder/

   Run the installer:

   $ ./flexbuilder_linux_install_a4_081408.bin

   Accept the license.
   When asked where to install Flex Builder, browse to the directory you just created (/usr/local/flex-builder/).
   When asked where Eclipse is currently installed, browse to the directory where you copied Eclipse (/usr/local/eclipse/).
   If you plan to develop for the Flash Player, tick the option to install the debug version of Flash Player 9 for Firefox (but you might be able to download it separately anyway).
   The “pre-installation summary” should look similar to this:

   

   Once the installation finishes you can launch FB3:

   $ /usr/local/flex-builder/Adobe_Flex_builder.sh &

   Flash projects will run fine …but most likely AIR projects won’t work. When you try to build and launch an AIR app, you will see this error message in Eclipse:

   

4. Back up one SWC library

   $ cp /usr/local/flex-builder/sdks/3.0.0/frameworks/libs/air/airglobal.swc ~

5. Upgrade the AIR SDK
   Download the AIR SDK for Linux to a temporary directory and uncompress it:

   $ mkdir ~/tmp-air/
   $ cd ~/tmp-air/
   $ wget "http://airdownload.adobe.com/air/lin/download/latest/air_1.5_sdk.tbz2"
   $ tar -xjf air_1.5_sdk.tbz2
   $ rm air_1.5_sdk.tbz2

   Delete the current SDK 3.0.0 runtime/ directory from the FB3 installation directory:

   $ rm -rf /usr/local/flex-builder/sdks/3.0.0/runtimes/

   Overwrite the SDK 3.0.0 with the version you downloaded (it will overwrite some files — that’s fine):

   $ cp -a ~/tmp-air/* /usr/local/flex-builder/sdks/3.0.0/

   Replace these two files:

   $ cd /usr/local/flex-builder/sdks/3.0.0/bin/
   $ rm adl_lin adt_lin
   $ mv adl adl_lin
   $ mv adt adt_lin

   Create this new symbolic link:

   $ cd /usr/local/flex-builder/sdks/3.0.0/runtimes/air/
   $ ln -s linux/ Linux

   Now it will almost work. When you run FB3 and try to run an AIR app, you will get this error:

   

6. Repair the offending SWC library from the backup

   $ cp ~/airglobal.swc /usr/local/flex-builder/sdks/3.0.0/frameworks/libs/air/

   This will fix the previous error. Try to build Flash and AIR apps again in FB3; everything should work fine.

Categories: Adobe Flex, Computers, Images, Work; Tags: Adobe, Adobe Flex, Air, bug, Debian, development, error, FB3, Flash, Flex Builder, how to, howto, install, installation, Linux, recipe, set up, setup, software development, tip, Ubuntu

14 comments so far        © 2006-2010 tripu        

Our Flex codebase is a nice instance of a complex, heterogeneous Air application to which probably more than twenty developers have contributed to date. A not-so-well-known Flex MVC framework is at the core of the architecture, and we leverage quite a good number of Flex components and Flash libraries from third parties. We do unit testing, code coverage and continuous integration.

Ever since I joined the team (when the guys had just upgraded from the beta 3 of Air to Air 1.0) there has been an odd issue with the Air project in Flex Builder 3: we could not use FB3‘s “design view” to preview the layout of the application or to edit our custom MXML components.

The problems were two. First, the design view displayed what looked like a blank canvas — sometimes with whimsical wireframe edges that seemed to represent containers and other children. But only a few of those children appeared (if any at all). Rarely their sizes and positions were right, or their actual contents visible (see the screenshot below). Only when previewing simple components that inherited directly from Flex standard components (and not from our own components) the result seemed correct.

The second problem was that when switching from code view to design view a pair of errors suddenly appeared for every custom font that the project uses (even if the project builds just fine in code view):

unable to resolve '/project/assets/fonts/customFont.ttf' for transcoding | project | line 195
Unable to transcode /project/assets/fonts/customFont.ttf.                | project | line 195

We gave it a go at trying to solve these issues at the time (ten months ago), with no luck. It never was much of a problem, though. Not for me at least, since I usually prefer to work on code view, even for building layouts and style-tweaking (in design view FB3 is slow rendering your changes, and I’m too fussy with my code to accept the auto-generated MXML). But boy, was it annoying.

A few days ago I investigated these problems again for a while… and this time I cracked it. Let me share what I learnt, because I think it is not that obvious.

The main problem has to do with the limitations of the design view in FB3. As you probably know (because you bothered to read this far), MXML is just a more readable way to describe visual Flash objects. MXML is more intuitive than ActionScript to define the layout of your Flex GUI precisely because the nesting of XML nodes in MXML matches the nesting of visual components that those XML nodes represent. Actually, the Flex SDK compiles all MXML classes to intermediate AS. If you know that, you would presume that Flex Builder treats both AS classes and MXML classes in pretty much the same way. Well, it doesn’t.

It turns out that the “design view” can render any MXML class, provided that all its ancestor classes (up to the first standard Flash component) are defined in MXML too, i.e. not in AS.

In our project we had the situation represented in the diagram below. Most of the “screens” or “pages” in our application are based (directly or indirectly) on a common class. That common class, in turn, inherits from some other class that is defined within the MVC framework. The problem was, that common class was written in ActionScript, thus cutting off the hierarchy of MXML classes that the design view in FB3 “understands”.

All I had to do was rewrite that class in MXML and keep the name of the file, changing its extension from as to mxml. It was a quick change: the class was short and I could maintain parts of the original ActionScript embedded within a Script component anyway. Note that no other changes were necessary, because the subclasses don’t care whether their superclass is originally written in AS or in MXML.

As for the other issue (the problem with the custom font families), it seems that the design view can’t load custom fonts unless they are defined as embedded resources in AS, i.e. not in separate CSS files.

Originally we had something like this:

<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml">
 
    <mx:Style source="../styles/fonts.css" />
 
    <!-- … -->
 
</mx:WindowedApplication>

Where styles/fonts.css contained:

@font-face {
    font-family: "_DefaultFont";
    font-weight: normal;
    src:         url("../assets/fonts/verdana.ttf");
}
 
@font-face {
    font-family: "_DefaultFontBold";
    font-weight: bold;
    src:         url("../assets/fonts/verdanab.ttf");
}

I removed the CSS file and embeded the two font families directly into the MXML component (which is less elegant, of course):

<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml">
 
    <mx:Script><![CDATA[
 
        [Embed(source='../assets/fonts/verdana.ttf', fontWeight='normal',
            fontName='_DefaultFont', mimeType='application/x-font')]
        private var thisObjectIsNeverUsedButItHasToExist_1:Class;
 
        [Embed(source='../assets/fonts/verdanab.ttf', fontWeight='bold',
            fontName='_DefaultFontBold', mimeType='application/x-font')]
        private var thisObjectIsNeverUsedButItHasToExist_2:Class;
 
    ]]></mx:Script>
 
    <!-- … -->
 
</mx:WindowedApplication>

I guess the moral of the story is: Adobe, we need a better IDE!

Categories: Adobe Flex, Computers, Work; Tags: Adobe, Adobe Flex, Air, class, CSS, design view, Eclipse, embed, error, FB3, Flex 3, Flex Builder, Flex Builder 3, font, issue, resource, transcode, transcoding, trick

6 comments so far        © 2006-2010 tripu        

First things first — what Adobe Flex is not:

• It is certainly not a tool for generating lexical analysers ;¬)
• It’s not “the new version of Flash” (FKA “Macromedia Flash”). Development of Flash is on-going and the two products coexist. Flex hasn’t replaced (and won’t replace) Flash anytime soon, the reason for that being that…
• …Flex is not “an alternative to Flash”. Sorry to disappoint you, but Flex is not a way to get rid of the dependence on the Flash Player. Actually Flex is built on top of Flash and needs Flash Player to run.
• It’s not a technology to build large, native apps that need to work close to the underlying platform or which performance needs to be optimised (read below to see why I believe this).

Flex in a nutshell (a rather small nutshell):

Flex is an attempt by Adobe to make Flash attractive to, and suitable for, many software developers who were disregarding Flash as something not serious enough to use for developing “proper software”. Adobe has done a praiseworthy effort in that sense and has brought Flash to the realm of OO programming. Adobe used Eclipse to develop Flex Builder. Flex Builder alone does a lot to make old-skool software developers feel at home — it’s a proper IDE with all the features you would expect, plus the extensibility (and the slowness, I’m afraid) of Eclipse.

Flex developers use the Flex SDK (command line compilers and component class library; free as in “freedom”) and the Flex Builder (the IDE) to build their applications. Flex apps are written mainly in two languages:

• Actionscript, an ECMAScript-based language that exists since the first Flash Player.
• MXML, a loose, proprietary implementation of XML used to define GUI elements.

The output of a Flex project is one or more Flash files (.swf). In terms of the approach to the development process, the single most important change from Flash to Flex is probably removing the “movie” way of thinking. Flash animators are used to the “movie paradigm” in which the time is an essential concept. In their animations they have been working with key concepts like “timeline”, “frame” and “loop”. Flex abandons that approach.

I have found that, in general, software developers without any experience with Flash get used to Flex even faster than Flash designers who don’t know much about programming.

What Flex is good at:

• Rendering cool interfaces. Animations, transitions, effects, gradients, reflections, customised skins, embedded movies, nice charts, changes in opacity, layouts that are resized well when their container is resized, etc. For a demo, check the Flex 2 Component Explorer.
• Working on all major desktops and web browsers and many mobile devices. OS‘s: Windows, Mac OS, Linux and Solaris. Browsers: IE, Gecko-based browsers, Safari, Opera. Mobile devices: many, and more to come.
• Keeping the same “look & feel” everywhere. You can see the default Flex 2 “look & feel” in the Flex 2 Style Explorer.
• Integrating and communicating with other Adobe formats. Flash movies, Acrobat documents, ColdFusion, Dreamweaver, etc.

What Flex is not good at:

• Computationally expensive software. As we saw before, Flex stresses GUI aesthetics, intuitive design, portability, compatibility with existing Flash files and other Adobe tools, easy deployment, etc. And it was aimed at the web (in spite of Air). So don’t expect it to be any good at doing system calls, invoking hardware drivers, messing with the network at low-level, fine-tuning loops to save cycles of CPU, dealing with gigabytes of data, delivering real-time, etc. Because Flex apps are deployed as Flash files, every Flex app “lives” inside the Flash security sandbox, which prevents it from accessing many of the resources of the computer. Also, Flash is a proprietary format that doesn’t run natively but is interpreted by the Flash Player. That extra layer of translation decreases the performance.
• Classic Flash stuff. Don’t bother to learn Flex if all you need to do is Flash banners and simple animations. For that you will need a timeline, drawing tools and accuracy at pixel-level. Flex is not designed for that.
• Being extrovert with its neighbours. I hear that even Air makes it quite difficult to launch an external executable from a Flex application.

Now, the “hello world” is mandatory, so here it goes.

This application simply displays a customised greeting (it’s a “hello world” on steroids). We’ll make the GUI inherit from the layer that processes the information, in a “code-behind” manner.

First, the Actionscript class contained in the file info/tripu/blog/flex/SimpleApp.as. This class extends the standard Application class and defines what to do with data:

package info.tripu.blog.flex {
 
    import mx.controls.Alert;
    import mx.core.Application;
 
    public class SimpleApp extends Application {
 
        public function greet (who:String): void {
            Alert.show ('Hello, ' + who + '!');
        }
 
    }
 
}

Second, the MXML application HelloWorld.mxml. It defines the GUI by using an instance of the class SimpleApp and adding a couple of visual controls to it. Notice how the AS class that we created before is now used straight as an XML element:

<?xml version="1.0" encoding="utf-8"?>
 
<tripu:SimpleApp xmlns:tripu="info.tripu.blog.flex.*" xmlns:mx="http://www.adobe.com/2006/mxml">
 
    <mx:TextInput id="user" text="world" />
    <mx:Button label="Greet" click="{greet (user.text)}" />
 
</tripu:SimpleApp>

The result of compiling those two files in a Flex project is this Flash file, HelloWorld.swf (you’ll need Flash Player version 8 or above to see the embedded Flash object):

Categories: Adobe Flex, Computers, Work; Tags:

3 comments so far        © 2006-2010 tripu