Quarta-feira, 23 de Março de 2011
Frameworks

 Depois de explorar as diferentes frameworks, partímos para a experimentação com as mesmas. Eis alguns resultados já obtidos:

 

Titanium Appcelerator:

A utilização desta framework acaba por não ser possível já que apenas permite a versão 1.6 do SDK de Android. Visto que esta já vai em 3.0, o download de uma versão mais antiga é bastante dificuldado e injustificado.

 

Sencha:

A instalação desta é relativamente simples: copiar a pasta da mesma para o WAMP, e aceder aos ficheiros de exemplo via URL (localhost). No entanto, a exportação dos ficheiros para Android é relativamente dificuldada já que não encontrámos documentação explícita o suficiente para o efeito.

 

Corona SDK:

Apesar da descrição da Framework indicar que esta utiliza JavaScript, exportando-o posteriormente para Android, deparámo-nos com uma framework que ao invés de javascript, exporta Ruby para JavaScript, pelo que não se ajusta aos nossos interesses.

 

PhoneGap:

Para a utilização do PhoneGap é necessária a instalação de vários softwares: Java JDK, Android SDK, Eclipse, ADT. Após a instalação de todos estes componentes, procedemos ao teste desta framework. Embora o tutorial encontrado online seja bastante explícito e tendo seguido todos os passos indicados, o emulador de Android (ADT) acaba por não interpretar o código HTML e não executa qualquer código por nós inserido. Acaba por ser uma framework acessível mas que não conseguímos ainda utilizar.

 

 

Para já, continuamos portanto sem opções viáveis para a implementação da vertente híbrida (online e offline) de uma aplicação nativa Android.




Terça-feira, 22 de Março de 2011
Sessão de orientação 22.03.11 - Demos gráfica e técnica

Hoje na sessão de orientação, colocámos aos professores a questão de desenvolvermos apenas a versão on-line da aplicação, uma vez que do ponto de vista do utilizador faz mais sentido, pois uma versão off-line em que o utilizador tem que descarregar a aplicação e os conteúdos para o telemóvel limita muito os conteúdos que pode visualizar devido ao seu espaço em disco. Esta opção do grupo tem a ver, também, com a complexidade das aprendizagens necessárias à realização do projecto e ao pouco tempo de desenvolvimento disponível, isto porque, na pesquisa que temos vindo a realizar encontramos muitas ferramentas (frameworks, APIs…) de ajuda para desenvolvimento de aplicações com acesso à rede, sendo que para aplicações off-line há muito pouca informação e no âmbito do projecto pensamos que nos podemos concentrar numa versão apenas.

Os orientadores recomendaram que começássemos o desenvolvimento da aplicação em versão on-line, já que esta, por ser menos complexa dá maior hipótese de apresentar um trabalho final mais completo, ao mesmo tempo, isto não significa que vamos deixar a versão off-line de parte, continua a ser um desafio para a equipa conseguir concretizar as duas versões do projecto, sendo que a realização das duas versões seria o ideal.

   Outro dos aspectos tratados, foi não esquecer as opções da funcionalidade da aplicação com e sem rede. Abrangendo assim o maior número de possibilidades existentes dentro da investigação.  

   Foi esclarecido também que não vai ser preciso limitar a planificação tecnológica do sistema de transmissão de dados, devido ao hardware e o seu custo para os responsáveis pelos POIs (antenas, servidores, dispositivos de transmissão por bluetooth etc.), pois a estratégia de custos tem a ver com o utilizador e a utilização gratuita que possa fazer da aplicação. Devemos, então, focalizar o estudo nas diferentes soluções possíveis e escolher as que sejam melhores para a implementação prática qualitativa e efectiva do nosso projecto.

As demos gráfica e técnica, vão ser realizadas separadamente. O professor Raposo recomendou o uso do Balsamiq (http://balsamiq.com/products/mockups) para fazer os mockups da demo gráfica. Na demo técnica é importante mostrar a funcionalidade ligada à visualização de conteúdos: o utilizador aponta a câmara para o QRcode correspondente e visualiza os conteúdos multimédia.

 



publicado por eduardojose às 21:08
editado por mariajcampos em 23/03/2011 às 11:46
link do post | comentar | adicionar aos favoritos

Demos gráfica e técnica – aula 21.03.11

 

Na aula de hoje o professor definiu o que se pretende com as demos gráfica e técnica, de baixa fidelidade.
 
A demo gráfica vai consistir num esboço da organização dos conteúdos da nossa aplicação, definindo como é que o utilizador vai ver os conteúdos, qual a sua organização ao utilizar a aplicação e como é feita a navegação entre os vários ecrãs. Neste momento ainda não vamos entrar no estudo gráfico da imagem da aplicação em si (logótipo, esquema de cores, desenho dos ícones, etc.), querendo apenas definir como os conteúdos vão estar dispostos nos diversos ecrãs.
 
Para a demo técnica vamos escolher uma ou duas funcionalidades essenciais da nossa aplicação e vamos implementar o seu funcionamento, ainda que de uma forma simplificada. O objectivo é demonstrar que as tecnologias que escolhemos são viáveis para implementação.
 
Nesta aula começaram a surgir algumas questões ligadas ao desenvolvimento da aplicação, nomeadamente à implementação da parte off-line, para sítios onde não haja cobertura de rede. O grupo discutiu a situação entre si e pôs a questão ao docente sobre a possibilidade de a aplicação ficar apenas disponível através de Wi-Fi ou 3G, com a qual o docente concordou mediante a aprovação dos orientadores. Amanhã na sessão de orientação esta vai ser uma questão chave.



Quinta-feira, 17 de Março de 2011
Entrega do módulo TP2 (3/3)

 

Justificação das Escolhas Técnicas
 
 
O asterisco (*) serve para assinalar opções que ainda não temos a certeza de serem necessárias ou possíveis de implementar, uma vez que estamos a trabalhar numa área completamente diferente do que desenvolvemos até agora no plano curricular da licenciatura de Novas Tecnologias da Comunicação. Embora este desafio seja aliciante é também complexo do ponto de vista das aprendizagens necessárias para a implementação da aplicação que vamos desenvolver, há muitos factores tecnológicos e técnicas que enunciámos que só quando forem postos em prática é que vai ser possível verificar a sua utilidade e exequibilidade. No caso de eventuais alterações a estas tecnologias aqui enunciadas, as rectificações serão feitas oportunamente, tanto nos posts do blog sobre as aulas de desenvolvimento como nas entregas que impliquem tais justificações.
 
As restantes escolhas têm a ver com características intrínsecas do próprio telemóvel, como é o caso do sistema operativo e do hardware no client-side.
As linguagens de programação foram escolhidas devido á familiaridade que temos com as mesmas e porque encontrámos frameworks que aparentemente nos vão facilitar o processo de transição para a linguagem nativa de Android.
 
Em geral e como conclusão, as nossas escolhas foram em muito influenciadas pelo levantamento da arte feito no módulo anterior e pelos testes efectuados num telemóvel com sistema operativo Android, daí julgamos ter optado pelas melhores soluções enquadradas no projecto que queremos desenvolver, respeitando as condições e recursos afectos ao seu desenvolvimento, enunciados no briefing da primeira entrega.

 

 

 




Entrega do módulo TP2 (2/3)
Estudo da Viabilidade Técnica
 
 
 
 
Server-side
 
·         Hardware
 
o   Servidor é essencial para o desenvolvimento da aplicação.
 
Forças:
- Facilidade de manutenção.
- Segurança elevada.
- Facilidade em gerir as permissões dos utilizadores.
- Capacidade de armazenamento e processamento elevadas.
 
Fraquezas:
- É necessário acesso à rede.
- Com o acesso de muitos clientes ao mesmo tempo pode entrar em sobrecarga.
- Pode implicar custos adicionais.
 
Fontes consultadas e datas de consulta:
http://elderstroparo.blogspot.com/2010/05/cliente-servidor-vantagens-e.html(17/03/11);
http://infiltrados-ufs.blogspot.com/2008/05/tipos-de-redes.html (17/03/11);
 
 
·         Software
É necessário que no servidor esteja instalado um sistema operativo que permita a instalação de MySQL e Apache. Para isto, existem duas soluções mais viáveis: Windows e Linux. Em baixo encontram-se listadas as forças e fraquezas destes softwares.
 
o   Windows é o sistema que a maioria dos elementos do grupo tem instalado nos seus computadores.
 
Forças:
- Mais conhecido pelo público geral.
- É o software mais desenvolvido.
- É mais fácil de utilizar.
- Sistema de referência utilizado pela maior parte dos fabricantes de computadores.
 
Fraquezas:
- Código fechado.
- Custo elevado.
- Maior susceptibilidade ao ataque de vírus.
- É o sistema operativo mais instável.
- A maior parte do software para este sistema é pago.
 
o   Linux outro sistema operativo a ter em conta para o desenvolvimento da aplicação.
 
Forças:
- Código aberto.
- Maior protecção contra o ataque de vírus.
- Existe uma grande quantidade de software livre para este sistema.
- Maior estabilidade, inclusivamente para o trabalho com servidores.
- Maior rapidez quando empregado para servidores.
- Não precisa de um software poderoso para ter uma boa performance.
- É grátis (ou pagamento opcional).
- Vulnerabilidades, falhas, erros e bugs corrigidos mais rapidamente.
 
Fraquezas:
- Menos conhecido pelo público em geral;
- A configuração inicial pode ser mais complicada;
- Alguns dispositivos de última geração não estão suportados;
- Não trabalha muito bem com ASP (Active Server Pages);
- Não pode executar MS SQL Server ou MS Exchange;
 - Não compatível com sistemas Windows ou partições NTFS;
 
o   Apache para que os ficheiros hospedados no servidor possam ser acedidos por outros utilizadores via internet, é necessária a instalação do Apache.
 
Forças:
- O download é livre e open-source.
- É suporte em mais de 54,68% de todos os sites.
- Funciona em diversos sistemas operativos (Windows, Novell Netware, OS/2, Unix, Linux, FreeBSD, etc).
- É flexível e consegue adquirir novas funcionalidades através da capacidade que tem de se combinar com outros tipos de softwares baseados em programação modular, suportando assim vários tipos de linguagens como Perl, Python, Tcl e PHP.
 
Fraquezas:
- O seu interface de linha de comandos pode ser uma limitação para os utilizadores.
- O suporte técnico concedido por newsgroups pode não ser o mais adequado para a maior parte dos utilizadores
 
o   MySQL é o sistema de base de dados que vamos utilizar pois permite a exportação dos dados para XML (que por sua vez irá ser alojado localmente, no dispositivo móvel do utilizador).
 
Forças:
- Um dos sistemas de bases de dados mais utilizados do mundo.
- Facilidade de integração com o PHP.
- Não necessita de grandes recursos de hardware.
- É compatível com várias linguagens de programação como Delphi, Java, C/C++, C#, Visual Basic, Python, Perl, PHP, ASP e Ruby.
- Sistema estável e de uso simplista.
- Funciona em inúmeras plataformas.
- Facilita a iniciação de novos utilizadores.
 
Fraquezas:
- É necessário comprar uma licença em caso de utilização para fins comerciais.
 
Fontes consultadas e datas de consulta:
http://pt.wikipedia.org/wiki/Servidor_Apache(17/03/11);
http://www.ehow.com/list_6499181_strengths-weaknesses-apache-server_.html (17/03/11);
http://pt.wikipedia.org/wiki/MySQL (17/03/11);
http://www.mysql.com/ (17/03/11);
http://www.philadelphia.edu.jo/courses/PHP/PHP%20Power%20Programming.page178.pdf(17/03/11);
http://www.kirupa.com/web/mysql_xml_php.htm (17/03/11);
http://cindhy.wordpress.com/2008/05/28/19/ (17/03/11);
http://es.scribd.com/doc/8566493/Ventajas-e-Inconvenientes-de-Linux-y-Windows (17/03/11);
http://anotherfreakintheworld.blogspot.com/2008/11/ventajas-e-inconvenientes-i-windows-xp.html (17/03/11);
http://www.linux.com/ (17/03/11);
http://en.wikipedia.org/wiki/Windows_Server_2003 (17/03/11);
http://en.wikipedia.org/wiki/Linux (17/03/11);
http://www.microsoft.com/windows/ (17/03/11);

 

 
·         APIs
 
o   ZXing* (Zebra Crossing) é uma biblioteca de código open-source para processamento de códigos de barras 1D ou 2D que suporta a descodificação do código QR.
 
Forças:
- É a biblioteca de leitura de códigos QR mais utilizada para desenvolvimento de projectos em Android.
- Biblioteca open-source.
 
Fraquezas:
- Apesar de ser de fácil implementação, os conhecimentos limitados de Objective C podem revelar-se como um entrave.
 
Fontes consultadas e datas de consulta:
http://www.androidpt.com/ (14, 15/03/11);
 
 
·         Linguagens
As linguagens estão representadas no server-side, assim como as frameworks, mas vão-se reflectir também no client-side.
 
o   HTML, CSS, JavaScript, PHP, Ajax
 
Forças:
- Linguagens já aprendidas e dominadas pelos membros do grupo, o que torna todo o processo de desenvolvimento da aplicação maisfluido e rápido.
- São linguagens universais, facilitando o processo de problem solving.
 
Fraquezas:
- Não são linguagens nativas da Android, para utilizar estas tecnologias, é necessário encontrar frameworks que permitam a sua utilização, posteriormente exportando-as para Objective C de maneira a poderem ser interpretadas nos dispositivos móveis desejados.
- Visto que não se trabalha directamente na linguagem nativa de Android, a integração de APIs e pequenos "tweaks" é dificultada.
 
o   Objective C*
 
Forças:
- As fraquezas das linguagens anteriormente referidas são, no fundo, as forças do Objective C: trata-se da linguagem nativa Android, pelo que a programação é directa e a implementação de APIs é facilitada.
- Não requer também a utilização de qualquer framework.
 
Fraquezas:
- Implica um processo de aprendizagem da linguagem pelos elementos do grupo, o que pode também resultar num período maior de desenvolvimento da aplicação.
- Diminuída capacidade de problem solving e debugging.
 
Fontes consultadas e datas de consulta:
http://www.anscamobile.com/corona/(15/03/2011);
http://www.sencha.com/(15/03/2011);
http://jqtouch.com/(15/03/2011);
http://www.phonegap.com/(15/03/2011);
http://www.appcelerator.com/ (15/03/2011);
 

 

 
·         Frameworks
Visto que existe alguma disputa entre os principais sistemas operativos móveis, é raro que haja, de facto, uma escolha sobre que sistema operativo utilizar (iOS, Android, Blackberry, Windows Mobile...). Para ultrapassar este obstáculo, as equipas de desenvolvimento de aplicações móveis optam frequentemente por utilizar frameworks. Estas frameworks têm como função a exportação de um código único para várias plataformas distintas, permitindo assim uma única programação ao invés de 2 ou 3 distintas. Sendo que as tecnologias e linguagens aprendidas até agora são bastante conhecidas e utilizadas (HTML, CSS, JavaScript, AJAX, PHP...), partimos em busca de frameworks que nos permitissem utilizar esses conhecimentos e exportá-los para Android.
 
o   Corona SDK* permite desenvolver plataformas cruzadas para diferentes sistemas.
 
Forças:
- Está disponível tanto para Mac como para Windows.
- Tem capacidade de adaptar a programação efectuada a sistemas operativos distintos.
- Quando instalado num Mac permite desenvolver aplicações para iOS e Android.
- As frameworks disponíveis permitem reduzir o tempo de programação e as linhas de código.
 
Fraquezas:
- Quando instalado em Windows apenas permite desenvolver aplicações para Android.
- É necessário passar a aplicação desenvolvida para Mac para que possa ser usada em iOS.
- Está mais direccionada para o desenvolvimento de jogos.
 
Fontes consultadas e datas de consulta:
http://www.anscamobile.com/corona/(15, 17/03/2011);
 
 

 

Outros requisitos técnicos
 
o   QRcode vão ser os códigos identificativos dos POIs, que vão corresponder a um ID na base de dados de POIs.
 
Forças:
- Baixo custo.
- Fácil de gerar, pode ser impresso numa impressora vulgar em papel comum.
- Fácil utilização.
- Neste momento há na Web imensos leitores e geradores de códigos QR.
- Generalização da utilização dos códigos QR, em revistas, panfletos, sites, etc.
 
Fraquezas:
- Necessita de um leitor para ter utilidade.
- Necessita de linha de vista entre o código e o leitor.
- Reconhecível a uma pequena distância do código.
 
o   Sinalética e Hotspot vão estar divididos em duas partes, assinalados na entrada com informação sobre o download da aplicação e instruções de uso e assinalados à saída para o upload de informação recolhida pelo utilizador durante a visita. Em alguns locais, devido às características físicas do mesmo, a sinalética de entrada e de saída pode estar junta, no entanto é importante distinguir as duas vertentes para não confundir o utilizador.
 
Forças:
- Dá a conhecer a aplicação ao utilizador.
- Pode funcionar como ‘cartão de visita’.
- A sinalética é simples e intuitiva, baseando-se em modelos universais.
- Disponibiliza instruções simples de fácil compreensão.
 
Fraquezas:
- Em condições de outdoor pode-se deteriorar com o tempo.
- Nos locais em que a sinalética de entrada e saída estão no mesmo sitio podem confundir o utilizador.
- Embora o design e concepção fiquem a cargo dos developers, a sinalética vai ser colocada pelos responsáveis pelos POIs o que pode gerar problemas de má colocação e confundir o utilizador.
 
Fontes consultadas e datas de consulta:
http://qrbcn.com/imatgesbloc/Three_QR_Code.pdf(17/03/11);
 
 
Tabela de correspondência entre requisitos funcionais e viabilidade técnica
viabilidade_tecnica.pdf
 

 




Entrega do módulo TP2 (1/3)

 

Módulo TP2 – definição do âmbito funcional e técnico do projecto
 
 
O módulo 2 tem como objectivo explorar os requisitos funcionais (“o quê?”) e os requisitos técnicos (“como?”) da aplicação a desenvolver. Para a análise dos requisitos funcionais, vamos pôr-nos na pele do utilizador e descrever como a aplicação deve funcionar, não nos prendendo muito com limitações técnicas, mas sim, explorando criativamente todas as opções, tendo em conta as funcionalidades das aplicações existentes que analisámos no levantamento do estado da arte. De seguida iremos abordar os requisitos técnicos que poderão condicionar as nossas primeiras opções, como por exemplo, recursos financeiros, tempo, materiais, tecnologias, etc.
 
 
Requisitos Funcionais
 
·         Foco da análise: o ponto de vista do utilizador.
 
Em primeira instância é necessário saber como o utilizador toma conhecimento da aplicação. Isto poderá ser feito de duas formas: através do computador, acedendo ao site (que poderá ser o site do Grupo 9 – Where to go? What was seen?) ou no próprio local visitado, através de sinalética ou hotspots para chamar a atenção do utilizador que a aplicação está disponível e como a pode utilizar, com algumas instruções simples. Ao descarregar a aplicação para o telemóvel, vai aceder a uma página de boas vindas com acesso a instruções de uso e informação sobre a aplicação. Nesta fase o utilizador pode optar por se registar na plataforma de partilha de comentários, para poder visualizar opiniões de outros visitantes e dar também a sua opinião.
 Ao visualizar qualquer obra contemplada no sistema do Mobile Tourist Guide, pode utilizar a câmara para reconhecer um código associado à imagem, que vai dar acesso a conteúdos multimédia complementares. O utilizador poderá também querer seguir trajectos por artista, por período cronológico, ou percursos aconselhados por outros visitantes que por ali passaram ou os mais pontuados.
                No final da visita, o utilizador pode aceder a plataforma de comentários, ou fazer o registo se tiver optado por não o fazer no inicio e deixar a sua opinião sobre o local ou as obras visitadas. Esta partilha de comentários pode ser feita no próprio museu ou ao chegar a casa acedendo à Web. Além da partilha de comentários, os visitantes podem também votar nos melhores locais que farão parte de um ranking que pode ser visualizado no site ou através da aplicação no telemóvel.
 
 
Tabela de requisitos funcionais e por utilizador

requisitos_funcionais_utilizadores.pdf

 

 

Tabela de requisitos não funcionais

requisitos_nao_funcionais_utilizadores.pdf

 

Tabela de requisitos funcionais organizados por front-end e back-end

requisitos_funcionais_BE_e_FE.pdf 

 

Estudo da Viabilidade Técnica
 
A viabilidade técnica pressupõe a procura de soluções técnicas adaptadas ao requisitos funcionais identificados anteriormente, para tal, convém definir e identificar atributos relativos ao hardware, software, linguagens de programação, entre outros. Vamos dividir o estudo em Client-side e Server-side, no final há ainda indicação de outros requisitos que não se enquadram nas duas categorias anteriores.
 
 
Client-side
 
·         Hardware
Os telemóveis que vão suportar a aplicação necessitam de quatro características de hardware: Wi-Fi, Bluetooth, câmara e touch-screen.
 
o   Wi-Fi e Bluetooth são os métodos necessários para descarregar, actualizar e interagir com a aplicação. Para que a utilização da aplicação não esteja restrita a áreas com redes Wi-Fi ou a utilizadores com acesso à rede 3G, decidimos optar por uma estratégia alternativa: download da base de dados para o dispositivo móvel do utilizador, para que este lhe possa aceder a qualquer dado momento. Visto que o sistema operativo Android suporta a utilização de ficheiros XML, é possível exportar todas as informações necessárias (nome, imagem, descrição e outras informações relativas a cada item) de uma base de dados MySQL online para um ficheiro, sendo que este é posteriormente transferido para o dispositivo móvel do utilizador, permitindo-lhe assim aceder a toda a informação necessária sem necessitar de estar ligado a qualquer rede.
 
Wi-Fi - Forças:
- Comodidade de ligação para os utilizadores.
- Poupança na montagem e desmontagem da rede.
- Facilidade para ligação múltipla.
- Equipamentos com baixo custo devido ao crescimento da oferta.
- Compatibilidade total com qualquer dispositivo marca Wi-Fi em qualquer parte do mundo (garantida pela Wi-Fi Alliance).
- A maioria dos equipamentos já vem com dispositivos de tecnologia Wi-Fi instalados.
 
Wi-Fi - Fraquezas:
- Menor velocidade que as redes com cabos, devido às interferências e perda de sinal que pode ter.
- Não se consegue controlar a área de cobertura da rede, criando assim mais um problema de segurança.
- Consumo de energia elevado, reduzindo o tempo útil das baterias dos dispositivos.
 
Bluetooth - Forças:
- Baixo consumo energético.
- Muito utilizado por diferentes tipos de dispositivos.
- Ideal para pequenas redes sem fios.
- Amplamente conhecido pelos utilizadores pela sua implementação em dispositivos de uso geral, como telemóveis e consolas.
- Utilização simples.
- Ligação à rede sem precisar de configuração prévia.
- Sem fios.
- Comodidade de ligação para os utilizadores.
- Uso gratuito.
 
Bluetooth - Fraquezas:
- Baixa velocidade de transmissão.
- Possibilidade de recepção de arquivos não desejados (bluejacking).
- Limitação na quantidade de equipamentos ligados à rede.
- Limitação no raio de alcance, bastante pequeno: 10 m (possibilidade de chegar até 100 m, mas com muita distorção do sinal).
- O espectro de radiofrequência que usa não é aberto ao público em todos os países.
- As suas características e frequência de raio, tornam-no susceptível a ataques e intercepção indesejada do sinal.
 
o   A câmara vai servir de leitor de código QR, que depois será processado pelo software adequado instalado no telemóvel.
 
Forças:
- Presente em todos os modelos de telemóveis actuais.
- Não tem custo adicional de utilização.
- Amplamente conhecida pelo público em geral, utilização simples.
- Não precisa de ligação a qualquer rede nem instalação.
 
Fraquezas:
- Precisa de uma outra aplicação para funcionar como leitor de dados, assim como para a transmissão e apresentação dos mesmos.
 
o   Touch-screen é uma característica dos telemóveis com sistema Android, para o qual vamos desenvolver a aplicação e é necessário para a interacção utilizador-telemóvel.
 
Forças:
- Interacção directa por parte do utilizador para uma experiência interactiva mais envolvente.
- Presente em grande número de telemóveis actualmente assim como também em outro tipo de dispositivos (livros electrónicos, computadores, PDAs etc.).
- Torna a interacção mais intuitiva.
 
Fraquezas:
- Incrementa o custo do telemóvel.
- Nem todos os modelos de telemóveis, mesmo os mais recentes, contam com esta tecnologia.
- Possíveis problemas ergonómicos em alguns casos, depois de uma utilização prolongada, pela pressão constante do(s) dedo(s).
 
Fontes consultadas e datas de consulta:
http://es.wikipedia.org/wiki/Wi-Fi#Ventajas_y_desventajas(16,17/03/11);
http://www.wi-fi.org/(16,17/03/11);
http://en.wikipedia.org/wiki/Wi-Fi(17/03/11);
http://wifeworld.blogspot.com/2006/02/ventajas-y-desventajas-de-wifi.html(16,17/03/11);
http://es.wikipedia.org/wiki/Bluetooth(16,17/03/11);
http://junihh.wordpress.com/2007/06/02/ventajas-y-desventajas-de-bluetooth/ (16,17/03/11);
http://www.movicel.mx/index.php?option=com_content&view=article&id=9:ventajas-y-desventajas-de-bluetooth&catid=2:articulos(16,17/03/11);
http://www.maismedia.com/q/redes/bluetooth/como.html(16,17/03/11);
http://es.answers.yahoo.com/question/index?qid=20100220224227AA8qcNM(16,17/03/11);
http://www.blue-tooth-wireless.com/Advantages_And_Disadvantages_Of_Bluetooth.html(16,17/03/11);
http://en.wikipedia.org/wiki/Bluetooth(16,17/03/11);
http://www.theallineed.com/computers/07102280.htm(16,17/03/11);
http://es.wikipedia.org/wiki/Pantalla_t%C3%A1ctil(16,17/03/11);
http://en.wikipedia.org/wiki/Touchscreen(16,17/03/11);

 

 
 
·         Software
O software essencial que o dispositivo necessita de ter é o sistema operativo Android, sem o qual não é possível instalar e utilizar a aplicação. O utilizador necessita também de instalar software de leitura de código QR, o NeoReader*e Quick Mark*.
 
o   Android sistema operativo que vem já instalado no dispositivo móvel.
 
Forças:
- Crescimento do número de utilizadores deste sistema operativo.
- Maior facilidade em encontrar informação sobre aplicações e ajudas de programação para este sistema.
 
Fraquezas:
- Concorrência de outros sistemas operativos para dispositivos móveis (Symbian, Bada, etc.).
- O sistema iOS tem maior número de aplicações disponíveis.
 
o   NeoReader* é uma aplicação universal de leitura de código de barras que transforma o telemóvel num leitor de código de barras, permitindo o acesso a conteúdos Web.
 
Forças:
- Uso simples.
- Gratuito.
- Funciona em Android e iOS.
 
Fraquezas:
- Concorrência de outros softwares similares.
- Necessita instalação.
 
o   Quick Mark* é um leitor de código QR.
 
Forças:
- Visto ser mais complexo, pode dar asas a uma maior manipulação dos dados descodificados de um código QR.
- Utilização gratuita.
 
Fraquezas:
- Tal como com o NeoReader*, é necessário o download da aplicação para o dispositivo móvel.
- O nível de complexidade elevado da aplicação pode alienar o utilizador durante a utilização do mesmo.
 
Fontes consultadas e datas de consulta:
https://market.android.com/(14, 15/03/2011);
http://www0.rtp.pt/noticias/?t=RTP-lanca-aplicacao-para-Android.rtp&article=424505&visual=3&layout=10&tm=6(16, 17/03/11);
 
 

 




Ponto de situação – OT 16.03.11

Na reunião da aula OT com a prof. Margarida os vários grupos partilharam em que fase está o desenvolvimento dos projectos e expuseram as suas questões relativamente aos mesmos.

 

Quanto ao nosso grupo, a professora sugeriu desenvolvermos a aplicação apenas para o sistema operativo Android, devido ao tempo reduzido que temos para desenvolver o projecto e à investigação e aprendizagem de novas linguagens e formas de desenvolvimento e programação exigidas para a sua exequibilidade. Sendo que uma sugestão/consideração futura fora do âmbito da disciplina ou do contexto académico pode ser o desenvolvimento da aplicação para outros sistemas operativos.

 

Falámos também da nossa dificuldade em decidir algumas técnicas de desenvolvimento, pois ainda não sabemos como irão funcionar na prática e a professora esclareceu que neste momento importa decidir aquilo que achamos melhor e no caso de incertezas, deixar claro que elas existem e que pode haver alterações com o desenvolvimento do projecto que serão comunicadas em momento oportuno.

 

Outra questão importante apontada pela professora foi a necessidade de colocar no blog referência a todos os testes efectuados no telemóvel de testes, pois ajuda a fortalecer a credibilidade da investigação.

 

Foram ainda esclarecidas algumas questões relacionadas com a forma como devem ser feitas as entregas, em forma de post com documentos anexos sempre que necessário.

 




Requisitos funcionais e viabilidade técnica – aula 16.03.11

Continuação do estudo da viabilidade técnica.

 

Expusemos algumas dúvidas ao professor sobre as tecnologias que queremos utilizar, uma vez que estamos a trabalhar para dispositivos diferentes daqueles abordados nas disciplinas de NTC, o que pressupõe uma maior aprendizagem da nossa parte e maior complexidade no desenvolvimento no produto final. O professor aconselhou-nos a verificar a compatibilidade entre essas tecnologias e os sistemas operativos para os quais vamos desenvolver a aplicação e a compatibilidade das tecnologias entre si. Sobre esta questão, já tínhamos feito testes anteriormente e instalado pequenas aplicações no telemóvel do Bruno que é a nossa cobaia de testes.

 

Da parte da tarde vamos ter OT com a prof. Margarida para fazer o ponto de situação do projecto.

 




Terça-feira, 15 de Março de 2011
Considerações Técnicas

 Com a finalidade de avaliar a viabilidade técnica de cada requisito funcional, procedemos a alguma pesquisa e ponderação sobre os recursos a ter em consideração no desenvolvimento futuro da aplicação.

 

 

Base de dados:

Existe a necessidade de alojar as informações inerentes tanto às obras/peças dispostas na aplicação como também dos utilizadores, tal como os seus comentários, reports, percursos, etc. Como tal, é necessária a escolha de uma base de dados a utilizar. No entanto, visto que a aplicação deve poder ser utilizada quando o utilizador se encontrar tanto online como offline, é importante que as informações a apresentar ao utilizador offline se encontram alojadas localmente.

Como tal, consideramos que a opção mais viável será a exportação de tabelas expecíficas da base de dados online para um ficheiro XML, que por sua vez sirva de base de dados local quando o utilizador assim o necessitar.

Visto que os custos do desenvolvimento do projecto devem ser os mais baixos possível, optámos pela utilização de uma base de dados MySQL.

Ao aceder a um hotspot com WiFi, ou mesmo nas áreas expecíficas para a actualização da aplicação encontradas em museus, por exemplo, o utilizador terá a oportunidade de importar um XML com informação actualizada encontrada na base de dados, sendo que a poderá consultar sempre que quiser.

 

Resumo:

Base de dados MySQL (para uso online)
Ficheiro XML importado para o dispositivo movel (para uso offline)

 

 

Desenvolvimento da aplicação:

Apesar de nos encontrarmos ainda na fase dos requisitos funcionais, achámos bastante importante começar a pesquisa por mecanismos e ferramentas que nos facilitassem a tarefa de desenvolver uma aplicação para um dispositivo móvel, com o objectivo de passar mais tempo futuro em debugging e em melhorias ao invés de uma fase de aprendizagem que pudesse boicotar tempo precioso.


Para isto, houve dois pontos aos quais démos mais importância:

1) Será necessário aprender uma nova linguagem de programação ou poderemos utilizar os conhecimentos já adquiridos?

2) Como fazer a interligação entre o leitura do código QR e a nossa aplicação?

 

1) Visto que existe alguma disputa entre principais sistemas operativos móveis, é raro que haja de facto uma escolha sobre que sistema operativo utilizar (iOS, Android, Blackberry, Windows Mobile...). Para ultrapassar este obstáculo, as equipas de desenvolvimento de aplicações móveis optam frequentemente por utilizar frameworks. Estas frameworks têem como função a exportação de um código único para várias plataformas distintas, permitindo assim uma única programação ao invés de 2 ou 3 distintas.

Visto que as tecnologias e linguagens aprendidas até agora são bastante conhecidas e utilizadas (HTML, CSS, JavaScript, AJAX, PHP...), partimos em busca de frameworks que nos permitissem utilizar esses conhecimentos e exportá-los para Android e/ou iOS 4.

Eis algumas opções encontradas:

Corona SDK - http://www.anscamobile.com/corona/ (pref.)

Sencha - http://www.sencha.com/

JQTouch - http://jqtouch.com/

PhoneGap - http://www.phonegap.com/

Titanium AppCelerator - http://www.appcelerator.com/ (Não permite a utilização do SDK de Android mais recente)

 

2) Para a interligação entre a aplicação e o leitor de código QR, recorremos a um forum português de desenvolvimento para android: http://www.androidpt.com .

Para o efeito pretendido, foi-nos aconselhada a escolha entre duas abordagens:

2.1) Invocar uma aplicação de leitura de códigos QR dentro da nossa aplicação e retornar o ID descodificado do código QR em questão, de modo a dispor as informações correctas ao utilizador;

2.2) Utilização do ZXing (Zebra Crossing) para o mesmo efeito, sendo que não seria necessária a utilização de qualquer software adicional para além da nossa própria aplicação, pelo que, muito provavelmente, será a abordagem que iremos adoptar no desenvolvimento do projecto.

 

ZXing (Zebra Crossing)

URL: http://code.google.com/p/zxing/

O ZXing é uma biblioteca de código open-source para processamento de códigos de barras 1D ou 2D e suporta a descodificação do código QR, tal como pretendemos.

Segundo um dos administradores da comunidade portuguesa anteriormente referida, o ZXing é a biblioteca de leitura de códigos QR mais utilizada no desenvolvimento de projectos para Android, devido, essencialmente, à facilidade da sua integração.




Sessão de orientação 15.03.2011

Hoje reunimos com os orientadores e apresentámos o trabalho desenvolvido até agora. Apresentámos a tabela dos requisitos funcionais por utilizador, sendo que os orientadores nos aconselharam a centrarmo-nos em áreas gerais e não nas suas especificações. Por exemplo, um requisito funcional é o registo de utilizador, e as suas especificações são os campos que é preciso preencher, o nome, e-mail e password mas não são requisitos funcionais em si mesmos. A sugestão para nos concentrarmos apenas nos requisitos funcionais tem a ver com tempo disponível e a complexidade que poderia exigir uma tabela com esse nível de detalhe, embora possa ser útil na altura do desenvolvimento da aplicação propriamente dita, neste momento não faz muito sentido detalhar exaustivamente todas as funcionalidades, uma vez que algumas podem não vir a ser implementadas, porque podem não ser viáveis do ponto de vista da viabilidade técnica ou necessitarem de outros recursos inacessíveis.

 

Alguns requisitos nesta tabela, atributos físicos no local de utilização da aplicação, vão ser passados para a tabela de requisitos não funcionais, uma vez que não são intrínsecos à aplicação.

 

Além dos requisitos funcionais, falámos também de algumas opções técnicas relativas a hardware e software. Abordámos a utilização de frameworks para Android e iOS.

 




.mais sobre mim
.pesquisar neste blog
 
.Junho 2011
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2
3
4

5
6
7
8
9
10
11

12
14
15
17
18

19
20
21
23
24
25

26
27
28
29
30


.posts recentes

. Mobile Tourist Guide / se...

. Back Office

. Reunião de grupo – 13.06....

. Módulo 6 - testes

. Módulo 6 – Versão beta

. Testes de usabilidade

. versão beta e testes – au...

. Actualizações – testes

. Ponto de situação – OT 01...

. Versão beta e testes – au...

.arquivos

. Junho 2011

. Maio 2011

. Abril 2011

. Março 2011

. Fevereiro 2011

.tags

. todas as tags

.participar

. participe neste blog

blogs SAPO
.subscrever feeds