Práticas recomendadas - Diretrizes de criação de aplicativos SWF

A melhor maneira de se criar aplicativos do Animate depende do aplicativo criado e da tecnologia usada para montá-lo.

Um aplicativo on-line permite que o usuário tenha influência sobre o site da web, interagindo com ele. Por exemplo, o aplicativo pode colher informações do usuário (como nome de usuário e senha para registro), informações podem ser acrescentadas ao site (como em um forum) ou o usuário pode interagir em tempo real com outros visitantes do site (como em uma sala de bate-papo ou lousas interativas). Os resultados do servidor frequentemente aparecem no arquivo SWF, dependendo da interação. Esses exemplos são aplicativos que envolvem o usuário e tipos diferentes de interação do servidor. Um site da web que não use dados ou informações dos visitantes não é um aplicativo (por exemplo, portfólio, desenho animado ou site de informações estático). Os aplicativos do Animate envolvem um processo interativo entre o usuário, um aplicativo da Web e um servidor. O processo básico é o seguinte:

Quando você monta um aplicativo, precisa selecionar um protocolo para a transferência de dados. O protocolo alerta o aplicativo quando os dados estão sendo enviados ou recebidos, o formato em que os dados são transferidos e como ele lida com a resposta do servidor. Após os dados serem recebidos no arquivo SWF, precisam ser manipulados e formatados. Se você usar um protocolo, não precisa se preocupar se os dados estão em formato inesperado. Quando transfere dados usando pares nome-valor, você pode verificar como os dados estão formatados. Verifique se os dados estão formatados corretamente, de modo a não receber dados em formato XML e o arquivo SWF sabe que dados esperar e trabalhar.

Coleta e formatação de dados

Os aplicativos dependem da interação do usuário com o arquivo SWF. Frequentemente, dependem do usuário digitar os dados em formulários. O Animate apresenta muitas maneiras de digitar e formatar dados nos aplicativos dele. Essa flexibilidade existe devido aos recursos que você tem com animação e controle criativo sobre a interface, a verificação de erros e a validação que pode executar usando o ActionScript.

Entre os benefícios do uso do Animate a fim de construir formulários para a coleta de dados estão:

• Maior controle do projeto.

• Menor ou nenhuma necessidade de atualização de página.

• Reutilização de recursos comuns.

   Para gravar as informações coletadas do usuário, grave-a em um objeto compartilhado no computador do usuário. Os objetos compartilhados permitem armazenar dados no computador do usuário, o que se assemelha a usar um cookie. Para obter mais informações sobre objetos compartilhados, consulte a classe sharedObject em Referência de linguagem do ActionScript 2.0 ou referência de componentes e linguagem do ActionScript 3.0.

Envio e processamento de dados

Em geral, você precisa processar as informações antes de enviá-las para o servidor, para que fiquem formatadas de modo que o servidor compreenda. Quando o servidor recebe os dados, estes podem ser manipulados de algumas maneiras e enviados de volta ao arquivo SWF em um formato que este possa aceitar, o que pode variar de pares nome-valor a objetos complexos.

 O servidor do aplicativo deve ter o tipo MIME da saída definido como application/x-www-urlform-encoded. Se não houver o tipo MIME, comumente o resultado não poderá ser usado quando ele chegar ao Animate.

A tabela seguinte mostra a você diversas opções para o envio de dados a um servidor e a recepção de dados usando o Animate:

Carregamento e validação dos dados incluídos

Valide todas as informações recuperadas antes de enviar esses dados para um servidor. Isso reduz o esforço no servidor remoto, que não precisará manusear tantos pedidos, como quando os usuários não preenchem todos os campos necessários. Nunca confie apenas na validação do lado do cliente em qualquer aplicativo; deve acontecer também a validação no lado do servidor.

Mesmo que você monte um formulário simples de registro ou de login, verifique se o usuário digitou o nome e a senha. Execute essa validação antes do envio do pedido para o script do lado do servidor remoto e de ficar esperando pelo resultado. Não confie apenas na validação do lado do servidor. Se o usuário digitar apenas o nome de usuário, o script do lado do servidor deve receber o pedido, validar os dados que estão sendo enviados e devolver uma mensagem de erro para o aplicativo do Animate, declarando que há necessidade do nome de usuário e da senha. Do mesmo modo, se a validação for executada apenas no lado do cliente (no arquivo SWF), um usuário poderia acessar ilegalmente o arquivo SWF, burlar a validação e enviar dados para o servidor na tentativa de enviar os dados ruins.

A validação do lado do cliente pode ser simplesmente assegurar-se que o campo do formulário tenha pelo menos o comprimento de um caractere ou que o usuário digitou um valor numérico e não uma string. Por exemplo, para validar um endereço de e‑mail, verifique se o campo de texto no Animate não está vazio e contém pelo menos os caracteres do sinal arroba (@) e do ponto (.) . Para a validação no lado do servidor, acrescente validações mais complexas e verifique se o endereço de e-mail pertence a um domínio válido.

Você precisa digitar o ActionScript para lidar com os dados carregados no arquivo SWF do servidor. Após terminar o carregamento dos dados no arquivo SWF, os dados podem ser acessados deste local. Use o ActionScript para verificar se os dados foram totalmente carregados. Você pode usar as funções ou os listeners de retorno para enviar um sinal de que os dados estão carregados no documento.

Quando você carrega dados, estes podem ser formatados de modos diferentes:

• Você poderia carregar XML, caso em que você usa as propriedades e métodos da classe XML, para analisar e usar os dados. Se usar pares nome-valor, os pares transformam-se em variáveis e você pode manipulá-los como variáveis.

• Você pode receber dados de um serviço de Web ou do Animate Remoting.

Nos dois casos, você poderia receber estruturas complexas de dados, como matrizes, objetos ou conjuntos de gravação, que precisará analisar e ligar adequadamente.

Uso do manuseio e da depuração de erros

Seu aplicativo precisa ser robusto o suficiente para antecipar determinados erros e manuseá-los de acordo.

Uma das melhores formas de manusear erros no ActionScript 2.0 é usar os blocos try-catch-finally que permitem lançar e capturar erros personalizados. Com a criação de classes de erros personalizados, você pode reutilizar o código por todo o aplicativo, sem ter que regravar o código de manuseio de erros. Para obter mais informações sobre o lançamento de erros personalizados, consulte a classe Erro na Referência de linguagem ActionScript 2.0. Para obter mais informações sobre os blocos try-catch-finally, consulte try..catch..finally na Referência de linguagem ActionScript 2.0.

No ActionScript 3.0, use a classe flash.errors para capturar erros.

Para obter mais informações, consulte “Manuseio de erros sincrônicos em um aplicativo” no Programação do ActionScript 3.0.

Organização de arquivo e armazenamento de código

Considere as diretrizes seguintes antes de começar a organização dos arquivos e o armazenamento do código:

• Você divide o arquivo SWF em múltiplos arquivos SWF e, se positivo, como eles devem interagir?

• Quais os recursos que você pode compartilhar através dos arquivos SWF?

• Quais os arquivos que são carregados dinamicamente?

• Como e onde você armazena o ActionScript?

  Quando você desenvolve um aplicativo, armazene o código e os arquivos do lado do servidor em uma estrutura lógica de diretórios semelhante às do pacote ActionScript. Ajuste seu código dessa forma, para mantê-lo bem organizado e reduzir o risco do código ser sobrescrito.

  Para aplicativos maiores, reúna os serviços e as comunicações cliente-servidor em classes. Quando você usa classes, tem os seguintes benefícios:

• Pode reutilizar o código em mais de um arquivo SWF.

• Pode editar o código em um local central e atualizar todos os arquivos SWF, reeditando-os.

• Você pode criar uma única API que possa manipular elementos de UI diferentes ou outros recursos que executem funções semelhantes.

Uso do padrão de projeto MVC

O padrão de projeto MVC é usado para separar as informações, saídas e processamento de dados em um aplicativo. O aplicativo é dividido em três elementos: modelo, visualização e controlador; cada elemento lida com uma parte diferente do processo.

incorpora os dados e as regras do aplicativo. Boa parte do processamento do aplicativo ocorre nessa parte do padrão de projeto. O modelo contém também todos os componentes (como CFCs, EJBs e serviços de web) e o banco de dados. Os dados retornados não estão formatados para a interface (ou linha de frente) do aplicativo nessa parte do processo. Os dados retornados podem ser usados para interfaces diferentes (ou visualizações).

lida com a linha de frente do aplicativo (a interface com que o usuário interage) e cria os conteúdos do modelo. A interface especifica como os dados do modelo são apresentados, fornece a visualização para uso do usuário e permite que o usuário acesse ou manipule os dados do aplicativo. Se o modelo mudar, a visualização se atualiza para refletir essas mudanças, empurrando ou atraindo dados (enviar ou solicitar dados). Se você criar um aplicativo de Web híbrido (por exemplo, um que inclua o Animate interagindo com outros aplicativos na página), considere as diversas interfaces como parte da visualização do padrão de desenho. O padrão de desenho MVC suporta o manuseio de diversas visualizações

lida com as exigências do modelo e da visualização para processar e exibir os dados e, comumente, contém muitos códigos. Ele chama qualquer parte do modelo, dependendo das solicitações do usuário na interface (ou visualização), e contém os códigos específicos do aplicativo. Como esse código é específico do aplicativo, em geral não é reutilizável. Entretanto, os outros componentes do padrão de projeto são reutilizáveis. O controle não processa ou produz qualquer dado, mas pega a solicitação do usuário, decide que parte do modelo ou da visualização precisa chamar e determina para onde mandar os dados e a formatação a ser aplicada aos dados retornados. O controlador garante que as visualizações tenham acesso a partes dos dados do modelo que precisam exibir. Normalmente, o controlador transmite e responde às mudanças que envolvem o modelo e a visualização.

Cada parte do modelo é construída como um componente autocontido no processo global. Se você mudar uma parte do modelo (por exemplo, você poderia refazer a interface), as outras partes do processo em geral não necessitam de modificação, o que reduz os problemas. Se o seu padrão de projeto for criado corretamente, você pode mudar a visualização sem refazer o modelo ou o controlador. Se o seu aplicativo não usar MVC, fazer mudanças em qualquer lugar pode causar um efeito de ondulação por todo o seu código, o que determina muito mais mudanças do que se você estivesse usando um padrão de projeto específico.

Um motivo importante para usar o padrão MVC é separar os dados e a lógica da interface do usuário. Com a separação dessas partes do processo, você pode ter diversas interfaces gráficas diferentes que usam os mesmos modelos e dados não formatados. Isso significa que você pode usar o aplicativo com interfaces diferentes do Animate, como uma interface para a Web, outra para o Pocket PC, uma versão para telefones celulares e, talvez, uma versão HTML que não use o Animate. A separação dos dados do restante do aplicativo pode reduzir enormemente o tempo de desenvolvimento, de teste e mesmo de atualização de mais de uma interface do cliente. Igualmente, acrescentar novas linhas de frente para o mesmo aplicativo é mais fácil, se houver um modelo existente para ser usado.

Use apenas o MVC se construir um aplicativo grande ou complexo, como um site da web de e‑commerce ou um aplicativo de e‑learning. O uso da arquitetura exige planejamento e a compreensão de como o Animate e este padrão de projeto funcionam. Considere cuidadosamente como as diferentes peças interagem entre elas, o que normalmente envolve testagem e depuração. Quando você usa o MVC, a testagem e a depuração são mais envolvidas e difíceis do que nos aplicativos comuns do Animate. Se montar um aplicativo no qual necessitará de maior complexidade, considere o uso do MVC para organizar o trabalho.

Criação de aplicativos seguros

Usuários desonestos podem tentar acessar ilegalmente seu aplicativo, seja ele um site de portal pequeno, onde usuários podem fazer login e ler artigos, ou uma grande loja de e-commerce. Por esse motivo, considere as seguintes etapas para tornar seu aplicativo seguro

• Envie os dados que precisem ser protegidos para o HTTPS Criptografe os valores no Animate antes de enviá-los a um servidor remoto para serem processados.

   Jamais armazene qualquer informação ou código em um arquivo SWF que não deseja que seja visualizado pelos usuários. É fácil dividir arquivos SWF e visualizar seus conteúdos usando software de terceiros.

• Inclua um arquivo de diretrizes entre domínios que impede que domínios não autorizados acessem seus recursos.