Apache Cordova/ ios/ Mobile/ NodeJS/ Notícias/ Phonegap

Phonegap App, um live reload para desenvolvedores

phonegap_app

Acabaram de lançar o PhoneGap App. Um aplicativo que permite você testar o aplicativo que você está fazendo, sem se preocupar nesse período em assinar, empacotar e testar o que você faz.

Para quem é desenvolvedor Front-end e conhece o benefício do Live Reload, é basicamente a mesma coisa, facilita para caramba na hora de testar enquanto desenvolve.

Como usar?

Primeiro passo

Baixe o Phonegap ou atualize para última versão.

Depois instale o Phonegap como global.

  npm install phonegap -g
Se você não tem ainda o phonegap ou Apache Cordova como é conhecido, você deve instalar primeiramente o NodeJs que vem acompanhado do NPM (Node Package Manager), para baixar o nodejs, vá até o site nodejs.org

Segundo passo

Acesse o Phonegap App e baixe o aplicativo para seu dispositivo Android ou iOS, para Windows Phone em breve será disponibilizado.

Terceiro passo

Com o aplicativo instalado em seu dispositivo e o phonegap já configurado começe com os seguintes comandos:

Se você não tem aplicativo, basta executar esses passos.

c:\ phonegap create MeuAplicativo
c:\ cd /MeuAplicativo
c:\MeuAplicativo/ phonegap serve

Se você já tem aplicativos, só executar assim:

c:\ cd /MeuAplicativo
c:\MeuAplicativo/ phonegap serve

O código fonte tanto do PhoneGap, assim como dos PhoneGap App e o site, estão disponíveis aqui

Sem categoria

Ferramentas Intel para desenvolvedores Android e Windows Phone

intel-android

A Intel acaba de lançar o Intel INDE, uma ferramenta estratégica ao seu atual SDK e compilador para Android.

O Intel INDE não compila apenas para o Android, compila também para o Windows Phone. A estratégia por trás do INDE é cada vez mais clara que a Intel está querendo abocanhar uma parte desse mercado já que possui mais de duas dúzias de dispositivos Android e Windows usando seus processadores.

Baixem e confira aqui.

Android/ Google/ Mobile

Android Wear, guia inicial para desenvolvedor

Moto-360-Android-Wear

Ontem o Google surpreendeu todo mundo com um SDK específico para wearables que são dispositivos pareados com seus aparelhos com Android, basicamente o Google Wear é um Google Now, só que em seu pulso e evita assim você fica toda hora com aquela mania de tirar e colocar o celular do bolso para ver notificações ou compromissos.

Não é novidade nenhuma em termos técnicos, A própria Samsung já tinha um SDK para o Galaxy Gear e uma série de aplicativos especificos para conectar com os seus aparelhos.

A diferença do SDK da Samsung para o seu Gear e o Google Wear é que será um SDK bem abrangente, não vai ficar só funcionando apenas com Samsung Galaxys e Samsung Galaxy Gear, você pode comprar qualquer smartphone com Android e o Motorola Wear ou LG Wear que são os dois modelos lançados justamente com o Google Wear e parear ambos e boom! Você tem eles perfeitamente casados, fico imaginando aqui quantos Google Wear Xing Lings vão aparecer depois dessa novidade, já que smartphones Xing Lings estão com os dias contados no Brasil.

Pois bem, me inscrevi no Preview do SDK e ganhei acesso ao SDK, para encurtar um pouco o post e fazer valer cada imagem, que por sí só valem mais do que mil palavras, eu gravei um rápido video no Youtube como será esse workflow de desenvolvedores usando o SDK do Google Wear.

O código fonte está disponível no GitHub.

Android/ Apache Cordova/ Dev. Software/ Dicas/ Notícias/ Open-source/ Phonegap

A fragmentação do Android e a dor de cabeça de desenvolver nativo

frag_droid_brands

frag_droid_brands

É fato e não tem como argumentar com dados, desenvolver para Android é um saco do ponto de vista nativo, na RIACycle cobramos muito mais caro para Android do que para iOS, por que justamente o cliente muitas vezes não entende o tamanho do problema que é para criar para dispositivos com Android.

[pullquote align=”left”]Relatório completo da Open Signal aqui.[/pullquote] E com base em quê para fazermos isso? Vejamos, sem dados eu não tenho como argumentar com você que lê agora, mas assuma que eu consegui os dados disponíveis aqui. Claro que isso não remete a realidade global, mais os dados podem ser comparados ao que temos no Brasil, você conhece alguém com smartphone que tenha o Android instalado? Percebeu qual a marca dele e o tamanho? Qual versão ele usa?

Esse relatório da Open Signal é basicamente o que eu tenho lutado nos últimos tempos e eu sempre venho com as seguintes perguntas em sequência:

[quote style=”1″] Para qual dispositivo Android você quer fazer?
Você quer fazer nativo ou usando tecnologias alternativas?[/quote]

Até ai, o cliente já está com o pé atrás e pergunta, Ah! Mais tem preço diferenciado? Sim, veja só, embora o Google tenta ao máximo lançar bibliotecas de compatibilidade entre diferentes versões da API, a questão é o mesmo aplicativo nativo que via rodar no Android 2.3 vai rodar no Android 4.2. A grande diferença é que você vai roda-lo mais lento no 2.3 e mais rápido no 4.2. Por que consequentemente quem está com o Android 4+ tem um aparelho no mínimo melhor.

Quem cria jogos como é nosso caso, o problema ainda é mais sério, já que você além de ter a dificuldade de trabalhar com diferentes tamanhos de telas, densidades, você tem que se preocupar com o consumo de energia da bateria.

frag_droid_

Um dos pontos chaves para trabalhar com a plataforma é a questão da API. Como mencionei rapidamente logo acima, é difícil você fazer isso de forma menos trabalhosa no Android, por mais que você queria, você vai acabar abrindo mão de um comportamento específico de navegação ou recurso e adotando um compatível com o nível de aplicativo que seu cliente quer.

O Google até se esforça nesse quesito e até com louvor nesse aspecto, mas é raro não ver algum desenvolvedor falando mal desse kit, justamente por que é limitante e vez ou outra você vai acabar implementando uma nova usando algum fragmento seu próprio ou criando um novo tipo de layout ou animação para superar as espectativas de seu cliente.

Claramente o que temos visto nos últimos 8 meses é que finalmente o cliente entendeu que o mercado de Android no Brasil é dominado pela Samsung, e fica mais fácil criar um aplicativo que rode apenas para ele, porém você não vai querer fazer um App apenas para uma marca, você quer fazer para o público em geral e isso cria uma falsa espectativa de que vai ficar bonito em tudo que é dispositivo.

Já viu o tanto de fabricante que existe?
frag_droid_brands

Imagine ter que criar vários deploys para diferentes marcas ou fabricantes? Haja recurso para isso.

Está tudo perdido? Claro que não, tudo depende de quanto você ou seu cliente está disposto à gastar na hora de criar as Apps, sempre a alternativa mais barata quando se não tem tanto prazo e dinheiro é usar cross-compilação, que no caso o Phonegap tem ajudado bastante.

A grande vantagem do phonegap é que você rapidamente pode criar Apps para peças publicitárias ou games em html5 ou até mesmo com Adobe AIR e usar uma API unificada e isso meu amigo, atrai e muito os olhos de quem desenvolve.

Leiam

ios/ iPad/ Iphone/ Mobile/ Negócios/ Notícias/ Pessoal

92.6% do mercado de smartphone é Android ou iOS, só que nem tudo que reluz é ouro

smartphones
[quote style=”1″] De acordo com a Gartner, 92,6% dos smartphones vendidos no primeiro trimestre de 2013 eram Android ou iOS. Os outros sistemas têm participação ínfima: BlackBerry (3%), Windows Phone (2,9%) e Bada (0,7%). Os dados divulgados pela IDC não são muito diferentes, mas dão o terceiro lugar para o Windows Phone, que alcançou 3,2% de participação de mercado.
[/quote]

Porém, nem tudo que reluz é ouro, vender para smartphone só por que ele lidera a lista não quer dizer que aquela plataforma paga suas contas necessariamente. Existe um ponto flutuante entre a plataforma e o ecosistema que sustenta ela.

Sem dúvida, para minha realidade, eu ganho mais dinheiro na Apple Store do que vendendo Apps para o Android, eu costumo fazer mais Apps para Apple do que para Windows e costumo fazer mais Apps para Blackberry do que para a Nokia.

Dá para ganhar dinheiro principalmente com plataformas emergenciais, fomentando a classe C e D do mundo, o Firefox OS mesmo é minha aposta para ganhar dinheiro diretamente com o público final.

Como 99% do tempo fazendo Apps para terceiros lucracrem sobre usuários finais, você acaba não faturando tanto quanto seu cliente fatura, mas manter o cheque recebível mensalmente é outra história.

Desde que lançaram a moda de Smartphones em 2007 a quantidade de apps que criamos para clientes foram:

[table style=”1″]
Apple Android Blackberry
49 Apps 21 Apps 13 Apps
[/table]

Destas apps 80% são gratuitas e envolve campanhas publicitárias, mercado de publicação digital, 12% são games e 8% apps institucionais.

De todas elas, a mais lucrativa foi a Blackberry, Apple Store dá dinheiro, mas não tanto. O mercado de Android é saturado, ou você distribui a App de graça com propaganda ou nem dinheiro para um burger king você vai ter.

Fonte: http://www.gartner.com/newsroom/id/2482816

Android/ ios/ Pessoal

Android Alerta: Cuidado com que o seu dispositivo envia quando está conectado

android_malware

android_malware

Quando se trata de celular, eu sou cético em sair instalando tudo que tem por ai, por mais gratuito e bem polído o aplicativo seja. Quando sobra aquele tempo eu investigo  um pouco a mais o que o app trás. E pasmem, Todos os Apps que eu baixo 2 em cada 5 querem os meus dados como ‘lista de contatos’, última localização válida, quais serviços estão sendo executados no exato momento.

Mesmo o Google com uma batalha de gato e rato e implementando novas coisas, mesmo assim tais Apps são só descobertos se você desconfiar.

Se você tem um Android, você tem a grande facilidade de monitorar isso com maior clareza, já que você é responsável pelos seus dados e toda fabricante (Apple/Google/Microsoft/RIM) afirma, você é quem deve dizer se deixa ou não acessar tais informações.

Ontem eu queria instalar um App grátis no meu Android, para manter a descrição intácta e preservar os autores, digamos que ela seja uma to-do-list. É sempre bom ficar de olho na concorrência e para minha surpresa, mesmo não pedindo autorização a lista de contatos a App tinha um serviço para tal coleta. Acreditem ou não o App faz duas instalações do aparelho, 1 que é o app propriamente dito e outra é o serviço.

Afim de estudar um pouco à mais essa perceção de captura de dados eu começei a debugar o Aparelho, mesmo com o .apk inacessível você consegue ver os serviços em questão e ver o que eles rodam.

Você pega o ADB e começa a dedilhar o que é exposto, mesmo assim não dá para saber muita coisa além do nome do serviço rodando que você também pode ver direto do Android.

Pesquisei como capturar o tráfego e o que estava saíndo do Android, e acabei com esse link que indico para você baixar e testar em seu próprio aparelho.

No final das contas, realmente o App copiava meus contatos apenas com e-mails, enviava minhas últimas coordenadas de GPS válidas e algumas variáveis métricas para saber que aparelho eu estava utilizando. Ficando apenas o ponto crítico e imoral de coletar meus dados pessoais.

Fiquem espertos com muita vantagem! Cabe a você fazer tais denúncias.

AIR Mobile/ Android/ Apache Cordova/ ios/ iPad/ Iphone/ JQuery Mobile/ Phonegap/ Tablets

Apache Cordova vs Adobe AIR para dispositivos móveis

cordova_logo

É bom ter competitividade na esfera web, assim nasce projetos fantásticos que ajudam o desenvolvedor a criar soluções práticas e rápidas.
Este é o caso do Apache Cordova aka “Phonegap”, o Cordova tem surpreendido diversos desenvolvedores móveis, pela sua praticidade em acessar recursos nativos do aparelho para diferentes plataformas móveis, assim como o Adobe AIR o Apache Cordova te ajuda de uma maneira fácil acessar calendário, contato, notificações, alertas, vibrar, geolocalização, compasso e uma diversidade de novas funções built-in que vem no seu celular.

Depois de gastar um bom tempo estudando seu modelo, seu comportamento e como ele trabalha, decidi escrever um post sobre ele e compara-lo ao Adobe AIR, o que nesse caso eu tenho mais intimidade.

Assim como em qualquer tecnologia, você tem os pros e cons, acho que com isso você já tem uma noção maior do que usar e o que não usar, colocando em mente que cada caso é obrigatório analisar primeiro antes de decidir.

Apache Cordova

Pros:

  • Atinge 6 plataformas com uma só API
  • 90% de sua API já é built-in ( Vibration, BatteryLevel, Menu, Alertas, Calendário, Contatos)
  • Possibilita você criar suas extensões próprias com facilidade
  • Larga comunidade e alta frequência de builds.
  • Curva de aprendizagem muito rápida
  • Arquivo de instalação leve máx (4mb)
  • Performance de execução do App e efeitos de transição beira o nativo.
  • Interface pode ser feita em HTML/CSS/JS o que muito designer pode criar suas próprias Apps facilmente.
  • Componentes são criados e desacoplados em tempo de execução
  • Interfae é interpretada por um navegador interno WebKit

Cons:

  • Diversos frameworks para UI, faz você se perder em qual usar para seu projeto
  • Não tem suporte a HTTPS
  • Não suporta gestos por padrão, você tem que usar biblioteca externa para isso.
  • Ainda para dispositivos ios você tem que colocar o velho POG em ação para aceleração de hardware
  • Documentação é pobre de exemplos
  • Sem suporte a SQlite por padrão
  • Não suporta encriptação do sqlite
  • Suporta transferencia de dados em XML/JSON

 

Adobe AIR  3.5 para mobile

Pros:

  • Atinge apenas (Android 2.3.3+, ios 3.1+ e Blackberry Playbook)
  • Ciclo de vida de componentes baseado em eventos
  • Suporte a gestos por padrão
  • Suporta transferencia de arquivos em AMF/AMF3/JSON/XML
  • Suporta HTTPS/ SQLite/ Webcam/Audio e Video
  • Live stream de videos
  • Componentes já pré-fabricados usando o Flex Framework
  • Performance de 60fps quando usadas as classes Stage3D
  • Documentação extensa

Cons:

  • Arquivo de instalação ~10mb o que é grande para se transmitir via 3G
  • Interface é compilada e rendenizada
  • Suporta recursos nativos apenas se você extender com o ANE
  • Rendenização de texto é um pesadelo
  • Layout fluido para diversas telas diferentes é um POG gigantesco
  • Performance lenta quando se tem mais de 5 views
  • Ciclo de 24fps deixa qualquer celular com Android 2.3.3 lento
  • Não melhora o gerenciamento da bateria.

 

Claro que tem outros pros e cons de cada tecnologia, só que essas são as mais corriqueiras que você vai ver em grande parte dos casos quando for escolher.

E qual devo usar? Essa deve ser sua pergunta agora depois de ter lido os pros e cons. Minha resposta é vai depender de seu caso e o que você precisa fazer.

Um exemplo é, se você vai fazer jogos, eu lhe aconselho usar o Adobe AIR, já que a performance é melhor e muito mais fácil para criar jogos, agora se você vai fazer uma App para empresa que ela coleta informações de inventário, informações de cliente ou um App para registro de compras, o Apache Cordova é seu melhor parceiro.

Depois de duzias de Apps escritos, eu estou considerando o Apache Cordova como primeira opção e logo em seguida o Adobe AIR para boa parte dos Apps que escrevo diariamente.

Pergunto a você quais foram seus maiores problemas entre as duas plataformas?

AIR 2.7/ Flex/ Flex 4.5/ Flex Mobile Framework

Criando seu primeiro aplicativo Flex 4.5 Mobile para smartphones Android parte (2 de 3)

Caso você tenha chegado direto nessa matéria, ela é uma série de 3 partes, essa é a segunda. Se quiser ler do começo, clique aqui.

A estrutura de uma aplicação Android

Uma aplicação Android é como um arquivo .zip, de fato sua extensão .apk é um pacote com a mesma estrutura de um arquivo .zip, onde tem todos os elementos necessários para serem identificados no sistema operacional e assim sua aplicação existir e ter funcionabilidade.

Então, assumindo a premissa que um arquivo .apk seja uma aplicação Android, sua estrutura parte de 3 pilares básicos.

  • Código fonte escrito em Java e usando API do Android SDK
  • Estrutura de organização do projeto
  • Arquivos de mídia

filestructure

Com essa estrutura simplificada você consegue entender facilmente onde vai caber o arquivo de .swf que é embarcado dentro de seu pacote .apk, Na pasta de arquivos de mídia.

Essa pasta guarda o swf compilado com o Flex Framework e as suas classes em um único SWF, evitando assim os preloads, ou erros de fuga que possam ocorrer durante o processo de uso da app, garantindo não só a solidez de uma aplicação flex mobile como sua portabilidade entre diferentes telas e requisitos de sistema Android.

flex_apk_estrutura

Na imagem acima, você pode ver que o time do Flex conseguiu adotar o padrão “assets”, amplamente usado por apps RIA. Vai dizer que você nunca colocou seus ícones dentro desse diretório? A pasta assets substitui naturalmente a pasta /res que guarda esses recursos.

Já que você viu a estrutura de onde vão as coisas, que tal se aprofundar agora no arquivo de maior importância para a estrutura de um app Android?

O arquivo AndroidManifest.xml é a espinha dorsal que faz com que um App seja um App, é o mesmo que sua coluna vertebral, embora você só lembre dela quando está com dores nas costas, a coluna vertebral nos ajuda a definir nossas capacidades musculares, andar hereto e também ter dores 😀

Em fim, o arquivo AndroidManifest.xml ele é uma espécie de coluna vertebral + nervos especiais que definem funções do que sua aplicação mobile vai acessar, requisitar, armazenar e interagir.

Tudo que você faz no AndroidManifest.xml é mapear acessos, requisições e o mais importante permissões, tudo a base de tag de XML. E uma das coisas bem fantásticas disso tudo é que o pessoal da Adobe fez isso de uma forma bem legal, deixando apenas agente se preocupar com os acessos, o que sua App vai acesssar, como GPS, Acelerometro, cartão de memória, Camera e por ai vai. O resto eles cuidam para gente.

Então você sabendo com o que você vai lhe dar, é ultra simples encarar o desafio, veja aqui as permissões existentes no Android, onde nem todas são acessíveis pelo Adobe AIR, algumas apenas são possíveis de acessar por padrão, dentre elas:

air_permissions_by_default

Ufa, chega de explicações, então está preparado para começar a criar seu primeiro projeto Flex Mobile no Flash Builder 4.5.1 ? Vamos lá.

Para criar um novo projeto é simples, existem 3 maneiras:

  • CTRL+N Cria um novo projeto pelo Wizard escolhendo a categoria Flex e depois Flex Mobile Project
  • Vá ao menu File -> New -> Flex Mobile Project
  • Ou usando o Navigator do Flash Builder com o botão direito File -> New -> Flex Mobile Project

De todas as opções, a mais rápida e que praticamente desenvolvedores usam é a terceira, por que economiza tempo na criação e atalhos.

new_flexmobile_project

Lembre-se de setar o SDK que você fez o overlay para a versão Flex 4.5.1 SDK com o AIR 2.7, é super simples de fazer isso, basta clicar na opção Configure SDKs e adicionar o diretório onde você tem o SDK com overlay.

Quando você dá um nome ao projeto, ele particularmente vira o nome da App que você está publicando para o Android Market, então dê nomes simples sem acentos para que você consiga alcançar não só a Android Market Brasileira mais a mundial.

A idéia do nome para App.

Meu aplicativo será um pesquisador de tags do twitter, onde eu vou analisar em diferentes intervalos e tags o que anda rolando na rede social, vou chamar ele de TagsMonitor.

Dado o nome da App de TagsMonitor, eu vou clicar em Next.

config_flexmobile_project

Essa próxima tela é a essência da configuração de sua App.Para não deixar de explicar cada passo, separei por tópicos para você não perder o raciocínio.

Escolhendo a plataforma de publicação

target_platforms

Com configurações extras e exatas você consegue fazer para as outras. Como agente só vai fazer para Android deixo apenas marcado Android.

Escolhendo o template para a aplicação

Existem 3 tipos de aplicação Flex Mobile que você pode fazer, esses templates definem o comportamento de como ela apresenta para o usuário final, os tipos são:
Blank – Uma tela branca onde você tem liberdade de fazer o que quiser, semelhante ao que o Flash também proporciona.
View-Base – Uma tela com um sistema de navegação para N Views(telas). Semelhante ao ViewStack do Flex 2/3.
Tabbed – Que é como o antigo TabNavigator do Flex 2/3 e semelhante ao View-Base, a diferença é que você terá abas prontas para navegar.

view_base_app

Essas diferenças são aplicadas em variados tipos de aplicações e em qual o propósito de sua aplicação. O template mais comum que usaremos é o View-Base. Marque essa opção e pulamos para o próximo tópico.

Permissões acessadas

permissions_config

Como você sabe que para consultar a internet do seu aplicativo dentro de um dispositivo Android você precisa permissões, o Flash Builder por padrão já entende isso e deixa marcado já para você. Se você quiser acessar os outros recursos basta marcar aquele que você deseja. Próximo passo.

Densidade dos dispositivos

Cada fabricante tem seu próprio formato de densidade, até mesmo usando o mesmo OS como é o Android. Uma soma geral de densidades e tipos de telas você pode achar aqui. Que é a referência básica que o Android dispõe baseado em estatísticas coletadas.

google_densidades

A coisa mais legal do Google é que eles atualizam constantemente essas densidades e tamanhos de telas;Felizmente grande parte dos 550mil dispositivos ativados diariamente são normais, tanto no tamanho da tela quanto em sua densidade, que pode variar pouco entre um fabricante e outro. Até por que existe o mundo dos tablets Android e você pode considerar também a criação para ele.

No geral a média é de 240dpi. O que já facilita para gente, que é basicamente o padrão de mercado consideramos assim.

density_config

As outras partes, acredito eu que você vai deduzir que sejam Auto-reorientação que por padrão vem marcado, isso faz sua app ficar responsiva em trabalhar tanto com o device na horizontal ou na vertical.
FullScreen marcando essa opção ele vai esconder a parte do relógio e status, rodando sempre em primeiro plano e deixando o resto da interface gráfica do sistema em segundo plano.
E a última opção que vem é auto escalonar sua aplicação para os padrões de DPI, a Adobe acredita que 160dpi está ótimo, eu discordo dessa abordagem e considero mais padrão 240dpi do que os 160dpi padrão. Seja esperto e marque essa opção e mude de 160dpi para 240dpi.

Clique em Finish. E seu projeto já está pronto para você começar a elaborar sua navegação.

Para fazer a prototipação desse App, usarei o Balsamiq Mockup, bem simples para você prototipar suas apps ou qualquer coisa. Se você tem a licença do Balsamiq, aqui está o código gerado do meu mockup, basta importar para a ferramenta e dá continuidade ou alterar.

mockup

Eu acabei chegando nessa configuração para esse novo App, é bem simples e funcional. O propósito desse App é ajudar você acompanhar hashtags ou termos utilizados no Twitter em um intervalo de tempo, ajudando você acompanhar as reações.

Navegando entre as views

Navegar entre as telas de uma App móvel é muito simples, e o pessoal da API bolou um esquema bem funcional, quando você imagina em telas você imagina a navegação saindo de um ponto A na tela A para um ponto B na tela B.
Apps móveis é 90% parecida com esse esquema de navegação, só que existem 2 fatores essenciais que as mudam, uma que a API só te leva de um ponto A da tela A para Tela B, não existe esse certo centrismo de um ponto específico para a outra tela; E o segundo fator que leva essa navegação é a maneira como você interage com ela, seja por toque ou seja por gesto, inverso do tradicional clique ou duplo clique de mouse.

navigator

Na imagem acima, você pode ver que a API utilizada pelo Flex para navegar entre Views, que é o componente principal de uma aplicação Flex Mobile é uma exclusiva palavra reservada que faz toda a diferença e dinâmica para trazer à vida sua App.

O “navigator”, é a palavrinha mágica que faz essa navegação, digamos que ela seja um Array que guarda o registro de cada tela, onde você executa alguns comandos básicos para navegar entre as views através dela. Esses comandos básicos são:

  • navigator.pushView(viewClass,data,context,transition);
  • navigator.popAll(transition);
  • navigator.popToFirstView(transition);
  • navigator.popView(transition);

Se você conhece bem de Array, sabe que comandos do tipo Pop, push, geralmente são associados a remoção e adição. É justamente isso que esses comandos faz, o primeiro o pushView, adiciona uma nova View ao navigator, o popAll, remove todas as Views do navigator, o popToFristView remove todas as telas, exceto a primeira, e o popView remove a View atual e volta para View anterior.

Definindo suas Views

Eu já sei como funciona a navegação, então vamos criar nossas Views, a primeira coisa que você deve pensar é em organiza-las, o Flash Builder deixa já por padrão dentro de um diretório views, eu particularmente gosto dessa configuração, deixando as views em um só diretório e colocando o inverse domain suas classes que irão manipula-la é quase perfeita sem precisa nenhum design pattern.

Minha primeira tela é a HomeView.mxml

home_view

Ela tem o seguinte código.

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
		xmlns:s="library://ns.adobe.com/flex/spark"
		actionBarVisible="false" title="HomeView">
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
	<s:Rect width="100%" height="100%">
		<s:fill>
			<s:SolidColor color="#52a2cb"/>
		</s:fill>
	</s:Rect>
	<s:Image x="74" y="48" source="assets/logo.png"/>
	<s:Label x="56" y="357" color="#FFFFFF" text="20 Tags"/>
	<s:Label x="304" y="357" color="#FFFFFF" text="30 Menções"/>
	<s:Button x="73" y="428" width="333" height="65" label="Novo hashtag"
			  icon="assets/tag_add_48.png" skinClass="com.riacycle.skins.WhiteButtonSkin"/>
	<s:Button x="73" y="505" width="333" height="65" label="Hashtags pesquisadas"
			  icon="assets/book_bookmark_48.png" skinClass="com.riacycle.skins.WhiteButtonSkin"/>
	<s:Button x="73" y="580" width="333" height="65" label="Configurações"
			  icon="assets/gear_48.png" skinClass="com.riacycle.skins.WhiteButtonSkin"/>
</s:View>

A próxima tela que eu preciso criar é a NovaView.mxml

nova_view

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
		xmlns:s="library://ns.adobe.com/flex/spark" title="Nova hashtag">
	<s:layout>
		<s:BasicLayout/>
	</s:layout>
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
	<s:navigationContent>
		<s:Button icon="assets/arrow_left_48.png"/>
	</s:navigationContent>
	<s:Button x="231" y="157" width="218" height="66" label="Adicionar" icon="assets/plus_48.png"
			  skinClass="com.riacycle.skins.WhiteButtonSkin"/>
	<s:Label x="43" y="51" color="#3A74CC" text="Termo"/>
	<s:TextInput x="42" y="82" width="403" height="64"/>
</s:View>

A próxima tela HashtagView.mxml é onde eu vou acompanhar as menções feitas pelos usuários do twitter.

hashtag_view

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
		xmlns:s="library://ns.adobe.com/flex/spark" title="Termo: #exemplo">
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
	<s:navigationContent>
		<s:Button icon="assets/arrow_left_48.png"/>
	</s:navigationContent>
	<s:actionContent>
		<s:Button icon="assets/arrow_circle_right_48.png"/>
	</s:actionContent>
	<s:List left="2" right="2" top="2" bottom="2"></s:List>
</s:View>

E a última View necessária para montarmos nossa App é a ConfigView.mxml onde, algumas configurações básicas serão adicionadas ao nosso App, para deixar ele um pouco personalizado.

config_view

Com o seguinte código:

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
		xmlns:s="library://ns.adobe.com/flex/spark" title="Configurações">
	<s:layout>
		<s:BasicLayout/>
	</s:layout>
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
	<s:navigationContent>
		<s:Button icon="assets/arrow_left_48.png"/>
	</s:navigationContent>
	<s:actionContent>
		<s:Button icon="assets/checkmark_48.png"/>
	</s:actionContent>
	<s:HSlider x="20" y="158" value="4"/>
	<s:Label x="19" y="37" text="Configurações gerais do App"/>
	<s:Label x="19" y="123" text="Intervalo entre consultas"/>
	<s:Label x="318" y="215" fontStyle="italic" text="Em minutos"/>
	<s:Button x="88" y="354" height="65" label="Apagar todo o histórico"
			  skinClass="com.riacycle.skins.WhiteButtonSkin"/>
	<s:Label x="22" y="317" text="Histórico de pesquisas"/>
</s:View>

Bem, até aqui nós definimos todas as Views que esse App pode apresentar, assim como um preview de cada dela, elas podem mudar no decorrer do artigo com algumas modificações simples e essenciais.

Para você acompanhar como ficou a organização do projeto, compartilho aqui o código fonte do projeto para você importar para seu Flash Builder.

Dica: Para salvar basta clicar no link com botão direito do mouse e escolher salvar como…

Até a próxima e última parte do artigo onde eu vou mostrar como codificar isso e publicar no Android Market.

AIR 2.7/ AIR Mobile/ Android/ Flex/ Flex 4.5/ Flex Mobile Framework

Criando seu primeiro aplicativo Flex 4.5 Mobile para smartphones Android parte (1 de 3)

Depois de muito tempo sem tempo, olha que controvérsia, acabei com algumas horas livres essa tarde e aproveito para escrever esse post.
Quer criar Apps para Android com o Adobe AIR e Flex? Siga a receita abaixo para isso.

Ja é sabido de sua parte que o Flex cria apps nativas para Android de forma hiper simples. Se você é acostumado ao seu workflow de componentes, ciclos de vidas, você irá facilmente criar Apps elegantes, rápidas e intuitivas para dispositivos móveis.

O Framework do Flex, que usaremos é o Flex 4.5 com overlay do Adobe AIR 2.7, que conta com 4x mais performance do que o AIR 2.6. Em suma, o Flex roda em dispositivos móveis por que o AIR Run-time roda no Android.

Só que antes de você sair comprando ai seus dispositivos xing-lings ou baratinhos com o Android para testar suas criações artisticas, aconselho ler esse POST.

Para começar a brincadeira, você vai precisar de alguns ingredientes, vamos aos itens:

Antes de configurar alguma coisa, é super importante que você tenha em mente a seguinte afirmação. Eu entendo os riscos e serei um bom garoto(a), e nunca irei portar nenhum App meu com Datagrid de 100 registros dentro de uma App móvel, não farei Zilhões de operações.

Ok! Agora pode continuar.

Criando uma conta no Google e no Android Market

Esse passo é o mais simples que você encontrará nesse post, duvido que você não tenha uma conta no Google, vai dizer pajé que tu não tem um @gmail.com ? Uma continha perdida do Orkut? Ah! você vive em outro mundo que não é esse, volta para lá de onde tu veio vai! Esqueça isso de Mobile.

Ok, animos acalmados, criou a conta? Ah! Já tem? Ótimo, o próximo passo é registra-se no Android Market e se tornar um publicador de Apps lá. O processo é mega simples, entre no endereço https://market.android.com/publish/Home
android_publish_home.

Coloque seu login e senha e clique em Login, como você ainda é novato, vai aparecer outra tela perguntando seu Developer Name, dados de contato e telefone. Lembre-se coloque um nome de guerra, nome profissional, nada de vitinho, Vikky, Fofinha, LindinhadoAndroid, algo que passe credibilidade aos seus futuros usuários, Caso você seja uma empresa nem preciso fazer essas recomendações, basta colocar o nome da empresa que você quer usar como Developer Name no formulário.

android_publish_info

Clique agora em Continue.

Depois disso, você precisará dos

US$25 dolares

para fazer a sua inscrição no programa por 1 ano, se você tem conta no Google Checkout basta gastar por lá, caso contrário use algum cartão de crédito de qualquer bandeira que aceite transações internacionais.

android_publish_pagamento

Pronto, você está com a conta no Google Android Market criada e é só aguardar a liberação. Em média esse processo é quase imediato, em outros pode levar cerca de 1 dia no máximo. A coisa é rápida, então fica de olho no e-mail de boas vindas quando tudo for aceito pelo Google.

Aqui está minha dashboard no Android Market.

android_publish_dashboard

Configurando o Flex 4.5.1 SDK para usar o AIR 2.7 SDK

Como o SDK do Flex 4.5.1 ainda vem com suporte ao Adobe AIR 2.6 que é cerca de 4.x mais lento tanto no Android quanto no IOS, você vai precisar configurar seu SDK, esse processo agente chama de “SDK Overlay”, que é basicamente um CTRL+C e CTRL+V em alguns diretórios que sobrepõem arquivos antigos do AIR 2.6.

Baixou o AIR 2.7 SDK? Ok, feito isso extraia ele para um diretório de sua confiança, que seja simples de acessar. O pacote contendo o AIR 2.7 SDK tem os seguintes diretórios e arquivos.

air_2.7_sdk

Se você tem um igual, sinal que vai dar tudo certo, meio caminho andado.

Baixou o Flex 4.5.1 SDK? Ótimo, faça o mesmo processo do AIR 2.7 SDK e descompacte ele no seu diretório predileto, eu particularmente sempre deixo em um diretório meu chamado SDKs, porém nesse exemplo tem pessoas que gostam de deixar no mesmo diretório dos já existentes SDK do Flash Builder 4.5.1.

Ok, se você tem o SDK já descompactado, basta copiar o conteúdo da pasta onde você descompactou o AIR 2.7 SDK dentro da pasta do Flex 4.5.1. SDK. A idéia é sobrescrever os já existentes.

Feito? Ok, próximo passo é instalar o Flash Builder, a ferramenta perfeita para você criar suas apps, não só para Android como para outros devices, ios, BlackBerry Playbook, Web e Desktop.

Flash Builder Instalado? Perfeito, vamos agora configurar o ambiente Android para rodar sua app no console nativo que o próprio google disponibiliza.

Configurando o Android Console

Já tem o Java instalado em sua máquina? Então pule essa etapa, ela só serve mesmo para quem nunca usou o JDK ou tem apenas o JRE.

Para você testar no console, você precisa do JDK(Java Development Kit), que já vem tudo em um, então dependendo de seu sistema operacional, você precisará fazer alguns processos manuais, já no Windows é meio for dummies, é next-> next-> finish.

Baixou o correto referente ao seu OS? Instalou? Ótimo, pois agora precisamos definir as variáveis de ambiente do JAVA_HOME nas configurações globais do sistema operacional.

No Windows, vá em Iniciar – > Computador -> Botão direito do mouse -> Escolha propriedades -> Escolha aba Configurações Avançadas -> Variáveis de ambiente.

Adicione um novo registro na suas variáveis de ambiente com o nome JAVA_HOME. Olhe o exemplo abaixo.

jdk_java_home

Se você configurou tudo certinho, você pode testar no prompt do DOS do windows digitando java -version. Vai aparecer isso aqui ó.

java_version_console

Agora você está pronto para o Android SDK.

Baixando e configurando o Android SDK

Baixou o SDK? Então descompacte em um diretório de fácil acesso, eu coloquei o meu em C:/android-sdk. Para facilitar digitação de comandos.

Execute o SDK Manager, que é o carinha responsável por baixar todos os arquivos necessários do Android SDK da nave mãe Google.

android_avd

Pela primeira vez, esse processo dependendo de sua conexão com a internet, leva uma média de 1 hora para baixar todos os arquivos para seu computador.
Depois disso ele fica como o meu aqui.

android_sdk_dir

Ok, tudo configurado e instalado, vamos verificar se está mesmo. Com o mesmo comando que fiz para o java -version, usarei agora o comando adb version que é o Android Debug Bridge , para ver se executa corretamente.

android_adb

Se aparecer como na imagem acima, é sinal que tudo está correto e perfeito para criarmos nosso Android Emulator, onde iremos simular o sistema operacional Android. Prontos para esse passo?

Ah! Que esqueci, que depois que ele instalar tudo, ele vai pedir para você fechar o SDK Manager e abrir novamente, para que as alterações sejam aplicadas.

Criando o Android Emulator

Ok, volte agora ao SDK Manager e escolha a opção Virtual Devices.

android_virtual_devices

Veja que nesse meu eu já possuo 2 devices virtuais, para criar outro basta clicar em “New…”.

android_new_console

Preencha os dados de seu virtual device, assim como mostra na imagem acima, veja que eu não esqueci de criar usando o Android 2.2 API level 8, que é o necessário para o Adobe AIR rodar e consecutivamente o Flex. Como eu quero apenas testar a App nativa no dispositivo virtual eu deixei as outras configurações padrão, salvo apenas para a memória alocada de 100mb para esse console. Agora clique em “Create AVD”.

O AVD foi criado, só que agora falta executar, esse processo é bem gastante se você tem pouca memória na máquina, típicos 2GB, demora aproximadamente 20min até 30min para ele começar realmente executar, Eu por exemplo tenho 8Gb de memória e leva uma média de 5min. Se você tiver problemas na hora de executar veja se o JVM está setado corretamente.

Para executar, basta clicar em “Start…”.

android_starting

Essa tela preta é demorada, então aproveita e vai tomar um café, falar com sua tchutchuca.

….
……………
Passados alguns minutos. E eis que temos a tela inicial do Android rodando.

android_started

Android rodando, navegando na Web, agora só temos um problema, não temos o Adobe AIR instalado para testar a App, como fazer?

Instalando o Adobe AIR APK no seu emulador

Se você é por natureza curioso, dúvido você não ter bisbilhotado o SDK do Flex que você fez o overlay(Sobreposição) do AIR 2.7 no Flex 4.5.1 SDK. Abra esse diretório para você navegar nele, dentro do SDK você vai encontrar o nosso famoso AIR.apk que é necessário para rodar suas Apps.

air_apk_folder

Veja que eu fiz um mapinha de onde você vai achar o run-time do AIR para seu emulador Android, existem dois, para o Device e para o Emulador, você deve usar a versão Emulador, que é com ela que você vai conseguir emular alguma coisa. Resumindo eis aqui o caminho completo em minha máquina.

C:Program Files (x86)AdobeAdobe Flash Builder 4.5sdks4.5.1_air2.7runtimesairandroidemulator

Lembre-se seu índio, que o diretório na sua máquina pode ser diferente, se não você vai reclamar depois nos comentários que não consegiu achar o tal APK.

Eu copiei o meu para esse exemplo para o diretório raiz, C:/ para facilitar agora o processo de digitação pelo prompt de comando.

Abra o CMD(MS-DOS), e digite o comandos abaixo.

adb devices

adb_devices_list

Se aparecer o nosso Emulador em execução,é por que está tudo OK.

Para instalar é super simples, digite o comando.

adb install {NOME-DO-EMULADOR} c:/Runtime.apk

adb_devices_install_sucess

Finalmente terminamos essa parte chata de configurar a máquina, seu Adobe AIR está funcionando perfeitamente no seu device, Só que como é que eu sei que ele está instalado? Tem 2 formas, vê se o resultado do comando de instalar deu certo e também indo no Emulador, clicar em
Settings -> Applications-> Manage Applications; E você vai ver o Adobe AIR instalado lá.

air_installed

Tudo pronto, agora só abrir o Flash Builder já instalado e começar com sua App Hello World. Nos vemos na próxima Etapa.

Aproveite e participe do grupo de discussão Flex-Mobile

Android/ Cursos/ Dicas

03 e 10 de Setembro Curso on-line Android Nativo Essencial

androidbanner2

Ser ou não ser eis a questão, essa é uma frase famosa do poeta William Shakespeare, escrita no século 15.

Hoje eu mudaria ela para Ser Android ou não ser, eis a questão. A empresa que eu trabalho eu realmente amo o que eu faço pelo simples fato dela ser uma empresa que motiva seus funcionários a fazer o melhor e não só isso, motiva a outras pessoas (alunos) a criarem coisas fantásticas e assim colaborar mais ainda para uma internet rica, móvel e fantástica.

Nos dias 03 e 10 de Setembro o Grande Stefan Horochovec vai ensinar ao pessoal como criar Apps nativamente para plataforma Android, o mais interessante de se criar apps nativas com código do próprio SDK é que você não fica só limitado ao AIR 2.5+ e Android 2.2. Você tem uma grande leva de dispositivos que você pode atingir.

Atualmente cerca de 550 mil novos smartphones com Android são ativados diariamente. Que juntos somam um exército de 130 Milhões de dispositivos rodando o Robozinho. Dai eu fico perguntando e você vai ficar ai parado e vendo toda essa manada passar diariamente e não vai fazer nada para criar algo para ela?

Pense bem, e faça esse curso que vai explorar todos esses recursos, quem é desenvolvedor Web ou Java vai adorar, afinal de contas a didática do Stefan é muito boa.

Ande logo! Por que é imperdível.