.NET CF para Windows Mobile: Smartphone x Pocket PC

O .NET Compact Framework (.NET CF) nos oferece um ambiente de execução, um modelo de desenvolvimento e uma biblioteca de tipos para fácil implementação de aplicativos para dispositivos móveis, tipo Windows Mobile. No entanto, existem diferentes plataformas de dispositivos baseados no Windows Mobile. Cada uma, com suas peculiaridades, torna o desenvolvimento do aplicativo móvel, mesmo que baseado no .NET CF, diferente.

A tabela a seguir apresenta as plataformas suportadas pelo .NET CF (Fonte: MSDN - Devices and Platforms Supported by the .NET Compact Framework)

Dispositivo	Plataforma
Pocket PC	Windows Mobile 2003 for Pocket PC, Windows Mobile 2003 for Pocket PC SE, Windows Mobile 5.0 software for Pocket PC, Windows Mobile 6.0 software for Pocket PC
Smartphone	Windows Mobile 5.0 software for Smartphone, Windows Mobile 6.0 software for Smartphone
Windows CE Embedded	Windows CE 4.2, Windows CE 5.0, Windows Embedded CE 6.0

Pocket PC x Smartphone

O Pocket PC é um computador de mão (Handheld ou PDA - Personal Digital Assistant), focado em aplicações e dados. O Pocket PC costuma ter uma tela maior que um Smartphone, no formato 3x4 de resolução 240x320. Além disso, sua tela é sensível ao toque, sendo o dispositivo operado com as duas mãos.

Já o Smartphone é um dispositivo focado em voz, como os tradicionais celulares, mas que também combina funcionalidades de computadores e PDAs. Dentro das características de um celular, o Smartphone não possui tela sensível ao toque e pode ser operado com uma única mão, através de um teclado numérico, um botão tipo Joystick e as Softkeys.

Biblioteca de tipos do .NET CF

No que se refere à biblioteca de tipos do .NET CF, a base é a mesma para as plataformas baseadas no Pocket PC e no Smartphone. A grande diferença fica por conta do desenvolvimento da UI, onde se percebe:

• O Pocket PC possui um estilo de formulário mais rico, com componentes mais sofisticados, para interação do usuário. No Pocket PC encontramos componentes como Buttons, Checkboxes, Radio Buttons, Tool Bar, Status Bar, entre outros. Alguns sequer fazem sentido no contexto do Smartphone, que não possui tela sensível ao toque.
• A entrada de informações no Pocket PC é feita através do SIP (Soft Input Panel) ou eventualmente através de teclado do hardware.
• No Smartphone, a navegação da aplicação é efetuada através do menu do dispositivo e do uso das Softkeys. A entrada de dados é feita através de teclado numérico, onde é possível utilizar modos de entrada como numérico, alfanumérico e T9.

Links:

• .NET Compact Framework Architecture
• Pocket PC Development and the .NET Compact Framework
• Smartphone Development and the .NET Compact Framework
• Overview of the .NET Compact Framework
• Application Development in the .NET Compact Framework

Conceitos da Orientação a Objetos com UML, parte 5

Neste último post, vamos cobrir alguns conceitos da Orientação a Objetos ainda em aberto.

Interface

Uma interface define um conjunto de comportamentos, e são implementadas por classes e componentes. Ao implementar uma interface, uma classe deve conter definições para todos os métodos definidos na mesma.

Uma interface permite a uma classe participar de uma funcionalidade, sem que outras classes saibam detalhes de sua funcionalidade. A única característica conhecida é que a classe 'suporta' a interface exigida.

Os diagramas a seguir apresentam exemplos de interfaces e suas notações.

Componente

É uma unidade funcional, que pode ser desenvolvida de forma independente e composta com outros componentes, de forma a criar sistemas. Um componente é tipicamente um agrupamento de classes com um propósito comum.

Diagrama de componentes de exemplo, com interfaces exigidas e interfaces expostas.

Padrões de Projeto

Padrões de projeto são conjuntos de soluções de modelagem e/ou implementação, que resolvem problemas conhecidos e consagrados do desenvolvimento de sistemas Orientados a Objetos.

Os padrões de projeto são benéficos ao desenvolvimento de sistemas OO em vários aspectos:

• Trazem soluções aprovadas para problemas do desenvolvimento de sistemas, pois os padrões já foram amplamente discutidos e refinados por especialistas
• Facilitam entendimento e manutenção de sistemas, pois criam um vocabulário comum entre desenvolvedores
• Auxiliam a especificação de arquiteturas de projetos complexos ou com propriedades específicas
• Focam propriedades importantes da Orientação a Objetos, como os conceitos já discutidos nos posts anteriores

Muitas são as referências para padrões de projeto na Internet. Alguns links interessantes:

• Wikipedia - Português
• Wikipedia - Inglês
• Padrões de Projeto em C# e VB.Net

Conceitos da OO nos posts anteriores:

• classe, objeto, atributo, método, instância, classe concreta
• abstração, coesão, acoplamento, encapsulamento, mensagem, polimorfismo, colaboração
• associação, agregação, cardinalidade, composição
• herança, subtipo, supertipo, sobreposição

Você sentiu falta de algum conceito importante neste conjunto de posts sobre Orientação a Objetos? Algum conceito foi abordado de forma insuficiente? Por favor, permita-me tomar conhecimento de sua opinião. Deixe seu comentário.

Programação Orientada a Aspectos

Se ouve falar bastante sobre a Programação Orientada a Aspectos, e os benefícios que ela agrega à Orientação a Objetos.

Na idéia de se tentar entender estes benefícios, precisamos primeiro entender os efeitos colaterais que encontramos na Orientação a Objetos.

• Espalhamento de funcionalidades, que ocorre tipicamente através da implementação de interesses "transversais", alheios às características dos objetos. Estes interesses transversais costumam estar relacionados com requisitos não funcionais do sistema. Exemplos: Log de auditoria, acesso a banco de dados e validações de segurança.
• Entrelaçamento de funcionalidades, que se refere à implementação de diferentes responsabilidades em um mesmo trecho de código ou classe.

Estas características acabam comprometendo vários conceitos importantes da Orientação a Objetos, como a Coesão e o baixo acoplamento.

Alternativas para lidar com estes efeitos colaterais:

• Padrões de Projeto
• Programação Orientada a Aspectos (POA)

Motivação da POA:

Separação de interesses (Separation of Concerns), segundo sua importância ou responsabilidade no sistema. Assim, o programador pode separar funcionalidades secundárias em módulos distintos do sistema.

Características da POA:

Prós:
Fica por conta da motivação central da POA, a separação de interesses.

Contras:
A grande queixa da POA fica por conta da depuração de código, que é mais complicada. Isto porque em tempo de codificação os códigos estão separados por interesses, mas em tempo de execução estes elementos estão juntos.

Ferramentas de POA para .NET:

Para os interessados, existem diversos frameworks de POA, inclusive open-source, para uso com o .NET Framework. Algumas referências:

• PostSharp
• Referências em CSharp-Source.net.

Conceitos da Orientação a Objetos com UML, parte 4

Este quarto post tem como objetivo discutir os conceitos associados ao mecanismo de herança da Orientação a Objetos. A herança é um dos recursos mais poderosos da OO quando falamos de "reuso" de código. Porém esta deve ser utilizada com muita cautela, pois muitas vezes é aplicada de forma desnecessária e leva muitas modelagens ao fracasso.

Herança

A herança é o mecanismo da OO que permite que compartilhemos atributos e métodos entre classes, quando detectamos similaridades entre estas. A herança modela relações como "Classe A é do tipo de Classe B" e "Classe A é como Classe B".

Neste primeiro exemplo vemos o uso de classes com características comuns, porém a herança não é aplicada.

Podemos ver claramente a duplicação de conceitos. Entre estas duplicações, temos as relações das classes semelhantes (Contas Corrente e Poupança) com as classes Pessoa e Transacao, além do atributo saldo, e sua respectiva propriedade.

É fácil percebermos que Conta Corrente e Conta Poupança são tipos de contas bancárias. Aplicando o mecanismo de reuso através da herança, podemos chegar ao seguinte modelo:

Perceba que os elementos duplicados não mais existem nesse modelo. As características comuns estão concentradas na classe abstrata Conta Bancaria. Uma vez que estes elementos comuns são agrupados em uma única classe, futuras adaptações ou correções do sistema ficarão mais fáceis (visto que estas não precisarão ser replicadas).

Supertipo: Refere-se à classe superior na relação de herança (no exemplo, a classe Conta Bancaria)

Subtipo: Refere-se à classe especializada na relação de herança (no exemplo, as classes Conta Corrente e Conta Poupança)

Sobreposição: A sobreposição refere-se à redefinição de métodos na hierarquia da herança, de forma que estes métodos implementam definições diferentes (mais especializadas) nos subtipos

Conceitos da OO nos posts anteriores:

• classe, objeto, atributo, método, instância, classe concreta
• abstração, coesão, acoplamento, encapsulamento, mensagem, polimorfismo, colaboração
• associação, agregação, cardinalidade, composição

Nos próximos posts, ainda serão tratados:

• componente, interface, padrões de projeto

Conceitos da Orientação a Objetos com UML, parte 3

Neste terceiro post, iremos explorar os relacionamentos entre objetos e classes.

Associação

A associação é um relacionamento entre classes ou objetos. As associações são modeladas com base nas relações reais dos objetos e identificam quais objetos se comunicam entre si.

O diagrama a seguir apresenta uma associação entre duas classes.

Uma associação possui uma série de ítens de modelagem, entre eles:

• Rótulo: Texto de poucas palavras (em geral uma ou duas) que descreve a associação
• Direção: Uma ou duas setas que indicam o sentido de navegação. Uma única seta indica uma associação unidirecional. Duas setas (ou a omissão de ambas) indicam uma associação bidirecional
• Cardinalidade: Indicada nas extremidades da associação, informa as multiplicidades da relação. Opções:

  0..1 - zero ou um (relação opcional)
  1  - apenas um (relação obrigatória)
  0..* - zero ou mais
  1..* - um ou mais
  n  - apenas n
  0..n - zero a n
  1..n - 1 a n
  

Agregação

A agregação é uma relação entre classes ou objetos, onde um é classificado como "parte" de outro. Ela representa uma relação onde um objeto é feito de outros objetos.

O diagrama a seguir apresenta uma relação de agregação.

Composição

É um tipo especial de agregação, mais forte, onde um objeto é totalmente responsável por suas partes. Além disso, uma "parte" pertence a apenas um objeto agregador.

Diagrama com exemplo de composição:

Conceitos da OO nos posts anteriores:

• classe, objeto, atributo, método, instância, classe concreta
• abstração, coesão, acoplamento, encapsulamento, mensagem, polimorfismo, colaboração

Nos próximos posts, ainda serão tratados:

• herança, subtipo, supertipo, sobreposição
• componente, interface, padrões de projeto

Desenvolvimento J2ME para celulares

Entre os grandes desafios do momento na Mobiltec estão alguns projetos específicos para desenvolvimento mobile. Entre os dispositivos móveis "alvo" dos projetos, temos os celulares convencionais e dispositivos Blackberry da RIM.

Uma pouco de pesquisa na internet nos leva a um ponto em comum: A Plataforma JavaME.

E junto, dois novos conceitos são introduzidos:

• Connected Limited Device Configuration (CLDC): É a especificação do conjunto de interfaces e da máquina virtual Java para dispositivos móveis limitados em recursos
• Mobile Information Device Profile (MIDP): É um perfil do JavaME, baseado no CLDC. É o ambiente JavaME mais popular hoje encontrado em celulares

Para desenvolvimento JaveME, é necessário o J2ME Wireless Toolkit, combinado com uma IDE Java para desenvolvimento (como Eclipse ou Netbeans).

Após a pesquisa inicial, um pouco de ambientação... Montamos o Eclipse com seu plug-in para JavaME, o EclipseME. A equipe desenvolveu alguns exemplos de MIDLet (aplicativo JavaME).

Próxima visita, site do Blackberry Developer Program. Lá encontramos o BlackBerry JDE. Segundo o site:

"The BlackBerry® Java® Development Environment (BlackBerry JDE) is a fully integrated development environment and simulation tool for building Java Micro Edition (Java ME™) applications for Java ® based BlackBerry® smartphones. It is a Mobile Information Device Profile (MIDP) compliant Java ME environment for developers who wish to maintain seamless portability in their wireless applications."

Ambiente instalado, e a surpresa: Uma série de pacotes específicos do Blackberry (net.rim.*), que me levam a desconfiar que os ambientes são incompatíveis e que os MIDLets de exemplo construídos anteriormente não funcionarão no Blackberry. Ou estes pacotes seriam apenas um novo conjunto de recursos?

Onde fica o "JavaME compliant"?

  [Ver post Compatibilidade da JVM do Blackberry com J2ME]

Outra preocupação fica na parte do "visual" dos aplicativos, que parece limitadíssimo. Tudo bem que estamos falando de "Limited Device Configuration", mas os componentes visuais já embutidos são extremamente simples.

E a aventura está apenas começando...

Conceitos da Orientação a Objetos com UML, parte 2

Segue mais um conjunto de conceitos da orientação a objetos. Embora o título do post cite a UML, esta segunda parte não apresenta diagramas da mesma. Isto pelo fato de que neste post são tratadas características mais conceituais da Orientação a Objetos.

Abstração

É a ação de pensarmos nas características essenciais de um objeto, sem nos preocuparmos como ele atinge estes objetivos. A abstração nos permite lidar mais facilmente com a complexidade de um sistema, pois em etapas iniciais da concepção do mesmo, ainda não dispomos de conhecimento suficiente para determinar os detalhes de cada objeto.

Dentro do conceito de abstração, definimos o que um objeto é capaz de fazer e o que a classe 'sabe'. Isso inclui atributos e métodos de interesse. O resto é postergado.

Coesão

A coesão refere-se à relação da implementação de uma classe ou método, com o seu propósito.

Classe e métodos altamente coesos são aqueles que implementam exatamente as suas responsabilidades. Quanto mais uma classe ou método implementa lógicas e controles que não são de sua responsabilidade, mais baixa é a sua coesão.

Caso não tomemos os devidos cuidados, a medida que um sistema é implementado a coesão das classes e métodos tente a diminuir, onde o ideal seria manter uma alta coesão.

Para lidarmos com este problema, é essencial um bom 'design' da estrutura do nosso sistema. Padrões de projeto são excelentes recursos para estruturarmos classes e métodos e eles nos ajudam a priorizar uma série de aspectos da OO, inclusive a alta coesão.

Acoplamento

O acoplamento está diretamente relacionado à dependência entre duas classes. O acoplamento é alto quando uma classe depende da implementação de outra (isto é, acessa os atributos da outra classe diretamente). Quando uma classe sabe interagir com outra sem conhecimento dos detalhes de implementação da segunda (apenas interagindo com esta através de métodos), então esta relação é de baixo acoplamento.

Encapsulamento

Refere-se a idéia de agrupar os conceitos de um determinado objeto dentro dele mesmo. Os métodos e atributos que conceitualmente pertencem a um objeto são compartimentados dentro da especificação da classe que o define.

O encapsulamento nos permite redefinir a implementação interna de uma classe, sem afetar outras classes e componentes do sistema, pois a utilização de um objeto não depende de sua implementação, mas sim de sua interface.

Mensagem

A mensagem é uma requisição de um objeto a outro, seja para obter uma informação ou para executar uma atividade. Uma mensagem é composta pelo nome de um método e lista de parâmetros.

Polimorfismo

É a habilidade de diferentes objetos responderem a uma mesma mensagem de forma distinta. Com o polimorfismo, é possível tratarmos instâncias de várias classes de uma forma comum. Assim, um objeto pode enviar uma mensagem a outro sem saber exatamente o seu tipo, e este segundo irá trabalhar corretamente.

Colaboração

É uma característica natural da OO, onde as classes trabalham em conjunto para realizar suas atividades

Conceitos da OO nos posts anteriores:

• classe, objeto, atributo, método, instância, classe concreta

Nos próximos posts, ainda serão tratados:

• associação, agregação, cardinalidade, composição
• herança, subtipo, supertipo, sobreposição
• componente, interface, padrões de projeto

Conceitos da Orientação a Objetos com UML, parte 1

Em uma série de posts, estarei cobrindo os principais conceitos da Orientação a Objetos. Além disso, irei apresentar estes conceitos através de pequenos diagramas da UML.

Classes e objetos

A classe é a abstração de um objeto. Ela define a estrutura de atributos e métodos dos objetos que são criados a partir dela.

O objeto, por sua vez, é o elemento que representa um conceito do mundo real. O objeto é capaz de realizar ações típicas do elemento que ele representa.

Instância: É um objeto de uma determinada classe. Ao processo de criação de um objeto, dá-se o nome de instanciação.

Classe concreta: Classe da qual podemos criar instâncias

Classe abstrata: Classe da qual não podemos criar instâncias

Atributos e métodos

Atributos são dados que determinam o estado de um objeto. Os métodos, por outro lado, são funções que determinam o comportamento do objeto.

Os métodos podem executar atividades que modifiquem o estado (atributos) do próprio objeto, ou que apenas computem um valor significativo retornado ao invocador dos mesmos.

Abaixo, diagrama de classes ilustrando métodos, atributos e relações. Na notação da UML, o primeiro quadro de uma classe exibe o nome da mesma. Os dois quadros opcionais abaixo deste exibem os atribudos e métodos da classe.

O próximo diagrama é um exemplo de diagrama de objetos. Cada objeto representando uma entidade real, instanciada no sistema. Atributos já podem se encontrar valorados.

Nos próximos posts, estarei apresentando outros conceitos da OO, como:

• abstração, coesão, acoplamento, encapsulamento, mensagem, polimorfismo, colaboração
• associação, agregação, cardinalidade, composição
• herança, subtipo, supertipo, sobreposição
• componente, interface, padrões de projeto