Windows 10 Store, Android, iOS, OS X, Linux: recursos para migrar sua aplicação Delphi/C++ Builder e suportar TODAS as plataformas (parte 5)

Estamos na quinta parte desta coletânea de artigos e tutoriais para migração de aplicações Delphi e C++ Builder, e hoje vamos falar sobre componentes de terceiros. Caso não os tenha encontrado, os artigos anteriores podem ser encontrados nos seguintes links:

Componentes e bibliotecas de terceiros são sempre um assunto polêmico.

Em muitas ocasiões, são a salvação quando precisamos de uma solução rápida para algo não contemplado nativamente pelo produto, ou ainda que vai lhe exigir um bom tempo de codificação, do qual você não dispõe.

Por outro lado, podem render uma boa dor de cabeça se não os tratamos de maneira adequada, com todo o gerenciamento e controle que você aplica ao seu próprio código fonte.

Eis uma lista – incompleta – dos problemas mais comuns relacionados a sua utilização, sejam componentes comerciais ou Open Source:

  • o componente acaba sendo descontinuado por qualquer razão, e você não tem o código fonte dos mesmos
  • o fornecedor tarda em disponibilizar uma versão atualizada, e isso está retardando seu processo de migração para uma versão mais recente do compilador
  • o componente é ótimo em uma determinada plataforma, mas não possui uma solução similar para suportar múltiplas plataformas

Ainda assim, os benefícios em se utilizar algumas soluções especializadas em seu projeto, o tempo salvo em codificação, a certeza de estar utilizando algo já amplamente provado, e a satisfação de seu cliente com a solução de alto nível e extremamente profissional que você está apresentando, em grande parte das vezes, não tem preço.

Então, se sua decisão é por utilizar componentes externos, tenho aqui algumas sugestões para você – novamente uma lista incompleta:

  • Revise uma vez mais os componentes e bibliotecas nativas, e tenha certeza que o framework nativo não cobre suas necessidades
  • Revise uma vez mais se você (ou seu cliente) realmente necessita do recurso em questão. Será que ele (cliente) realmente espera este recurso, ou você achou aquele Label piscante que gira 360 graus a coisa mais incrível do mundo?
  • Sempre que possível, obtenha o código-fonte do componente, e o versione em seu repositório, juntamente com o projeto – mesmo que o pacote seja de código aberto e encontre-se público no Github ou similar. Você nunca sabe quando o “dono” do projeto vai mudar de ideia.
  • Optando por utilizar um componente sem o código-fonte, tenha certeza tratar-se de um fornecedor consolidado e  conhecido no mercado. Observe para quantas versões do produto ele já disponibilizou o componente, e qual seu compromisso com novas releases. Pergunte pelo seu roadmap.
  • Fornecedores de componentes para múltiplas plataformas costumam ser  bastante estáveis.
  • Parcimônia é a palavra chave ao pensar em componentes de terceiros. Lembre-se que todo exagero é ruim, praticamente em todas as áreas da vida e da programação 😉

Encontrando seus Componentes

Num processo de migração, a etapa zero é tomar a nova versão da IDE, e instalar todos os componente utilizados na versão atual de seu projeto.

A grande novidade nesta área é o GetIT. Trata-se de um gerenciador de pacotes integrado na IDE (lançado a partir do XE8), o qual disponibiliza e instala automaticamente uma vasta quantidade de componentes, comerciais e de código aberto.

800px-getitwindow

Mas e seu componente não pode ser encontrado no GetIt? A lista de componentes disponíveis é boa, mas obviamente não compreende todo o universo de possibilidades.

Para este cenário, além do bom e velho Google… existem alguns bons repositórios disponíveis:

Se você deseja contribuir com esta lista, envie sua sugestão, seja sobre um único componente ou um repositório, provavelmente será útil para outros desenvolvedores!

 

 

Feliz Aniversário Delphi! #ILoveDelphi

ilovedelphi

Chegamos a mais um aniversário do Delphi, e podemos atestar que o aniversariante encontra-se em ótima forma ao completar seus 22 anos, um jovem na verdade!

Neste tempo todo, poucas tecnologias tiveram tamanha capacidade de se manter tão atualizadas, inovadoras e seguir ditando tendências. A começar pelo conceito do RAD, criado pela então Borland, e presente nas principais ferramentas da atualidade, até os dias atuais, com um dos melhores suportes para desenvolvimento cross-platform disponível no mercado!

Para marcar o dia, algumas fotos de pequenos tesouros e lembranças que mantenho da minha participação nesta história, afinal lá se vão 15 anos nesta industria vital!

ps: aos mais mais novos, é recomendado assistir este vídeo para entender a frase acima 😉

Foram centenas de treinamentos ministrados, consultorias e sistemas desenvolvidos. Apresentações em todas as capitais do país, e muitas cidades do interior também, e a incrível experiência de trabalhar ao menos por uma semana em cada país da América Latina e América Central, visitando clientes e fazendo eventos. É impressionante o que um compilador é capaz de fazer!

Mas além de um compilador, temos as pessoas. Sim, em tempos de pragmatismos e racionalização de tudo, talvez seja este o fator que nos permitiu chegar tão longe, todas verdadeiramente apaixonadas pelo que fazem.

Seria uma tremenda injustiça citar qualquer nome, cada qual contribuiu com o seu melhor, empurrando a ferramenta para frente, empurrando minha vida para frente… cada qual sabe o quanto sou grato por tudo!

Obrigado Delphi!

Windows 10 Store, Android, iOS, OS X, Linux: recursos para migrar sua aplicação Delphi/C++ Builder e suportar TODAS as plataformas (parte 4)

Estamos na quarta parte desta coletânea de artigos e tutoriais para migração de aplicações Delphi (e também C++ Builder).

Iniciamos por uma visão geral de projetos de migração (parte 1), passamos por impactos do Unicode (ou não) em projetos Delphi e C++ (parte 2), e também por compilação nativa 64 bit, disponível desde o XE2 (parte 3).

Hoje vamos abordar migração de frameworks de acesso a dados, ou seja, BDE, ADO, DBX, IBX, e tantos outros disponíveis.

Iniciando pelo saudoso BDE, este framework de acesso a dados possui algumas características que o diferenciam de todos os demais. O BDE pode ser considerado – guardadas as devidas proporções – um middleware. Isto porque, para funcionar, o BDE necessita de uma instalação completa no sistema operacional onde seu projeto será executado, o que não ocorre com nenhum outro framework Delphi ou C++. Ele possui dlls as quais são responsáveis pelo acesso aos mais diversos banco de dados, em um processo que ocorre de maneira externa ao espaço de memória e ao processo alocado pela aplicação. Complicou? Então vamos detalhar isso um pouco mais…

Por tratar-se de um processo externo a sua aplicação, algo como uma camada adicional carregada no momento em que uma conexão com o banco de dados é estabelecida pela primeira vez por esta aplicação, o BDE permitia algumas “peripécias” não suportadas por outro frameworks, como por exemplo:

  • O BDE permitia facilmente suportar múltiplos banco de dados, de maneira quase transparente, isso graças a esta camada intermediária, que fazia a “conversação” com cada um dos banco de dados suportados, e entregava uma resposta homogênea para sua aplicação. Na prática, sua aplicação não sabia efetivamente a qual banco de dados estava  conectado, digamos assim.
  • O BDE, por tratar-se de um processo externo a sua aplicação, permitia as aplicações compartilharem uma mesma conexão com o banco de dados entre distintos executáveis. Basicamente, tudo o que você tinha que fazer era utilizar um “handle” compartilhado e voilà, podemos ter uma aplicação modularizada em distintos executáveis em uma mesma máquina compartilhando da mesma conexão ao banco de dados.

Outros frameworks, como DBX, também apresentação dlls externas, porém as mesmas não representam um processo externo a sua aplicação, ao contrário, são carregadas no espaço de memória do executável principal, não permitindo o compartilhamento da conexão.

Os demais, como o FireDAC, são código 100% Pascal ou C++, e são compilados efetivamente com sua aplicação, não possuindo drivers externos de qualquer espécie, sendo uma enorme vantagem no deployment e também em aplicações multiplataforma.

De todos eles, o FireDAC aparece com o melhor framework disponível atualmente para acesso a dados, sendo disparado a melhor opção para migração de BDE, já que ele “imita” o comportamento do mesmo, exceção feita ao compartilhamento de uma conexão entre executáveis distintos, o que pode ser solucionado de outras maneiras (utilização de BPLs, multicamadas, pool de conexões, etc.).

FireDAC possui características que nenhum outro framework oferece, seja no mundo Delphi e C++ Builder, seja em qualquer ambiente de desenvolvimento, como .NET ou Java. Um deles é o suporte a consultas SQL em bases de dados heterogêneas, em resumo, fazer uma Join entre Oracle e SQL Server e um arquivo XML, para citar um exemplo apenas.

Migrando seu Projeto

Existem muitas formas de se migrar um projeto, algumas mais eficientes que ouras, mas você não vai encontrar uma receita mágica. Existem sim alguns recursos realmente úteis e de alta produtividade, os quais vou resumir abaixo.

Iniciando por conhecer melhor o FireDAC, recomendo estes webinars, gravado para a série Delphi Academy:

  1. Acesso a Dados com FireDAC
  2. FireDAC Cached Updates
  3. FireDAC DataSets em Memória
  4. FireDAC Local SQL Cache
... algumas horas depois...

Agora que você já conhece o beabá do FireDAC, a migração efetiva pode ser facilitada em muito com a utilização de um utilitário chamado reFind.exe. Trata-se de um executável de linha de comando, o qual – com a ajuda de expressões regulares – vai fazer um parser em seu projeto, de acordo com configurações que você vai determinar em um arquivo de script, e substituir o antigo framework pelo FireDAC.

Felizmente, já faz parte do pacote de exemplos que a ferramenta traz, scripts para migração de BDE e DBX, ambos para FireDAC. Mas observe que, baseado nos scripts existentes, e na documentação, você será capaz de criar seu próprio script, e migrar qualquer outro framework ou componente, não há nada no reFind criado especialmente para o FireDAC, neste caso o FireDAC é um caso de uso do reFind.

Detalhes sobre o reFind você pode encontrar nestes links da documentação:

http://docwiki.embarcadero.com/RADStudio/Berlin/en/Migrating_dbExpress_Applications_to_FireDAC
http://docwiki.embarcadero.com/RADStudio/Berlin/en/ReFind.exe,_the_Search_and_Replace_Utility_Using_Perl_RegEx_Expressions

Mas também tenho um tutorial completo de migração em um dos episódios do Academy, onde algumas técnicas e recursos adicionais são discutidos:

Bem, por hoje é o que temos ;-). Espero que estes recursos sejam úteis de alguma forma, e no próximo – e último artigo da série – vamos explorar a migração de componentes de terceiros.

Até lá!

 

Windows 10 Store, Android, iOS, OS X, Linux: recursos para migrar sua aplicação Delphi/C++ Builder e suportar TODAS as plataformas (parte 3)

Nos últimos dois artigos aqui e aqui discutimos basicamente sobre Unicode e seu impacto na migração de projetos Delphi (e também C++) para a versão mais recente do produto.

Neste post, a terceira parte desta série, vamos discutir migração para 64 bit.

Desde XE2, tem sido possível gerar aplicativos de 64 bits Delphi e C++ a partir da mesma base de código 32 bits. A importância de 64 bits para empresas é abordado neste artigo “The Impact of 64-bit Applications to your Company’s Bottom Line“.

Toda a mudança para 64 bits é incrivelmente simples de ser executada! Pode ser tão simples como adicionar a plataforma de destino Windows 64bit  no gerenciador de projetos e reconstruir o projeto.

Minha experiência ao falar com muitos desenvolvedores é que normalmente há algumas coisas para verificar em seu código, mas normalmente não é uma tarefa maciça para obter a compilação e estar pronto para testar.

Muita coisa foi gravada com relação a migração de 32 para 64 bit e este deve ser um bom resumo se você está planejando esta migração. Se você estiver construindo aplicativos iOS, então você precisará usar a compilação de 64 bits para entrar na AppStore. Felizmente, RAD Studio torna a tarefa de usar 64 bits muito simples em todas as plataformas, e tem nos protegido das dores de cabeça que os desenvolvedores de outras plataformas tiveram em geral.

Vamos começar com este pequeno vídeo de David I que cobre algumas das principais características:

O que é igual entre 32 e 64 bit?

Integer, LongInt, Cardinal – permanecem 32bit em ambas as plataformas. Int64 e UInt64 são 64bit (8bytes) em ambas as plataformas.

Unicode String, AnsiString, WideString etc. são todos os mesmos. Trabalhe da mesma maneira e use as mesmas chamadas RTL.

Manipulação de exceção também é o mesmo! Você pode definir pontos de interrupção e eles funcionam da mesma maneira ao depurar, as exceções que são geradas ainda são tratadas da mesma maneira.

As unidades que você usa são ainda as mesmas, por exemplo, SysUtils, Classes etc. O RTL (Run Time Library) ainda é o mesmo.

Diferenças entre 32 e 64 bit

Existem alguns tipos que são diferentes, dependendo da plataforma para a qual você compila.

NativeInt e NativeUInt são 32 bits ou 64 bits / 4 ou 8 bytes, dependendo da plataforma de destino. As matrizes dinâmicas usam indexação de 64 bits em uma compilação de 64 bits. Os processadores de 64 bits não têm o mesmo tipo estendido que existe no 32bit, o que significa que o tipo Extended reverte para DOUBLE em 64 bits.

Mas o ponto-chave são os ponteiros, os quais são todos de 64 bits em versões de 64 bits. Isso significa algumas coisas. Em primeiro lugar, todos os objetos têm um ponteiro maior do que um Integer. Então, se você tem usado typecasting para Integer em seus ponteiros… precisa revisar isso!

Tipos de ponteiro que são 4 bytes no código 32 bits e 8 bytes no código de 64 bits, incluindo:

  • Pointer
  • String
  • Class Instance
  • Class reference
  • Interface
  • AnsiString
  • WideString
  • UnicodeString
  • Procedure Pointer
  • Dynamic Array
  • PAnsiChar
  • PWideChar
  • PChar

Você está usando a propriedade TAG para armazenar ponteiros?

Felizmente a equipe atualizou a propriedade Tag em TComponent para ser um NativeInt, por isso será 4/8 bytes, dependendo da plataforma para não quebrar seu código!

Pre-defined conditions

O compilador Delphi 64 bits introduziu um número de novas condições pré-definidas. Embora você não precise usá-los regularmente, eles podem ser usados se você quiser manter algum código otimizado para o Win32 ou Win64.

Condições pré-definidas permitem que blocos de código específicos sejam compilados dependendo da plataforma. O bloco a seguir mostrará o Win32 como uma mensagem de exibição somente em versões do Windows 32 bits.

procedure FazAlgumaCoisa;
var
  S : string;
begin
{$IFDEF WIN32}
  S := 'Aqui é Win32';
{$else}
  S := 'Aqui não é Win32';
{$ENDIF}
  ShowMessage(S);
end;

Recursos Adicionais