# Programação de Dispositivos Móveis

# Teórica 1
## Definição de Dispositivo Móvel

* Um **dispositivo móvel** (handheld) é um aparelho eletrónico com as seguintes características:

1. **Computação:** capacidade de processar e armazenar dados;
2. **Interatividade com Utilizador:** possui dispositivos de entrada e saída de dados embutidos (ecrã, teclado, etc) que são usados para interagir com um utilizador. Dispositivos que não permitem a interatividade com um utilizador não são considerados dispositivos móveis;
3. **Portabilidade:** são sobretudo definidos pela sua capacidade de serem movidos com frequência e facilidade. Qualquer dispositivo móvel deve funcionar consistentemente quer em repouso quer em movimento, independentemente da proximidade a uma fonte de alimentação ou ligação física à Internet (possuem baterias recarregáveis);
4. **Dimensões e peso:** algumas definições de dispositivos móveis ditam que apenas os dispositivos que podem ser utilizados com uma só mão é que devem ser considerados móveis (componentes eletrónicos com maior grau de miniaturização);
5. **Comunicações sem fios:** possuem normalmente tecnologia que permite a comunicação com outros dispositivos semelhantes, computadores e sistemas, com redes de computadores ou de telecomunicações, ou com telefones portáteis. Estes dispositivos, atualmente, são capazes de acederem à Internet através de redes bluetooth e Wi-Fi.

## Razões para trabalhar na plataforma Android

* São 4 as razões que justificam a colocação de algum foco no desenvolvimento de aplicações para a plataforma Android:

* Em 1º lugar --> a plataforma Android **é gratuita**, e é simples encontrar ferramentas também gratuitas e prontamente disponíveis para desenvolvimento de aplicações.
* Em 2º lugar --> esta é atualmente a plataforma que **domina o mercado global** em termos de smartphones e tablets;
* Em 3º lugar --> esta **linguagem de programação é a mais utilizada hoje em dia**, seguida de C e de C++;
* Em 4º lugar --> a **enorme fragmentação**, quer em termos de versões de SO, quer em termos de hardware e das suas especificações, fazem do Android a plataforma ideal para ganhar alguma destreza com a programação para dispositivos móveis.

# Teórica 2

## Desenvolvimento de Interfaces de Utilizador

* Uma **Interface de Utilizador** um programa de computador,ou parte dele, que permite que o utilizador comunique com esse computador ou com outras partes do programa;

### Programas Sequênciais

* são os programas que controlam o fluxo de interação de uma forma bastante rígida. Os utilizadores esperam que o programa peça inputs para aí interagirem com o mesmo (controlo interno);

* **Pontos Positivos:**
* Funcionam sempre em linha de comandos;
* Aguentam todas as funções que quiserem (à custa de variáveis e de uma estratificação em árvore e divisão em modos).

* **Pontos Negativos:**
* Pouco intuitivos;
* Dificuldade em captar ações do utilizador fora do comportamento comum do progranma
* Funções disponíveis só após mudança de modo;
* Quem controla a interação é o programa.

### Interfaces de Utilizador Orientadas por Eventos

* Este modelo, utilizado na maior parte das aplicações móveis modernas, **permite disponibilizar um conjunto maior de funcionalidades em simultâneo e de forma intuitiva**, correspondendo ainda a uma simplificação na estrutura do programa. Neste caso, é o programa que espera pelo utilizador (controlo externo), nomeadamente que este lhe forneça um dos possíveis inputs.

* A **manipulação** destas interfaces pode ser **feita de forma direta**, um **evento** corresponde a uma ação ou ocorrência que um programa foi capaz de detetar e tratar, depende do tipo de acontecimento, por ex:
* clique de um dos botões do rato;
* a posição do cursor ou tecla pressionada;
* o programa ao qual se destina o evento, entre outros.

* **A rotina principal de captação de eventos é da responsabilidade do Sistema Operativo** (SO), que a executa constantemente e **coleciona os eventos numa pilha First In First Out** (FIFO), assegurando que estes são tratados pela ordem que chegaram;

* Na programação orientada por eventos, **um programa pode entrar no estado de sleep quando não existem eventos**, pelo que o SO pode atribuir tempo de processamento a outros programas;

* A programação baseada por eventos é feita recorrendo ao modelo de delegação de eventos, baseado nas entidades **Controlos**, **Consumidores** e **Interfaces**:
1. **Os Controlos** (widgets) serão a fonte do evento (ex: botão);
2. **Os Consumidores** (Listeners) correspondem às rotinas de tratamento desses eventos;
3. **As Interface** são a forma normalizada de comunicação entre os controlos e os consumidores.

* Aquando da implementação, o programador tem de definir os controlos e registar o conjunto de eventos que deseja escutar para cada um deles, bem como implementar a interface do evento que pretende escutar;

* A captura e reencaminhamento dos eventos é feito de forma transparente para o programador, que não precisa de se preocupar com esses detalhes;

* A programação orientada por eventos assenta em vários pressupostos:

1. A **interface gráfica é composta por vários objetos interativos** e elementos cuja localização é conhecida, e que podem ser **estruturados hierarquicamente em árvore** (MAIS IMPORTANTE);

2. A **profundidade desta hierarquia não costuma ser superior a 5 ou 6 níveis**, caso contrário também se torna difícil de gerir e desenhar, para além de **afetar negativamente a performance da mesma**.

* O comportamento das aplicações cuja programação é orientada por eventos é inteiramente definido pelas rotinas de tratamento desses eventos. Em termos de programação, são essas rotinas que definem grande parte do fluxo, lógica e funcionalidades das aplicações. O desenvolvimento da aplicação pode começar pelo planeamento da interface de utilizador e evoluir para a implementação das rotinas de tratamento;

* Existem dois tipos genéricos de elementos úteis para o desenho de interfaces de utilizador orientadas por eventos:

1. Objetos interativos de entrada ou saída;

2. Contentores: são elementos que podem conter outros contentores ou objetos interativos (botões ou caixas de texto) e permitem organizar o aspeto gráfico da aplicação.

* **Eventos mais comuns usados para construir aplicações móveis:**
1. **Botões** de pressão com rato, toque ou caneta: podem gerar eventos de clicados, premidos ou libertados e duplamente clicados;
2. **Teclado:** pode gerar eventos de tecla premida ou libertada;
3. **Movimentação do rato ou cursor:** pode gerar eventos de entrada e saída de regiões;
4. **Os controlos das janelas ou da aplicação:** podem gerar eventos de fecho, minimização, redimensionamento, etc.

* **Os objetos interativos têm acesso aos métodos de outros objetos no mesmo nível hierárquico** ou acima;

* **A comunicação entre objetos interativos pode ser feita de 3 formas:**
1. **Manipulação direta de propriedades de outros objetos**;
2. **Avisando o elemento imediatamente acima na hierarquia** acerca das alterações a fazer, sendo que este terá acesso a outros elementos do mesmo grau hierárquico;
3. **Gerando outros eventos** que são capturados e tratados pelas rotinas dos consumidores registadas pelo objeto interativo destino.

* **Fonte -->** é o objeto interativo onde o evento é gerado.

## Modelo - Visão - Controlador

* A arquitetura padrão para Aplicações Móveis é o **Modelo-Visão-Controlador** (MVC);

* A **arquitetura Modelo-Visão-Controlador é um modelo de arquitetura para desenvolvimento de software que separa a lógica da aplicação, a representação da informação e a interação do utilizador** através de 3 componentes:
1. O **modelo**;
2. A **visão**;
3. O **controlador**.

* A arquitetura **MVC** é muito popular na indústria de desenvolvimento de Aplicações Web e Móveis. Tem como **objetivos**:

* favorecer a sua escalabilidade e manutenção;
* o a portabilidade e a reutilização de código;
* permitir um maior grau de abstração por parte de cada um dos elementos da equipa de implementação e desenho.

* Implementar esta arquitetura significa normalmente dividir o projeto de uma aplicação em vários ficheiros e pastas, cada um afeto a uma destas partes:
1. Esquema de dados, e acesso e manipulação desses dados(SQL+PHP);
2. Aspeto visual da aplicação (HTML+CSS);
3. Código que liga o aspeto visual aos dados (Javascript, PHP).

### Modelo

* O Modelo é o componente central do MVC;

* Encapsula o estado interno e consiste na implementação dos objetos, métodos ou rotinas que capturam o **comportamento base da aplicação**;

* O Modelo **processa os dados ou muda o seu estado**;

* **Só** pode interagir com o componente Controlador, sendo completamente independente da interface do utilizador;

* É o Modelo que contém as classes e métodos para **aceder e manipular bases de dados** ou memória persistente, assim como toda a informação que pode ser exibida ao utilizador através de uma visão;

* No MVC, **um utilizador nunca interage diretamente com o Modelo**;

* A implementação das classes pertencentes ao Modelo da aplicação devem ser o **menos específicas possível em relação à representação dos dados**, para favorecer a **portabilidade** do código;

* A sua **interface de programação deve ser clara e consistente** ao longo do período de vida da aplicação (já que isso garante que o controlador pode comunicar corretamente com o modelo).

### Visão

* No MVC, uma Visão consiste numa possível representação dos dados da aplicação;

* É na Visão que se **definem as Interfaces de Utilizador**;

* **importante separar este componente da lógica aplicacional porque podem existir várias representações para o mesmo conjunto de dados**, por um lado, permite que a equipa de desenvolvimento seja dividida pelas várias áreas, por outro, permite que a **interface do utilizador possa ser desenvolvida em paralelo e melhorada ao longo do tempo**;

* A separação entre Modelo e Visão é crucial em aplicações Web;

* No caso das aplicações móveis, essa separação também acontece de forma vincada. Na **plataforma Android**, por ex., é permitido que **a interface do utilizador seja definida em ficheiros XML** completamente independentes do código da aplicação escrito em Java.

### Controlador

* O Controlador é o intermediário entre o Modelo, as Visões e o utlizador;

* É possível encontrar referências em que se define o Controlador como intermediário dos outros dois componentes e não do utilizador, sendo que este interage apenas com a Visão, onde são gerados os eventos;

* Apesar dos eventos poderem ser gerados sobre objetos da Visão, **é no Controlador que estão as rotinas de captura e reencaminhamento desses eventos**;

* **São procedimentos do Controlador que atualizam os objetos da Visão e que despoletam mudanças no estado da aplicação através do envio de eventos para o Modelo**;

* O Controlador tem a responsabilidade de coordenar as tarefas de uma aplicação ou a gestão do ciclo de vida de objetos;

* As **rotinas de tratamento de eventos** incluem-se no Controlador. Estas rotinas invocam métodos do Modelo, que são os que melhor sabem manipular os dados.

### Comunicação entre Componentes

1. **O utilizador interage com a aplicação através de uma ou mais Visões e do Controlador**;
* As Visões mostram a informação do Modelo ao utilizador, que interage com a interface para manipular essa informação.
2. Essa **interação gera eventos**, capturados pelo Controlador, que os processa e envia para as rotinas de tratamento definidas no Modelo;
3. O **Controlador pode imediatamente atualizar uma ou mais Visões aquando da receção de um evento**;
4. **Não existe comunicação direta entre o Modelo e as Visões**, qualquer alteração que precise ser refletida na interface tem de ser comunicada ao Controlador. A **notificação contém os dados do Modelo necessários à alteração**.