Delphi Academy Latinoamérica: I’m back!

Hola a todos!

Estamos con el programa de la Academia Delphi casi listo, pronto publicaremos las fechas y los temas en los medios sociales de Embarcadero, y todos los que participaron en el último año también recibirá un correo electrónico.

Y para el lanzamiento de esta temporada, el primer episodio será especial, vamos a hablar sobre el nuevo compilador de Delphi para Linux, actualmente en fase beta.

Para aquellos que no participaron el año pasado, o se perdió un episodio, aquí está la lista de reproducción de todos los vídeos:

  • Lista de reproducción de todos los episodios anteriores

Estén atentos, en unos días vamos a tener disponible la agenda. La primera transmisión debe ocurrir en 10/02!

Delphi Academy Brasil: I’m back!

Olá pessoal!

Estamos com a agenda do Delphi Academy praticamente pronta, em breve estaremos divulgando as datas e tópicos nas mídias sociais da Embarcadero, e todos que participaram durante o ano passado receberão também um e-mail.

E para o lançamento desta temporada, o primeiro episódio será especial: vamos falar do novo compilador Delphi para Linux, atualmente em beta.

Para aqueles que não participaram no ano passado, ou perderam algum episódio, aqui temos o playlist com o replay de todos os vídeos:

  • Playlist de todos os episódios anteriores

Fiquem atentos, em alguns dias teremos a agenda disponível. O primeiro broadcast deve ocorrer em 07/02!

Delphi Squad – Florianópolis

Last week I was in Florianópolis to participate in the Delphi Squad event, organized by our MVP Samuel “Muka” David and Softplan.

Softplan is one of the biggest Delphi users in the world, they develop software for several areas, including Justice, that are used in Brazil and Latin America.

Softplan recently inaugurated headquarter in Florianópolis

We had a full day of presentations, conducted by MVPs and developers from Softplan. To give you an idea, this was the line up:

  • Fernando Rizzato – Embarcadero (What’s new in Berlin Update 2 and Roadmap)
  • Carlos Henrique Agnes – MVP (FireDAC: Getting Started and Survival Guide)
  • Marcelo Varela – MVP (DataSnap, REST, JSON)
  • Kelver Merlotti – MVP (Mobile Applications: Questions and Answers)
  • Alessandro Fragnani – Softplan (Builds Automation)
  • Rômulo Pelachini – Softplan (Coding Analysis and Metrics)
  • Mario Guedes – MVP (BigData: from the Theory to the Implementation)
  • Samuel Muka David – MVP (Writing a Better Code)
  • Alan Glei – MVP (Delphi, Bluetooth and Beacons)

Here you have some pictures from the event, but you can find a lot more, including videos, here: https://www.facebook.com/DelphiSquad/

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

Na primeira parte deste artigo (aqui) exploramos os principais desafios na migração de projetos Delphi/C++ Builder, listamos alguns tópicos que vamos tratar ao longo de uma série de artigos, e iniciamos o entendimento da parte teórica sobre Unicode.

Neste post vamos retomar o assunto Unicode, porém de um ponto de vista mais técnico, buscando compreender as alterações que são necessárias (ou não) em um projeto.

Vale ressaltar que o suporte a Unicode foi introduzido no Delphi/C++ Builder 2009, portanto, projetos compilados em versões 2009+ não devem sofrer qualquer impacto no tocante a Unicode durante um processo de migração.

O que mudou?

A partir da versão 2009 (inclusive), o tipo String passou a ser definido pelo tipo UnicodeString, que é uma string UTF-16. Da mesma forma, o tipo Char é agora WideChar, um tipo de caractere de dois bytes e PChar é um PWideChar, um ponteiro para um Char de dois bytes.

O ponto significativo sobre as alterações a esses tipos de dados básicos é que, no mínimo, cada caractere é representado por pelo menos um “code unit” (dois bytes), e às vezes mais.

Coincidente com essas mudanças é que o tamanho de uma sequência de caracteres, em bytes, não é mais igual ao número de caracteres na sequência de caracteres. Da mesma forma, um valor do tipo Char não é mais um único byte; são dois bytes.

Opção #1: Mantenha tudo em seu lugar

Uma das opções com relação a Unicode é simplesmente não fazer nada. Isso mesmo… ou na verdade… quase isso. Nas versões anteriores a 2009, o tipo String era então mapeado para AnsiString. Logo, reverter as declaração de String para AnsiString pode ser uma alternativa para uma migração rápida – caso você não necessite suportar caracteres estendidos. O que precisa ser feito, na verdade, é converter declarações String para AnsiString, Chars para AnsiChars e PChars para PAnsiChars.

Para auxiliar nesta tarefa, um membro do Australian Delphi Users Group (ADUG) – Roger Connell – criou um convertor para pesquisar seus arquivos  Delphi (.pas e .dpr) e fazer as conversões, se essa abordagem funciona para você:http: /www.innovasolutions.com.au/delphistuf/ADUGStringToAnsiStringConv.htm

Obviamente, mesmo reduzindo as mudanças ao mínimo, testar e validar sua aplicação previamente a enviá-la para um ambiente de produção, continua sendo uma recomendação mandatória.

Opção #2: Abraçando o Unicode de vez

O Unicode incentiva o uso de alguns novos termos. Por exemplo, a idéia de “caractere” é um pouco menos preciso no mundo do Unicode do que você pode estar acostumado. No Unicode, o termo mais preciso é “code point”. A partir da versão 2009, o SizeOf (Char) é 2. Dependendo da codificação, é possível que um determinado caractere ocupe mais de dois bytes. Estas sequências são chamadas de “Surrogate Pairs“. Assim, um “code point” é um código exclusivo atribuído a um elemento definido pelo Unicode.org. Mais comumente isso é um “caractere”, mas nem sempre.

String agora é igual a UnicodeString, logo suas suposições anteriores sobre o tamanho em bytes de uma matriz de caracteres ou sequência de caracteres podem agora estar incorretas.

Procure qualquer código que:

  • Pressupõe que SizeOf (Char) é 1.
  • Pressupõe que o comprimento de uma sequência de caracteres é igual ao número de bytes na sequência de caracteres.
  • Diretamente manipula sequências de caracteres ou PChars.
  • Grava e lê strings em algum tipo de armazenamento persistente.

As duas suposições listadas aqui primeiro não são verdadeiras para Unicode, porque para Unicode SizeOf (Char) é maior que 1 byte, e o comprimento de uma sequência de caracteres é metade do número de bytes.

Além disso, o código que grava ou lê a partir de armazenamentos persistentes precisa garantir que o número correto de bytes estão sendo gravados ou lidos, uma vez que um caractere pode não ser mais capaz de ser representado como um único byte.

Compreendidas estas alterações, temos um sem números de ótimos documentos e tutoriais para se aprofundar no tema Unicode, os quais estou listando abaixo, porém gostaria de chamar a atenção para uma ferramenta em especial, o Unicode Statistics Tool. Este pequeno utilitário tem a capacidade de revisar seu código e dizer onde e o que você provavelmente vai ter que mudar. Obviamente, trata-se de um auxiliar e não uma ferramenta mágica, mas ajudará muito!

Recursos Adicionais