Novo Endereço

Caro Visitante/Assinante,

Estamos com Novo Visual no endereço :

http://blog.magicsoftware.com.br

Visite-nos e dê sua opinião na opção contato.

 

 

Por que ficar “Rico” não precisa ser caro

Equipe de Marketing da Magic Software Enterprises

Muitas empresas hoje sabem porque faz sentido mudar para RIA. Elas reconhecem os benefícios substanciais que podem ser obtidos com a migração, mas ainda estão relutantes em dar o próximo grande passo e desenvolver aplicações de negócios que incorporam a verdadeira essência do RIA corporativo, ou seja, uma rica experiência do usuário que melhora performance e produtividade.

RIAs corporativos são aplicações estilo desktop que se caracterizam pela riqueza e funcionalidade interativas para oferecer uma experiência do usuário muito melhor em comparação com as aplicações padrões baseadas em browser. Enquanto a interface do usuário no RIA corporativo não precisa incluir os elementos gráficos elaborados e complexos ou animações interativas associadas com aplicações comerciais, sociais ou jogos, ela deve, porém, ser clara e envolvente para prover usabilidade intuitiva e eficiente. Um conjunto de aplicativos como o Google Docs mostra a impressionante, robusta e rica  experiência do usuário que pode ser alcançada na implementação do RIA em todo o seu potencial.

Frequentemente as empresas se limitam a fornecer apenas as funcionalidades mais básicas, com pouca atenção para a qualidade da experiência do usuário.  Ao fazer isso, elas tiram o ‘rico’ fora do RIA. Mas por que isso está acontecendo? Como podemos explicar essa relutância para abraçar o verdadeiro valor agregado do RIA?

Parece que a resposta reside principalmente na natureza do processo padrão de desenvolvimento do RIA. As ferramentas de desenvolvimento RIA normalmente exigem esforços de desenvolvimento separados para o lado Client e para o lado Server de uma aplicação, utilizando normalmente linguagens de programação diferentes e exigindo diferentes habilidades do desenvolvedor. Equipes separadas de desenvolvedores precisam ser contratadas, treinadas, e gerenciadas. A dependência de múltiplas equipes e conhecimentos pode criar gargalos no processo, e torna mais difícil atualizar uma aplicação conforme as necessidades dos usuários evoluem. Então, diante do alto custo e do trabalhoso  processo de criação e manutenção de aplicações verdadeiramente ricas, algumas empresas barram o investimento necessário de tempo, dinheiro e esforço.

No entanto, essas empresas não precisam mais ter receio do ciclo de desenvolvimento para RIA. Plataformas de aplicações orientadas a metadados oferecem uma nova abordagem para a implantação RIA, simplificando e racionalizando o processo de desenvolvimento. Por exemplo, com a tecnologia correta, agora é possível usar uma única linguagem de programação e ter um único esforço de desenvolvimento para criar tanto o lado Client quanto o lado Server do aplicativo. Sem múltiplas equipes; sem múltiplos esforços de desenvolvimento; sem ciclos de desenvolvimento morosos e caros; apenas a liberdade para se concentrar em melhorar a riqueza da experiência do usuário.

Basta somente utilizar as ferramentas corretas para o trabalho. As empresas não devem se contentar com menos, quando se pode obter muito mais da experiência RIA, com um investimento relativamente pequeno. Quando se trata de RIA, ficar ‘rico’ não tem que ser caro.

Migrando Telas ActiveX para o uniPaaS 2.0 – Parte 02

Manoel Frederico da Silva / Product Manager & MAGIC Evangelist / Magic Software Brasil

Falamos anteriormente a respeito de alguns passos necessários na migração de projetos eDeveloper ou uniPaaS que utilizam controles ActiveX. Basicamente, da necessidade de se converter o ActiveX em .NET User Control usando o utilitário AXImp.

Vamos agora abordar outro aspecto a respeito do mesmo assunto, que pode causar algumas dúvidas nos desenvolvedores.

Imagine que o desenvolvedor já utilizava anteriormente controles .NET em seus projetos:

Como tanto o eDeveloper quanto o uniPaaS 1.x (ou mesmo o VB6, Delphi, etc…) não são aplicações MS.NET, eles não tem como exibir .NET User Controls em suas telas.

Usava-se então os recursos de interoperabilidade do MS.NET e convertia-se o controle .NET em controle ActiveX:

Pronto. Agora com um controle ActiveX proxy criado, este controle .NET podia ser utilizado nas soluções eDeveloper ou uniPaaS.

Porém, este tipo de controle não pode ser convertido utilizando-se o AXImp, porque ele já é um .NET User Control originalmente.

Como então migrar estas telas para o uniPaaS 2.0?

É muito simples.

Basta utilizar o controle .NET original, diretamente nas soluções uniPaaS  2.0:

Nas telas dos programas/tarefas, cria-se uma virtual .NET (ao invés de ActiveX) associada ao controle:

Coloca-se o controle no formulário (janela):

E está pronto para utilização:

Migrando Telas ActiveX para o uniPaaS 2.0 – Parte 01

Manoel Frederico da Silva / Product Manager & MAGIC Evangelist / Magic Software Brasil

Falamos anteriormente a respeito de algumas mudanças em nossas soluções baseadas no novo uniPaaS 2.0, especialmente na questão da interface (telas). A lista completa dessas mudanças pode ser conhecida no DevNET* da MAGIC: http://devnet.magicsoftware.com/en/library?book=en/uniPaaS2/&page=Whats_Different_in_uniPaaS_V2.0.htm.

Basicamente, se resumem ao fato de que agora o runTime é MS.NET e conseqüentemente, as telas são objetos WinForms.

Um dos efeitos mais diretos, é a impossibilidade de se mostrar controles ActiveX nas telas WinForms.

Desde o eDeveloper 9.4, as soluções MAGIC podem incluir controles ActiveX em seus formulários (telas).

Exemplo em Visual Basic 6:

Exemplo em uniPaaS 1.9g:

No uniPaaS 2.0 nós continuamos tendo a opção de criar objetos OLE e acessá-los através do comando Invoke COM. Mas colocar controles ActiveX em telas, não é mais possível.

Como manter minhas soluções antigas, que usam ActiveX, funcionando?

É simples, bastante simples na verdade. O MS.NET SDK possui um utilitário chamado AXImp.exe. É um programa de linha de comando, que converte uma classe ActiveX em uma classe MS.NET, e permite que seja utilizada em telas WinForms (como é o nosso caso aqui).

O AXimp converte um ActiveX em um .NET User Control.

NOTA: Existem versões específicas do AXImp para Windows 32bits e 64bits. Veja mais detalhes em: http://social.msdn.microsoft.com/Forums/en/netfx64bit/thread/d5d11837-d697-4a64-9b61-8a974b622098

Neste nosso exemplo, com o controle ChartFX 2.0, poderíamos fazer desta forma:

AXImp C:\Windows\system32\CFX32.OCX /out:CFX32.DLL

Serão gerados alguns assemblies .NET, contendo a classe ActiveX já convertida. Entre eles, o assembly CFX32.DLL.

NOTA: Os assemblies gerados são classes “proxy” (capas) para os verdadeiros controles, que permanecem sendo um ActiveX. Por isso, a distribuição e registro do ActiveX (arquivo .OCX) continua sendo necessária.

Então, carregamos estes assemblies como componentes de nossa solução  uniPaaS 2.0:

DICA: Os assemblies que for utilizar que não sejam registrados no GAC do MS.NET, você pode copiá-los para a pasta %EngineDir%RIAModules\Desktop, pois ela já está relacionada no probing path do uniPaaS.

Criamos a virtual associada a este controle .NET:

Colocamos o controle no formulário do programa/tarefa:

E está pronto.

O controle ActiveX agora convertido em controle .NET está disponível para uso em nossa solução uniPaaS 2.0:

(*) O DevNET (http://devnet.magicsoftware.com/) é um portal repleto de informações sobre todos os produtos MAGIC, que todo desenvolvedor/arquiteto de soluções uniPaaS/iBolt deveria conhecer.

A Nova Plataforma de Aplicações da Magic Software e o Framework .NET: O Melhor dos Dois Mundos

Glenn Johnson – Senior Vice President – Magic Software Americas

A nova Plataforma de Aplicações da Magic Software, uniPaaS 2.0, implementa um novo mecanismo de implantação .NET, que transforma qualquer aplicação uniPaaS já existente em uma aplicação .NET nativa. Segundo a Microsoft, o framework .NET é composto de um Common Language Runtime (CLR) que fornece uma camada de abstração sobre o sistema operacional; Bibliotecas de Classe de Base que entregam código pré-construído para tarefas comuns de programação de baixo nível, e soluções de tecnologias e  frameworks de desenvolvimento reutilizáveis e customizáveis ​​para as tarefas maiores de programação. O novo runtime do uniPaaS 2.0 utiliza o Windows Forms .NET como o front-end GUI para as aplicações. Para ser claro, o Windows Forms é o nome dado pela Microsoft para a interface gráfica de programação de aplicativos (API) incluída no Microsoft .NET Framework. O Windows Forms provê acesso nativo a elementos da interface do Microsoft Windows por encapsular a API Windows existente em código gerenciável. O uniPaaS 2.0 aproveita facilmente essa capacidade para fornecer recursos GUI magníficos para aplicações cliente/servidor e RIA. Na verdade, o uniPaaS 2.0 oferece total integração com o framework Microsoft. NET para melhorar significativamente o design da aplicação, sua funcionalidade e a experiência geral do usuário. O uniPaaS 2.0 também traz novas melhorias relacionadas ao RIA.

Com o uniPaaS 2.0, a Magic Software em breve estará oferecendo sua primeira Plataforma de Aplicativos Móveis Corporativos com suporte para dispositivos BlackBerry ou Windows Mobile 6.5 como plataforma client de implantação. Ambos devem vir imediatamente, e iPhone e Android chegam logo em um futuro próximo.

Em um press release no mês passado, a Magic Software Enterprises (NASDAQ: MGIC) incluiu uma citação de um gerente de produto da Microsoft sobre o uso da plataforma de integração da Magic Software para integração com o SharePoint. Com o lançamento do uniPaaS 2.0, fica claro que Magic Software está agora ainda mais estreitamente alinhada para alavancar tecnologias Microsoft Windows e .NET framework.

De fato, poderíamos mesmo dizer que o uniPaaS 2.0 é uma linguagem de programação NET (assim como também se pode dizer que é uma linguagem de programação IBM i ou uma linguagem de programação AIX ou uma linguagem de programação Linux). Então, a diferença é  que antes você apenas podia dizer que a programação cliente/servidor do uniPaaS 1.9 era uma linguagem de programação Windows. Agora, pode-se ver a plataforma de aplicações da Magic suportando plenamente e sendo totalmente suportada pelo framework .NET. Neste sentido, ela pode ficar ao lado do Visual Basic .NET e outras linguagens de programação .NET para servidores a clientes Windows, assim como pode da mesma forma ficar ao lado do RPG e do  COBOL para criação de aplicativos para  servidores IBM i, etc

A boa notícia para os departamentos de TI das empresas que adotaram o desenvolvimento de aplicações .NET como um padrão corporativo é que uniPaaS 2.0 agora atende (e mesmo ultrapassa) os requisitos por ser uma plataforma de aplicações framework .NET. Esta é uma boa notícia, porque ao contrário das linguagens .NET existentes, o uniPaaS superalimenta o .NET de uma forma que nenhuma outra abordagem pode fazer.

Como a plataforma de aplicações uniPaaS 2.0 da Magic Software turbina o desenvolvimento e a implantação de aplicativos de negócios? Primeiro, o uniPaaS acelera o desenvolvimento nas aplicações .NET, por fornecer uma metodologia de desenvolvimento fácil e simplificada que ainda abstrai o processo de desenvolvimento sem sacrificar o controle. Então, ele estabiliza o desempenho e a integridade operacional das aplicações, aproveitando nossas tecnologias comprovadas e altamente escaláveis.

Esta versão é apenas mais um exemplo da longa história da Magic Software de fornecer soluções que protegem seus aplicativos das mudanças de sistemas operacionais, clientes, servidores e outras tecnologias. Por ter suas aplicações de negócios à prova de futuro com o uso da plataforma Magic Software, você é capaz de superar a concorrência e todas as expectativas quanto à sua capacidade de se adaptar a quaisquer mudanças que o futuro pode trazer. Para saber mais, por favor acesse esses recursos.

uniPaaS 2.0 – Detalhes que fazem a diferença – 02

Manoel Frederico da Silva / Product Manager & MAGIC Evangelist / Magic Software Brasil

Falamos anteriormente (ver aqui) a respeito de alguns cuidados necessários ao utilizar classes MS.NET em nossas soluções baseadas no novo uniPaaS 2.0.

Vamos agora abordar mais um, bastante importante.

O MS.NET, assim como o Java, é um ambiente gerenciado automaticamente. Resumindo: ele cuida de toda a alocação e liberação de recursos (ex: memória) necessários ao programa, de forma automática e nos bastidores.

Mas, ao menos no MS.NET, o desenvolvedor não está 100% livre de se preocupar com estas coisas.

Algumas classes .NET implementam a interface IDispose. Quando uma classe implementa “IDispose”, ela está dizendo ao desenvolvedor que, internamente, ela faz uso de recursos do sistema operacional (normalmente não gerenciados) que são escassos ou compartilhados, e precisam ser utilizados com prudência e liberados (devolvidos ao sistema operacional) assim que não forem mais necessários. Por exemplo: conexões com bases de dados, sockets, arquivos abertos, etc…

“…

Certa vez tivemos de enviar mensagens (e-mails) através do MS.NET, e verificou-se que os arquivos enviados como anexo permaneciam inacessíveis (sem poder ser lido por mais ninguém) até que o programa .NET fosse encerrado. Isso era porque faltava realizar o Dispose() do objeto “mensagem” que mantinha aberto os arquivos anexados

…”

Este tipo de classe .NET possui um método chamado Dispose() que deve ser chamado “manualmente” pelo desenvolvedor, assim que ele entender que objeto não será mais usado em seu programa. Do contrário, o recurso ficará “preso” até que o framework MS.NET decida que é hora de liberar o objeto da memória.

Caso você queira estudar mais sobre o “Dispose/Finalize Pattern”, há bastante material disponível na internet sobre isso (como aqui).

Mas o que isso tem a ver com meus programas uniPaaS?

Depende do tipo de classe que você utilizar na sua aplicação.

Vamos tomar como exemplo a classe .NET “FileStream”. Podemos utilizá-la para fazer leitura/gravação de arquivos binários. Veja:

Quando instanciamos um objeto da classe “FileStream”, temos ativo (na memória) um objeto .NET que internamente está alocando recursos não gerenciados (neste caso, um “handle” para o arquivo aberto/criado):

Quando a tarefa uniPaaS que criou o objeto finalizar, este objeto será considerado “out of scope” pelo MS.NET e liberado em algum momento (segundo as regras do GC). Pode ser em seguida, ou pode demorar um pouco.

E se tivermos aberto um arquivo em modo exclusivo? Enquanto o objeto não for efetivamente liberado pelo MS.NET, este arquivo ficará bloqueado a qualquer outro usuário ou processo.

Por isso, devido a natureza “não determinista” do GC MS.NET, é prudente que venhamos a liberar este recurso não gerenciado assim que terminar de utilizarmos o objeto (quando ele não for mais necessário):

Não dá para saber visualmente, se uma classe .NET implementa ou não a IDispose. É preciso recorrer a documentação da classe, ou pelo menos listar seus métodos públicos e ver se há algum chamado Dispose().

Para encerrar: algumas dessas classes .NET (como é o caso de FileStream) possui também um método chamado Close(), que faz o mesmo serviço que o Dispose(). Isso ocorre apenas por questões de legibilidade, já que faz mais sentido “fechar” um arquivo que foi aberto, do que “descartá-lo”. Por isso, a instrução a seguir também seria correta neste caso:

uniPaaS 2.0 – Detalhes que fazem a diferença

Manoel Frederico da Silva / Product Manager & MAGIC Evangelist / Magic Software Brasil

A integração do uniPaaS 2.0 com o MS.NET abre sem dúvida um leque muito grande em termos de funcionalidades e recursos para as nossas soluções.

Mas como sempre, com o poder vem a responsabilidade. Algumas coisas precisam ser observadas.

Por exemplo: criar uma variável/tipo .NET é exatamente igual ao procedimento de se criar variáveis nativas do uniPaaS. Mas apesar disso, elas só parecem ser a mesma coisa. De fato, não são.

Uma variável/campo uniPaaS definida nas tarefas/programas representa um tipo “valor”. Sua vida útil vai desde a instanciação da tarefa (antes do Task Prefix), até a sua finalização (após o Task Suffix). E sua área de memória é criada automaticamente pelo runTime uniPaaS durante a instanciação da tarefa, a mantida durante a vida útil desta tarefa.

Já uma variável/campo .NET representa (*em geral) um tipo “objeto”. O objeto é uma variável que irá conter a referência a uma instância de uma classe. A variável do tipo “objeto” não contém nada (é nula) até que a instância da classe seja criada e sua referência seja colocada ali dentro. E quando se utiliza uma variável “objeto” que ainda não possui uma referência de instância válida, o resultado é uma exceção do tipo NullPointerException.

Esse conceito é básico para os desenvolvedores MS.NET, mas pode ser uma novidade para o mundo uniPaaS, já que nunca houve necessidade de se lidar com alocação explícita de memória (tá vendo pq o uniPaaS sempre foi top? ).

Quando criamos uma variável .NET no uniPaaS que é relacionada a um controle .NET que será colocado na tela (formulário), a instanciação da classe é feita automaticamente pelo runTime no momento da criação da janela (antes do Task Prefix).

Mas e quando formos utilizar uma classe que não é um controle?

Nestes casos, precisamos instanciar a classe (através de seu construtor) e colocar a referência dentro da variável. Isso deve ser feito apenas uma vez, já que cada execução do construtor cria uma nova instância (e normalmente não é o que se deseja).

Vejamos este exemplo: Supondo que queremos usar a classe MS.NET “ContextMenuStrip”, para criar um menu de contexto que poderá depois ser associado a algum controle .NET existente.

“ContextMenuStrip” é definido no assembly “System.Windows.Forms”, que iremos referenciar como componente do projeto:

NOTA: Usaremos a alias “SWF” apenas para diminuir o esforço de digitação. Isto é um passo “opcional” (mas muito legal ).

Criamos o nosso programa (RIA, On-Line ou Batch), e nele definimos uma variável deste tipo:

Agora temos um objeto “ContextMenuStrip” na tarefa, que representa um menu de contexto vazio. Os itens deste menu devem ser criados através do método “Add” da coleção “Items”, ex:

<var>.Items.Add( “Opção 1”)

<var>.Items.Add( “Opção 2”)

<var>.Items.Add( “Opção 3”)

O uso completo do “ContextMenuStrip” não é o foco neste post. O fato é que ao executar a tarefa, a variável .NET estará nula e a execução das instruções acima resultará em nada.

NOTA: a função uniPaaS “DNExceptionOccurred()” deverá retornar ‘TRUE’LOG, e “DNException()” retornará o objeto “Exception” descritivo da exceção.

Por isso, antes de qualquer uso desta variável deveremos instanciar a sua classe e guardar a referência dentro dela. Como queremos fazer isto uma única vez (nesta tarefa), o local mais apropriado parece ser o Task Prefix:

NOTA #1: “construtores” de classes MS.NET são métodos que possuem o mesmo nome da classe. As classes podem ter mais de um construtor, variando os argumentos, e você seleciona aquele que desejar.

NOTA #2: “DotNet” é uma palavra especial que pode ser usada nas expressões uniPaaS para acessar métodos .NET (ex: construtores e estáticos), não obrigatoriamente associados a uma variável .NET.

Agora sim. Após esta instrução, a variável “v. ContextMenuStrip” contém uma referência a uma instância da classe “ContextMenuStrip”, e poderá ser utilizada normalmente no restante da tarefa/programa.

E quando a memória associada a este objeto será liberada?

Esta decisão pertence ao GC (Garbage Collector) do framework MS.NET, que irá determinar quando aquela instância não é mais necessária e liberar a sua memória associada. Normalmente é após a tarefa/programa uniPaaS finalizar.

(*) O MS.NET também possui os tipos “valor”.

uniPaaS 2.0 – Uma nova era

Manoel Frederico da Silva / Product Manager & MAGIC Evangelist / Magic Software Brasil

O uniPaaS 2.0 está oficialmente lançado. Depois de muita expectativa da comunidade MAGIC, finalmente ele está disponível.

E este é o seu grande novo recurso: runTime .NET

Muitas outras novidades (algumas até já anunciadas) virão nos próximos releases/services packs, mas esta: runTime .NET, já está disponível para todos nós.

Seu motor de execução de aplicações (runTime) que antes era um engine C++, agora é um engine MS.NET.

NOTA: Ainda existe (e permanecerá existindo) o engine C++, para as demais plataformas (não Microsoft Windows) atendidas pelo uniPaaS. E mesmo no novo engine MS.NET, uma pequena parte permanece em C++ para realização de P/Invoke e outras atividades de baixo nível necessárias.

Quando o desenvolvedor abre o Studio do novo uniPaaS 2.0 e se depara com a mesma interface conhecida das versões anteriores:

Ele pode ficar tentado a não “ver” tanta novidade assim.

Mas é um engano.

O novo runTime .NET muda tudo!

É um marco no desenvolvimento de soluções, tanto para quem já é desenvolvedor uniPaaS, quanto para quem é desenvolvedor .NET

 

 

Para quem já é adepto do uniPaaS:

Pare alguns instantes, e imagine o mar de possibilidades que se abriu com a integração nativa MS.NET nas tarefas/programas On-Line e Batch do uniPaaS:

Não se resumindo aos novos (e importantes) recursos visuais que você poderá colocar em suas aplicações, mas se você necessitar trabalhar com comunicações (https, ftp, tcp, snmp, smtp, udp, …), WorkFlow Foundation (WWF), certificados digitais, assinaturas digitais, API do MS-Windows, tudo isso e muito mais está lá no framework MS.NET. E agora está ao alcance de suas aplicações uniPaaS, de uma forma fácil e nativa. Tudo que o uniPaaS tem de bom, agora está multiplicado pelos recursos do MS.NET.

 

 

Para quem já trabalha com o MS.NET:

Os recursos que você já está acostumado a usufruir do framework .NET agora podem ser acessados sem aquele emaranhado de códigos e arquivos. Através da arquitetura ágil, eficiente e code-free do uniPaaS, que privilegia a camada de regras de negócio, abstrai a camada tecnológica, reduz drasticamente o esforço de desenvolvimento e multiplica a eficiência da manutenção e evolução das soluções, a qualidade de suas soluções alcançará um nível até então não imaginado. Tudo que o MS.NET tem de bom, agora está multiplicado pelos recursos do uniPaaS.

 O uniPaaS 2.0 é um marco divisor em tecnologia de desenvolvimento de aplicações, e está ao seu alcance. Não perca a oportunidade.

uniPaaS 2.0 – Primeiras Impressões

Manoel Frederico da Silva / Product Manager & MAGIC Evangelist / Magic Software Brasil

O uniPaaS 2.0 está oficialmente lançado. Todos os usuários da ferramenta podem acessar o site de download, realizar o seu login e baixar esta nova versão.

É importante observar que a licença mudou:

Será necessário solicitar ao seu revendedor uniPaaS o upgrade de licença 1.x para 2.x

Instalação

O processo de instalação não sofreu alterações. Praticamente são os mesmos componentes existentes na versão 1.x (incluindo o SystInet 6.6), e o mesmo fluxo de seleção para executar o instalador:

Contudo, existe agora um pré-requisito a mais: as estações (MS-Windows) onde for instalado o uniPaaS 2.0 necessitam ter também o MS.NET FrameWork 3.5 (ou +). Veja a documentação oficial:

Isso porque agora o uniPaaS 2.0 runTime é uma aplicação 100% (genuinamente) MS.NET. E assim também serão todas as soluções (.ecfs) criadas com o uniPaaS.

Estrutura de Pastas

A estrutura de pastas criada pelo instalador para conter os módulos (arquivos) que compõem a suíte uniPaaS também permanece a mesma, mantendo todo o conjunto uniPaaS centralizado num único local (como sempre foi). Contudo, duas diferenças devem ser observadas:

A primeira é que o uniPaaS 2.0 runTime é um programa extremamente pequeno, e possui um arquivo “.config” associado. Isso se deve ao fato do runTime ser 100% MS.NET.

A segunda é que, por ser um programa MS.NET, ele está subordinado às políticas de segurança do MS.NET. E por padrão, o MS.NET não executa programas (.exe) que estejam localizados em pastas de rede (compartilhadas). Somente se estiverem em pastas locais. Como é costumeiro instalar o uniPaaS em pastas compartilhadas, será necessário executar um utilitário do MS.NET chamado casPol (Code Access Policy), para tornar esta pasta de rede um local confiável para o MS.NET. Veja a documentação oficial:

Interface do Studio (IDE)

A interface do desenvolvedor (uniPaaS Studio) permanece a mesma existente na versão 1.x:

Não haverá absolutamente nenhum esforço de adaptação à interface da nova versão.

Estrutura dos Projetos/Soluções

A estrutura interna dos projetos uniPaaS na versão 2.0 mudou. Isso significa que será preciso executar uma migração do seu projeto 1.x para o 2.x, e que não é possível abrir o mesmo projeto nas duas versões (ex: 1.9 e 2.0). A migração é um processo automático quando você abre um projeto antigo no novo uniPaaS 2.0 Studio. Veja os detalhes em Guia de Migração para o uniPaaS 2.0.

Este documento (.PDF) é muito importante, especialmente porque ele também detalha o que mudou no uniPaaS runTime em relação à versão 1.x, e quais recursos que ficaram postergados para os próximos releases do produto.

Além disso, estes outros links do DevNet também são interessantes:

• Migrando para o uniPaaS 2.0
• Migrando webServices para o uniPaaS 2.0
• O que muda na versão 2.0 do uniPaaS

Novidades

Enfim, o mais legal de qualquer nova versão são os novos recursos. Como dito anteriormente, o uniPaaS 2.0 runTime é uma aplicação 100% (genuinamente) MS.NET e assim também serão todas as soluções (.ecfs) criadas com ele. Toda integração com MS.NET que antes existia apenas nas tarefas RIA (Rich Client), agora estão disponíveis para as tarefas On-Line (interativas) e Batch (não-interativa).

Agora é possível em todo projeto uniPaaS:

1) Vincular assemblies MS.NET como componentes do projeto

2) Criar variáveis .NET vinculadas a objetos do MS.NET FrameWork

3) Colocar controles .NET nas telas da aplicação uniPaaS (que agorasão telas WinForms)

4) Criar handlers para eventos dos objetos MS.NET

5) Invocar código VB ou C# diretamente das tarefas uniPaaS

6) Acessar métodos e propriedades dos objeto .NET diretamente nas expressões

 

Concluindo: sua aplicação pode agora se beneficiar 100% dos recursos existentes na biblioteca MS.NET.

NOTA: é importante ressaltar, que estes novos recursos (MS.NET) não devem ser utilizados em tarefas batch que deverão rodar em outras plataformas (não MicroSoft Windows), como por exemplo Linux, System i, Unix, etc… O runTime uniPaaS continua disponível para todas elas, mas obviamente os recursos .NET só existem na plataforma MS Windows.

Mais Mudanças

Como mencionado anteriormente, este link (O que muda na versão 2.0 do uniPaaS) lista todas as mudanças significativas da versão 2.0, especialmente as relacionadas com a interface interativa (telas) da aplicação.

Estas foram as primeiras impressões. Sempre que houver novidades publicaremos novamente, para mantê-los sempre atualizados.

O uniPaaS 2.0 chegou!

Glenn Johnson – Senior Vice President – Magic Software Americas

A Magic Software lançou ontem uma nova importante versão de nossa plataforma de aplicações. Com base no sucesso das versões anteriores, o uniPaaS 2.0 fornece melhorias-chave para o desenvolvimento BlackBerry, aplicações cliente/servidor com melhor interface, desenvolvimento RIA aprimorado e padronização.

O uniPaaS 2.0 baseia-se em benefícios importantes que você espera da Magic Software, fornecendo uma plataforma de aplicações orientada por metadados, à prova de futuro que combina recursos de um stúdio poderoso para  desenvolvimento com interfaces ricas em padrão .NET  para uma experiência de usuário altamente interativa em uma variedade de clients.

Uma ampla funcionalidade não suportada  anteriormente pelo uniPaaS agora está totalmente incorporada para que os desenvolvedores possam utilizar os controles padrões de mercado em novas aplicações e também nas já existentes. O uniPaaS 2.0 provê uma excelente base para o desenvolvimento futuro para implantações em vários ambientes de dispositivos móveis, RIA, cliente-servidor e baseadas em nuvem.

O novo runtime cliente/servidor utiliza controles da biblioteca Windows Forms. NET para proporcionar uma interface altamente interativa e atraente graficamente para os usuários. A aparência e a usabilidade das aplicações estão aperfeiçoadas com um estilo mais moderno. Devido ao client uniPaaS agora ser baseado em uma camada .NET é fácil para o desenvolvedor chamar qualquer classe. NET, incluindo bibliotecas de terceiros. Você pode obter vantagens de muitas dessas melhorias migrando sua aplicação para uniPaaS 2.0 tanto através de esforço de sua própria equipe de desenvolvimento ou utilizando os serviços profissionais da Magic Software para ajudá-lo em seu esforço de modernização de suas aplicações. Nossos consultores possuem vasta experiência em consultoria e implementação de interfaces de usuário aprimoradas com base em Controles .NET e bibliotecas de terceiros.

Iremos discutir melhorias específicas em nosso próximo post. Deixe a era do uniPaaS 2.0 começar!