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.

• Somente pelo lado cliente, através do Flash Player/AIR
• Em conjunto com ActionScript Communication, linguagem de servidor do Flash Media Server

Vejamos o primeiro caso:

Através do lado cliente, através do Flash Player/AIR

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.

• Vá até o diretório de instalação do Flash Media Server e procure pela pasta “applications”, lá crie um diretório chamado “sharedBall”, dentro dele um arquivo chamado “main.asc”
• Abra o main.asc no seu editor de textos de preferencia ou pelo próprio Flash e digite: trace(“sharedBall…”);
• Vamos testar esse arquivo, abra o console do Flash Media Server, geralmente fica localizado no diretorio de instalação/webrrot/swfs. Você pode abrir pelo browser ou o swf diretamente.
• Clique no botão “View Applications” e em seguida procure o nome “sharedBall” no combobox logo no canto inferior esquerdo onde está escrito “New Instance…”
• Selecione “sharedBall” e deveremos ter na aba Live Log algo como na imagem abaixo:

• No Flash, criei uma bola com as ferramentas de desenho e converti para MovieClip dando o nome de “mc_ball”.
• Estamos prontos para começar a integração entre o Flash e o Flash Media Server. Crie um layer para o ActionScript e abra o editor apertando F9 ou “Window->Actions”
• Nosso código começa com a conexão com o servidor Flash Media Server

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:

Download sharedBall

Twitter!

Como Html 5 é algo novo para mim e acredito que para muita gente que visita o blog, os meus exemplos irão se limitar a coisas simples, mostrando novidades básicas. No exemplo do post de hoje vou falar sobre duas novidades, a edição de conteúdo e o Web Storage.

Your browser does not support iframes.

Edição de conteúdo nada mais é do que colocar o Html da sua aplicação em modo de design, deixando que o usuário final possa editá-lo como um simples editor de texto, porém sem conhecer nada sobre Html. Essa funcionalidade parece ser algo inútil a primeira vista, porém ela pode se tornar poderosa se formos discutir sobre aplicações html5 offline.

Web Storage tem a função de persistir uma informação dentro de um escopo definido, com um espaço de armazenamento maior do que um cookie (bem maior), e que pudesse ser acessível em qualquer página a qualquer momento sem a necessidade de carregar essa informação de página por página. Essa API é dividida em 2 itens, sessionStorage e localStorage.

sessionStorage
Esse item da API serve para armazenar informação na sessão do cliente que está acessando sua aplicação. É interessante utilizar esse tipo de storage quando o usuário tem informações específicas para a sessão como por exemplo, você deseja abrir 2 janelas da sua aplicação e em uma janela fazer a configuração A e na segunda janela, fazer a configuração B sem que elas tenham interferência uma na outra. Esse tipo de storage também não é persistido, ou seja, quando a sessão fechar, todas as informações são perdidas

localStorage
Esse item da API serve para manter uma informação guardada por tempo indeterminado, ou seja, se o usuário fechar o browser e desligar a máquina e no dia seguinte acessar sua aplicação, ela poderá recuperar qualquer informação que tenha sido armazenada no storage. Para o pessoal que conhece Flex, essa função é idêntica ao SharedObject, pelo pouco que pude testar.

Utilização
A api é bem simples, todo armazenamento é baseado em CHAVE=VALOR e agora vou comentar sobre 3 métodos básicos para sua utilização:

1. setItem(key, value)
Utilizado para adicionar um item ao storage.
localStorage.setItem(‘nome’, ‘DClick’);

2. getItem(key)
Utilizado para recuperar o valor de uma key.
alert(localStorage.getItem(‘nome’)); //resultado ‘DClick’

3. removeItem(key)
Utilizado para deletar o registro referente a key.
localStorage.remoteItem(‘nome’);

Gostaria de ressaltar que os conceitos mostrados aqui são bem simples, apenas como algo introdutório ao assunto. Espero que estejam gostando!

Hoje surgiu um problema aqui na @PontoSistemas, onde teríamos que salvar a posição e o tamanho da coluna de acordo com o que o cliente preferir, como cada pessoa organiza a tela de um jeito diferente. Tudo isso porque toda vez que o DataGrid é construído novamente, ele volta ao estado inicial.

A idéia:
Ao organizar ou alterar os tamanhos das colunas de um DataGrid/AdvancedDataGrid salve as posições e os tamanhos das colunas.

A solução:
Altere o tamanho e/ou a ordem das colunas, e recarregue a página. Elas irão voltar na mesma ordem e tamanho que você as deixou.

Clique com o botão direito em cima do DataGrid, depois em “view source” para visualizar o código fonte.

Da maneira que foi implementado, as definições da posição e do tamanho das colunas são salvas na memória do FlashPlayer (como se fosse os cookies das páginas web), ao limpar esse “cookie” as configurações voltam ao estado original.

Por hoje é isso. Em breve novas dicas.

Comentem!!!

Se calhar reparou numa alteração recente aos seus gráficos de estatísticas. O que aconteceu foi que abandonamos o Flash em detrimento de uma biblioteca mais robusta de gráficos, chamada Flot. Se não notou, vá já ver. Agora já pode examinar todos dos novos gráficos em browsers modernos, incluindo os de dispositivos móveis como o iPhone e o  iPad. Como poderá ver, actualizamos os diagramas para usarem barras em vez de pontos e linhas. Também redesenhamos a página de estatísticas para a tornar mais agradável.

Cada módulo pode ser aberto e fechado, movido, ou ocultado. Se não quiser ver um módulo, minimize-o com um clique ou use as Opções para mantê-lo longe da sua vista. Construa e examine a sua página de estatísticas da maneira que mais lhe agradar.

Ao passar com o rato por cima de cada barra no diagrama, a sua cor muda e expõe um pequena janela que lhe dá mais informação sobre esses dados. Se o diagrama mostrar dados diários, os sábados e domingos têm um fundo cinza leve para facilitar a identificação de comportamentos semanais. Por baixo do gráfico, notará uma nova área, chamada “fortune cookies” onde destacamos estatísticas cruciais.

Neste redesenho escolhemos gráficos de barras porque na realidade o fim de um dia e o começo do outro não deveriam ser unidos. Cada dia parte do zero e um gráfico de barras adapta-se muito melhor a tipo de dados. Esperamos que esteja de acordo, assim que se tenha habituado à modificação.

Nesta primeira fase concentramo-nos na página principal. Isto vai-nos permitir obter as vossas reacções àquilo que deveríamos mudar. Só mencionamos aqui algumas novidades do redesenho, pelo que vá navegando pelas suas estatísticas para se habituar à sensação. À medida que formos recolhendo opiniões, iremos também aplicar o redesenho a outras páginas de estatísticas.

Os sites que usam o nosso plug-in em blogs auto-alojados verão uma actualização assim que fizermos uma nova iteração deste redesenho.

Funcionalidade muito utilizada em sites, a qual é o armazenamento de dados no cookie do browser, esta função é muito utilizada para salvar as preferências de usuários como: login, email, ultimo acesso entre outras informações.
No Flex isso também é possível podendo ser até mais poderoso do que as formas atuais, para fazer isso você deve utilizar o SharedObject.

A função do Shared Objects (ShO) é armazenar dados localmente, funcionando como um cookies do browser. Assim você pode armazenar dados e chamá-los durante a sessão atual ou em outra futura sessão. Contudo estes dados não podem ser acessados por outra aplicação Flex mais sim apenas pela aplicação criadora.

Shared Objects vs Cookies

É comum desenvolvedores confundirem ShO com cookies.
Os cookies que aderem ao padrão RFC 2109 geralmente têm as seguintes características:

• Eles podem expirar, e geralmente é feito isso no final da sessão por default.
• Podem ser desabilitados pelos clientes.
• Há um limite de 300 cookies sendo no Maximo 20 por site.
• Um cookie tem o espaço de armazenamento de 4 kb.
• Há a possibilidade de serem considerados como arquivos maliciosos.
• Há uma comunicação entre cliente e servidor para armazenamento dos dados.

Shared Object tem as seguintes características:

• Eles não expiram por default.
• Por padrão o seu limite de armazenamento é de 100 kb.
• Eles podem armazenar dados simples como: String, Date, Array ….
• A aplicação pode indicar locais específicos para o armazenamento dos dados.
• Não há transmissão e comunicação entre o cliente e o servidor para a busca e armazenamento dos dados.

Com a classe SharedObject é possível realizar qualquer manipulação dos dados que ficarão armazenados no cliente. Esta possui os seguintes métodos:

• clear() – Limpa permanentemente todos os dados contidos no Shared Object.
• flush() – Grava os dados do ShO no cliente.
• getLocal() – Retorna uma instancia do ShO no cliente, caso não exista o mesmo cria uma.
• getSize() – Retorna o tamanho em Bytes do ShO no cliente. Uma observação o tamanho default é de 100kb, contudo isto pode ser alterado para mais.

Na prática:
Criando uma lista de contatos.

Criar uma classe chamada ShareObjectHelper a qual irá realizar a manipulação dos dados do Shared Object, tais como: incluir, remover e listar.
Esta é uma classe bem simples no qual será usado um ArrayCollection para armazenar todos os dados que armazenarão dos contatos que o usuário incluiu.

package {
	import mx.collections.ArrayCollection;
	import flash.net.SharedObject;
 
	public class SharedObjectHelper {
 
		private var _sharedObject:SharedObject;
		private var _dpSharedObject:ArrayCollection;
		private var _nomeArquivoSharedObject:String;
 
		/**
		 * Construtor
		 */
		public function SharedObjectHelper(valor:String) {
			inicializaHelper(valor);
		}
 
		/**
		 * @private
		 * Responsavel por recuperar a instancia do SharedObject baseado no
		 * parametro.
		 *
		 */
		private function inicializaHelper(valor:String):void {
			_dpSharedObject = new ArrayCollection();
			_nomeArquivoSharedObject = valor;
			_sharedObject = SharedObject.getLocal(_nomeArquivoSharedObject);
 
			if (getObjects()) {
				_dpSharedObject = getObjects();
			}
		}
 
		/**
		 * Retorna todos um array de dados que está armazendo no SharedObject
		 * @return ArrayCollection
		 */
		public function getObjects():ArrayCollection {
			return _sharedObject.data[_nomeArquivoSharedObject];
		}
 
		/**
		 * Adiciona um dado ao array de dados.
		 * @param Object
		 */
		public function addObject(o:Object):void {
			_dpSharedObject.addItem(o);
			updateSharedObjects();
		}
 
		/**
		 * @private
		 * Vincula o array de dados a um SharedObject.
		 */
		private function updateSharedObjects():void {
			_sharedObject.data[_nomeArquivoSharedObject] = _dpSharedObject;
			_sharedObject.flush();
		}
	}
 
}

<?xml version="1.0"?>
<mx:Application xmlns:local="*" xmlns:mx="http://www.adobe.com/2006/mxml"
				creationComplete="init()" backgroundColor="#ffffff"
				layout="vertical" 
				backgroundGradientAlphas="[1.0, 1.0]" 
				backgroundGradientColors="[#D3D3D3, #E7E7E7]" viewSourceURL="srcview/index.html">
	<mx:Script>
		<![CDATA[
			import mx.events.ValidationResultEvent;
			import mx.validators.ValidationResult;
			import mx.collections.ArrayCollection;
			import mx.utils.ObjectUtil;
			import flash.net.SharedObject;
 
			[Bindable]
			public var dpContatos:ArrayCollection = new ArrayCollection();
 
			public var shoHelper:SharedObjectHelper;
 
			/**
			 * @private
			 * Inicializa a classe SharedObjectHelper e ja cria/recupera
			 * instancia de um objeto SharedObject.
			 */
 
 
			private function init():void {
				shoHelper = new SharedObjectHelper("contatos");
 
				if (shoHelper.getObjects()) {
					dpContatos = shoHelper.getObjects();
				}
 
			}
 
			/**
			 * @private
			 * Adiciona um contato na lista de contatos e executa o addObject da classe
			 * sharedObjectHelper.
			 */
			private function addContato():void {
				if(valNome.validate().type == ValidationResultEvent.VALID){
					/* Cria um objeto dinamico com os atributos dos fomularios */
					var objInsert:Object = {nome: txtNome.text, apelido: txtApelido.text};
					shoHelper.addObject(objInsert);
 
					dpContatos = shoHelper.getObjects();
 
					/* Limpa os campos do formularios */
					txtNome.text = '';
					txtApelido.text = '';
				}
			}
 
			/**
			 * @private
			 * Remove um contato do DataGrid e da lista de contatos do SharedObejct
			 */
			public function removeContato():void {
				if (dgContatos.selectedIndex > -1) {
					dpContatos.removeItemAt(dgContatos.selectedIndex);
				}
			}
 
		]]>
	</mx:Script>
	<mx:StringValidator id="valNome" source="{txtNome}" property="text" 
		required="true" requiredFieldError="Campo Obrigatório"
		triggerEvent="''"/>
 
	<mx:Panel title="Contatos" layout="vertical" horizontalAlign="center" width="400">
 
 
		<mx:Form width="100%">
			<mx:FormItem label="Nome" width="100%">
				<mx:TextInput id="txtNome" width="100%"/>
			</mx:FormItem>
			<mx:FormItem label="Apelido" width="100%">
				<mx:TextInput id="txtApelido" width="100%"/>
			</mx:FormItem>
			<mx:Button id="b2" label="Salvar" click="addContato()"/>
		</mx:Form>
 
		<mx:DataGrid id="dgContatos" dataProvider="{dpContatos}" width="100%">
			<mx:columns>
				<mx:DataGridColumn headerText="Nome" dataField="nome"/>
				<mx:DataGridColumn headerText="Apelido" dataField="apelido"/>
				<mx:DataGridColumn headerText="Opções" width="80" textAlign="center">
					<mx:itemRenderer>
						<mx:Component>
							<mx:Button label="Excluir" width="8" click="outerDocument.removeContato()"/>
						</mx:Component>
					</mx:itemRenderer>
				</mx:DataGridColumn>
			</mx:columns>
		</mx:DataGrid>
	</mx:Panel>
 
</mx:Application>

O que é?
Feliz  cada vez mais nos estamos a virar mais para o “mundo” da WEB e para a CLOUD.
A prever isso a Microsoft lançou já há alguns anos o ASP.NET (Active Server Pages), que ao contrário do que se diz não é uma linguagem de programação mas sim uma Framework para desenvolvimento WEB.
Como é uma Framework assente na Framework .NET podemos usar para programar as linguagens C# e VB.NET. Em ASP.NET criamos páginas (WEB Forms) dinâmicas em que o código é corrido no servidor como é o caso de outras tecnologias (PHP, JSP).

Pressupostos:
Não que seja imperativo mas para sermos bons programadores de WEB, antes de sequer abrir o Visual Studio, temos de entender o mundo que vai por trás do browser.
Temos de entender o protocolo HTTP, Request / Response, ciclos de vida de uma página, diferença entre cliente e servidor, State Management, PostBack, JavaScript, CSS e claro HTML.
Não irei falar sobre tudo isto, apenas do que está relacionado com o ASP.NET, mas é bom sabermos o que está por detrás de cada ação que fazemos no browser

Cliente VS Servidor:
Como já referi uma Web Form ASP.NET é executada do lado do servidor, o que significa que cada vez que pedimos (Request) essa página ela é executada no servidor e posteriormente devolvida (Response) para o browser em HTML, esta operação ocupa largura de banda e tempo, logo se o podermos evitar ou então não enviar a página toda melhor (Partial PostBack (AJAX)), podemos concretizar isso usando JavaScript, que é uma linguagem que corre directamente no Browser (Cliente) ou AJAX (Javascript assíncrono e XML).
Não significa que no cliente é melhor ou que no servidor é mais seguro, o grande desafio das WebForms é a fusão entre código do lado do cliente e servidor, tornando assim a página rápida e menos pesada.

PostBack:
O PostBack é o nome que se dá à operação de Request e Response, ou seja, quando uma página inteira e o seu conteúdo são enviados para o servidor, processados e devolvidos para o browser.
Sabem quando fazem refresh a uma página ou carregam num botão e o browser fica branco e depois aparecem os conteúdos? É isso um PostBack.
Mais tarde falaremos da propriedade Page.IsPostBack do ASP.NET.
Felizmente existem formas de contornar isso graças ao AJAX que permite que sejam só enviados pedaços da página e de modo assíncrono o que permite continuar a trabalhar sem o browser bloquear.

Ciclos de vida de uma página:
Falaremos aqui do mais importante e utilizado o Load.
É a melhor altura para fazer acções devido ao facto de que os controlos já estão todos carregados, o viewstate disponível e ainda não é tarde para fazer alterações pois não chegou ao Render que é quando o HTML da página já está todo desenhado.

State Management:
Entende-se por State Management a capacidade do ASP.NET poder guardar informação entre PostBacks da mesma ou de outras (várias) páginas.
Existem várias opções relacionadas com desempenho e capacidade, cliente ou servidor:

Do lado do cliente:

View State: o view state “vive” nas páginas, o viewstate é criado a partir de cada controlo que adicionamos á nossa página para, entre postbacks, poder manter o seu valor.

Ex: Temos uma caixa de texto na página e ao carregar num botão a página faz postback mas o valor permanece na caixa de texto.
Vantagens: Simples, não requer implementação
Desvantagens: Não é recomendado para guardar muita informação pois a página ficará lenta.

Hidden Fields: Uma espécie de variável global na própria página
Vantagens: Fácil implementação
Desvantagens: Pouco seguro (ao ver o source da página está lá o valor) e claro pesa na página

Cookies: Todos já ouvimos este termo, são pequenos ficheiros guardados no lado do cliente para poupar viagens desnecessárias ao servidor.
Vantagens: Pode ser configurado o tempo de expiração e simples implementação
Desvantagens: Pouca capacidade de armazenamento, cliente tem de aceitar cookies, pouco seguro pois o cliente pode alterar as informações.

Do lado do Servidor:

Application State: Informação guardada no servidor disponível em todas as páginas e utilizadores até que o processo da aplicação termine.
Vantagens: Variáveis globais, fácil implementação.
Desvantagens: Ocupa memória no servidor.

Session State: Informação guardada no servidor disponível em todas as páginas enquanto a sessão do utilizador estiver disponível (mesmo Browser), tem limite de tempo de inactividade.
Vantagens: Variáveis globais, fácil implementação.
Desvantagens: Ocupa memória no servidor.

Ferramentas úteis para ajudar no desenvolvimento e debug:
Firebug: http://getfirebug.com/
Fiddler: http://www.fiddler2.com/fiddler2/

Cumpz