Recentemente percebi que muitos profissionais ainda possuem uma certa dificuldade em entender as tais nomenclaturas do ramo… como UX / UI / IxD / Guideline etc. Mas o que tenho visto de mais comum é o uso do termo Guideline para referenciar a User Interface, UI. É fato que a diferença entre ambos na idéia…
SharedObject é um recurso que dar ao Flash Player a capacidade de salvar dados localmente para poder ser usado posteriormente em sua aplicação, a grosso modo é como um cookie. Com o Flash Media Server, foi introduzido a possibilidade de usar o SharedObject Remote, no qual os dados são salvos no servidor Flash Media Server e compartilhados para todas as instâncias de uma conexão entre o Flash Player e o Flash Media Server. Isso possibilita a criação de aplicativos em real time como Dashboards, chats e o que mais a imaginação permitir.
O uso do SharedObject Remote pode ser usado de duas maneiras em conjunto com o Adobe Flash Media Server.
Vejamos o primeiro caso:
Caso você não tenha conhecimento para usar a linguagem Server-side do Flash Media Server, é possível utilizar o SharedObject Remote somente pelo ActionScript 3.0. Vamos a um exemplo clássico sharedBall, onde o objetivo é compartilhar as posições da bolinha a atualizar nos outros clientes conectados a mesma instância.
Feito isso, podemos testar o swf apertando Ctrl+Enter, se tudo correr bem, deveremos ter a seguinte mensagem no output do Flash:
NetConnection.Connect.Success
Com a conexão feita, podemos instanciar o nosso SharedObject Remote para compartilhar as posições de x e y da bolinha.
O handlerSync é responsável por atualizar os dados de x e y pegaremos do SharedObject Remote:
Daremos a opção de ao clicar na bolinha, que ela possa ser arrastável, em seguida atualizaremos as posições de x e y no SharedObject Remote:
Segue o código completo:
Veja uma demostração em funcionamento:
Como todos devem ter percebido, nos últimos meses o CSS3 e o HTML5 tem ganho um grande destaque no desenvolvimento web. Grandes empresas como o Google, Microsoft, Adobe e Apple estão apoiando fortemente o desenvolvimento web utilizando WebStandards. Caso você já conheça algo sobre CSS, provavelmente deve saber como é complicado a organização desses documentos em um projeto de médio ou grande porte. Dado esses problemas conhecidos, foram surgindo os chamados pré-processadores de CSS, que viabilizam a criação de documentos de estilo, adicionando novas funcionalidades.
Hoje vamos conhecer o LESS, The Dynamic Stylesheet Language. O objetivo dessa biblioteca em javascript é prover uma série de funcionalidades para as, usualmente criadas a mão, folhas de estilos. Recursos tais como, variáveis, mixins (Multiple Inheritance, Traits), mixins parametrizáveis, funções, namespaces, importação, etc. Vamos aprender como utilizar os principais recursos dessa biblioteca em um projeto e como aproveitar o melhor dessa biblioteca para organizar corretamente nossas folhas de estilo.
As variáveis ajudam-nos a definir valores que podem ser utilizados em diversas regras do nosso CSS. Elas possuem escopo assim como em uma linguagem de programação orientada a objetos, trocando em miúdos:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
// Arquivo stylesheet.less
// Essa variável foi definida no escopo do arquivo, logo, todas as regras do arquivo podem acessar seu valor. @siteBackgroundColor: #FF3300; // Laranja h1 // Isto significa que, se criarmos uma outra regra chamada &.mainTitle h2 |
O que é interessante no uso de variáveis é a reutilização e organização. Imagine uma design guideline onde existem RGBs específicos a serem seguidos, essas cores poderiam ser definidas em um documento chamado color_variables.less e adicionados ao nosso arquivo principal utilizando a clausula @import.
Quando um arquivo LESS é importado, todas as suas variáveis e mixins são adicionados ao arquivo principal. Os escopos serão mantidos e a extensão .less é opcional.
@import “lib.less”
@import “lib”
É possível utilizar pastas nas clausulas de @import:
@import “where/is/my/stylesheet.less”
@import “where/is/my/stylesheet”
No LESS, mixis são como uma espécie de classe CSS que pode ser reutilizada em diversas outras regras. Quando utilizadas, todas as propriedades definidas no mixin são adicionadas a regra onde a mesma foi adicionada, caso um mixin mude, todas as regras que o referenciam serão também modificadas.
Imagine o conceito de mixin como classes CSS orientadas a objeto, o que é interessante do mixin é que temos aqui algo como uma herança múltipla, caso uma mesma instrução seja declarada em mixins diferentes, e esses mixins adicionados a uma regra, o mixin declarado por último terá vantagem na construção final do CSS da regra onde foi adicionado.
|
1
2 3 4 5 6 7 8 9 10 11 12 |
.bordered
border-top: dotted 1px black; border-bottom: solid 2px black; // Declaramos agora uma regra qualquer que fará uso do nosso mixin. |
Quando modificarmos o mixin .bordered, todos os elementos que o estão utilizando serão modificados. Reutilização!
Vamos para um exemplo mais usável para exemplificar como é um mixin parametrizável.
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
// Bordas arredondadas cross-browser.
// Observe que utilizamos algo parecido com uma função de javascript para declararmos nosso mixin. // A notação de variável deve ser adicionada (@radius), com isso, criamos uma variável chamada “radius” no escopo // do mixin que poderá ser utilizada apenas internamente pelo método. // Observe também que declaramos um valor padrão para o parâmetro, de 5px. .border-radius( @radius: 5px ) // Repare que utilizamos a mesma variável para todas as regras. border-radius: @radius; -moz-border-radius: @radius; -webkit-border-radius: @radius; // Para utilizarmos a regra, seguimos o mesmo padrão |
É importante destacar que um mixin pode conter diversos parâmetros. Isso pode ser feito da seguinte forma:
|
1
2 3 4 5 6 |
// Declaramos um novo mixin
.border-radius-and-color( @radius: 5px, @borderColor: #000000 ) .border-radius( @radius ); // Observe que aqui reutilizei o mixin previamente definido. Composição de mixins. border: 2px solid @borderColor; // Adicionamos agora a cor para a borda. |
Com o LESS você pode criar suas regras de CSS utilizando uma espécie de hierarquia. Vamos ver como isso funciona na prática.
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
// Dado o CSS abaixo
div#header #menu … rules div#header #menu li a div#header #topNav |
Com o LESS, o mesmo CSS acima poderia ser escrito da seguinte forma:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 |
// Como utilizar hierarquia com Less
div#header #menu ul li #topNav |
Depois de processado, o CSS será exatamente igual. Você não precisa utilizar esse esquema de hierarquia caso não queira, é importante lembrar que o LESS é apenas uma extensão do CSS, se for de desejo do desenvolvedor, podemos escrever um código LESS sem usar nenhum recurso especial, como se fosse um CSS tradicional.
Com o LESS o seu CSS sabe fazer contas. Qualquer número, cor ou variável pode ser utilizada em uma operação aritmética.
Ele sabe identificar quando estamos utilizando uma cor ou um número, por exemplo:
|
1
2 3 4 5 6 7 |
@base: 5%;
@filler: @base * 2; @other: @base + @filler; color: #888 / 4; |
Assim como no javascript, é possível também utilizar parênteses nas suas operações:
|
1
|
width: (@var + 5) * 2;
|
Na minha opinião um dos recursos mais úteis durante o desenvolvimento de uma aplicação. Podemos efetuar operações em cima de RGBs, por exemplo, imagine que o layout do seu website foi criado baseado-se em apenas uma cor, utilizando diversos tons dessa cor. Com o LESS é possível utilizar métodos pré-definidos como lighten, saturate, darken, fadein, fadeout e spin. Esses métodos retornam sempre um RGB que pode ser utilizado em seu LESS. Vejamos alguns exemplos:
|
1
2 3 4 5 6 7 8 9 |
@base: #f04615;
.class // Utilizo a cor base 25% mais clara |
É possível também extrair informações de uma determinada cor para ser utilizada em outra.
Isso é feito a partir dos métodos hue, saturation e lightness.
|
1
2 3 |
hue(@color); // retorna o valor do canal ‘hue’ da cor @color
saturation(@color); // retorna o valor do canal ‘saturation’ da cor @color lightness(@color); // retorna o valor do canal ‘lightness’ da cor @color |
Em dado momento necessitamos organizar uma série de mixins e variáveis. Para isto podemos utilizar um conceito presente no LESS chamado Namespaces. Assim como em linguagens de programação orientadas a objetos, que possuem o conceito de pacotes, os namespaces fornecem encapsulação para nossas folhas de estilo. Isso pode ser implementado facilmente utilizando a mesma notação de ID do CSS tradicional. Vejamos.
|
1
2 3 4 5 6 7 8 9 10 11 12 |
#bundle
.button () display: block; border: 1px solid black; background-color: grey; &:hover background-color: white } .tab … .citation … } |
Verifique que acima, criamos um mixin chamado button dentro do namespace bundle. Para o utilizarmos devemos fazer da seguinte forma:
|
1
2 3 4 |
#header a
color: orange; #bundle > .button; // Estamos acessando o namespace ‘bundle’ e fazendo uma chamada para o mixin ‘button’. |
Uma utilização muito comum dos namespaces é na criação de pequenas bibliotecas de utilidades. Imagine que sua empresa pode possuir uma série de arquivos LESS, e em um determinado projeto você necessita de acesso a esses mixins, variáveis, etc. Organizar seus documentos com namespaces fácilita a visualização e localização de uma determinada instrução no seu documento LESS, como por exemplo, um mixin customizado que pode ser facilmente encontrado a partir da sua indicação de namespace.
|
1
2 3 |
someRule
#dclick > .border-radius(10px); |
Como podemos ver, o LESS facilita uma série de tarefas que são praticamente impossíveis de serem efetuadas pelo CSS tradicional.
Aconselho a todos que tenham interesse em se aprofundar mais na biblioteca a conhecer o website (http://lesscss.org/). Lá você poderá encontrar a documentação com maior riqueza de informações também poderá ver alguns exemplos de código que não foram abordados nesse post.
Qualquer dúvida, sinta-se a vontade e envie-nos um comentário!
Abraço!
São Paulo foi escolhida como a primeira cidade para cediar o Google Developer Day, e não foi por acaso. O Google deixou bem claro em seu KeyNote que está acreditando muito no mercado brasileiro no que diz respeito a desenvolvimento de software, e não é uma mera crença, mas sim um argumento baseado em dados que o CTO do Google faz questão de mostrar pra todo mundo em sua palestra. Dentre tais números está a marca impressionante de 500.000 (quinhentas mil) ativações de dispositivos Android no mundo por dia e crescendo, sendo que um dos maiores mercados é o Brasil.
Para participar do GDD era preciso se inscrever no site, e resolver uma provinha com um problema simples de programação. Acertando as questões da provinha, suas chances de ser convidado aumentavam consideravelmente. E foi assim que eu fui convidado.
Trata-se de um evento voltado principalmente para desenvolvedores, com brindes, comida e Wi-Fi de graça, ou seja, o paraíso para muito Nerd entusiasta Google. Com direito a tendinhas e logos do Google espalhados por todo Hall de eventos do Hotel Sheraton.
Fiquei espantado com a quantidade de pessoas, e principalmente com a quantidade de pessoas usando algum smartphone top de linha (com Android claro) no mesmo ambiente. Ambiente esse que tocava música 8 bits dos video games antigos (bons tempos… =) ). E para começar o evento e dar início a maratona de palestras, o CTO do Google pessoalmente ministrou o KeyNote.
O KeyNote deixou todo mundo bem curioso sobre o que estava por vir ao longo do dia nas palestras separadas por tracks como Android, Google AppEngine, Google Chrome e talvez o mais esperado Html 5.
Nada de muito novo com as palestras sobre Android. O pessoal do Google fez questão de manter o suspense sobre qual seria a versão do novo Android (Ice Cream Sandwich), mas que agora já foi revelado que será a 4.0.
Foram feitas algumas palestrar sobre usabilidade de Apps para Android, e passado bem por cima as features novas da plataforma, dentre elas o que acredito fosse o mais esperado é a integração total entre celulares e tablets, ou seja, o mesmo apk para ambos os dispositivos.
Para tornar fácil tal integração, foi adicionado o conceito de Fragment, que nada mais é do que uma porção específica da interface do dispositivo, que varia de acordo com o tamanho da tela. Por exemplo um tablet, pode possuir 3 Fragments padrão, sendo um uma barra de tarefas, outro uma listagem e um uma área de trabalho todos mostrados ao mesmo tempo, mas a mesma aplicação em um celular iria do Fragment de listagem para o Fragment com a área de trabalho por meio de uma transição, pois não cabem os 3 fragments na tela ao mesmo tempo.
Falou-se muito de In App Billing, ou seja, compra de artefatos dentro das próprias aplicações e não diretamente no market. Foram mostrados números bem convincentes, como por exemplo: do top 10 de aplicações mais rentáveis na AppMarket, 9 usam In App Billing. Números no mínimo tentadores para arriscar com a tecnologia.
Acredito que o Google tem muito mais novidade guardada para o Android, mas não falaram nada no GDD, porque o foco do evento foi outro, como veremos.
A procura pelas palestras sobre AppEngine foi muito grande, tanto que não consegui entrar em uma delas pois a sala lotou logo depois do anúncio do começo do evento.
O Google definitivamente acredita que seu Cloud é o futuro no que diz respeito a hospedagem de serviços para as Apps Mobile. O foco principal no GDD foi mostrar como que é fácil desenvolver para a AppEngine todos os tipos de aplicativos, incluindo jogos (foi reservada uma palestra apenas para falar de jogos usando a AppEngine).
Acredito que a intenção do Google é difundir mais o uso da AppEngine aqui no Brasil. Acredito que apesar do crescimento que foi obtido, eles percebem que o crescimento pode ser muito maior. Não acompanhei muito o track sobre AppEngine, então não consigo entrar muito em detalhes sobre o que mais foi abordado.
Eu não esperava que fosse ser dada tanta atenção ao Google Chrome como foi dada no GDD.
Em todas as palestras o Google Chrome era referenciado como principal porta de entrada para a Web e as novas tecnologias. Foram apresentadas ferramentas de produtividade e desenvolvimento para criar aplicativos específicos do Google Chrome.
Acredito que o Google está preparando terreno, e já quer ter em mãos muitos aplicativos compatíveis com o Google Chrome quando chegar a hora de lançar o Chrome OS. E o discurso deles é muito convincente para os desenvolvedores. Eu ouvi muita gente impressionada com as possibilidades e facilidades de desenvolver aplicativos Chrome.
Html 5 foi a estrela do evento. Não tinha uma pessoa que os olhos não brilhavam ao ver o trailer de Era do Gelo em 3D no Youtube, ou alguns avatares dançando conforme a música que tocava no ambiente de maneira dinâmica. E todo mundo ficou impressionado quando descobriu que todos os slides de todas as palestras estavam sendo passados no Chrome, e foram feitos em Html 5.
Foram mostradas muita features de Html 5 que ainda estão em teste, e que não necessariamente irão dar certo, mas a idéia não era conseguir algum tipo de vantagem, e sim mostrar o potencial do que está por vir.
Foi apresentado um framework muito interessante em Java: PlayN!. Uma biblioteca para construir jogos que podem ser jogados em Html 5, Android ou até mesmo Java nativo.
Muitas melhorias com tratamento de áudio e vídeo foram mostradas, e do jeito com que os palestrantes demonstraram, é difícil não acreditar que Html 5 ditará o ritmo das aplicações Web em um futuro próximo.
Espero que eu tenha despertado a curiosidade de alguns sobre as tecnologias do Google e da Comunidade que estão por vir. E de uma coisa eu estou convencido, preciso conhecer mais Html 5 
.
Por @Gust4v0_H4xx0r
São Paulo foi escolhida como a primeira cidade para cediar o Google Developer Day, e não foi por acaso. O Google deixou bem claro em seu KeyNote que está acreditando muito no mercado brasileiro no que diz respeito a desenvolvimento de software, e não é uma mera crença, mas sim um argumento baseado em dados que o CTO do Google faz questão de mostrar pra todo mundo em sua palestra. Dentre tais números está a marca impressionante de 500.000 (quinhentas mil) ativações de dispositivos Android no mundo por dia e crescendo, sendo que um dos maiores mercados é o Brasil.
Para participar do GDD era preciso se inscrever no site, e resolver uma provinha com um problema simples de programação. Acertando as questões da provinha, suas chances de ser convidado aumentavam consideravelmente. E foi assim que eu fui convidado.
Trata-se de um evento voltado principalmente para desenvolvedores, com brindes, comida e Wi-Fi de graça, ou seja, o paraíso para muito Nerd entusiasta Google. Com direito a tendinhas e logos do Google espalhados por todo Hall de eventos do Hotel Sheraton.
Fiquei espantado com a quantidade de pessoas, e principalmente com a quantidade de pessoas usando algum smartphone top de linha (com Android claro) no mesmo ambiente. Ambiente esse que tocava música 8 bits dos video games antigos (bons tempos… =) ). E para começar o evento e dar início a maratona de palestras, o CTO do Google pessoalmente ministrou o KeyNote.
O KeyNote deixou todo mundo bem curioso sobre o que estava por vir ao longo do dia nas palestras separadas por tracks como Android, Google AppEngine, Google Chrome e talvez o mais esperado Html 5.
Nada de muito novo com as palestras sobre Android. O pessoal do Google fez questão de manter o suspense sobre qual seria a versão do novo Android (Ice Cream Sandwich), mas que agora já foi revelado que será a 4.0.
Foram feitas algumas palestrar sobre usabilidade de Apps para Android, e passado bem por cima as features novas da plataforma, dentre elas o que acredito fosse o mais esperado é a integração total entre celulares e tablets, ou seja, o mesmo apk para ambos os dispositivos.
Para tornar fácil tal integração, foi adicionado o conceito de Fragment, que nada mais é do que uma porção específica da interface do dispositivo, que varia de acordo com o tamanho da tela. Por exemplo um tablet, pode possuir 3 Fragments padrão, sendo um uma barra de tarefas, outro uma listagem e um uma área de trabalho todos mostrados ao mesmo tempo, mas a mesma aplicação em um celular iria do Fragment de listagem para o Fragment com a área de trabalho por meio de uma transição, pois não cabem os 3 fragments na tela ao mesmo tempo.
Falou-se muito de In App Billing, ou seja, compra de artefatos dentro das próprias aplicações e não diretamente no market. Foram mostrados números bem convincentes, como por exemplo: do top 10 de aplicações mais rentáveis na AppMarket, 9 usam In App Billing. Números no mínimo tentadores para arriscar com a tecnologia.
Acredito que o Google tem muito mais novidade guardada para o Android, mas não falaram nada no GDD, porque o foco do evento foi outro, como veremos.
A procura pelas palestras sobre AppEngine foi muito grande, tanto que não consegui entrar em uma delas pois a sala lotou logo depois do anúncio do começo do evento.
O Google definitivamente acredita que seu Cloud é o futuro no que diz respeito a hospedagem de serviços para as Apps Mobile. O foco principal no GDD foi mostrar como que é fácil desenvolver para a AppEngine todos os tipos de aplicativos, incluindo jogos (foi reservada uma palestra apenas para falar de jogos usando a AppEngine).
Acredito que a intenção do Google é difundir mais o uso da AppEngine aqui no Brasil. Acredito que apesar do crescimento que foi obtido, eles percebem que o crescimento pode ser muito maior. Não acompanhei muito o track sobre AppEngine, então não consigo entrar muito em detalhes sobre o que mais foi abordado.
Eu não esperava que fosse ser dada tanta atenção ao Google Chrome como foi dada no GDD.
Em todas as palestras o Google Chrome era referenciado como principal porta de entrada para a Web e as novas tecnologias. Foram apresentadas ferramentas de produtividade e desenvolvimento para criar aplicativos específicos do Google Chrome.
Acredito que o Google está preparando terreno, e já quer ter em mãos muitos aplicativos compatíveis com o Google Chrome quando chegar a hora de lançar o Chrome OS. E o discurso deles é muito convincente para os desenvolvedores. Eu ouvi muita gente impressionada com as possibilidades e facilidades de desenvolver aplicativos Chrome.
Html 5 foi a estrela do evento. Não tinha uma pessoa que os olhos não brilhavam ao ver o trailer de Era do Gelo em 3D no Youtube, ou alguns avatares dançando conforme a música que tocava no ambiente de maneira dinâmica. E todo mundo ficou impressionado quando descobriu que todos os slides de todas as palestras estavam sendo passados no Chrome, e foram feitos em Html 5.
Foram mostradas muita features de Html 5 que ainda estão em teste, e que não necessariamente irão dar certo, mas a idéia não era conseguir algum tipo de vantagem, e sim mostrar o potencial do que está por vir.
Foi apresentado um framework muito interessante em Java: PlayN!. Uma biblioteca para construir jogos que podem ser jogados em Html 5, Android ou até mesmo Java nativo.
Muitas melhorias com tratamento de áudio e vídeo foram mostradas, e do jeito com que os palestrantes demonstraram, é difícil não acreditar que Html 5 ditará o ritmo das aplicações Web em um futuro próximo.
Espero que eu tenha despertado a curiosidade de alguns sobre as tecnologias do Google e da Comunidade que estão por vir. E de uma coisa eu estou convencido, preciso conhecer mais Html 5 .
Por @Gust4v0_H4xx0r
Olá pessoal, que tal trabalhar com Adobe Flex e Java na cidade maravilhosa?
A Avanti Prima Engenharia está com oportunidades para trabalho com Adobe Flex/Java no Rio de Janeiro.
Segue abaixo informações sobre a vaga:
Experiência Exigida
Interessados, enviar seus CV para: stefan.horochovec@avantiprima.com.br ou para eric.sander@avantiprima.com.br
Uma das funcionalidade que mais me foi útil no Adobe AIR, foi a adição de uma API mais bem elaborada para fazer atualização automatica de meus aplicativos. Isso pode ser muito importante porque nem todos os usuários tem tempo(ou vontade) de voltar no site do aplicativo para baixar a última versão.
Isso já é rotina para sistemas operacionais e softwares que usamos no dia-a-dia como o Mozilla Firefox e o Google Chrome(que nem pede permissão para atualizar né senhor Google).
A partir do Adobe AIR 1.5, temos a classe ApplicationUpdater e ApplicationUpdaterUI que tem como objetivo, definir o básico de funcionalidade de atualização para os aplicativos feitos com Adobe AIR
Gerenciar as atualizações pode ser complicado e o AIR update framework possui as API’s necessarias para que você faça isso de maneira prática e funcional. O desenvolvedor pode por exemplo:
As informações são obtidas a partir de arquivos XML onde você diz qual a última versão do software, as novidades da nova versão etc. Vamos a um exemplo prático, no caso usarei o Flash Builder que já deve ter os arquivos applicationupdater.swc e applicationupdater_ui.swc como referencia na biblioteca.
Começamos pelo xml chamado updateConfig.xml, que “dira” a seu aplicativo onde estão os arquivos para atualização.
Ele deve ser salvo no mesmo diretorio da sua aplicação, junto com os outros arquivos xml e swf. Agora no Flex, instanciaremos a classe ApplicationUpdateUI e setaremos o arquivo xml de configuração para que o Flex possa saber onde está a atualização.
O arquivo updateDescriptor.xml é onde fica setado a versão em si da atualização do seu aplicativo e onde você pode colocar a descrição das novidades da atualização.
Basicamente é isso, vamos só implementar a chamada para que ao abrir o aplicativo, ele verifique se existe atualização.
Criei uma segunda versão do meu aplicativo de teste para demonstração, deveremos ter o seguinte resultado:
Clique para ampliar
Caso o usuário queira verificar se existe alguma atualização do aplicativos, basta clicar no botão “check for upadates. O arquivo atualizado é baixado e instalado.
Clique para ampliar
Clique para ampliar
Clique para ampliar
Referências:
http://help.adobe.com/en_US/air/build/WS9CD40F06-4DD7-4230-B56A-88AA27541A1E.html
http://www.adobe.com/devnet/air/flex/quickstart/articles/update_framework.html
A Adobe lançou um serviço anteriormente conhecido com o codinome de Cocomo(Common Collaboration Model), logo em seguida passou a se chamar Adobe Flash Collaboration Service e agora é oficialmente parte da família LiveCycle, sendo chamado de Adobe LiveCycle Collaboration Service.
O LCCS tem como objetivo funcionar como um SAAS(Software as a Service) para simplificar e facilitar o desenvolvimento de aplicativos RIA baseados em multimidia. Permite que os arquitetos e desenvolvedores possam criar experiências de usuário mais envolvente e mais dinâmicas oferecendo suporte a multi-user, colaboração em real time para novos ou já existentes aplicativos RIA.
Alguns destaques:
Para começar a usar o LCCS, basta acessar o portal LCCS Developer Portal e entrar com seu login ou cadastrar-se. O portal serve para você administrar instancias das suas aplicações, você pode acompanhar o número de conexões, banda usada etc.
Modelo de cobrança
LCCS tem 3 diferentes metodos para cobrança:
Leia o FAQ para mais detalhes. Você tem uma cota free e pode usar até 15 dolares por mês.
Referencias:
http://www.flashrealtime.com/livecycle-collaboration-service-pricing/
https://portal.collaboration.adobelivecycle.com/
Salve pessoal!
Essa semana eu inicie a fase de contratações da equipe que vai trabalhar comigo em um projeto nos próximos meses, entre horas de pesquisa e análise de possibilidades eu me deparei com uma situação engraçada e atípica, pesquisando sobre média salarial de profissionais de agências de publicidade encontrei um estudo feito pela ABRADI (Associação Brasileira de agências digitais), esse estudo mostra o salário dos profissionais de agências digitais descriminado por áreas e níveis de conhecimento.
Para minha surpresa percebi que nesse estudo Flash Developers estão na lista dos mais bem pagos do mercado, ficando atrás apenas de profissionais de atendimento, planejamento e diretores.
Essa grata surpresa me incitou a escrever uma matéria sobre quais são as principais características e os principais conhecimentos de um Flash Developer Sênior, basicamente nessa matéria vou descrever sob o meu ponto de vista os conhecimentos que um “Flash Developer” tem que ter para alcançar o topo da agência onde trabalha ou vai trabalhar.
O Flash há muito tempo desperta amor e ódio nas pessoas, varias vezes eu me vi incluso em “brigas” sobre qual é a melhor tecnologia e qual é o lugar do Flash na escala de desenvolvimento.
Minha opinião sobre o assunto sempre foi clara, caso alguém me mostre uma tecnologia que seja tão hibrida quanto o Flash no quesito integração com outras tecnologias, ferramentas de desenvolvimento, documentação oficial útil e descomplicada, cursos, metodologia, comunidade de desenvolvimento ativa, padronização de desenvolvimento e possibilidade de desenvolvimento para várias plataformas, nesse dia eu com certeza vou parar de trabalhar com Flash/Actionscript e aprender essa incrível tecnologia que terá batido o Flash, até esse dia, eu prefiro continuar no mundo da plataforma flash. Então fica a dica, não perca seu tempo nesse tipo de discussão, deixe que cada um escolha seu caminho, acredite, isso vai ser melhor para você!
Se você é um verdadeiro “Flash Developer” com certeza já fez alguma coisa em OOP, esse padrão de programação pode salvar a sua vida quando o tempo for curto e o projeto desafiador. Para saber mais acesse esse link
Frameworks ajudam você a manter um padrão de desenvolvimento e diminuem o tempo de tarefas simples, existem ótimos frameworks de desenvolvimento, entre eles eu destaco o Gaia Framework e o ASF-AS3(Neto Leal). Use sem moderação!
Não é novidade alguma que as redes sociais revolucionaram a forma como as coisas acontecem na web, então é muito importante que você saiba integrar diversos serviços ao seus sites/aplicativos em Flash, serviços como Youtube, Facebook, Twitter e Flickr tem áreas específicas para desenvolvedores de várias tecnologias e em todas elas você pode encontrar APIs para auxiliar no desenvolvimento de seus sites/aplicativos.
Não que você tenha que ser um expert nessa linguagem, mas é muito bom você ter a visão do “outro lado”, não serão poucas as vezes que vão querer que aquele “hotsitezinho” que você fez tenha uma área administrativa e grave/leia dados de um banco de dados, ou que aquele outro programador “mala” vai dizer que isso ou aquilo não é possível com flash, nesse caso eu indico duas tecnologias exatamente nessa ordem, Coldfusion e PHP. Não se esqueça de aprender a trabalhar bem com Mysql, mas atenção, você não vai se tornar o melhor programador Serve-Side do mundo então tente não perder sua “veia” de design com essas tecnologias o interessante é você ainda continuar “mandando bem” em áreas fundamentais como Motion e Design.
Isso pode levantar certa polêmica, mas a grande verdade é que se você pretende ser um Flash Developer e gerenciar um projeto é fundamental que você conheça profundamente o Photoshop, que tenha uma boa noção de design, tipografia e afins e conheça muito de motion design, por mais que digam o contrário 80% do trabalho de um Flash Developer é dar vida a interfaces malucas criadas por Diretores de Arte ainda mais malucos!
Falar isso para os desavisados pode parecer uma heresia, mas a verdade é que, seja um banner, um hotsite ou um grande site é muito melhor você fazer todas as transições e motions via código, nesse caso eu indico que você use a Greensock. Trabalhando dessa forma você terá uma facilidade maior na hora de fazer aquele ajuste fino ou implementar aquela alteração de última hora.
A comunidade de desenvolvimento Flash é muito unida, existem vários blogs como o meu que visam o crescimento profissional das pessoas sem nada em troca, é fundamental que você tenha boas referencias, que fique ligado nas constantes novidades que circulam no mundo da plataforma flash(sabe o que é molehill?), quer saber quem são as minhas referencias? Segue o link. Outra dica, tenha uma pagina de Labs sempre atualizada ou então crie um blog para compartilhar seus conhecimentos e experiências, isso coloca você em destaque na comunidade e pode abrir portas para bons trabalhos =)
A IDE do flash é muito boa, na versão CS5 o pessoal da Adobe melhorou bastante o editor de código, porém, ele está longe de ser a melhor opção do mercado, eu particularmente uso o FlashDevelop para fazer isso, mas o Flash Builder 4 também é uma boa opção, escolha a sua!
Há muito tempo o flash player domina as estatísticas de software mais instalado do mundo, mas é importante saber que o Flash não serve apenas para desenvolver sites, hoje em dia existe uma infinidade de dispositivos que utilizam o flash player, hoje você pode criar conteúdo para Iphone, Ipad, Smartphones com Android e tablets como o Motorola Xoom. Eu acho muito importante estar sempre ligado nessas novas possibilidades e de preferência ter um (ou todos) para estudos, pense fora da caixa, quem sabe isso não vai te render uma grana extra!
Tenha sempre um portfólio bem atualizado, eu não posso falar disso com muita autoridade, pois há três anos venho tentando ter tempo para atualizar meu site, kaekae, mas é fundamental que você tenha um portfólio online que mostre exatamente o que você é capaz de fazer, ele com certeza vai ser decisivo na hora da contratação para uma empresa ou freela.
É importante que você faça pelo menos uma vez ao ano uma reciclagem de seus conhecimentos, eu particularmente guardo 5% do que ganho ao ano para fazer isso, esse ano vou estar no FlashCampBrasil, uma dica que deixo são os cursos do Luciano Augusto o cara manda super bem em cursos a distância.
O maior erros do Flash Developer está na hora de passar o orçamento, acredite, nós estamos no topo da cadeia alimentar dos desenvolvedores, quando aparecer aquele freela não fique com medo de cobrar o valor real, você é um Flash Developer e sua hora é uma das mais caras do mercado.
Outra coisa importante são os prazos, saiba quanto tempo você leva para fazer determinadas atividades comuns a um Flash Developer, não cumprir prazos está fora de questão e lembre-se sempre existe alguém que conhece outro alguém e uma vez queimado no mercado você estará fadado ao limbo!
Não existe limite para a criatividade dentro do flash, não desanime o caminho é longo mais as recompensas em R$ são grandes depois de um tempo!
Deixe um comentário sobre esse artigo e não se faça de difícil se precisar de ajuda!
Um abraço
BlazeDS é uma aplicação Java opensource mantida pela Adobe, sob licensa GNU Lesser General Public License, Version 3 (LGPL v3), que fornece um conjunto de serviços, todos sobre o protocolo HTTP(Hyper Text Transfer Protocol), para permitir uma aplicação Flex fazer chamadas a serviços remotos Java, retornando os dados tanto de forma assíncrona como em tempo real.
Por utilizar o formato de dados binário chamado AMF(Action Message Format) para a serialiazação e deserialização de dados, a comunicação entre uma aplicação Flex e o servidor Web se torna muito otimizada. Existem estudos feitos comparando as diversas tecnologias, como o Jamesward, mostrando o potencial do AMF.
Outra grande vantagem quando usamos o BlazeDS é a facilidade de ter classe Java automaticamente convertida para uma classe ActionScript e vice-versa.
O BlazeDS pode ser baixado do site da Adobe em dois formatos:
Você pode optar também por fazer o download do código fonte. A documentação também está disponível neste link.
Entendendo os arquivos de configuração do BlazeDS
A estrutura de arquivos do BlazeDS é bem simples, quando descompactamos o blazeds.war, presente na versão binária, podemos ver a seguinte estrutura:
Devemos nos atentar a duas pastas. A pasta lib, que contém todos os jars necessários, e a pasta flex, que contém todos os arquivos de configuração do BlazeDS. Vamos ver o que cada arquivo significa:
Criando o seu primeiro projeto com o BlazeDS
Para criar o projeto iremos precisar de:
Feito os downloads e a instalação do Eclipse e FlashBuilder, vamos iniciar o FlashBuilder para criar o projeto.
Antes de criar o projeto, vamos configurar o Tomcat:
Feito a configuração do Tomcat, vamos criar o projeto:
Agora vamos criar a classe Java que terá o serviço para retornar a string “HelloBlazeDS”
|
1
2 3 4 5 6 7 8 |
package br.com.dclick.service;
public class RemotingService { ? ? public String sayHello() { |
Agora vamos configurar o BlazeDS para disponibilizar o serviço que acabamos de criar.
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
xml version=“1.0″ encoding=“UTF-8″?>
? ? ? ? ? ? ? ? ? ? ? ? class=“flex.messaging.services.remoting.adapters.JavaAdapter” ? ? ? ? ? ? default=“true” /> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
Vamos colocar na aplicação a chamada para o servidor.
|
1
2 3 4 5 |
? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? result=“services_resultHandler(event)” ? ? ? ? ? ? ? ? ? ? ? ? fault=“services_faultHandler(event)” /> ? ? |
Alguns detalhes:
* Perceba que a propriedade destination aponta para o destination que configuramos no arquivo remoting-config.xml
* Precisamos declarar um id para poder referenciar o RemoteObject
* Adicionamos um ResultHandler para tratar o resultdo do serviço
* Adicionamos um FaultHandler para tratar a falha do serviço
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
? ? ? ?
? ? ? ? [CDATA[ ? ? ? ? ? ? import mx.controls.Alert; ? ? ? ? ? ? import mx.rpc.events.FaultEvent; ? ? ? ? ? ? import mx.rpc.events.ResultEvent; ? ? ? ? ? ? protected function services_resultHandler(event:ResultEvent):void
? ? ? ? ? ? protected function services_faultHandler(event:FaultEvent):void ? ? ? ? ]]> |
Alguns detalhes:
* A propriedade result do evento ResultEvent vai conter o resultado do serviço. No nosso caso o serviço retorna uma String “HelloBlazeDS”
* A propriedade fault do evento FaultEvent contém os detalhes do erro.
|
1
2 3 4 |
? ? ? ? protected function application1_creationCompleteHandler(event:FlexEvent):void
? ? ? ? ? ? { ? ? ? ? ? ? ? ? services.sayHello(); ? ? ? ? ? ? } |
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
? ? ? ? xml version=“1.0″ encoding=“utf-8″?>
? ? ? ? ? ?? ? xmlns:s=“library://ns.adobe.com/flex/spark” ? ? ? ? ? ?? ? xmlns:mx=“library://ns.adobe.com/flex/mx” minWidth=“955″ minHeight=“600″ ? ? ? ? ? ?? ? creationComplete=“application1_creationCompleteHandler(event)”> ? ? ? ? ? ? [CDATA[ ? ? ? ? ? ? import mx.controls.Alert; ? ? ? ? ? ? import mx.events.FlexEvent; ? ? ? ? ? ? import mx.rpc.events.FaultEvent; ? ? ? ? ? ? import mx.rpc.events.ResultEvent; ? ? ? ? ? ? protected function services_resultHandler(event:ResultEvent):void
? ? ? ? ? ? protected function services_faultHandler(event:FaultEvent):void
? ? ? ? ? ? protected function application1_creationCompleteHandler(event:FlexEvent):void ? ? ? ? ]]> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? result=“services_resultHandler(event)” ? ? ? ? ? ? ? ? ? ? ? ? fault=“services_faultHandler(event)” /> ? ? |
Agora só falta fazer o deploy da aplicação e subir o servidor.
Agora é só executar a aplicação e ver o resultado:
Isso é tudo, guarde esse projeto configurado para ser usado nos próximos posts.
