logo
  • Home
  • Acerca
  • Autores
  • Faq
  • Rede
  Twitter   Feed-me! RSS!
Mai 20

Windows Phone 7–UI Thread e Composition Thread

Escrito por Alexandre Tadashi em 1, 2.0, 2009, 3.5, 4, 6, Animação, Animações, app, AR, Artigo, auto, back, Behavior, BI, bitmap, busca, C#, cache, class, CSharp, Curso, Cursos, demo, desempenho, dispatch, Diversos, Draw, DRE, event, exemplo, Experiência do Usuário, for, function, git, Gráfico, handle, html, ide, IE, if, image, imagens, int, interface, Introdução, library, map, maps, mg, Microsoft, monitor, Monitoramento, movimento, MSDN, O, on, Outros, RIA, Ria’s Geral, S+S, silverlight, Silverlight 3, SmartPhone, Software, Storyboard, Sun, super(), TAT, Tema, try, UI, Vídeo, Visual Studio, Visual Studio 2010, vs, window, windows, XP @ 05 20th, 2011 | via http://alexandretadashi.net/ | Sem comentários
Alexandre Tadashi
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

imageA renderização da interface gráfica do Windows Phone 7 foi projetada para buscar o máximo de performance que o smartphone pode proporcionar, a UI Thread é responsável pelo desenho da interface principal do aplicativo, quando criamos um software para o WP7, devemos evitar bloquear a UI Thread, pois ela está diretamente relacionada a performance do software e também com a experiência do usuário com o aplicativo.

Os smartphones com Windows Phone 7, tem disponível um recurso que utiliza a aceleração da GPU, aumentando consideravelmente o desempenho gráfico para algumas tarefas relacionadas a manipulação de imagens e animações, principalmente as que usam a rotação de eixos, escalas e alguns tipos de? animações que usam de Storyboard. Não é necessário acionar nada para que alguns tipos de Storyboards utilizem esse recurso, eles automaticamente usam o Composition Thread ou também chamado de Render Thread.

O Render Thread pode ser usado para animações simples utilizando DoubleAnimation ou Easing Functions, ou em propriedades? como Opacity, Render Transforms e Rectangular Clip. Habilitando o EnableRedrawRegions podemos ver quais regiões na aplicação estão sendo desenhadas no momento, visualizando? quadro a quadro:

Application.Current.Host.Settings.EnableRedrawRegions = true;

Composition Frame Rate Thread? e UI Frame Rate Thread

Quando executamos um aplicativo através do Visual Studio 2010 com o smartphone plugado no computador,? podemos visualizar alguns números no lado superior direito da tela, esses números servem para você ter como parâmetro alguns pontos sobre a renderização gráfica, memória, etc, os dois primeiros números de 3 dígitos são referente a Render Thread e a UI Thread.

Thread

O Composition Frame Rate Thread está associado a velocidade com que a tela é atualizada em uma thread separada da UI Thread, como referência, o Windows Phone 7 utiliza o valor 30 como ponto de equilíbrio, ou seja, quando for abaixo de 30, os números estarão na cor vermelha, acima de 30 ele ficará com a cor default, o valor mais próximo de uma boa performance é 60, sua aplicação deve buscar sempre se aproximar desse número.

O UI Frame Rate Thread mostra a taxa de atualização da Thread principal, enquanto a interface do usuário estiver ativa, o valor de 30 também foi definido como ponto de equilíbrio, ficando vermelho se a aplicação estiver abaixo deste valor, porém este valor deve ser acima de 20 para ter um tempo de resposta aceitável e quanto maior o valor , o tempo de resposta será mais rápido.

Exemplo prático de UI Thread VS Render Thread

Vou criar um aplicativo simples com dois elementos Ellipse na tela, um com o nome BolaVermelha e outro com BolaAzul, as duas Ellipses serão animadas na tela, a BolaAzul vai utilizar o Render Thread, pois vamos utilizar uma Storyboard com a propriedade RenderTransform, já a BolaVermelha vamos anima-lá atualizando a mesma propriedade, mas utilizando um timer DispatcherTimer para atualizar a propriedade, ou seja, não utilizaremos uma Storyboard para realizar a animação e ela estará utilizando a UI Thread.

   1:    public partial class MainPage : PhoneApplicationPage
   2:      
   3:  
   4:          DispatcherTimer timer;
   5:          RotateTransform rotateVermelho;
   6:          bool bateVolta;
   7:          int contador = 0;
   8:  ? 
   9:          public MainPage()
  10:          
  11:              InitializeComponent();
  12:              Loaded += new RoutedEventHandler(MainPage_Loaded);
  13:  ? 
  14:              Application.Current.Host.Settings.EnableRedrawRegions = true;
  15:  
  16:              this.BolaVermelha.RenderTransform =
  17:                  new RotateTransform();
  18:              this.BolaAzul.RenderTransform =
  19:               new RotateTransform();
  20:  
  21:              rotateVermelho =
  22:              BolaVermelha.RenderTransform as RotateTransform;
  23:              rotateVermelho.Angle = -50;
  24:  ? 
  25:              timer = new DispatcherTimer();
  26:              timer.Tick += new EventHandler(timer_Tick);
  27:              timer.Interval = new TimeSpan(0, 0, 0, 0, 33);
  28:              timer.Start();
  29:  ? 
  30:              bateVolta = false;
  31:  
  32:          
  33:  ? 
  34:          void MainPage_Loaded(object sender, RoutedEventArgs e)
  35:          
  36:  ? 
  37:              Storyboard storyboard = new Storyboard();
  38:              DoubleAnimation animation = new DoubleAnimation();
  39:              animation.From = 0;
  40:              animation.To = 180;
  41:              animation.Duration = new Duration(new TimeSpan(0, 0, 1));
  42:              animation.AutoReverse = true;
  43:              Storyboard.SetTarget(animation, this.BolaAzul.RenderTransform);
  44:              Storyboard.SetTargetProperty(animation, new PropertyPath("Angle"));
  45:              storyboard.Children.Add(animation);
  46:              storyboard.RepeatBehavior = RepeatBehavior.Forever;
  47:              storyboard.Begin();
  48:  
  49:          
  50:  ? 
  51:          void timer_Tick(object sender, EventArgs e)
  52:          
  53:              if (rotateVermelho .Angle == 120)
  54:              
  55:                  bateVolta = true;
  56:              
  57:              if (rotateVermelho.Angle == -50)
  58:              
  59:                  bateVolta = false;
  60:              
  61:  ? 
  62:              if (bateVolta == true)
  63:              
  64:                  rotateVermelho.Angle -= 1;
  65:              
  66:              else
  67:              
  68:                  rotateVermelho.Angle += 1;
  69:              
  70:  ? 
  71:              contador++;
  72:  ? 
  73:              if (contador == 600)
  74:              
  75:                  MessageBox.Show("Parando a UI Thread");
  76:                  Thread.Sleep(1000);
  77:              
  78:  ? 
  79:              if (contador == 1000)
  80:              
  81:                  MessageBox.Show("Inserindo BitmapCache");
  82:                  BitmapCache cache = new BitmapCache();
  83:                  BolaVermelha.CacheMode = cache;
  84:  ? 
  85:              
  86:  ? 
  87:          }
  88:  ? 
  89:      }

?

Na linha 71 criei um contador, quando chegar a 600, ele vai bloquear a UI Thread, na linha 76, a UI Thread é bloqueada propositalmente utilizando Thread.Sleep, neste momento você irá notar que a animação da? BolaVermelha irá parar com base no tempo definido em Sleep, pois a sua Thread está bloqueada, mas a BolaAzul continuará a se movimentar.

Quando o contador chegar a 1000,? vou adicionar um BitmapCache na propriedade CacheMode da BolaVermelha, em alguns casos onde não estamos utilizando a Render Thread, podemos criar um cache, ou seja, colocar os bitmaps na memória, e com isso aproveitar da aceleração da GPU, com performance semelhante a Composition Thread, porém a BolaVermelha continuará na UI Thread,? uma simples mensagem na tela utilizando um MessageBox irá bloquear a UI Thread enquanto a BolaAzul continuará em movimento.

Conclusão

UI Thread e Composition Thread são recursos fundamentais que o Windows Phone 7 utiliza para apresentar a interface gráfica, conhecendo essas Threads você poderá melhorar a perfomance da sua aplicação, os smartphones são equipamentos limitados se comparado a um PC, conhecer quando utilizar determinado recurso pode fazer muita diferença, existem diversos outros pontos a serem considerados quanto ao monitoramento da aplicação com objetivo de melhorar a perfomance, neste artigo somente apresentei uma introdução sobre o assunto.

Alguns recursos podem não funcionar como esperado no emulador, pois depende de diversos fatores como o suporte a DirectX pela placa de video, neste link você encontra mais informações:

WP7/Silverlight Graphics Performance

Mais informações sobre Bitmap Cache : Bitmap Cache

Mais informações sobre performance: Performance Considerations in Applications for Windows Phone

Mai 19

10 coisas que um bom programador flex deve saber

Escrito por Daniel Schmitz em .NET, 1, 2.0, 2009, 3.5, 4, 6, action, Action Script, Actionscript, ActionScript 3, Actionscript 3.0, Actionscript3, Adobe, Air, api, Aplicativos, Apresentação, AR, Arquitetura, arte, Artigo, as3, BI, Bindable, blog, bug, builder 4, C#, Cairngorm, class, classe, classes, código, código fonte, Componente, Componentes, components, control, Controles, css, Curso, Cursos, custom, dados, Data Binding, DataGrid, Debug, demo, desempenho, Desenvolvedor, desenvolvedores, Design, developer, development, dispatch, dispatchEvent, DRE, empresas, err, Estilo, event, EventListener, Evento, Eventos, eventos customizados, events, Excel, explorer, Ferramenta, flash, flash builder, Flash Builder 4, Flash Player, Flex, Flex 3, Flex 4, Flex Examples, fonte, for, framework, Frameworks, Google, Gráfico, handle, html, HTTPService, ide, IE, if, int, interface, Java, layout, lista, live, Livro, lógica, map, Mate, MAX 2009, mvc, MXML, O, on, oop, opensource, Outros, player, polimorfismo, problema, problemas, programação, Projetos, pt, RIA, Ria’s Geral, ruby, S+S, site, skins, Sun, tag, TAT, Tech, Tecnologia, tv, UI, uint, utf8, Ved, Vídeo, vs, web, Webservice, XML, XP @ 05 19th, 2011 | via http://flex.etc.br | Sem comentários
Daniel Schmitz
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

Esta é uma tradução do seguinte artigo: 10 Things A Good Flex Developer Should Know

Para ser um bom programador Flex é preciso mais que simplesmente saber como usar alguns componentes nativos do Flex. É preciso muito mais.

Aqui está minha contribuição sobre o assunto… juntamente com alguns recursos ou algumas palavras-chave que você poderá pesquisar facilmente através do Google.

Por favor, comente no blog se você achar que esqueci algo (o que é inevitável) ou se quiser sugerir alguns recursos interessantes que devo acrescentar.

1- Programação orientada a Objetos (OO)

O Flex se baseia na linguagem ActionScript3, que é totalmente orientada a objetos. Embora não seja um conceito fácil de aprender, programação orientada a objeto é um pré-requisito para aprender Flex. Se já possui experiência com OO (Java, C#, Ruby, etc), então você está pronto. Se não, você precisará pegar um livro sobre OO e começar a aprender o mais rápido possível.

· Head First Java (Java? Sim, Eu sei. Mas confie em mim.)

· Object-oriented programming with ActionScript 3.0

Nota: Alguns de vocês poderão perguntar – “O que são padrões de projetos?”. Vamos dar um passo de cada vez? Preocupe-se em entender classes e objetos, interfaces, herança, composição, polimorfismo, encapsulamento, etc. Só então considere estudar padrões de projetos. De fato, se eu escrever um post intitulado “10 coisas que um GRANDE programador Flex deve saber”, padrões de projeto estará nessa lista.

2- ActionScript/MXML

ActionScript é a linguagem de programação usada juntamente com MXML para criar aplicações Flex. MXML é uma linguagem de marcação baseada em XML. Cada tag MXML é mapeada diretamente para uma classe ActionScript correspondente. MXML é usado pelos desenvolvedores Flex principalmente para apresentar a interface do usuário, enquanto que, o ActionScript é usado para a lógica de negócio. Com exceções, é claro.

O Framework Flex inclui centenas de classes ActionScript e interfaces usadas para desenvolver aplicações Flex. Seu nível de habilidade como um desenvolvedor Flex está diretamente ligado ao seu conhecimento em relação ao ActionScript e MXML.

· Flex in a Week

· Tour De Flex

· Essential ActionScript 3.0

Nota: Fique ? vontade com a API do Flex. Como um desenvolvedor Flex, você vai usá-la diariamente.

3- Debugging

Boa parte do tempo de qualquer programador é gasto no debugging. Obviamente, é necessário debugar para rastrear a causa de bugs. No entanto, também é uma ótima maneira de conhecer o código fonte.

Felizmente, existem muitas ferramentas disponíveis para ajudá-lo com o trabalho de debugging. Invista algum tempo para aprender essas ferramentas. Seu investimento irá proporcionar retorno imediato.

· Flash Builder 4.5 Debugger

· De MonsterDebugger

· Kap Inspect

4- Programação orientada a eventos

Aplicações Flex são orientadas a eventos. Toda ação é o resultado de um evento assíncrono.

Como um desenvolvedor Flex, você deve saber como responder a eventos e como criar e disparar eventos. Para isso, é necessária uma sólida compreensão da arquitetura de eventos do Flex, incluindo familiaridade com os seguintes conceitos:

· Eventos nativos (Flash Player ou Framework de eventos Flex)

· Eventos customizados (Eventos criados pelo desenvolvedor, que estende a classe Event ou uma de suas subclasses)

· Disparar eventos, propagação de eventos (ver classe EventDispatcher e seu método dispatchEvent)

· Event listeners, event handlers (ver classe EventDispatcher e seus métodos addEventListener e removeEventListener)

· Fases do evento (capture, target & bubbling phases; target vs. currentTarget)

· Objetos do evento, tipos de eventos (ver classe Event e subclasses)

· Comportamento do evento default (ver classe Event e subclasses e seu método preventDefault)

5- Data binding

Aparentemente, data binding é um “no brainer”[1]. É só vincular o valor de uma propriedade ao valor de outra propriedade usando chaves. Quando o valor da propriedade de origem for alterado, o valor da propriedade de destino também é alterado.

No entanto, existe uma sobrecarga associada ao uso indiscriminado de data binding, podendo haver implicações no desempenho. Uma sólida compreensão de data binding ajudará a determinar quando é apropriado o seu uso e quando não é.

· Flex Tips – Using Bindable Metadata Events

· Michael Labriola’s presentation entitled Diving in the Data Binding Waters

6- Item renderers

Uma característica de uma aplicação Flex bem projetada é a apresentação dos dados de uma forma visualmente atraente. O Flex oferece uma série de controles baseados em listas (DataGrid, List, TileList, HorizontalList, etc) responsável pela apresentação dos dados. Portanto, pode-se personalizar a exibição dos dados com a ajuda de item renderers.

Você irá consumir muito tempo trabalhando com item renderers. Então é melhor saber bem como ele funciona.

· Flex Examples – Item Renderers in Practice

· A Deep Dive into Flex 4 Lists and Layouts

7- Acesso remoto a dados

Você conhece muitas aplicações que não interagem com os dados? Eu também não. Saiba como recuperar dados através de HTTPServive, WebService e RemoteObject. A arquitetura do framework Flex também poderá ajudá-lo com isso (ver #9).

· Retrieving and handling data with HTTPService

· Retrieving and handling data with WebService

· Retrieving and handling data with RemoteObject

8- Styling / Skinning

Não vamos nos esquecer que o Flex é uma tecnologia de interface e, como tal, certamente há expectativas em relação ao design. Como um desenvolvedor Flex, você deve ser capaz de personalizar a aparência de seus aplicativos usando estilos CSS, gráficos e/ou skins.

Com o Flex 4, não há mais desculpas. Use um pouco do seu tempo para conhecer de uma vez o lado direito do seu cérebro. É uma excelente mudança de paradigma, e vai ajudá-lo a diferenciar-se dos outros desenvolvedores Flex.

· Flex Style Explorer

· ScaleNine

· Introduction to Flex: Part 3 – Styles & Skins

9- Pelo menos um framework de arquitetura Flex

A maioria dos frameworks de arquitetura Flex impõe uma separação de camadas através da implementação do MVC (model-view-controller). Além disso, esses mesmos frameworks especificam como seu código deve ser organizado dentro do projeto Flex.

Embora muitos argumentariam que os frameworks são desnecessários, acredito que os desenvolvedores Flex se beneficiam em muitos aspectos da experiência de usá-los. Basta assistir ? s técnicas (boas ou más) empregadas por um framework para resolver problemas complexos de arquitetura. Isso contribuirá para seu crescimento como um desenvolvedor Flex.

Além disso, é difícil negar o fato de que a experiência com framework aumentará substancialmente o seu valor comercial como um desenvolvedor Flex. Jesse Warden me disse recentemente “Existem poucas empresas que não usam frameworks, mas isso é raro. Queiramos ou não, está na ‘moda’”. Eu concordo com Jesse.

· Cairngorm

· Parsley

· PureMVC

· Mate

· Swiz

· Robotlegs

10- Ciclo de vida de componentes e display list

Eu não estava convencido da necessidade de aprender o ciclo de vida de componentes Flex ou da display list até que escrevi o meu primeiro componente customizado (na verdade foi um componente semi-customizado que se estendia do componente Canvas). Até essa época eu usava componentes nativos do Flex, usando apenas o MXML enquanto que a display list era renderizada para mim. Em nenhuma vez tive que usar os métodos addChild, createChildren ou commitProperties, e usava o evento creatiomComplete para tudo.

Meu primeiro componente customizado usava uma quantidade enorme de eventos assíncronos, e eu não poderia prever a ordem em que cada evento seria disparado. Só depois que eu aprendi os métodos e variáveis do ciclo de vida dos componentes do Flex que eu pude ter um certo controle.

Estes métodos do ciclo de vida estão lá para serem usados. Saiba como funcionam e use-os para o seu benefício. Sua vida será mais fácil e você perderá menos cabelos.

· Colin Moock’s Lost ActionScript Weekend – The Display List

· Creating New Components in Flex 3

· Diving Deep with the Flex Component Lifecycle

· Understanding the Flex 3 Component and Framework Lifecycle


[1] Expressão americana usada para algo que requer pouco esforço mental ou inteligência para realizar ou compreender

Mar 10

Novos cursos na Egenial

Escrito por Daniel Lopes em 1, 3d, 4, 6, Adobe, api, app, AR, arte, BI, browser, código, comunidade, Cotidiano, Curso, Cursos, Desenvolvimento, Design, Desktop, Dica, egenial, err, Excel, exemplo, Exemplos, Ferramenta, flash, Flex, Flex4, for, fundo, git, Gráfico, IE, Iniciando, int, jogo, Jogos, kit, Mercado, mg, mudanças, NaN, novidade, Novidades, O, object model, on, opensource, Palestra, platform, Projetos, rails, RIA, Ria’s Geral, ruby, Ruby e Rails, ruby on rails, site, Software, tag, Tecnologia, tool, toolkit, UI, variados, Ved, web @ 03 10th, 2011 | via http://blog.areacriacoes.com.br/ | Sem comentários
Daniel Lopes
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

Nossa empresa está passando por várias mudanças e nas próximas semanas teremos algumas novidades, mas ainda não é esta a razão deste post. Este post é sobre os próximos cursos na Egenial que começam na semana que vem.

No ano passado nossa parceria com a Egenial se estreitou um pouco mais já que a empresa está voltando suas atenções em massa para a comunidade de software Brasileira. Eu (Daniel) acabei sendo convidado para dar uma mão nessa empreitada.

Nos últimos dias tivemos o mega sucesso que foi o RubyMasters, com mais de 270 inscritos e com 12horas de palestra (que também teremos um post a parte). Agora a novidade é que na semana que vem teremos 3 cursos iniciando e as matrículas ainda estão abertas.

Ruby on Rails

Ruby on Rails do Básico ao Avançado comigo como instrutor. Essa é a minha 12 turma na Egenial e a minha 8 só em Ruby/Rails. Ao longo dos últimos anos fui refinando os exemplos deste curso e acho que chegamos no ponto perfeito. São 22 horas de aula onde passamos desde o básico de Ruby e vamos construindo uma aplicativo real em Rails. O aplicativo é tão próximo de um projeto real que eu mesmo uso como referência várias vezes no meu desenvolvimento diário em Rails 3.0.

Neste curso eu tento cobrir tudo que é fundamental para o cotidiano de um Railer. Veja a grade detalhada no site: http://www.egenial.com.br/cursorails

GIT

Git revolucionou o mercado de desenvolvimento opensource e comercial. Chega a ser impossível pensar como era o desenvolvimento com equipe remota ou em projetos opensource antes do GIT. É o tipo de ferramenta que é praticamente impossível contestar seu valor mesmo trabalhando sozinho e sem equipe nenhuma.

Uma das coisas que mais me motiva em continuar envolvido com a comunidade Rails é que é um local onde as coisas novas sempre acontecem muito rápido e isso foi bem marcante com GIT. Boas práticas surgem e se tornam leis na comunidade Rails e GIT é uma dessas leis.

Sem exceção, todos os projetos opensource são versionados com GIT e a grande maioria dos projetos privados também. Isso ocorre por uma única razão: GIT é fantástico.

Uma tecnologia com dezenas de benefícios como sua organização descentralizada incrível para trabalho em equipes, um modelo de armazenamento que reduz drasticamente o tamanho dos repositórios e sua simplicidade que o torna acessível para qualquer pessoa.

Por essas razão a Egenial tem tentado levantar um curso de GIT realmente prático e aprofundado tem bastante tempo. Finalmente conseguimos. Em Março, Arthur Zapparoli vai ministrar um curso de 16h ensinando desde o básico da ferramenta até os detalhes mais profundos como Cherry Pick, Rebase, Object Model, Bisect, Gitosis e muito mais.

Essa é a sua chance de dominar o GIT: http://www.egenial.com.br/git

FlashPlataform – Flex4

Outro curso que também começa na semana que vem é o FlashPlataform Flex4. Um curso totalmente reformulado para cobrir as novas ferramentas criadas pela Adobe e o mais legal que o instrutor será Fábio Vedovelli. Figurinha carimbada do mundo Flex e com uma excelente didática.

Ultimamente tenho participado muito pouco da comunidade Flex o que não indica que ainda não utilizo e utilizarei estas ferramentas se for necessário. É preciso ser pragmático e para muito objetivos Flash/Flex ainda são imbatíveis e são as melhores soluções do mercado.

Soluções como o próprio TreinaTom ainda são impossíveis de serem implementadas da forma correta sem essas tecnologias. Jogos, interatividade que envolve gráficos 2D/3D de forma compatível com todos os browsers, multimídia, compatibilidade com API de escrita e leitura de arquivos pelo browser, desenvolvimento desktop usando o mesmo código web e muitas outras vantagens que só a Plataforma Flash consegue atender hoje em dia.

Se você precisa dessas soluções então esse curso é o que faltava para complementar o seu toolkit.

Não perca tempo e conheça: http://www.egenial.com.br/flashplatformweb

Fev 13

Da Imaturidade à Agilidade

Escrito por Edgard Davidson em 1, 4, 6, Agile, Air, api, AR, arte, Artigo, bar, BI, busca, class, cliente, control, cultura, Curso, Cursos, Desenvolvedor, desenvolvedores, Desenvolvimento, Desenvolvimento de Software, Dica, Documentação, DRE, empresas, err, erro, Excel, exemplo, Ferramenta, Flex, for, gestão, Gráfico, ide, IE, if, image, int, lite, Livro, Mercado, Mestrado, mg, Motivação, O, on, Opinião, Outros, padrão, problema, problemas, processo, produto, Projetos, pt, RIA, Ria’s Geral, Scrum, serviço, Serviços, Software, Sugestões, TAT, Tecnologia, UI, Vários, Ved, vs, XP @ 02 13th, 2011 | via http://edgarddavidson.com | Sem comentários
Edgard Davidson
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

…Houve um tempo em que eu achava que métodos ágeis eram um excelente álibi para programador preguiçoso. E, ainda hoje, as vezes fico pensando sobre o significado do nome “ÁGIL”. Será que esse nome contempla, de fato o seu propósito, ou é um nome meramente “marketeiro”? Veja só:  No dicionário, o significado de “ágil” é ser rápido e flexível, por sua vez, no dicionário, o antônimo de ágil é lento e vagaroso.  Ora, ninguém quer ser taxado como lento e vagaroso!  Sendo assim, se eu não quero ser taxado de lento e vagaroso, então por eliminação eu sou ágil.

Esse clichê formado sobre a palavra ÁGIL distorceu um pouco as coisas. Muitas empresas e desenvolvedores que não conseguiam implantar processos de desenvolvimentos de software maduros, e que por muitas vezes cairam no mito da Fantástica Fábrica de Software,  começaram a se intitular como ágil. Nesse contexto continuo achando que métodos ágeis são um excelente álibi para programador preguiçoso.

A questão é que desenvolver software é uma tarefa que dependente de  tecnologia, processos, e, sobretudo, do conhecimento das pessoas.  Como já diria Fred Brooks em seu famoso artigo No Silver Bullet, não existe bala de prata, não existe ferramenta, metodologia ou qualquer outra mágica que resolva milagrosamente todos os problemas.

Segundo [Filho, 2008]:  “em uma organização imatura os mesmos problemas se repetem de projeto em projeto, o trabalho é excessivo e estressante e frequentemente há a necessidade de corridas desesperadas contra os prazos, a qualidade de vida no trabalho é ruim, o ambiente é desgastante e os profissionais são desmotivados. Os erros relativos ao processos de desenvolvimento de software são comuns em organizações  que utilizam processos imaturos, ocorrendo também naquelas que possuem processos rígidos, complexos e burocráticos e naquelas em que os processos apesar de existirem são seguidos parcialmente, ou em última instância, não são seguidos.”

Não obstante, o mercado tem exigido produtos de software ainda mais sofisticados e em prazos de desenvolvimento mais curtos. A referida exigência, tem instigado a pesquisa na área engenharia de software, objetivando encontrar meios para garantir que o software seja produzido atendendo às expectativas do cliente e aos atributos de qualidade definidos pela organização fornecedora de software e esperados pelo mercado.

Antes  de enfatizar a importância da agilidade do processo, é preciso entender o que ela realmente significa. Em suma, é a capacidade que uma organização possui para responder rapidamente às forças , fraquezas, oportunidades e ameaças do mercado. Há inúmeras situações práticas, onde agilidade do processo é altamente desejado, incluindo: apresentando um novo produto, entrar em um novo mercado,  responder à entrada de concorrentes, responder a alterações de requisitos em produtos em construção, etc.

Outro aspecto, é que o processo de desenvolvimento de software é complexo e precisa favorecer a criatividade e a inovação, e ter um nível adequado de flexibilidade para beneficiar a engenharia de processos na melhoria contínua. O grande desafio na proposta de um processo é conseguir um conjunto de regras que guiem o desenvolvimento sem comprometer a criatividade e a motivação dos desenvolvedores e sem travar a organização para a constante evolução da tecnologia e as adequações necessárias.

Uma abordagem adotada para romper a barreira da imaturidade é a definição de um processo de desenvolvimento de software padrão. O referido processo descreve as atividades que devem ser realizadas no desenvolvimento de software em todos os projetos da organização. A idéia é que isso favoreça que a organização atinja a conformidade com os padrões de qualidade esperados. Na literatura existem várias definições para processos de desenvolvimento de software:

  • “Uma sequência de passos executadas para um determinado propósito; por exemplo, o processo de desenvolvimento de software.” [IEEE, 1994]
  • “Um processo ´e um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos práticas e transformações usado para atingir uma meta.” [Filho, 2008]
  • “O processo de software ´e um conjunto de atividades que leva à produção de um produto de software.” [Sommerville, 2007]

De forma bem resumida, o processo de desenvolvimento de software formal descreve por meio da sua documentação: o que é feito , quando é feito, por quem é feito, como é feito, além dos insumos que usa e os produtos de saída. Em outras palavras, o processo enfatiza a padronização para possuir um parâmetro de medida e de controle e para poder circunscrever o erro em busca de qualidade. Contudo, embora seja necessário definir um processo de desenvolvimento de software, só isso não é suficiente para a construção satisfatória de um software. Existem vários fatores envolvidos que influenciam diretamente a construção do software, por exemplo: a capacitação das pessoas envolvidas, as tecnologias e ferramentas utilizadas, a cultura organizacional, entre outros.

Um processo de desenvolvimento de software não é definido do zero. Na literatura existem vários modelos que descrevem orientações para a definição e implantação de processos, dentre eles a ISO 12207/15504, CMMI e MPS-BR. Nesta linha, o processo de desenvolvimento de software deve estabelecer :

  • atividades a serem realizadas durante o processo, sua estrutura e organização (decomposição e precedência), incluindo a definição de um modelo de ciclo de vida quando pertinente;
  • artefatos requeridos e produzidos por cada uma das atividades do processo;
  • procedimentos (métodos, técnicas, roteiros e padrões) a serem adotados na realização das atividades;
  • recursos necessários (humanos, hardware e software) para a realização das atividades.

Em busca de eliminar a imaturidade, as organizações investem em definir e implantar um processo baseando-se em modelos de maturidade como CMMI e MPS-BR. Entretanto, esses modelos são densos, repletos de subprocessos que devem ser implementados em cada área de processo de cada nível de maturidade (no caso de CMMI) .

Um nível de maturidade é um patamar evolutivo bem definido que que “determina” a capacidade que uma organização possui em desenvolvimento de software. Cada nível visa alcançar um processo de desenvolvimento de software cada vez mais maduro.  Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de forma continua. Assim, os níveis de maturidade são cumulativos, ou seja, um nível de maturidade mais alto inclui os atributos dos níveis mais baixos. Uma vez que os modelos são projetados para descrever níveis discretos de melhoria de processo, níveis de capacidade provêem uma ordem recomendada para abordar a melhoria de  processo dentro de cada área de processo.

É  esperado que a cada nível alcançado pela organização, mais madura ela se torna em desenvolvimento de software. Um bom processo não garante que os produtos produzidos são de boa qualidade, mas é um indicativo de que a organização é capaz de produzir bons produtos.  Para que isso seja alcançado, um bom processo de desenvolvimento de software baseado em modelos de maturidade como CMMI e MPS-BR só podem ser considerados maduros se houver uma equipe de Quality Assurance atuante, autônoma e não condicionada. Essa equipe trabalha constantemente na garantia e no controle de qualidade do processo e do produto, respectivamente.

Quando uma organização atinge o nível 5 no CMMI ou A do MPS-BR, ela entra em um espiral de melhoria continua.  A equipe de projeto e  a equipe de qualidade reportam para a equipe de definição de processo gargalos e deficiências do processo atual, e complementam com sugestões para melhoria de processo. A equipe de definição de processo por sua vez avalia todas as sugestão, e, se pertinentes, implantam a melhoria no processo. Isso se torna um ciclo de inspeção e adaptação do processo.  Quanto mais madura a equipe, menos atividades de inspeção técnica e verificação são necessárias para garantir a conformidade com o processo e mais esforços podem ser realocado para garantir a conformidade do produto. Veja o post sobre Conformidade com o Produto vs. Conformidade com o Processo.

No gráfico acima tentei ilustrar o que percebo sobre a agilidade de processos. Quando se fala em agilidade em processo, já estamos condicionados a pensar em métodos ágeis de desenvolvimento de software como Scrum, eXtreme Programming , princípios Lean etc. No entanto, agilidade, na essência,  se aplica em um ambiente de desenvolvimento formal também.  No início, quando a organização não possui nenhum processo definido o ambiente não é estável, e, frequentemente, ela depende da competência e heroísmo das pessoas para atingir seus objetivos. Neste ambiente, a rigidez de processo é baixa, informal e caótico, mas apesar disso as organizações muitas vezes produzem produtos e serviços que funcionam. Entretanto, elas freqüentemente estão expostas a vários problemas de projeto como: exceder o orçamento e o cronograma planejado, baixa qualidade, não cumprir compromissos, abandonar processos em momentos de crises e não ser capazes de repetir sucessos do passado.

Para não ficar tão expostas aos problemas de projeto citados, as organizações partem para implantação de processos, e, a medida que esses processos são implantados e os níveis de maturidade de processo são obtidos, mais “rígido”, mais “burocrático”  o processo se torna.  No entanto, entendo que a tão criticada rigidez e burocracia de processos formais é uma fase transitória, de aprendizado, de padronização e, sobretudo de amadurecimento.  Nos níveis mais altos de maturidade o objetivo é a simplificação, a “des-burocratização” de processo. Lendo isto alguém poderia estar perguntando: “Ora! Então porque a organização não vai direto para esse estado?”  Bom, imagino que isso se torna necessário na caminhada da Imaturidade à Agilidade.

Dez 28

Resumo de 2010 + O que esperamos para 2011

Escrito por Daniel Schmitz em .NET, 1, 4, 6, Adobe, Adobe Air, Air, AR, Arquitetura, BI, blog, Blogs, comunidade, Curso, Cursos, demo, Desenvolvimento, Desktop, Enquete, flash, flash builder, Flex, Flex 4, for, framework, Geral, git, Gráfico, gratuito, guias, ide, IE, if, int, Java, lista, Livro, Livros, mobile, NaN, Notícias, O, on, Orientação, Orientação a Objetos, Outros, PHP, problema, rails, RIA, Ria’s Geral, servidor, Tecnologia, Tema, UI, web @ 12 28th, 2010 | via http://flex.etc.br | Sem comentários
Daniel Schmitz
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

O ano de 2010 fez história para a comunidade Flex em Geral. Para quem acompanha o Flex desde 2006, sabe perfeitamente que este ano foi o melhor de todos, com o Flex cada vez mais acessível para os programadores e analistas. Se antes a falta de conteúdo sobre Flex era um motivo para não adotá-lo, hoje isso não é mais problema. Somente neste ano, foram mais de 6 livros em português e mais de 10 cursos distintos, sem falar nos inúmeros blogs e conteúdo gratuito criado pela comunidade. Isso somente tende a reforçar o Flex para 2011.

Analisando o Framework Flex, neste ano tivemos a concretização do Flex 4, com uma nova arquitetura e com o seu crescente crescimento. Já estamos aguardando a versão 4.5 tornar-se oficial, além do Flash Builder Burrito com suas ótimas melhorias na IDE,  e com o tão esperado desenvolvimento mobile. Tudo isso deverá ser apresentado no início de 2011.

Com a ascensão dos dispositivos mobile, esperamos para 2011 e 2012 uma nova era, onde as aplicações web também terão uma “versão mobile”. Se há 5 anos atrás as aplicações WEB ganharam força em relação ao Desktop, agora veremos uma nova tendência, das aplicações Mobile ganharem força em relação a Web.  E felizmente o Flex está preparado para isso !

Com isso já podemos prever alguns novos livros para 2011. O principal deles será “Dominando Flex Mobile”, que será concluído nas primeiras semanas após o lançamento da versão oficial do Flash Builder Burrito. Além deste, também estamos criando o “Dominando Adobe Air”, muito pedido pela comunidade. Outro livro que está ganhando forma (devido a enquete no loja.flex.etc.br) é Dominando Orientação a Objetos, um livro que irá abordar a OO de um jeito prático e eficiente, reforçando assim os seus conceitos OO.

Além destes dois livros que serão impressos, iniciaremos em 2011 uma série de mini-livros digitais, que terão uma visão mais prática do desenvolvimento de sistemas com Flex. Estes livros serão chamados, a princípio, de “Guia Prático Flex+X”, onde X seria uma tecnologia de servidor. Muitos leitores, durante as diversas conversas neste ano, pediram tecnologias diversas como Rails, .Net, Python, e estes livros serão criados para este fim. A ideia é focar no desenvolvimento prático da criação de um sistema por completo, envolvendo login, telas de cadastro e consulta, gráficos etc. Muitos foram os leitores que me pediram uma ideia de estrutura de diretórios para o desenvolvimento de suas aplicações e, nos guias práticos, isso será abordado com bastante clareza. Uma particularidade que pude notar nos meus livros é que eles abordam a prática, enquanto muitos outros abordam apenas a teoria. Eu acredito fielmente que este é um dos maiores diferenciais em termos de qualidade dos livros de tecnologia atuais. Quem seguir este caminho estará criando uma obra de qualidade.

Resumindo, se 2010 foi bom, aguardem por 2011! Estejam preparados conhecendo bem o Flex, se possível um framework como o SWIZ, e uma linguagem de servidor como o PHP ou Java. Não deixe para aprender o Flex em 2011. Deixe para se especializar em 2011.

Aproveite as férias para estudar um pouco, fazer um pequeno projeto, realizar um curso e/ou ler um livro!

E um ótimo 2011 para todos nós !

Dez 28

Resumo de 2010 + O que esperamos para 2011

Escrito por Daniel Schmitz em .NET, 1, 4, 6, Adobe, Adobe Air, Air, AR, Arquitetura, BI, blog, Blogs, comunidade, Curso, Cursos, demo, Desenvolvimento, Desktop, Enquete, flash, flash builder, Flex, Flex 4, for, framework, Geral, git, Gráfico, gratuito, guias, ide, IE, if, int, Java, lista, Livro, Livros, mobile, NaN, Notícias, O, on, Orientação, Orientação a Objetos, Outros, PHP, problema, rails, RIA, Ria’s Geral, servidor, Tecnologia, Tema, UI, web @ 12 28th, 2010 | via http://flex.etc.br | Sem comentários
Daniel Schmitz
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

O ano de 2010 fez história para a comunidade Flex em Geral. Para quem acompanha o Flex desde 2006, sabe perfeitamente que este ano foi o melhor de todos, com o Flex cada vez mais acessível para os programadores e analistas. Se antes a falta de conteúdo sobre Flex era um motivo para não adotá-lo, hoje isso não é mais problema. Somente neste ano, foram mais de 6 livros em português e mais de 10 cursos distintos, sem falar nos inúmeros blogs e conteúdo gratuito criado pela comunidade. Isso somente tende a reforçar o Flex para 2011.

Analisando o Framework Flex, neste ano tivemos a concretização do Flex 4, com uma nova arquitetura e com o seu crescente crescimento. Já estamos aguardando a versão 4.5 tornar-se oficial, além do Flash Builder Burrito com suas ótimas melhorias na IDE,  e com o tão esperado desenvolvimento mobile. Tudo isso deverá ser apresentado no início de 2011.

Com a ascensão dos dispositivos mobile, esperamos para 2011 e 2012 uma nova era, onde as aplicações web também terão uma “versão mobile”. Se há 5 anos atrás as aplicações WEB ganharam força em relação ao Desktop, agora veremos uma nova tendência, das aplicações Mobile ganharem força em relação a Web.  E felizmente o Flex está preparado para isso !

Com isso já podemos prever alguns novos livros para 2011. O principal deles será “Dominando Flex Mobile”, que será concluído nas primeiras semanas após o lançamento da versão oficial do Flash Builder Burrito. Além deste, também estamos criando o “Dominando Adobe Air”, muito pedido pela comunidade. Outro livro que está ganhando forma (devido a enquete no loja.flex.etc.br) é Dominando Orientação a Objetos, um livro que irá abordar a OO de um jeito prático e eficiente, reforçando assim os seus conceitos OO.

Além destes dois livros que serão impressos, iniciaremos em 2011 uma série de mini-livros digitais, que terão uma visão mais prática do desenvolvimento de sistemas com Flex. Estes livros serão chamados, a princípio, de “Guia Prático Flex+X”, onde X seria uma tecnologia de servidor. Muitos leitores, durante as diversas conversas neste ano, pediram tecnologias diversas como Rails, .Net, Python, e estes livros serão criados para este fim. A ideia é focar no desenvolvimento prático da criação de um sistema por completo, envolvendo login, telas de cadastro e consulta, gráficos etc. Muitos foram os leitores que me pediram uma ideia de estrutura de diretórios para o desenvolvimento de suas aplicações e, nos guias práticos, isso será abordado com bastante clareza. Uma particularidade que pude notar nos meus livros é que eles abordam a prática, enquanto muitos outros abordam apenas a teoria. Eu acredito fielmente que este é um dos maiores diferenciais em termos de qualidade dos livros de tecnologia atuais. Quem seguir este caminho estará criando uma obra de qualidade.

Resumindo, se 2010 foi bom, aguardem por 2011! Estejam preparados conhecendo bem o Flex, se possível um framework como o SWIZ, e uma linguagem de servidor como o PHP ou Java. Não deixe para aprender o Flex em 2011. Deixe para se especializar em 2011.

Aproveite as férias para estudar um pouco, fazer um pequeno projeto, realizar um curso e/ou ler um livro!

E um ótimo 2011 para todos nós !

Nov 30

Ícones da Barra de Status

Escrito por DClick Team em 1, 4, 6, Adobe, Android, Aplicativos, AR, arte, bar, blog, class, dados, efeito, efeitos, err, exemplo, Exemplos, Ferramenta, for, fundo, Gráfico, ide, IE, if, image, imagens, menu, mg, O, on, photoshop, procura, pt, RIA, Ria’s Geral, Segurança, TAT, Tema, Tutoriais, Twitter, UI, XP @ 11 30th, 2010 | via http://blog.dclick.com.br/pt/ | Sem comentários
DClick Team
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

Os ícones da barra de status servem para representar as notificações que acontecem no sistema operacional ou de seus aplicativos.

Graficamente eles são semelhantes aos ícones do menu, mas são menores e possuiem maior contraste, portanto não se deixe enganar e siga a Guideline.

Não esqueça das dimensões que são sempre pequenas, médias e grandes, tal como descrito nos primeiros posts, e que tem suas resoluções descritas na tabela 1.

.

Estrutura

.

  • Os cantos arredondados não devem ser muito extensos, devem respeitar uma margem máxima de 2px, para entender verifique a Figura 9 (o número das figuras não é de acordo os nossos posts e sim de acordo com a Guideline oficial) e perceba no canto direito superior esse detalhe e de como fazer o canto arredondado corretamente.
  • Todas as dimensões possuem 25 x 25px, e com um área de segurança (safeframe) de 2px, tal como na Figura 9.
  • Detalhe importante, os ícones da barra status podem vazar essa área de segurança na direita e na esquerda caso necessário, mas jamais poderá vazar nos cantos superior e inferior.
  • Como você já deve saber, a arte deve ser exportada com um PNG transparente, para isso eu sugiro o Fireworks como ferramenta para desenvolver esses ícones, ele é fácil de mexer para criar ícones com esses padrões.
  • Porém, o pacote enviado pela Android é em PSD, e você poderá editar e fazer seus ícones através do Photoshop.

.

Luzes, Efeitos e Sombras

.

Observe que os ícones da barra de status são ligeiramente menores, por isso eles possuem um alto contraste, para facilitar a sua visualização, dando um aspecto mais clean e objetivo das suas formas. Eu não sei se você usa um Photoshop ou outro programa gráfico em português, eu espero que não, vide que a maioria dos tutoriais não dão suporte a esses programas, ainda mais que as traduções ficam péssimas, mas, vou procurar deixar alguns detalhes em inglês e fazer comentários, o motivo é um só, imagine Depth, traduzido como profundidade, a gente sabe bem o que é um Depth em um gráfico, mas profundidade pode ter outro sentido, então tome cuidado com isso, as imagens ajudam a você entender o que é cada coisa.

.

Passo a Passo

.
1.  Em uma ferramenta como o Adobe Photoshop, crie uma forma base em uma imagem de 25?25 px com fundo transparente. Cuidado com o safeframe, e mantenha o superior e inferior de 2 pixels livre, recorde-se do que foi citado acima
2. Adicione cantos arredondados, conforme especificado na Figura 9.
3. Adicione luz, efeitos e sombras, conforme especificado na Figura 10.
4. Exportar o ícone com tamanho 25?25 como um arquivo PNG com fundo transparente.
.

“O que fazer e o que não se deve fazer”

.

Abaixo segue alguns exemplos do que se deve e não se deve fazer, ou seja, seguir os padrões é importante.

Nov 29

Android UI Guidelines

Escrito por DClick Team em 1, 4, 6, Android, app, AR, Artigo, Atalhos, bar, BI, blog, bug, class, Componente, Componentes, Curso, Cursos, dados, Desenvolvedor, desenvolvedores, Design, designer, Dica, Dicas, Dicas e Truques, Documentação, Download, fonte, fonts, for, Geral, git, Gráfico, icones, ide, if, image, int, interface, internet, lista, Mate, menu, mg, O, on, Otimização, padrão, photoshop, problema, problemas, pt, RIA, Ria’s Geral, skins, Software, Sun, TAT, Tecnologia, Tema, template, Twitter, UI, UX, Ved, Widget, XML, XP @ 11 29th, 2010 | via http://blog.dclick.com.br/pt/ | Sem comentários
DClick Team
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

Este artigo visa explicar a User Interface do Android, voltado principalmente para o design, portanto vamos abordar aqui a documentação do Android que trata desse assunto.

Em pesquisa intensa pela internet percebi que poucos abordam as especificações do Android para fazer a aplicação de uma skin, a discussão está mais voltada a desenvolvedores, otimização, xml etc, quase nada trata de fontes, ou padrões visuais. Então muitos designers se perguntam como fazer uma skin para uma app Android, já que não é somente abrir o Photoshop ou outro software gráfico e começar a desenhar.

Eu vou tratar aqui exatamente desse tema, não só deixando a mão as fontes (TTF) para você, mas como toda pesquisa que for feita sobre o assunto, haverá PSDs para baixar, ícones e muito mais, material para você começar a produzir sem qualquer complicação. Portanto deixe esse link nos seus favoritos pois ele será atualizado semana a semana, conforme eu for criando novos posts eu vou inserir o link dos temas nesse artigo, assim ele será um guia para você encontrar o que deseja.

Estarei postando aqui a UI Guidelines e comentando-a onde for pertinente, e alguns desenvolvedores poderão fazer uso já que estará tudo mastigado e com isso quem quiser se aventurar em criar algumas skins para suas apps não terão tantos problemas, mesmo assim aconselho, contrate um bom designer, pois ele saberá discutir não só como fazer uma skin, mas como criar um visual atraente e funcional, discutindo inclusive seu wireframe.

Vamos começar entendendo o que é a UI Guidelines, ela é separada na plataforma Android por:

.

Icon Design (design dos ícones)
.

  • Ícones
  • Ícone Menu
  • Ícone da barra de status
  • Ícone Guia
  • Ícone de diálogo
  • Ícone de exibição de lista
  • Dicas para Designers
  • Usando os templates do pacote de ícones
  • Índice de ícones
  • Ícones padrões iniciais
  • Ícones padrões do menu
  • Ícones padrões da barra de status

.

App Widget Design (componentes da interface da app)

.

  • Padrão anatômica de um widget
  • Projetando um widget
  • Padrão de tamanho de um Widget
  • Padrão de frames de um Widget
  • Padrão de sombras de um Widget
  • Widget – dicas e truques gráficos
  • Widget – formato de arquivo gráfico

.

Activity and Task Design (atividades e tarefas, ou seja, os comportamentos)

.

  • Entendendo de forma geral as tarefas
  • Dicas de design

.

Menu Design (todo o comportamento do menu)

.

  • Opções do Menu
  • Contexto do Menu e atalhos

.

Talvez você se pergunte porque é necessário saber isso e não apenas pegar um PSD Guideline e começar a criar. A resposta é bem simples, se você quer criar um app que realmente as pessoas vão usar você deve respeitar e entender esses padrões, saber dos recursos que são suportados por essa plataforma e suas limitações.

Afinal por ser um sistema aberto, qualquer um pode subir uma aplicação na AndroidMarket, por mais bugada que seja, porém o que vai definir o sucesso da sua app será os cuidados que tiver em respeitar a Guideline, o seu conceito, e o seu design.

FONTES

Droid Serif

Droid-Sans

Droid-Sans-Mono

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.

@eduardohorvath

Nov 12

MOLE HILL – FLASH

Escrito por DClick Team em 1, 3d, 4, 6, Access, Adobe, Adobe Flex, Adobe Max, Android, api, Aplicativos, app, apple, AR, arte, Artigo, audio, Beta, BI, blog, Carreira, class, código, comunidade, conversor, Curso, Cursos, demo, Desenvolvedor, desenvolvedores, Desenvolvimento, Design, designer, Diversos, Download, engine, err, erro, Experience Design, Experiências, flash, flash media, Flash Media Server, Flash Player, Flex, for, Formação, framework, Frameworks, free, FullScreen, futuro, game, git, Gráfico, html, html5, ide, IE, if, image, int, Introdução, iphone, jogo, kit, labs, loop, Mac, Mercado, mg, mobile, NaN, novidade, Novidades, O, on, online, oop, Opinião, Outros, PHP, platform, player, procura, pt, RIA, Ria’s Geral, runtime, screen, SDK, server, site, Sun, swf, tag, TAT, team, Tech, Tecnologia, Tema, Teste, tv, Twitter, UI, UX, Ved, Vídeo, Vídeos, vs, wave, web, XML, XP, zend @ 11 12th, 2010 | via http://blog.dclick.com.br/pt/ | Sem comentários
DClick Team
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

Twitter!


.

Essa notícia é bem interessante, e no sentido real da palavra, de que nos interessa e muito, o Rafael Martinelli trouxe diretamente da MAX essa informação. Fiquei bastante impressionado com o MoleHill, motivo que me fez escrever esse post dando uma introdução sobre o assunto.

Estarei acompanhando com muito interesse o que estiver acontecendo nesse segmento e sempre que possível vou procurar trazer novidades sobre essa engine.

Mas afinal, o que é MoleHill?

“Molehill” é o nome de código para um novo conjunto de baixo nível, com APIs de aceleração GPU  3D  que permitirá avançadas experiências em 3D nas telas através do Adobe ® Flash ® Platform runtimes.

Existem diversas comunidades, frameworks para desenvolvedores poderem ampliar seus horizontes na criação de aplicações 3D, como Alternativa3D, Away3D, Flare3D, Sophie3D ou Yogurt3D.

Durante a AdobeMAX um vídeo muito interessante foi apresentado para os participantes, ele mostra um jogo em 3D com gráficos mais apurados, algo que não deixa nada a desejar a consoles físicos para games, e que, talvez não fosse nada fantástico o vídeo abaixo se o game não estivesse rodando em um FlashPlayer.

Impressionante ver o que a Adobe fez, e contrariando muitos que dizem que o flashplayer requer processamento da máquina, a Adobe fez um game com uma estrutura potente e que requer ZERO, isso mesmo, ZERO de processamento da CPU, utilizando somente a placa aceleradora.

Confira o vídeo antes de continuar o artigo.

.

De acordo com o anúncio feito pela Adobe, no primeiro semestre de 2011, (quando em versão pública beta) a versão do Flash Player irá suportar essas novas APIs, bem como também acontecerá uma atualização do Adobe Flex SDK. Para obter mais informações leia atentamente o Molehill faq:

http://labs.adobe.com/technologies/flash/molehill/#faq

Para a maior parte das suas dúvidas você com certeza encontrará as respostas aí nesse link, portanto vou me fixar a falar das possibilidades de algo assim.

Não será novidade pensar que milhares de desenvolvedores começarão a criar seus games, mas não é só de game que vive o homem, apesar de ser muito bom é claro. Essa engine nos dará possibilidades de experimentar de fato uma nova era da web em 3D. Lembramos que o shockwave não deu certo, não emplacou, mas pelo visto a Adobe aprendeu com o erro e fez uma engine de qualidade, a cada dia mais e mais computadores saem de fábrica com placa aceleradora 3D, ao ponto que isso está se tornando comum, se essa engine é a primeira fase, podemos esperar muito pelo que esta por vir.

Pense nas aplicações 3Ds que poderão ser desenvolvidas, pensem em um showroom virtual, hotsites etc, tudo aquilo que era feito antigamente com as piores gambiarras possíveis, hoje poderá ser realizado com qualidade.

Sou suspeito para tecer elogios a Adobe visto que sou um entusiasta, fiz minha carreira em cima de todos os seus sofwares, e claro, da Macromedia, que hoje é Adobe… portanto fico feliz em saber que ela nunca abandonou o Flash, e mais que isso, se empenhou em criar inclusive um conversor de SWF para HTML5, fazendo com que os desenvolvedores Flash (vulgo flasheiros) não percam seu mercado, afinal, se Flash fará HTML5, certo é dizer que HTML5 nunca fará um SWF e nem chegará perto da qualidade, visto que essa tecnologia com todo respeito ainda está engatinhando.

Mas o assunto é MoleHill, vamos  continuar falando de quem vai se dar bem nessa história toda na minha opinião.

.

.

Evidente, ela já se deu bem, e depois e todo o alvoroço e discussão sobre o Flash rodar ou não no Iphone fica aí um susto que a Adobe está dando a Apple, ou não, pois talvez a mesma já previa tal situação e portanto procurou evitar os games em Flash para poder alavancar a AppStore, sem entrar muito no tema, nem são os games 3Ds os mais vendidos na mesma (portanto nem sei porque da preocupação do Steve, talvez parcerias , enfim) mas…  certamente essa é uma tecnologia fantástica que faz a Adobe novamente ficar a frente dos demais, como sempre esteve. Afinal, uma plataforma para desenvolvimento de games mais sérios, com suporte a joysticks, volantes etc, (nada pronunciado a respeito mas isso vemos nos vídeos, o volante do XBox sendo utilizado), combinado com um Flash Media Server, um ambiente de multiusuário, online,  pode ser realmente devastador (no bom sentido) para o mercado como um todo.

Então não poderíamos deixar de falar quem é que mais ganha com isso.

.

Android

.

O Android tem sido um parceiro do Flash simplesmente porque a Apple não quis ser no seu iOS, e a Adobe já se pronunciou a respeito dizendo que haverá acesso as APis 3D também para as plataformas móveis…  fantástico, não só para games, mas como falei, para outros recursos de aplicativos.

A web sempre procurou introduzir o 3D, é uma tendência natural, também sou suspeito para falar do assunto pois sempre apostei no 3D e sou um 3Ddesigner também e obviamente amo o assunto e sempre acreditei que a experiência 3D é muito poderosa, pois ela trata quase todas as sensações visuais que o cérebro pode comportar, dando é claro maior realismo ainda que não haja muitos detalhes gráficos.

Posso dizer que consigo passar horas desenvolvendo algo em 3D sem me cansar, pois me sinto imerso no ambiente, mas não é a mesma coisa para desenvolver algo em 2D.

Enfim, o Android de fato vai se dar bem nessa história, vai abocanhar todo um mercado de 3D para mobile, com milhares de desenvolvedores famintos para migrar diversas aplicações e games prontos para essa engine, para rodar em Flash.

.

Portanto quem também ganha com isso?

Os diversos frameworks que já citei.

.

Dentre eles eu aposto mais no AlternativaPlatform, me pareceu mais robusto, mais acabado inclusive, a maioria dos vídeos que trago aqui são desse framework, no mais, outras como Frare3D e Away3D também me parecem boas, mas como ainda não botei a mão em nenhuma delas fica suspeito comentar, em um futuro próximo farei alguns testes (como designer) e darei a minha visão. Mesmo assim, tanto designer como desenvolvedor terá uma gama de possibilidades bastando ver as suas necessidades, e ter várias opções nesse caso é muito bom.

Vou dar um foco maior a AlternativaPlatform, portanto veja o anúncio feito no blog da própria empresa sobre a Adobe Max.

http://blog.alternativaplatform.com/en/2010/10/16/alternativa-3d-is-free-see-you-at-adobe-max

Confira a qualidade do site:
http://alternativaplatform.com/en/

Uma breve introdução visual:

.

Vamos agora a imersão, vamos aos vídeos:

.

Confira outro vídeo, agora de uma visão externa mostrando o “jogador” do MaxRacer :

.

.

Outro vídeo da Alternativa3D:

.

.

Agora da Frima Studio (http://www.frimastudio.com/), que utilizou a engine usada para PSP do jogo Zombie Tycoon (http://www.zombietycoon.com/EN/index.htm) migrando para Molehill (sim fantático, não o jogo mas a possibilidade) :

.

.

Away3D :

.

.

Vamos a uns vídeos mais instrutivos:

O primeiro é a sessão de Sebastian (engenheiro-chefe na Molehill):

.

.

O segundo vídeo é da equipe Flare3D, apresentando o Molehill e suas vantagens:

.

.

Away3D e Alternativa3D teams (equipes), ainda sobre seus respectivos frameworks e vantagens:

.

.

E então a Pixel Bender 3D:

.

.

Bom galera, espero que esse post tenha sido uma boa introdução para conhecer o assunto, fiz uma pesquisa vasta para trazer as melhores informações sobre o tema e espero que tenham gostado.
Assim que tiver novas informações interessantes estarei postando, até lá se você também tiver algo a acrescentar não deixe de comentar aqui nesse post.

E que venha o mundo 3D na web.

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.

@eduardohorvath


Nov 5

IPHONE E IPAD DESIGN

Escrito por DClick Team em 1, 3d, 3g, 4, 6, Adobe, Android, Aplicativos, app, apple, AR, Artigo, auto, bar, BI, blog, botão, Botões, class, Curso, demo, Desenvolvedor, Design, designer, developer, Dica, Documentação, Download, DRE, efeito, efeitos, encontro, err, event, Evento, exemplo, Exemplos, Experiências, explicação, for, Formação, futuro, Geral, git, Google, Gráfico, html, ide, IE, if, image, imagens, int, interface, iphone, iTunes, library, lite, Mate, mg, mobile, NaN, O, on, Outros, padrão, Partilha, photoshop, problema, processo, prova, pt, RIA, Ria’s Geral, screen, Screencast, SDK, Sem categoria, site, skins, Software, Sun, tag, TAT, Tecnologia, Tema, Twitter, UI, uint, UX, Ved, XP @ 11 5th, 2010 | via http://blog.dclick.com.br/pt/ | Sem comentários
DClick Team
? X
  • Bookmarks

Blinkbits BlinkLists BlogLines Blogmarks Buddymarks CiteULike Co.mments Del.icio.us Digg Diigo

Fark Feed Me Links Furl Google Linkagogo ma.gnolia Mister Wong Newsvine Propeller Rawsugar

Reddit Rojo Simpy Sphinn Spurl Squidoo StumbleUpon Tailrank Technorati Yahoo

More »

Twitter!

Tudo o que você sempre quis saber para começar a criar sua skin.

Esse post é para você designer, que atualmente está sonhando em criar uma skin para app de Iphone ou Ipad e simplesmente não sabe como fazê-lo, ou porque não sabe inglês, ou porque não encontrou material a respeito.

Lá fora (na gringa) há muito material a respeito, mas infelizmente nem todos são objetivos e respondem as perguntas mais básicas.

Vamos supor que você já sabe alguma coisa sobre Iphone, afinal deve possuir um, sabe como desenhar uma skin, afinal entende de Fireworks, Photoshop, Ilustrator ou outro software gráfico (sem ser Adobe não recomendo…).

Então você chegou nas seguintes dúvidas:

Qual o tamanho da tela? Iphone 3G ou 4G tela de retina? Qual o procedimento certo para criar o design, já para Iphone 4 ou para 3? Entre outras muito comuns.
Em pesquisa para criar interfaces para esses gadgets aqui na DClick me deparei com essas questões, e como já as solucionei estou aqui para contribuir com esse material muito valioso.
Esse é o primeiro de muitos posts do mesmo tema. Em breve estarei ensinando também aos novatos na área de Design de Interface como criar uma bela skin para esses portáteis, e vou indicar material sobre o assunto.

Bem, chega de blá blá blá e vamos ao post.

Tamanho padronizado da tela e dos ícones

.

É possível que você já tenha lido a documentação da Apple sobre Iphone e Ipad Guidelines, são os padrões para a criação das skins. Caso não tenho lido aconselho a faze-lo, é o primeiro passo para entender como funciona esse mundo, no entanto, o conteúdo está em inglês,  se tiver dificuldades peça ajuda ao concorrente da Apple e utilize nosso amigo Google Translator, não será a melhor tradução do mundo mas com esforço você chega lá.

Iphone Guidelines

Ipad Guidelines

É possível ler este artigo sem ter o conhecimento acima?  Sim é, mas será melhor com a leitura dos padrões da Apple.

Quando comprei meu Iphone 4 no dia do seu lançamento (não peguei fila acredite) eu fiquei surpreso com a resolução da sua tela, mas logo veio algo a mente… como isso afetaria os aplicativos,  e não demorou até eu ver aplicativos com a resolução perfeita, e aplicativos com os famosos pixelados, sim, com um visual podre, literalmente falando. São os aplicativos que foram criados para a resolução 320 x 480px, todos os modelos anteriores a quarta geração de Iphone.  Claro que não eram totalmente ruins, porém muito da qualidade se perdia, e logo não demorou para  que a maioria deles fossem atualizados para a nova resolução de 640 x 960px.

Essa é a vantagem de quem desenvolveu em vetor, bastaram redimensionar suas skins para o novo tamanho e aplicá-las na app e então enviar o pedido de atualização ao usuário.

Quando você exporta os arquivos para Iphone ou Ipad geralmente é PNG. O Xcode (leia tópico a respeito), não considera o valor PPI (não confunda com DPI) quando você salva a imagem, portanto, para matar a charada siga as configurações abaixo:

Agora, um comentário importante sobre isso,  qual software utilizar? Eu particularmente gosto do Fireworks para a criação de Interfaces, esse software é fantástico e prático, mas se realmente quer ter facilidade com skins para Iphone e Ipad volte ao Photoshop, caso não seja usuário do mesmo, crie suas skins bases no Fireworks e salve com PSD, e depois aplique os efeitos e detalhes no Photoshop, ele é realmente uma máquina de guerra para esse assunto.
Nos futuros posts estarei falando melhor disso.

Supondo portanto que estamos falando do Photoshop, vejamos então algumas padronizações de configurações:

.

iPhone 3.0
Resolução da tela: 72 ppi
Tamanho da tela: 320 x 480 px
Icone tamanho: 57 x 57 px
Formato do arquivo: PNG-24
iPhone 4.0
Resolução da tela: 72 ppi
Canvas size: 640 x 960 px
Icone tamanho: 114 x 114 px
Formato do arquivo: PNG-24
IPAD
Resolução da tela: 72 ppi
Canvas size: 768 x 1024 px
Icone tamanho: 72 x 72 px
Formato do arquivo: PNG-24

.

E quanto ao Itunes Store segue:
Ícone: 512 x 512 px (tif, jpg ou png, 72 dpi, RGB…)
Imagens iPhone: 320 x 480 px ou 640 x 860 px (tif, jpg ou png, 72 dpi, RGB…)
Imagens IPAD: 1024 x 768 px (tif, jpg ou png, 72 dpi, RGB…)

Agora a grande questão, criar uma Interface pensando na resolução do 3G (terceira geração) ou 4G (quarta geração)?

Apesar da sua resposta parecer óbvia, e ela até é, você certamente disse a si mesmo “criar skin para a quarta geração, evidente… não precisa ser guru para saber isso.” Ela não é a resposta correta acredite.

Antes de mais nada a pergunta, você já possui um Iphone4? Se sua resposta é não, relaxe, mas será necessário você entender através desse link as nossas preocupações:

Comparações entre tela 3G e 4G (Retina)

Como pode ver, as resoluções são drasticamente diferentes, o Iphone 4 tem uma resolução superior ao olho humano (segundo a própria Apple) e de fato é uma resolução impecável, a tela de retina .Utilize o mouse e percorra a rosa mostrada no Iphone nesse link que te apresentei…

Assim você vai pensar, “Então como não fazer para a melhor resolução?”

Simples, muito simples, porque quando você cria interfaces com resoluções maiores você tende a ser mais detalhista, e interfaces detalhadas quando forem redimensionadas a tamanhos menores vão dar problema, não será uma boa interface, não ficará com um belo padrão de visualização. Os pixels podem se confundir, criando até mesmo embaçamentos.

Portanto a melhor técnica é criar, obviamente tudo em vetor, na resolução de 320 x 480px, ver se está tudo harmonico, e então só depois redimensionar para o dobro, 640 x 960px. Confie, ficará muito melhor que desenhar diretamente para 640 x 960px, já tive algumas experiências ruins criando diretamente nessa resolução. Deixe para aplicar texturas caso queira faze-lo na resolução de 640, já as bases tem que ser vetorial.

E claro, agora sim não precisa ser guru para saber que se fizer em 320 x 480px sem ser vetor e redimensionar (que é o acontece com as aplicações sem suas interfaces atualizadas) ficará pixelado e granulado, tal com vemos nos exemplos abaixo.
.

.

Padrão de imagem na exportação

.

Como bom brasileiro sei que para tudo há um jeitinho, mas no caso de interfaces para iOS o jeitinho pode ser uma não aprovação na Apple Store, ou mesmo uma interface ruim.

Portanto não custa nada enfatizar, o padrão que você deve usar na exportação das imagens dos seus elementos é o PNG, na teoria o iOS pode exibir outros formatos, mas… na prática não ficará bom, o motivo é que o PNG é otimizado automaticamente no pelo SDK do iOS. Assim sendo, como estamos nosso software gráfico utilizado é o Photoshop vamos exportar em PNG 24 e com transparência.

.

Padrão de botões

.

Você já se deparou com aplicações cujos botões eram pequenos demais? Aquelas aplicações que para poder inserir um determinado evento o designer implementou um botão pequenininho que coubesse na interface a fim de executar a função desejada mas… que por vezes não era sensível ao toque?

Pois bem, seja bem vindo ao maravilhoso mundo daqueles que acreditam que pesquisa não serve para nada, a Apple padronizou os botões em 44 x 44px, apesar do rigor que a mesma tem na aprovação dos aplicativos muitos dos mesmos passam com botões inferiores a isso, e espero que você não seja um destes, afinal, você estará estragando toda a UX (leia artigo) da sua aplicação caso se meta a achar que um botão menor é melhor para o seu usuário, sendo que a Apple fez inúmeras pesquisas para definir o melhor tamanho, sendo esse, 44 x 44px o tamanho MÍNIMO recomendado.

.

O Mistério, como preparar os arquivos para o seu desenvolvedor

.

Sim, sua obrigação, e talvez a leitura desse texto inteiro seja por conta dessa preciosa informação, afinal você pensa “Fazer interface eu sei, design eu sei, conceito eu sei, mas como afinal eu devo exportar tudo isso para o desenvolvedor?”.

Eis a fórmula mágica, volte a ler os Padrões de imagem para a exportação. Sim isso mesmo, você apenas tem que fatiar os arquivos e enviá-los de forma organizada ao seu desenvolvedor, ele tratará de incluir isso através do XCode, caso você tenha interesse em agilizar esse processo e trabalhar em parceria com seu desenvolvedor de forma mais dinâmica, então terá que estudar o XCode, um bom primeiro passo para isso é o post que indiquei no começo do artigo do nosso colaborador Artur Fabri (@arturfabri), que explica como implementar uma skin em uma tabbar, incluindo formas de testar nas versões 3G, 4G e Ipad, é imperdível o Screencast dele, se você assim como eu é um pouco mais que um designer e gosta de fuçar em como as aplicações se comportam vai gostar muito da explicação dele.

Espero com esse artigo ter elucidado os primeiros passos para que você venha a criar interfaces para Iphone, Ipad , futuramente estarei falando aqui no Blog de Android também, bem como compartilhando métodos de criação de skins e as próprias skins (Guidelines) para download.

Espero que tenham gostado do artigo.

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

« Entradas anteriores | Entradas recentes »

ACERCA

O que é o RedeRIA ?

O redeRIA não é nada mais que um agregador de feed's que disponibiliza o conteudo de varios blogs e autores ao redor do mundo RIA, actualmente agregamos mais de 2791 entradas vindas de 53 blogs especializados em ria’s, pelo que só fica a ganhar em assinar o feed ou seguir a comunidade no twitter.

Se acha que o seu blog ou um blog de um amigo é interessante e util para os leitores o redeRIA, faça a sua submissão aqui.

Feed: assine já
Twitter: siga-nos

GOOGLE

Votação


Deveria o RedeRia agregar conteúdo em inglês?
Ver Resultados

AUTORES


Eduardo KrausAlexandre TadashiBindableCognitiva SoluçõesDaniel LopesDaniel SchmitzDanielPedrinhaDClick TeamEbercomEdgard DavidsonElvis FernandesErko BrideeFabiel PrestesFábio Batista da SilvaFabio da SilvaFabriccio BernardesFelipe BorellaFlavia MoreiraGabriel VersalliniGabriela T. PerryIgor MusardoJanderson CardosoJoão AugustoJose Carlos FielKelps SousaLeonardo FrançaLucas MarçalLuis MessiasLuiz TarabalMario JuniorMário SantosMauro MartinsPablo SouzaPedro ClaudioreneRia BrazilriaPTRicardo CerqueiraRobson FernandesRodrigo Pereira FragaSaintBrSamuelFacchinelloSergio SouzaSilva DeveloperStefan HorochovecTech CaffeTecinforThiago BuenoVedVinícius SandimWillian ManoXAML Cast

PUBLICIDADE








Powered by Wordpress & msdevstudio.com