Embarcadero acaba de anunciar o Delphi XE5, a grande novidade é o suporte a desenvolvimento para Android. Desde que se iniciou o desenvolvimento do FireMonkey o objetivo foi sempre permitir o desenvolvimento para outras plataformas além do Windows, o que começou com o suporte a Mac e iOS, e agora para Android.

O compilador ARM é baseado na arquitetura LLVM o qual facilitou a possibilidade de se ter o novo compilador Delphi para outras plataformas.

Nas últimas semanas foram publicados diversos artigos na internet sobre esta nova versão, mais precisamente comentando sobre a possibilidade de se compilar o mesmo código para iOS e Android. No mundo mobile a experiência do usuário é um dos fatores criticos para o sucesso da sua aplicação, assim sendo precisamos tomar cuidado com o design da aplicação e não achar que só pelo fato de se ter uma única tela para diferentes plataformas é a solução para se ter produtividade, longe disso.

Recentemente comentei aqui no blog sobre o Android Studio, IDE da Google para desenvolvimento Android, com o lançamento do Delphi XE5 os desenvolvedores ganham mais uma opção para o desenvolvimeto de aplicações para Android que traz uma abordagem diferente e com o “objetivo” de trazer maior produtividade através de um único código em desenvolvimento para iOS e Android.

Hoje podemos destacar os seguintes IDE para Android:

• Android Studio (Google) – Java – FREE – http://developer.android.com/sdk/installing/studio.html
• Eclipse + ADT plugin (Google) – Java – FREE – http://developer.android.com/tools/sdk/eclipse-adt.html
• Xamarin Studio (Xamarin) – C# – COMERCIAL – http://xamarin.com/monoforandroid
• Delphi XE5 (Embarcadero) – Pascal – COMERCIAL – http://www.embarcadero.com/products/delphi
• Oxygene (RemObjects) – Pascal – COMERCIAL – http://www.remobjects.com/oxygene/

Entre outras novidades para Android estão um conjunto de funcionalidades que permite o deploy direto no emulador, debug da aplicação, suporte da RTL, componentes de acesso a dados, etc. Muito similar ao suporte para iOS. Além disso o suporte a iOS 7 através de estilos customizados.

Foram incorporados uma série de funcionalidades relacionadas ao acesso a serviços REST, como os componentes TRestClient, TRestRequest e TRestResponse, mecanismos de autenticação e ferramenta para debug que pode auxiliar durante o uso de desenvolvimento com REST.

Em resumo o foco é o desenvolvimento mobile, agora com o suporte a Android e a possibilidade de compartilhar o mesmo código utilizando o novo compilador ARM e FireMonkey.

É hora de testar e ver se o Delphi XE5 irá atender suas expectativas.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

A Google na semana passada anunciou no Google I/O o Android Studio, seu mais novo ambiente de desenvolvimento para Android baseado no IntelliJ IDEA.

O Android Studio é FREE e pode ser usado em Windows, Linux e Mac, o preview inicial já foi disponibilizado para download aqui. Eu já me antecipei e instalei no meu Mac, durante os últimos 2 dias dediquei um tempo para brincar com a ferramenta e estou bem impressionado.

Atualmente a maioria dos desenvolvedores utilizam o o Eclipse juntamente com o plugin ADT (Android Development Toolkit plugin) para desenvolver aplicativos para Android, o que traz uma grande vantagem, usufruir de todos os recursos disponíveis no mundo Eclipse.

Eu venho usando a algum tempo o Eclipse para desenvolver aplicativos Android, certamente tem muito espaço para implementar melhorias e novos recursos específicos para Android.

O Android Studio é construído sobre a versão Community do IntelliJ e agora com atuação em conjunto da equipe de desenvolvedores da Google imagine o que eles serão capazes de fazer. Só de usar a ferramenta algumas poucas horas, posso dizer que o editor de código é sensacional e vai além dos recursos já implementados em outras IDEs, o Designer é fantástico e traz um recurso que nos permite ter um preview da aplicação em vários dispositivos, incluindo tablets. Além disso podemos importar os projetos desenvolvidos em Eclipse para o Android Studio.

Android Studio multi device preview

Assista o vídeo abaixo e você terá uma boa ideia do que estou falando.

Vou ficando por aqui e divirta-se com o Android Studio.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Migração de sistemas legados é um assunto que pode render horas, dias, semanas ou meses em qualquer empresa, algo que considero normal, pois envolve uma quantidade enorme de variáveis e traz grandes desafios. Não precisamos ir muito longe para identificar sistemas legado e os desafios para mantê-lo nos dias de hoje.

Sistemas que cresceram muito rápido e em um curto espaço de tempo, menos de 1 ano por exemplo, pode não ser considerado legado, entretanto na maioria das vezes este crescimento rápido e não planejado não irá suportar o crescimento da empresa a médio e longo. Com isso, o assunto migração entra em cena novamente.

Meu objetivo nesta série de artigos é ir a fundo no tema, trazer um pouco da minha experiência, sugerir caminhos e alternativas para uma migração menos dolorosa, além de recomendar soluções que irão ajudá-los. Vale lembrar que não existe receita de bolo e vocês verão isso aqui, cada caso é um caso e ninguém melhor do que você para saber dos problemas nas soluções desenvolvidas por você ou sua empresa. Faça seus comentários ao final do artigo, eles irão agregar e ajudar outros a refletir sobre que caminho tomar na neste processo, além de me ajudar nos próximos artigos.

Se não é fácil e sabemos, então por onde começamos?

Todos tem de estar desarmados

A primeira coisa a se fazer neste processo é entrar desarmado, aberto a mudança, aceitar ideias, críticas e sugestões, expor o que você pensa e ouvir, ouvir, ouvir e ouvir muito. Todos aqueles envolvidos neste projeto, deverão estar conscientes disso e preparados para mudar seu comportamento, a pior coisa neste longo projeto é ter um grupo de pessoas remando contra, enquanto todos os outros estão remando para frente. Trabalho em equipe será fundamental, críticas, sugestões e debates calorosos existirão, mas todos tem que estar cientes de que é para o melhor do projeto.

Incorporar métodos ágeis como SCRUM já na fase inicial do projeto pode ser de grande ajuda, as práticas ágeis enfatizam muito a colaboração, trabalho equipe, interação entre as pessoas, etc. Isso pode começar a estabelecer um ponto de equilíbrio na equipe e reforçar de forma continua o trabalho em equipe.

Por que migrar?

Faça esta pergunta a si mesmo “Por que migrar?”, esqueça por um instante o famoso ditado “Time que está ganhando não se mexe”, ou seja, “sistema que está funcionando não se mexe”.

A grande maioria dos sistemas ERP desenvolvidos na década de 80 e início dos anos 90 adotaram a arquitetura Cliente/Servidor (Cliente/Server) e foram desenvolvidos para plataforma Desktop, ao longo do tempo isso foi mudando, a web se tornou uma plataforma mais atrativa e hoje vivemos no mundo dos dispositivos móveis. Naquela época muitas soluções baseadas em Web surgiram, mas o avanço da tecnologia foi tão rápido que essas antigas aplicações web não foram bem estruturadas, trazendo vários outros problemas. Enfim, integração entre plataformas e diversidade de meios de acesso tornou o modelo Cliente/Servidor obsoleto.

Considere como exemplo sistemas ERPs legado ou outros similares, reflita sobre o cenário mencionado no parágrafo anterior e traga para sua realidade, seus clientes hoje querem acesso as informações via web, via iPhone, iPad, Android e seus muitos celulares e tablets e assim por diante. A recente pesquisa que fiz aqui no blog mostrou que 75% dos entrevistados irão desenvolver aplicações para mobile e 45% irão migrar suas aplicações desktop para web em 2013. Como você faria essa migração hoje de forma rápida e escalável? Como você integraria apps com seu backend? Quanta regra de negócio seria reutilizada? Já se perguntou?

Seja Desktop ou Web, se seu sistema está baseado em Cliente/Servidor, a eficiência da sua empresa está comprometida pois você está o tempo todo fazendo remendos para atender as necessidades do mercado, isso eleva a dificuldade de manutenção do código, diminui a eficiência da sua equipe, aumenta o seu custo e o custo do seu cliente, ou seja, diminui sua competitividade no mercado.

Já deve fazer um tempo que seu cliente pede para que TODO o sistema seja Web, ele faz questão de dizer TODO O SISTEMA, ele não precisa de tudo e sim certos módulos importantes, como por exemplo relatórios, gráficos estatísticos em tempo real, acesso ao cadastro de clientes, etc. Mais uma vez arquitetura Cliente/Servidor se torna um problema, o seu cliente disse que os relatórios tem de estar acessíveis pela web e relatórios na web podem trazer uma carga enorme em todo o sistema. Como você atenderia a estas solicitações? Não precisa me dizer dos remendos, eu já imagino, replicar os dados para um servidor web, manter sincronizado, etc.. Isso é caro, não é escalável e se torna um remendo temporário que irá rasgar em pouco tempo.

Já se perguntou quanto custa manter seus sistemas Desktop? Depois de muitos anos sua aplicação virou um grande sistema, com dezenas de módulos, integrações, recursos, dependências, etc.. Para responder essa pergunta, você precisa se fazer as perguntas abaixo:

• Quantos problemas de instalação do sistema são registrados mensalmente?
• Quantos problemas de compatibilidade de Windows são registrados mensalmente?
• Quantos problemas de atualização do sistema são registrados mensalmente?
• Quantas visitas mensais os técnicos do suporte técnico fazem a clientes para resolver problemas que não são possíveis de resolver remotamente?
• Quanto representa essa grande estrutura de suporte técnico no seu custo final?
• Que crescimento você estima para o negócio se todo sistema estivesse na Web?
• Quais diferenciais a web traria para o seu negócio?
• Quanto tempo irá levar para você desenvolver uma aplicação Android com base na atual infra que sua empresa oferece?
• Etc…

Provavelmente você não tenha a resposta para todas, então é hora de começar a buscar e mensurar estes custos.

Aplicações desktop aumentam o custo final, principalmente por causa do alto-custo do suporte técnico, não estou dizendo para mandar embora metade da equipe de suporte técnico, muito pelo contrário, a equipe de suporte técnico tem um grande conhecimento do sistemas e pode ser reutilizado em outras funções, como desenvolvedores, testadores, analistas, etc…

Que tal oferecer sua solução como serviço (SaaS), o negócio do seu cliente não é TI, porque não ter  uma infra-estrutura na nuvem e oferecer sua solução? Cobrar por este serviço.

São inúmeros os pontos a se pensar, os pontos aqui mencionados são alguns entre os milhares e talvez não seja razão para você, o que é totalmente aceitável da minha parte, entretanto reflita sobre outros pontos que você acha importante e faça sua própria análise.

Vou ficando por aqui com esta primeira parte, enquanto isso reflita sobre as razões que o levaria a migrar sistemas legados ou mal estruturados.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

A Google disponibiliza o Android Designer guide que é um guia completo chamada Android Design que aborda todos os aspectos a serem considerados. É natural pensar na aplicação que temos e tentar imagina-la em dispositivos móveis, entretanto isso se torna uma armadilha pois acabamos levando hábitos de uma interface que não irá se adequar para um telefone ou tablet.

Para aqueles que pretendem criar apps para Android, além de conhecer a linguagem Java, a plataforma Android e SDK, além de vários outros aspectos técnicos é super importante entender os padrões de Designer da plataforma Android, desenvolver para Mobile pensando em aplicações Desktop sem dúvida não funciona e irá trazer uma desastrosa experiência para o usuário.

O guia da Google da uma dica bem legal com relação a isso, ele sugere que você pense em 3 objetivos durante o desenvolvimento da sua interface:

• Me encante
• Simplifique minha vida
• Me faça incrível

Basicamente com estes objetivos ele está lhe dizendo para pensar no usuário, tornar a vida dele mais fácil, usar os padrões da plataforma e não reinventar a roda.

Uma outra dica que pode irá ajudá-lo a pensar mais no Designer da sua app é observar os detalhes das apps que você mesmo mais utiliza no seu dia-a-dia, observe os controles utilizados, o uso de gestures para fazer algo, touch e multi-touch. Observe também a app responsável pela configuração (Settings) do telefone, geralmente elas usam muitos controles nativos, animações, etc.. e pode lhe dar mais idéias ainda.

Vale lembrar que o guia não está lhe impondo como fazer sua app e sim lhe dando um direcionamento. Android é a plataforma mobile mais aberta do mercado, lhe permite customizar de todas as formas, o guia vem para nos ajudar, pois as opções são inúmeras e muitas das vezes acaba dificultando nossa decisão.

Abaixo a apresentação “Android Design for Success” com engenheiros do Google que aconteceu no Google I/O 2012, eles abordam inúmeros aspectos a serem considerados durante o desenho de uma aplicação, usando o próprio projeto Android como exemplo. Vale a pena.

Fico por aqui, até o próximo artigo.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

O uso de findViewById em Android é algo que considero inconveniente, ele acaba fazendo você escrever mais código, com isso cresce o seu código de forma desnecessária, dificulta a leitura, manutenção, etc. Entretanto temos uma solução para este problema e que se chama @InjectView que é parte do framework RoboGuice, este irá tornar nosso código mais claro, menor e fácil de manter ao substituirmos findViewById, vamos ver como funciona.

Vamos supor que temos o EditText abaixo definido em nosso Activity.

A forma de acesso através do findViewById ficaria assim:

class Main extends Activity { 

    public void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        setContentView(R.layout.main);
        EditText nome;
        nome = (EditText) findViewById(R.id.nomeEditText);
        nome.setText( "Meu nome é João"); 
    } 
}

Para usar @InjectView nosso Activity passa a herdar de RoboActivity (não esqueça de baixar o RoboGuice aqui) ficando assim:

class Main extends RoboActivity { 
     @InjectView (R.id.nomeEditText)      EditText nome; 

    public void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        setContentView(R.layout.main);
        nome.setText( "Meu nome é João" ); 
    } 
}

Desta forma não precisamos obter uma referência ao objeto “nome” toda vez que for necessário acessá-lo, pois o mesmo está sendo feito pela @InjectView. Em telas onde temos vários objetos a manutenção e leitura do código será mais fácil como você pode ver no exemplo abaixo.

class Main extends RoboActivity { 
     @InjectView (R.id.nomeEditText)      EditText nome; 
     @InjectView (R.id.sobrenomeEditText) EditText sobrenome; 
     @InjectView (R.id.fotoImage)         ImageView foto; 

    public void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        setContentView(R.layout.main);
        nome.setText( "Meu nome é João" ); 
        sobrenome.setText( "Meu sobrenome é Silva" ); 
        foto.setImageBitmap( null ); 
    } 
}

Espero que esta pequena dica tenha ajudado.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Neste vídeo explico como você pode utilizar DataSnap Connectors para conectar suas aplicações móveis, como exemplo mostro como conectar apps Windows Phone e Android, mas você pode conectar aplicações iOS e BlackBerry também.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Este é segundo vídeo do Delphi Conference 2010 Brasil onde o italiano Daniele Teti apresenta na prática como integrar aplicações para Android com servidores DataSnap, reserve um tempinho e assista ou faço o download desta apresentação que foi um show a parte.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse