Luis Carlos Quinhone -Designer / Developer

Este material é uma tradução do original http://code.google.com/intl/pt-BR/apis/maps/documentation/flash/intro.html#Versioning e todos os crédito são da Google, eu apenas traduzi o mesmo para o Português, ainda terão mais 5 partes que serão os exemplos de uso, já estou traduzindo e logo estará online. Se vocês querem Screencast sobre o assunto, pede pro Vedovelli que ele com certeza fará, se já não o fez.O Google Maps API para Flash fornece um novo caminho para adicionar Google Maps interativo para seu site da web, usando plugin Flash® da Adobe para exibir conteúdo de mapas dinâmicos! Esta API existe como uma alternativa completamente independente do existente JavaScript Maps API, e fornece muitas das características daquela API enquanto também adicionando a habilidade de se misturar conteúdo de Flash com Google Maps.
O Google Maps API para Flash é novo, então nós gostaríamos de ouvir seu feedback. Nós o encorajamos a dar a nós um feedback.

Público

Esta documentação é projetada para as pessoas que tem familiaridade com Flash, Programação de ActionScript, conceitos de programação orientado a objeto.
Esta documentação é organizada para cobrir as seguintes áreas chave:

• Google Maps Flash Basics (and “Hello World” Tutorial)
• Google Maps Flash Events
• Google Maps Flash Controls
• Google Maps Flash Overlays
• Google Maps Flash Services

Todos os novos desenvolvedores deviam ler ambos os documento, que explicam como instalar seu Google Map no ambiente de desenvolvimento Flash/Flex e mantê-lo, e , que explica como escrever sua primeira aplicação Google Maps Flash.

Introdução

Fornecendo uma versão de Flash, o Google Maps API permite aos desenvolvedores de Flash atuais integrar facilmente o Google Maps em seu ambientes de desenvolvimento Flash/Flex existente. Também, o Google Maps API para Flash abre um mundo inteiro de possibilidades interativas para exibir e usar conteúdo de mapa para aqueles desenvolvedores que não usam atualmente Flash.
Este guia de desenvolvedor assume que você está familiarizado com desenvolvimento de Flash e programação de ActionScript. Também não assume uso de qualquer ambiente de desenvolvimento particular, entretanto ele usa o Adobe Flex SDK livremente disponível dentro deste tutorial.
Note: Este guia usa exemplos da linha de comando COMO UNIX, entretanto seu uso não deve prejudicar a um ou outro desenvolvedores de Windows ou Macintosh.

Instalando Seu Ambiente de Desenvolvimento

O desenvolvimento de flash pode tomar muitas formas. Alguns desenvolvedores criam puramente dentro da aplicação de Flash para criar e organizar conteúdo, e adiciona ActionScript dentro daquele framework. Outros desenvolvedores usam uma IDE full-featured como Adobe® Flex® Builder para criar aplicações robustas com uso pesado de ActionScript. A escolha de ambiente de desenvolvimento é sua. Para este tutorial, porém, nós nos concentraremos em documentar o mais simples e a maioria da solução geral: O uso livre do Adobe Flex SDK 3 pela linha de comando.
Esta seção discute como obter e instalar o Adobe Flex SDK, como obter o Google Maps API para biblioteca do Flash, e como instalar seu ambiente de desenvolvimento para você conseguir programar em ActionScript e construir seu primeiro Google Maps API para Flash Maps.

Obtendo e Instalando o Adobe Flex SDK

Estarei omitindo aqui essa parte já que a maioria já deve ter instalado na sua máquina o Flex, mas quem não tiver pode ir nesse endereço.
http://www.adobe.com/products/flex/overview/#section-3

Obtendo a Biblioteca de Interface

O conteúdo para desenvovimento em flash que integra Google Maps exige a inclusão do Google Maps API para biblioteca de interface de Flash dentro de seu código de aplicação. Esta biblioteca consiste em um arquivo *.swc que é contido dentro da API de Maps para Flash/Flex SDK disponível na seguinte URL:

http://maps.googleapis.com/maps/flash/release/sdk.zip

Este arquivo SWC contém interfaces para todas as classes públicas no Google Maps API para o ambiente de desenvolvimento Flex/Flash. Compilando sua aplicação com esta biblioteca assegura que pode utilizar e comunicar com toda funcionalidade pública do runtime Google Maps API para biblioteca do Flash, que é recuperado de servidores do Google sempre que um cliente carrega sua aplicação.
Note que o tamanho do código que está correndo atualmente sua aplicação Flash Maps permanece separado do runtime que Google Maps API da biblioteca do Flash. Isto permite que façamos encarecimentos, bugs e modificações para a funcionalidade da core library sem exigir que você recompile sua aplicação. Note que se você já desejar utilizar nova funcionalidade que exige novas interfaces, você precisará carregar um SWC atualizado e recompilar sua aplicação.
A biblioteca de interface filename contém um sufixo identificando seu número de versão. (Por exemplo, map_flex_1_1 identifica versão “1.1″ da biblioteca de interface. Uma vez que você carregou a biblioteca de interface, crie um diretório de desenvolvimento e coloca o arquivo na raiz daquele diretório.

CÓDIGO UNIX:

# #Create a development directory
#

hostname$ mkdir myflashapp
hostname$ cd myflashapp

# # Copy the Google Maps API for Flash SDK to the root of your working development directory
#

hostname$ cp ~/sdk.zip

# # Unzip the SDK. The SWC interface library is located within the “lib” directory # Offline ASDoc HTML documentation is available within the “docs” directory
#

hostname$ unzip sdk.zip

Obtendo uma Maps API Kye

O Google Maps API para Flash, como o Google JavaScript Maps API, exige uso de um freely available developer key que você precisará especificar esta clave dentro de um dos três locais possíveis:
· Seu código ActionScript (compilando isto no SWF resultante)
· Um arquivo de configuração especial chamando uma declaração MXML
· O container DOM element em suas página da Web.
Este conjunto de documento discute as duas técnicas posteriores.

Instalando seus Diretórios de Desenvolvimento

O Google recomenda que você desenvolva sua aplicação usando um unico namespace que você possui, para prevenir colisões com outras aplicações, especialmente se você terá muitos desenvolvedores que trabalham em aplicações de flash múltiplo ao mesmo tempo. Usando namespaces também permite que você empacote seu código de aplicação em packages, que permita mais facilidade no compartilhando de código comum.
Os pacotes e namespaces devem ser definidos usando seu domínio de organização, e sub-domínio. Por exemplo, o Google Maps namespace é definido como com.google.maps e um pacote de exemplos dentro daquele namespace seriam definidos como com.google.maps.examples. Você pode então usar este namespace implicitamente para definir a estrutura de diretório de sua aplicação (por exemplo com/google/maps/examples/).
Você usará este namespace para definir um pacote dentro de seu código ActionScript, e definir sua aplicação dentro da declaração de MXML. Geralmente, ActionScript (*.as) reside dentro do diretório mais baixo de qualquer namespace que é definido, enquanto as declarações de MXML (*.mxml) residam na “raiz” da estrutura de diretório.

A base Cairngorm Event Flow que é tratada na parte 3 é essencial para qualquer aplicação Cairngorm, mas a maioria das aplicações interage com um servidor. O Serviço para trabalhar com o padrão que foi discutido no tutorial anterior é fundamental para este processo. Para aprender e expandir o Cairngorm Flow, você precisa aprender alguns novos elementos do Cairngorm.

O Servidor - Interações e Elementos

Existem três novos tipos de classes que você precisará estar familiarizado com a compreender o pleno Serviço Worker Pattern.

• ServiceLocator [Referência] - O ServiceLocator é um singleton que contém referências para todos os serviços que a sua aplicação irá utilizar. E geralmente inclui chamadas HTTPService, WebService, ou RemoteObject.
•  Business Delegate - O Business Delegate tem três funções: para localizar o serviço que é necessário, para efetuar uma chamada para um método sobre o serviço, bem como a rota do resultado para o especificado respondedor. Geralmente, há uns Negócios delegados para cada serviço.
• Value Object – Value Objects são classes que por definição não exigem qualquer métodos, apenas propriedades. Eles permitem a aplicação transferir dados strongly-typed  complexos do objetos para e do servidor.

Organizando seu projeto Cairngorm (Com Server Interaction)

No último tutorial você viu o padrão da estrutura de um projeto Cairngorm. Para completar esta estrutura, você precisará adicionar duas novas pastas:

• /business - Esta pasta contém normalmente dois tipos de arquivos: o ServiceLocator (chamado Services.mxml) e Business Delegates.
• /vo - Esta pasta contém o valor dos objetos que são passados de e para o servidor

Entendendo o processo

Antes de começar a elaborar a interação com servidor para o seu projeto, você precisa entender o pleno Serviço Worker pattern. A Figura 1 ilustra todo o processo.

Figure 1 - Cairngorm Event Flow with Server Interaction

Fase I – Executando

• O usuário está visualizando um componente que tem um botão login. Quando o botão é clicado, esse componente enviará um evento chamado LoginEvent que se estende do CairngormEvent.
• O FrontController irá receber o LoginEvent e executar o comando que é mapeado para o evento. Para este exemplo, será nomeado LoginCommand e implementará ICommand.
• O comando é executado e receberá o LoginEvent como um argumento. O LoginCommand cria uma instância Delegate enquanto passar uma referência ao Responder. O Comando então chama o método especificado no Delegate.
• O Delegate recebe o serviço do ServiceLocator e convida o método específico sobre o serviço.
• O serviço definido no ServiceLocator recebe as informações que são passadas para ele a partir da chamada do Delegate.

Phase II – A Aplicação processa a camada
Phase III – Responde

• O serviço que está definido no ServiceLocator retorna o resultado do processamento do lado do servidor.
• O Delegate recebe o resultado e passa-o para o responder  especificado.
• O Responder recebe o resultado indicando um login bem-sucedido.
• O ModelLocator terá uma constante predefinida para o " Logged in View ". O Responder mudará workflowState para este valor.
• Desde o ponto de vista é obrigado a workflowState, irá automaticamente atualizar-se para a nova posição.

Nota: Tradicionalmente, o Command e Responder eram da mesma classe em uma aplicação Cairngorm. Se estiver trabalhando com outros desenvolvedores, os pedidos serão provavelmente codificados desta forma. Contudo, a maioria dos desenvolvedores (incluindo Adobe Consulting) estão agora separando estas classes em duas classes diferentes. Pelo menos em um projecto complexo, é possível que não faça sentido para esses itens separados, mas em um grande pedido poderá ser vantajosa na organização e prática para ter duas classes diferentes

O ServiceLocator

O ServiceLocator é um singleton que contém referências para todos os serviços que o pedido será utilizado. Esses serviços podem ser RemoteObjects, HTTPServices, WebServices, personalizado ou serviços. Tal como o FrontController, esta classe é geralmente instanciado no seu arquivo principal da aplicação. Ao contrário de muitos dos outros projetos Cairngorm que você criou, esta classe pode ser definida em MXML (bem como ActionScript). Para definir corretamente esta em MXML, deve haver um namespace que aponta para a pasta business da pasta Cairngorm. Neste caso, o namespace cairngorm é tipicamente usado. O ServiceLocator no Código Exemplo 1 dispõe de um serviço definido, loginService

Actionscript:

• <?xml version="1.0" encoding="utf-8"?>
• <cairngorm:ServiceLocator
•     xmlns:cairngorm="com.adobe.cairngorm.business.*"
•     xmlns:mx="http://www.adobe.com/2006/mxml">
•    
•     <!– Login Service –>
•     <mx:RemoteObject id="loginService"
•         showBusyCursor="true"
•         destination="ColdFusion"
•         source="CairngormTest.CairngormLogin">
•        
•         <mx:method name="login" /> 
•        
•     </mx:RemoteObject>
•    
• </cairngorm:ServiceLocator>

Code Example 1 - Simples ServiceLocator

O ServiceLocator é normalmente chamado Services.mxml e reside na pasta business do seu projeto Cairngorm
 Comandos com Server Interaction
No último tutorial você hard-coded alguns valores no LoginCommand para verificar se um determinado nome de usuário e senha. Aqui foi o método execute:

Actionscript:

public function execute(event:CairngormEvent):void {

    var loginEvent:LoginEvent = event as LoginEvent;

    if( (loginEvent.username == "david") && (loginEvent.password == "password")) {

        modelLocator.workflowState = ViewModelLocator.WELCOME_SCREEN;

    }

}

Code Example 2 – Comandos com Without Delegate

Esta metodologia será uma realidade para qualquer comando que não tem interação com o servidor, mas se você tem interação com o servidor, terão de ser modificados para incluir o delegate. Primeiro você terá que tomar uma decisão. Tal como referido anteriormente, você pode ter separado Comandos e respondedores, ou eles podem ser a mesma classe. Para este exemplo, que será a mesma classe. O Comando irá agora também ter necessidade de se implementar a classe mx.rpc.IResponder (observe que com.adobe.cairngorm.business.Responder está obsoleta e deve deixar de ser utilizado).

A outra alteração inicial é que execute o método agora instanciando uma classe chamada LoginDelegate (que será criado em breve). A classe LoginDelegate exigi um argumento em seu construtor, o Respondedor do serviço. Neste caso, o comando irá funcionar tanto como o comando e a resposta, assim você só precisa inserir a palavra-chave this dentro do parêntese. Se optar por ter um respondedor separado, você iria inserir a referência a ele aqui (em vez da palavra-chave this).

Actionscript:

package net.davidtucker.CairngormSample.commands {

   import com.adobe.cairngorm.commands.ICommand;

    import com.adobe.cairngorm.control.CairngormEvent;

    import mx.controls.Alert;

    import mx.rpc.IResponder;

    import net.davidtucker.CairngormSample.business.LoginDelegate;

    import net.davidtucker.CairngormSample.events.LoginEvent;

    import net.davidtucker.CairngormSample.model.ViewModelLocator;

   

    public class LoginCommand implements ICommand,IResponder {

   

        public var modelLocator:ViewModelLocator = ViewModelLocator.getInstance();

       

        public function LoginCommand() {

        }

       

        public function execute(event:CairngormEvent):void {

            var loginEvent:LoginEvent = event as LoginEvent;

            var delegate:LoginDelegate = new LoginDelegate( this );

            delegate.login(loginEvent.loginAttempt);

        }

       

        public function result( event:Object ):void {

            if(event.result == true) {

                modelLocator.workflowState = ViewModelLocator.WELCOME_SCREEN;

            } else {

                mx.controls.Alert.show("Password Incorrect","ERROR");

            }

        }

       

        public function fault( event:Object ):void {

            trace("Service Error");

        }

       

    }

}

Code Example 3 - Command with Server Interaction Through a Delegate

Value Objects

O Value Object não prorrogar ou implementa qualquer classe Cairngorm. Tal como referido anteriormente, ele simplesmente é uma classe que só é obrigado a ter propriedades, mas não métodos. Por exemplo, se você criou um Value Object para uma entrada - ele teria uma propriedade de um nome de usuário e senhaActionscript:

 

package net.davidtucker.CairngormSample.vo {

    [RemoteClass(alias="CairngormTest.LoginVO")]

    public class LoginVO {

        public var username:String;

        public var password:String;

        public function LoginVO(username:String,password:String) {

            this.username = username;

            this.password = password;

        }

    }

}

Code Example 4 - Value Object for Login

A metatag RemoteClass é importante notar. Esta permitirá o correspondente objeto server-side  (Componente do ColdFusion, classe PHP, Classe de Java, etc…) Para ser mapeado para este Valor de Objeto. Neste caso, é mapeado para um componente do ColdFusion chamado LoginVO no pasta  CairngormTest..
Business Delegates
O padrão de projeto final na Micro-Arquitetura do Cairngorm é o Business Delegate. Uns Business Delegate essencialmente é a camada de abstração entre seus serviços e o resto da sua aplicação. Como declarado anteriormente, tem três funções. Primeiras, o Business Delegate localizará o serviço que é necessário no ServiceLocator. Segundo, solicitará um método de serviço. Finalmente, ele criará uma rota de resposta que volta para o responder especificado (normalmente ou um comando responder separado).
Uma classe Delegada não estende ou implementa classes Cairngorm, mas ela geralmente segue as seguintes diretrizes.

•          O Delegate tem pelo menos duas propriedades: Uma chamada serviço o qual é uma referência para um serviço no ServiceLocator e um chamado responder que é a resposta para as chamadas de serviço.
•          Existe um método para cada método server-side que você estará chamando.
•          Ambos o responder e as variáveis de serviço são fixadas no construtor.

Actionscript:

package net.davidtucker.CairngormSample.business {

   

    import mx.rpc.IResponder;

    import net.davidtucker.CairngormSample.vo.LoginVO;

    import com.adobe.cairngorm.business.ServiceLocator;

   

    public class LoginDelegate {

        private var responder : IResponder;

        private var service : Object;   

       

        public function LoginDelegate( responder:IResponder ) {

            this.responder = responder;

            this.service = ServiceLocator.getInstance().getRemoteObject("loginService");

        }

       

        public function login(login:LoginVO):void {

            var call:Object = service.login( login );

            call.addResponder( responder );

        }

       

    }

}

Code Example 5 - Service Delegate

Existem muitos benefícios em ter esta camada. Se codificada corretamente, você deve ser capaz de mudar a interação de servidor (indo de PHP até ColdFusion por exemplo) e só ter que mudar o código em seu ServiceLocator e seu Delegate. Você também pode facilmente inserir "stub code" simular a interação de servidor real durante as primeiras fases de desenvolvimento.
The Application Tier
Neste exemplo, a Camada de Aplicação será lidada por uma instalação do ColdFusion 8. Conterá dois componentes de Coldfusion. Estes componentes são propositadamente simples.

1. LoginVO.cfc - Este componente corresponderá a classe ActionScript LoginVO que você criou anteriormente.
2. CairngormLogin.cfc - Este componente apresentará o processo de login atual.

Neste exemplo, A aplicação Flex passará por um objeto LoginVO ActionScript para o método login do CairngormLogin.cfc por uma chamada RemoteObject. Isto será mapeado para um objeto de LoginVO.cfc. Se este objeto LoginVO.cfc tem o username "David" e a senha de "password" o método retornará true. Se não, retornará false.

Coldfusion:

<cfcomponent displayname="LoginVO" hint="Login VO For CairngormTest" output="false">

 

    <cfset this.username = "" />

    <cfset this.password = "" />

   

</cfcomponent>

Code Example 6 - LoginVO.cfc

Coldfusion:

<cfcomponent displayname="CairngormLogin" hint="CFC to Test Cairngorm Service Interaction" output="false">

    <cffunction name="login" displayname="login" access="remote" output="false" returntype="boolean">

        <cfargument name="loginAttempt" type="LoginVO" required="true" />

            <cfif (loginAttempt.username EQ "david") AND (loginAttempt.password EQ "password")>

                <cfreturn true />

            <cfelse>

                <cfreturn false />

            </cfif>

    </cffunction>

</cfcomponent>

Code Example 7 - CairngormLogin.cfc