Flex 2 si occupa della parte presentazionale dell‘applicazione. In questa seconda parte approfondiremo ancora di più lo sviluppo di Rich Internet Application con Flex 2 integrandolo con Java partendo proprio da dove ci eravamo lasciati: le chiamate remote con Flex 2 SDK.

Nel primo articolo abbiamo introdotto la linea di prodotti Flex 2. Abbiamo parlato della differenza tra Flash e Flex sia dal punto di vista dello sviluppo che dell‘ambiente di programmazione. E ci siamo lasciati con i primi assaggi del modo in cui è possibile integrare Flex 2 come strato di presentazione all‘interno di architetture Java EE preesistenti.

In questa seconda parte approfondiremo ancora di più lo sviluppo di Rich Internet Application con Flex 2 integrandolo con Java partendo proprio da dove ci eravamo lasciati: le chiamate remote con Flex 2 SDK.

Flex 2 si occupa della parte presentazionale dell‘applicazione e non ha nativamente accesso a database. Quello che però ci permette di fare è di usufruire delle classi RPC per effettuare delle chiamate alla business logic, accedendo a un qualsiasi programming enviroment come Coldfusion, Java, Ruby on Rails o altri, per passare e ricevere dati remoti.

In Flex 2 i servizi  RPC provvedono a un modello call e response per accedere a dati remoti ed espongono dei componenti basati su architetture SOA (service-oriented).
Sono tre le classi RPC di Flex 2: la HTTPService class, la WebService class (SOAP-compliant) e la RemoteObject class.

Cominciamo proprio illustrando le prime due (effettuando delle chiamate remote attraverso il protocollo http, passando parametri da un file JSP e ritirando i risultati della chiamata) e un webservice.

Per svolgere i prossimi esempi avrete bisogno del Flex Builder 2 e delle Flex SDK 2. Il Flex Builder 2 è l‘ambiente di sviluppo integrato basato su Eclipse per la programmazione di RIA, che coniuga le funzionalità  avanzate delle applicazioni desktop con le potenzialità  multipiattaforma del Flash Player. Essendo un plug in di Eclipse, IDE noto a tutti i Java Developers, non ci soffermeremo sui fondamentali di questo IDE. Creare un progetto Flex in Flex Builder 2 è del tutto equivalente a creare un progetto Java in Eclipse. Potete scaricare una trial del prodotto dal sito di Adobe

http://www.adobe.com/products/flex/flexbuilder/

Chiamate remote a file XML, pagine JSP e Webservices

Abbiamo detto che Flex 2 espone 3 classi per le chiamate remote (RPC). Tra queste la più semplice e immediata è la classe HTTPService.
La HTTPService class permette di effettuare richieste http in modalità  GET o POST a URL specifiche. Permette di usare sia il protocollo HTTP che HTTPS per chiamare dati XML in maniera statica e dinamica.
Un XML è statico quando il file è generato fisicamente sul server, mentre si dice dinamico quando è generato dinamicamente da un linguaggio server side. Questo significa che la http request si aspetta di ricevere sempre come dati di risposta informazioni XML.
Ecco un esempio di applicazione che carica un file XML remoto (si tratta di un feed RSS http://weblogs.macromedia.com/mesh/index.xml) all‘interno di un DataGrid control:

http://www.adobe.com/2006/mxml" 
layout="vertical">

import mx.rpc.events.FaultEvent;
import mx.controls.Alert;
import mx.collections.ArrayCollection;
import mx.rpc.events.ResultEvent;

[Bindable]
private var risultato:ArrayCollection;

private function httpResult(evt:ResultEvent)
{
 mx.controls.Alert.show("Entrato nella funzione di Result");
 risultato = evt.result.rss.channel.item;
}

private function httpFault(evt:FaultEvent)
{
 mx.controls.Alert.show("Si è verificato un errore:"
    + evt.fault.message 
    + evt.fault.faultDetail);
}

url="http://weblogs.macromedia.com/mesh/index.xml"
result="httpResult(event)"
fault="httpFault(event)" />

dataProvider="{risultato}">

 ÂÂ

Voglio farvi notare una delle più potenti funzionalità  di Flex 2, il data binding.
La chiamata HTTPService che punta al file XML remoto, associa due event handler per l‘evento result, che scatta nel momento in cui vengono restituiti dei dati, e l‘evento fault, che scatta se si verificano degli errori.
La funzione associata all‘evento result, httpResult, popola la variabile risultato (che è tipizzata come ArrayCollection) puntando direttamente al repeating node del file XML (evt.result.rss.channel.item):

private function httpResult(evt:ResultEvent)
{
 mx.controls.Alert.show("Entrato nella funzione di Result");
 risultato = evt.result.rss.channel.item;
}

La variabile risultato è poi associata al dataprovider del DataGrid utilizzando le parantesi graffe. Con questo scrittura creiamo un data binding tra il controllo DataGrid e il contenuto della variabile. In questo modo se la variabile risultato cambierà , automaticamente i nuovi dati verranno aggiornati all‘interno del DataGrid e visualizzati all‘utente:

dataProvider="{risultato}">

Oltre a caricare file XML remoti statici  possiamo utilizzare chiamate http che accedono a  pagine JSP per andare a caricare dei dati remoti.
Possiamo infatti velocemente effettuare una stessa chiamata HTTP ad un file JSP che ritorna dei semplici dati in formato xml.
Scriviamoci il seguente file JSP che restituisce un file xml utilizzando il metodo  out.println():

<%
out.println("

marcocasario

giovannilenoci");
%>

Nel nostro caso il file XML che verrà  generato da questa chiamata sarà  il seguente:

 


marco 
casario 


giovanni 
lenoci 

Salviamo il file con il nome my.jsp ed effettuiamo il deploy del file sotto un servlet container come per esempio Tomcat (http://tomcat.apache.org/).
Adesso andiamo a creare il file MXML che andrà  a lanciare ed eseguire la pagina JSP caricando i dati di risposta in un datagrid:

http://www.adobe.com/2006/mxml" 
layout="absolute"
creationComplete="init();">

import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
import mx.collections.ArrayCollection;
import mx.rpc.http.HTTPService;
import mx.managers.CursorManager;

[Bindable]
private var myAC:ArrayCollection;

private var myHTTP:HTTPService;

private function init():void
{
 myHTTP = new HTTPService();
 myHTTP.url = "http://localhost/mokabyte/my.jsp ";
 CursorManager.setBusyCursor();
 myHTTP.send();
 myHTTP.addEventListener(ResultEvent.RESULT, resultHandler);
 myHTTP.addEventListener(FaultEvent.FAULT, faultHandler)
}
private function resultHandler(event:ResultEvent):void
{
 myAC = event.result.root.user;
 CursorManager.removeBusyCursor();
}

 
private function faultHandler(evt:FaultEvent):void
{
 var errors:String = "Some errors occurred 
";
 errors += "
 Fault Code is :  
" + evt.fault.faultCode;
 errors += "
 Fault Detail is : 
" + evt.fault.faultDetail; 
 errors += "
 Fault String is : 
" + evt.fault.faultString;
 mx.controls.Alert.show(errors);
 
 CursorManager.removeBusyCursor();
}

dataProvider="{myAC}" x="92" y="49">

Salvate e compilate l‘applicazione per vedere caricati i dati dal file JSP alla pagina DataGrid.

Adesso andiamo a occuparci della seconda classe RPC di Flex 2: la WebService class.
La classe WebService permette di accedere a web services, ossia a moduli software che espongono operazioni.
Un‘applicazione Flex può interagire con un web service se la sua interface è definita in un web service description langue (WSDL versione 1.1) e se le requests e le results sono formattate come messaggi SOAP (Simple Object Access Protocol).

Come per la classe HTTPService, la classe WebService permette di consumare i metodi di un web service andando semplicemente a definire la proprietà  WSDL, che contiene l‘URL del servizio:

http://weblogs.macromedia.com/mxna/webservices/mxna2.cfc?wsdl"
useProxy="false" id="wsBlogAggr">


30
{cbxNumPosts.value}

Inoltre, dato che i web service possono contenere più di un metodo, è necessario specificare quale metodo consumare e passargli degli eventuali paramentri, utilizzando i tag operation e request:

30

I parametri vengono passati al webservice all‘interno del tag request, utilizzando i nomi delle proprietà  che si aspetta di ricevere.
Vediamo l‘applicazione Flex 2 che consuma i web service di macromedia MXNA per leggere i blog ufficiali di Macromedia all‘indirizzo

http://weblogs.macromedia.com/mxna/Developers.cfm#web):

Ecco il codice completo

http://www.adobe.com/2006/mxml" layout="vertical"
creationComplete="wsBlogAggr.getMostPopularPosts.send()">

http://weblogs.macromedia.com/mxna/webservices/mxna2.cfc?wsdl"
useProxy="false" id="wsBlogAggr">


30
{cbxNumPosts.value}



title="Most Popular Posts">

change="wsBlogAggr.getMostPopularPosts.send()">

dataProvider="{wsBlogAggr.getMostPopularPosts.lastResult}">


width="75"/>


label="Select an item and click here for full post"/>

Compilate l‘applicazione dal Flex Builder 2 e vedrete i dati caricati all‘interno del DataGrid non appena l‘utente selezionerà  un valore all‘interno della ComboBox.

Possiamo passare all‘ultima classe RPC di Flex, la RemoteObject che permette di accedere e invocare metodi pubblici realizzati in Java.
Per poter utilizzare i RemoteObject non sono più sufficienti le Flex 2 SDK. Dobbiamo infatti  installare un modulo server che è a tutti gli effetti un‘applicazione Java EE: i Flex Data Services. I FDS sono gratuti fino a che vengono usati su una sola CPU e possono essere scaricati al seguente indirizzo:

http://www.adobe.com/products/flex/dataservices/

Installare i Flex Data Service sotto Tomcat

Durante la fase di installazione, i Flex Data Services offrono l‘opzione di usare il web server JRun. La stessa documentazione di Adobe consiglia di usare questo web server installato di default come un development server e non come un production server. Nel caso in cui si utilizzasse il JRun come web server, la context root avrà  la seguente URL: http://localhost:8700/flex/

Ma la maggior parte delle volte nella fase di deploy dovrà  essere installato sulla macchina di produzione anche un web server Java EE compliant su cui verranno installati i Flex Data Services e l‘applicazione da far girare. Nel nostro esempio utilizzeremo Tomcat.

Tomcat è un servlet container che si occupa di controllare le servlet che vengono eseguite all‘interno del web server. Tomcat fa parte del progetto Jakarta ed è open source.

La directory Structure di Tomcat non è complessa. Le folders che interessano un‘applicazione Flex Data Services sono: la cartella bin, conf e webapps.

L‘ultima, webapps, è la directory di default per le applicazioni web, quella in cui copieremo i file WAR di Flex. Installato il web server possiamo passare all‘installazione dei Flex Data Services ed eseguire il loro deploy sul webserver.

Lanciando l‘installer del FDS basterà  lasciare le opzioni di default (i Flex Data Services vengono installati nella cartellina “fds2”), scegliendo però la versione J2EE web application. A questo punto saranno create le seguenti cartelle all‘interno della directory fds2:

• Filesla root d‘installazione che include i WAR files (flex.war, samples.war e il flex-admin.war)
• flex_sdk_2 directorycontiene il framework e il compilatore
• resources directorycontiene gli installer per il  Flash Player 9 e files utilizzati per HTML Wrapper, clustering, Hibernate etc.
• UninstallerData directorycontiene gli uninstaller.

Per portare a termine l‘installazione sul deployment enviroment è necessario copiare i tre file WAR, presi dalla Files folder della directoyr fds2, nella cartella webapps di Tomcat (yourDrive:Program FilesApache Software FoundationTomcat_5_5webapps). Il file Flex.war è una Web application directory che contiene classi Java, filters e listeners per interpretare le applicazione Flex scritte in MXML e Actionscript. Copiando i 3 file WAR all‘interno della webapps di Tomcat, automaticamente il web server riconoscerà  i file, li scompatterà , creerà  una web application espansa e ne effettuerà  il deploy.

Adesso all‘interno della webapps ci sono altre 3 cartelle: Flex, Flex-admin, Samples. Potete già  da ora testare la corretta installazione e funzionamento dei Flex Data Services lanciando gli esempi contenuti nella folder Samples

http://127.0.0.1:8080/samples/.

Se la vostra applicazione Flex Data Services utilizza i Data Services, Tomcat ha necessità  di avere installato e correttamete configurato il package JOTM (Java Open Transaction Manager). JOTM è un gestore di transazioni JTA-compliant che implememta il protocollo XA e che provvede al supporto per la transazioni EJB e per progetti con Servlets container.

Dall‘indirizzo

http://forge.objectweb.org/projects/jotm/

scaricate l‘ultima versione dei JOTM. Scompattate il file e copiate il contenuto (JAR files) nella cartella jotm-root/lib to tomcat-root/common/lib. Rimane solo da fare le configurazioni all‘interno del file di configurazione dell‘applicazione, nel nodo la definizione della Transaction:

Riavviate Apache Tomcat service e avete eseguito tutti gli step per il deploy dei Flex Data Services sotto Tomcat sulla macchina di produzione. NOTE: Per appronfodire la procedura d‘isntallazione di FDS su Tomcat potete leggere la documentazione di supporto di Adobe

http://www.adobe.com/support/documentation/en/flex/2/install.html#tomcat

Prima di poter andare a lavorare con i RemoteObject è necessario andare a configurare alcuni file nella cartella Flex Data Services:

• service-config.xmlquesto file contiene le definizioni dei channels, dei settaggi per i logs e alcuni settaggi per la sicurezza
• remoting-config.xmlè il file più importante perché è quello che definisce la configurazione della destinazione dei Remoting Service per lavorare con i RemoteObject sul client
• proxy-config.xmldefinisce le destinazioni dei Proxy Serviceper poter lavorare con i web services e le chiamate HTTP
• messaging-config.xmlper la gestione dei Messaging Services
• data-management-config.xmlper la gestione dei Data Services

Ecco un esempio di configurazione per il file services-config.xml:

 
ÂÂ

 
ÂÂ

 
ÂÂ

 
ÂÂ

All‘interno del file remoting-config.xml andiamo a definire la destinazione del RemoteObject andando a puntare alla classe remota Java:

class="flex.messaging.services.RemotingService"
messageTypes="flex.messaging.messages.RemotingMessage">

class="flex.messaging.services.remoting.adapters.JavaAdapter"
default="true"/>

 
  com.mokabyte.business.myException 
  application
 

Andiamo a vedere un esempio di utilizzo di RemoteObject che potete trovare in uno degli ultimi libri su Flex 2 a cui ho partecipato come co-autore: “Flex 2 Professional” edito dalla Wrox. Creiamo una classe Java:

import flex.messaging.MessageException;
import java.util.HashMap;
import java.util.Map;

public class myException
{
 
 public String generateMessageException(String extraData)
 {  
  MessageException me = new MessageException("Testing extendedData.");
  Map extendedData = new HashMap();
  extendedData.put("extraData", extraData);
  me.setExtendedData(extendedData);
  me.setCode("999");
  me.setDetails("Hello World");
  throw me;
 }
}

Il seguente codice MXML invoca il metodo pubblico della classe Java:

http://www.adobe.com/2006/mxml" 
creationComplete="init()"> ÂÂ

import mx.rpc.events.*;
import mx.messaging.messages.*;

 public var dataString:String = "Extra data.";

 public var actualData:String;

public function onServiceFault(event:FaultEvent):void
{
actualData = ErrorMessage(event.message).extendedData.extraData;
}

 public function runException():void
 {
  var call:Object 
  = myException.generateMessageExceptionWithExtendedData(dataString);
 }

 public function init():void
 {
  runException();
 }
ÂÂ

id="myException"
fault="onServiceFault(event)" />

Flex Data Services o Flex 2 SDK ?

Con il Flex 2 SDK è possibile creare applicazioni che richiamano dati remoti esterni attraverso il servizio HTTPService o il WebService senza quindi poter accedere alle funzionalità  server side che invece richiedono i Flex Data Services (RemoteObject).

Questa è la grande differenza tra i due servizi Flex.

I Flex Data Services permettono quindi di creare applicazioni più complesse per la gestione di dati remoti (Enterprise), accedendo ad una serie di features avanzate per l‘uso di servizi proxy lato server.
In particolare i Flex Data Services provvedono alla sincronizzazione tra i dati, all‘aggiornamento dei dati in real-time, alla replicazione dei dati, alle applicazioni occasionally-connected (quelle che possono funzionare anche offline) e all‘integrazione di data sources remoti attraverso degli adapters. Queste funzionalità  avanzate permettono quindi di sviluppare applicazioni che lavorano con dati distribuiti e permettono la gestione di collections di dati complessi e tra loro in relazione.

La risposta alla domanda “Quando usare i Flex Data Services invece che il semplice Flex 2 SDK?” è a questo punto semplice.

I componenti RPC dei Flex Data Services permettono di creare applicazioni Enterprise come il proxying di traffico di servizi tra differenti domini, autenticazioni lato client, server-side logging, supporto per la localizzazione e gestione centralizzato dei servizi RPC. Inoltre attraverso l‘uso del RemoteObject è possibile accedere a metodi di classi Java remote, accedendo a complesse architetture Java EE che comunicano con l‘applicazione Flex 2 attraverso l‘invocazioni di EJB, POJO (o qualsiasi altro servizio Java remoto), senza ricorrere a configurazioni SOAP-compliant (webservices).

È infatti possibile creare applicazioni Flex con i Flex Data Services che utilizzano Struts, Spring, Liberante. Quando si utilizzano i Flex Data Services invece di contattare direttamente i servizi, i componenti RPC contattano i destinations, servizi di endpoint che possono essere gestiti attraverso file di configurazione lato server basati su XML.

Dei Flex DataServices fanno parte i Data Management Service che permettono agli sviluppatori di creare applicazioni che lavorano con dati distribuiti. Sono questi servizi che permettono di usufruire delle funzionalità  in grado di occuparsi della sincronizzazione tra i dati, all‘aggiornamento dei dati in real-time, alla replicazione dei dati, alle applicazioni occasionally-connected.
Un componente DataService lato client, che è possibile creare ed istanziare attraverso codice MXML o Actionscript, chiama metodi di un “destination” lato server dei Data Management Service per eseguire attività  come la sincronizzazione dei dati tra il server ed il client.

Infine i Flex Messaging Services offrono le funzionalità  per applicazioni collaborative, ovvero applicazioni che possono inviare messaggi e riceverli da altre applicazioni, incluse le applicazioni che utilizzano i Java Message Service.

Quindi le potenzialità  dei Flex Data Services possono fare la differenza nella creazione e distribuzione di applicazioni RIA Enterprise.

Dal web al desktop: portare “in locale” una Flex application con il runtime Adobe Apollo

Di Adobe Apollo si parla da tempo ed è una delle teconologie più attese del 2007. Rappresenta inoltre per Adobe il primo vero esperimento (facciamo finta di aver dimenticato Macromedia Central) di guadagnare fette di un mercato dove per ora il dominio assoluto è di Microsoft e qualche fetta della Sun. Ma cos‘è Apollo?
Apollo è il nome in codice per un sistema di runtime cross platform (indipendente dal sistema operativo) che permetterà  agli sviluppatori di portare le loro conoscenza di sviluppo di Rich Internet Application per il web (Flash, Flex, HTML, JavaScript, Ajax) sul desktop.
Da tempo si parla di nuovi approccio allo sviluppo di applicazioni web con definizioni come Rich Internet Application e Web 2.0. Flex, Flash, Actionscript ma anche AJAX (Javascript e HTML) sono le tecnologie a supporto di queste nuove applicazioni che aumentano notevolmente l‘esperienza dell‘utente nella loro fruizione.
Ma si tratta sempre di applicazioni Web e come tali devono necessariamente essere caricate all‘interno del browser. Inoltre non possono funzionare in modalità  offline, ma necessitano di un collegamento constante ad internet.
Il progetto Apollo di Adobe (www.adobe.com/go/apolllo) ha l‘obiettivo di portare le Rich Internet Application dal Web al Desktop in una modalità  che fonde le caratteristiche migliori di entrambi i mondi di sviluppo.

Gli sviluppatori saranno in grado di migrare le loro applicazioni create per il web e renderle fruibili anche offline usufruendo inoltre di funzionalità  per l‘accesso al file system e al supporto della programmazione delle finestre di sistema.
Tutto questo in un contesto indipendente dal sistema operativo. Infatti la definizione di Apollo è proprio “… un sistema runtime cross-platform che permette agli sviluppatori di ampliare i loro skill per lo sviluppo di applicazioni web (Flash, Flex, HTML, JavaScript, Ajax) per creare Rich Internet Apllication per il desktop” (per ulteriori informazioni leggete le Apollo Developer FAQ di cui una versione in italiano si trova su www.augitaly.com/apollo).

Apollo si programma con Flex Builder 2, usando Actionscript 3, JavaScript e il semplice HTML. Chiunque è già  da oggi in grado di creare un applicazione desktop per Apollo. Una delle caratteristiche principali del runtime di casa Adobe è infatti quella di supportare Javascript e HTML sfruttando un famoso HTML engine WebKit (http://webkit.org).

WebKit è un web browser engine open source usato da Safari e molte altre applicazioni OS X. Le motivazioni che hanno portato Adobe alla scelta di un HTML engine da inglobare nel runtime desktop sono: riutilizzo di applicazioni e serivizi web già  esistenti supporto ai layout che utilizzano il CSS Box model, costruzione di complesse interfacce HTML, supporto ai mobile devices.

Il WebKit è usato anche dai browser dei dispositivi Nokia S60. Per gli sviluppatori, questo si traduce nella possibilità  di importare applicazioni o servizi web già  esistenti ed interagire con essi all‘interno delle loro applicazioni desktop di prossima generazione (per esempio GoogleMap) (http://casario.blogs.com/mmworld/2006/10/google_maps_tur.html) o Amazon.

Le applicazioni Apollo sono formate da una serie di file che vengono poi compilati in un file con estensione AIR usando il compilatore ADL (Apollo Deployment Tool) con una sintassi molto vicina a quella usata per file jar:

adl -runtime ..runtime application.xml 
adl -package HelloWorld.air application.xml HelloWorld.swf

I file che verranno passati al compilatore sono i seguenti: contents file: html, swf, js etc data file: text, xml etc metadata: application.xml file.

Creare un‘applicazione Apollo può quindi essere del tutto simile a creare un‘applicazione Flex, basandosi sullo stesso ambiente di sviluppo.

1. Come per una qualsiasi applicazione Flex, create dal menu di Flex builder 2 “File” la voce “Nuovo”.ÂÂ
2. Selezionate “Apollo project”, quindi cliccate su “Next”.ÂÂ
3. Si aprirà  la finestra di un nuovo progetto Apollo.ÂÂ
4. Lasciate selezionato la voce “Basic”, quindi proseguite con “Next”.ÂÂ
5. Nella schermata successiva, salvate subito il file (chiamandolo ad esempio: “primoLavoroApollo”) lasciando selezionate le impostazioni di default. Quindi proseguite con “Next”ÂÂ
6. Proseguite con “Next” anche nella schermata successiva, lasciando inalterate le impostazioni. Si aprirà  il pannello delle proprietà  dell‘applicazione XMLÂÂ
7. Specificate quanto segue per impostare l‘applicazione Apollo. ID –> primo.lavoro.Apollo Name –> Apollo 1 Publisher –> Mario Rossi Description –> Prima prova con Apollo Copyright –> Mario Rossi. All Rights Reserved.

Fate bene attenzione al nome che assegnate al campo ID: questo infatti identificherà  l‘applicazione univocamente.
Il valore inserito nel campo name invece si riferirà  al nome dell‘applicazione che verrà  mostrato all‘utente nella title-bar della finestra. Gli altri campi sono puramente facoltativi.
I valori poc‘anzi inseriti saranno salvati nel file descrittore dell‘applicazione con il nome: primoLavoroApollo-app.xml
Concludete facendo click su “Finish”.
Ora che il progetto è pronto, si può cominciare a scrivere il codice MXML per l‘applicazione.
La finestra principale di Adobe Flex dovrebbe presentarsi più o meno così:

http://www.adobe.com/2006/mxml"

layout="absolute" title="Primo Lavoro con Adobe Apollo" backgroundcolor="0xFFAA00">

fontsize="14" horizontalcenter="0" verticalcenter="0">

Come vedete anche a colpo d‘occhio abbiamo aggiunto due attributi (title e backgroundColor) al componente ApolloApplication, il cui uso è ovviamente comprensibile.
Quindi abbiamo usato il componente “Label”, con tre attributi, per scrivere la nostra frase.
Salviamo il file e proviamo a visualizzare quanto fatto finora.
Cliccate sul pulsante Debug.
A schermo dovreste visualizzare una finestra (tipo quelle di Windows) con il titolo in alto “Primo Lavoro in Apollo”. Al centro (orientativamente) la frase: “Questo testo è stato scritto con Apollo in Flex”.
Nel pannello Console di Flex non dovrebbero apparire errori. Tuttavia se ciò dovesse verificarsi ricontrollate i passaggi precedenti.
Potenzialmente la nostra applicazione è terminata. Bisognerà  ora concludere, creando il file AIR conclusivo.
Per distribuire i lavori di Apollo bisognerà  utilizzare le librerie del file AIR. Vediamo tuttavia come si crea il file finale.

1. Con il progetto ancora aperto in Flex, selezionate dal menu la voce “Export”.ÂÂ
2. Dal pannello che si aprirà  selezionate “Deployable AIR file” e cliccate su “Next”.
3. Trovate e selezionate il file primoLavoroApollo-app.xml nella lista e quindi cliccate su “Next”.
4. Nel pannello successivo sarà  possibile aggiungere alcuni asset ausiliari (come SWF file, HTML files o media files) che vorrete eventualmente includere nell‘applicazione, anche se ora non è il nostro caso.
5. Terminate facendo click sul pulsante “Finish”

Il progetto è ora concluso. Potrete testarlo facendo doppio click sul file con estensione AIR.
Affinchà© l‘utente finale possa lanciare ed eseguire l‘applicazione AIR deve avere installato sulla propria macchina il runtime di Apollo (scaricabile dal sito: www.adobe.com/go/apollo).

Quasi dimenticavo che questa fantastica tecnologia verrà  distribuita del tutto gratuitamente! Apollo sembra davvero promettere bene. Quello che è stato mostrato alla MAX Conference 2006 ha lasciato tutti senza parole, ma le potenzialità  della tecnologia si potranno apprezzare solo quando il runtime sarà  stato utilizzato per un po‘ dagli sviluppatori.

Conclusioni

In questo secondo articolo siamo andati più in profondità  di Flex e abbiamo visto come effettuare delle chiamate remote utilizzando le tre classi RPC che mette a disposizione. Abbiamo utilizzato i Flex Data Services per utilizzare i RemoteObject e accedere quindi a metodi Java pubblici. Con i due articoli ho solo voluto dare una panoramica più precisa anche se non esaustiva riguardo alla linea di prodotti Flex 2.

Se volete saperne di più su Flex e Apollo e rimanere sempre aggiornati mi raccomando di inserire sul vostro browser o blog aggregator i bookmark che trovate qui sotto, nei Riferimenti. Per ora concludo con una importante novità : a breve Adobe annuncierà  Flex 3 e lo renderà  Open Source!

Riferimenti

Adobe Apollo User Group
http://www.augitaly.com/flexgala

Mike Chambers, (Product Manager di Apollo)
http://weblogs.macromedia.com/mesh/

Marco Casario, Apollo Category
http://casario.blogs.com/mmworld/apollo/index.html

Apollo Home Page
http://labs.adobe.com/wiki/index.php/Apollo

Adobe User Group italiano FlexGala
http://www.augitaly.com/flexgala