30 de Abril de 2012

Esta aula foi utilizada para se prosseguirem os trabalhos dos projectos após a semana académica. Uma vez que todos os grupos estão já "lançados" nas suas tarefas, o professor Caixinha esteve junto destes para se inteirar dos progressos feitos até este momento.

 

Assim, mostramos ao professor Caixinha a evolução do WiP Mobile até aqui. O ecrã de pesquisa e das preferências está praticamente concluído do ponto de vista gráfico, onde já se encontram colocados todos os elementos (elementos textuais, gráficos e checkboxes).

 

Figura 1. Ecrã de Pesquisa e Preferências 

 

Por sugestão do professor Caixinha, comprometemo-nos ainda a questionar o professor Pedro Amado sobre esta versão final dos ecrãs ilustrados acima, uma vez que foram efectuadas alterações à versão entregue na demo gráfica.

 

Durante o tempo restante da aula o grupo continuou a trabalhar noutras tarefas de alguma importância, nomeadamente no login através do Facebook e algumas pesquisas sobre a implementação do serviço de geo-localização.

24 de Abril de 2012

Boas tardes!

 

Como já é habitual, na passa quarta-feira tornámo-nos a reunir com o orientador de projeto, Prof. Pedro Almeida. Aproveitando então esta oportunidade para mostrar os progressos da aproveitando então esta oportunidade para mostrar os progressos da aplicação. Estes consistiam na reparação do bug encontrado e mostragem da demo técnica em funcionamento. Para além destes progressos, aproveitámos o tempo para discutir alguns pontos a serem corrigidos na entrega anterior.

 

Visto que o projeto WIP – work in prespetive tem mais duas plataformas, web e itv, a linha gráfica tem que ser coerente em todas elas. Com isto o grupo WIP, vertente web, mostrou aos restantes grupos como ficará a linha gráfica final.

 

Nesta reunião estiveram presentes, como habitual, os três grupos e os orientadores do grupo itv e mobile, excetuando-se o Prof. Telmo, que ainda está em casa a recuperar. Aproveitamos assim, para lhe desejar as melhoras.

 

Em suma, esta reunião mostrou-se proveitosa para a correção de erros antigos e para a evolução da própria aplicação.

 

Por enquanto é tudo.

Continuação de um bom dia.

24 de Abril de 2012

 Ora muito boa tarde !

 

Este post servirá para indicar os avanços obtidos desde a reunião da passada quarta-feira (18/4).

Nesta fase, ainda nos encontramos "de volta" da construção da UI (user interface).

O ecrã das preferências está praticamente concluido, faltanto nesta "tab" aprimurar a interface da pesquisa e dos feeds (landing page).

 

 

 Figura 1. Ecrã de escolha de preferências

 

De momento há dificuldade na implementação de fontes externas ao titanium e na implementação dos mapas, nomoeadamente na geolocalização (detetar e mostrar a localização atual do dispositivo).

Mas como nem tudo são problemas, já superámos a situação do "publish" do .apk depois de uma ajuda do nosso colega Daniel Vieira. Outro problema que nos assutou (e bastante) foi o fato de, sem razão aparente, o emulador deixar de correr a aplicação (erro: Titanium SDK version: 1.8.2 (02/23/12 17:46 59b3a90) ). Depois de alguma pesquisa, descobriu-se que é um bug do titanium e que basta eliminar a pasta "build", rieniciar o titanium e o emulador.

 

Ficam aqui também alguns "guides" que nos têm ajudado bastante:

http://developer.appcelerator.com/apidoc/mobile/latest/Titanium-module

https://wiki.appcelerator.org/display/guides/Quick+Start

 

E a documentação completa de uma aplicação (Kitchen Sink) que contém praticamente tudo o que se pode fazer com o titanium:

https://github.com/appcelerator/KitchenSink/tree/master/Resources/examples

 

E por enquanto é tudo :)

Bom 25 de Abril !

20 de Abril de 2012

Com esta entrega pretende-se a (re)construção do mapa de navegação da aplicação com apenas os módulos que iremos implementar (ou pelo menos é esse o nosso objectivo) no protótipo de alta fidelidade.

Na Figura 1. estão ilustrados a verde os módulos de Front-Office que decidimos serem os mais importantes da aplicação, daí serem escolhidos para este protótipo de alta fidelidade. Os módulos de fundo amarelo são os comuns aos de Back-Office, uma vez que são constituídos por elementos de Back e Front Office.

Figura 1. Módulos de Front-Office a serem implementados.

 

 

 

Na Figura 2. estão discriminados a azul os módulos de Back-Office a serem prototipados. Tal como acontece na Figura 1. os módulos de fundo amarelo são os que possuem vertente de Back e Front Office.

Figura 2. Módulos de Back-Office a serem implementados.

20 de Abril de 2012

 

Boa noite!

Finalmente, apresentamos a demo técnica há tanto esperada. Depois de diversas dificuldades, que impediam a entrega da mesma, descobrimos que o impedimento era, apenas, um bug do próprio programa.

O código seguinte exemplifica a nossa resolução:

button1.addEventListener('click', function(e){

               

                var params = String(input.value);

                var xhr = Titanium.Network.createHTTPClient();

                xhr.open('GET','http://10.0.2.2/jobfinder/teste_demo_grafica/Resources/teste.php');

                xhr.send('params=' + encodeURIComponent(input.value))

                xhr.onload = function(){

               

    var response = this.responseText;

    alert(response);

                if (response != null)

                {

                               alert("voltou ao js e funca");

                }

                else

                {

                               alert("-.-");

                }

                };

               

                xhr.setRequestHeader("Content-Type","application/x-www-form-urlencoded");

               

                xhr.onerror = function(e){alert('Transmission error: ' + e.error);};

               

})

O referido bug encontra-se representado pelo texto a vermelho. Nesse excerto de código é criado um http client que “abrirá” um determinado URL (neste caso o url do nosso servidor local), onde enviará para pesquisa a palavra que escrevemos na caixa de texto.  

Resolução:

                if(input.value=="")

               

                show.value = "Introduza dados para a Pesquisa";

               

                else

               

                {             

                var url = "http://10.0.2.2/jobfinder/teste.php";

                var params = "?params=" + input.value;

                var encodedURI = encodeURI(url + params);

               

                var xhr = Titanium.Network.createHTTPClient();

                xhr.open("GET", encodedURI);

                xhr.send();

               

                xhr.onload = function(){

               

    var response = this.responseText;

    show.value = response;

                };

               

                xhr.setRequestHeader("Content-Type","application/x-www-form-urlencoded");

                xhr.onerror = function(e){alert('Transmission error: ' + e.error);};

               

                }

               

});

 

Ao separarmos cada elemento por variáveis, o bug foi resolvido começando então, a realizar a conectividade entre o ficheiro Javascript  e a base de dados, quebrando a barreira que nos impossibilitava o desenvolvimento do projeto.

 

Passemos agora à apresentação da demo. Esta percorrerá uma das muitas funcionalidades da aplicação WIP e tem como objetivo explicar o que acontece ao usarmos a funcionalidade de pesquisa, mostrando como será realizada na aplicação móvel. A demo vai, deste modo, explorar desde o seu ambiente gráfico à execução da própria funcionalidade.

 

Em seguida apresentamos o vídeo demo:

 

demo from Vera Rodrigues on Vimeo.


 

Para suportar a realização desta demo apresentamos também, imagens que mostram excertos do código usado, tanto da página javascript como php:


Fig. 01 - Ficheiro php (nesta imagem, podemos ver a forma como a pesquisa é feita à base de dados e como o resultado é mostrado ao utilizador).


Fig. 02- Ficheiro javascript (nesta imagem vemos como o javascript recebe a resposta provinda do php).

 

Em suma, com esta demo quisemos mostrar que, apesar de sabermos que demorámos muito tempo até chegarmos à resolução do bug anteriormente referido, as dificuldades foram superadas. Além disto, com a apresentação do código, tencionamos alertar que o que parece estar correto, (e que no fundo está), pode por vezes, fazer conflito com algo e levar a um impasse. Foi nossa intenção, ainda e por último, demonstrar como o WIP irá funcionar, pelo menos, esta funcionalidade.

Gostaríamos então de agradecer a todos os professores que nos ajudaram nesta fase mais complicadado nosso trabalho.

Um resto de uma boa noite.

19 de Abril de 2012

Após conversarmos com o nosso orientador, chegamos à conclusão que o nosso projecto carece de alguma fundamentação e consolidação na escolha do leque de dispositivos móveis mais indicados para os quais estamos a trabalhar.

Cedo decidimos que iríamos trabalhar para dispositivos Android que possuam versões entre 2.2 e 2.3.7. Tal escolha é justificada pelo simples facto de que (segundo estatísticas presentes no website Android Developers) este intervalo representa 86,8% dos utilizadores de Android, por isso logo à partida, estaremos a trabalhar para um leque de mercado extremamente abrangente, havendo assim mais possibilidades de adesão à aplicação.

Figura 1. Tabela que mostra a distribuição dos utilizadores Android.

 

 

 

 

No entanto não é suficiente apenas nos centrarmos na versão do sistema operativo do dispositivo. Outra característica fundamental e que pode comprometer o desempenho da aplicação é a resolução do dispositivo para a qual estamos a desenvolver a WIP. Uma vez que um dos elementos possui um dispositivo Android recente (Samsung Galaxy S2), pareceu-nos sensato desenvolver para este dispositivo, mas tomar esta decisão sem um pouco mais de fundamentos poderá trazer algumas consequências. Assim, decidimos investigar um pouco mais sobre esta questão.

Figura 2. Tabela que mostra as diferentes categorias dos dispositivos Android relativamente aos seus ecrãs.

 

 

 

 

O Samsung Galaxy S2 tem um ecrã de alta densidade (240 HDPI), com uma resolução de 480x800 DP’s. Tal como é possível reter, este dispositivo é colocado no grupo dos HDPI, e dos quatro grupos existentes (LDPI, MDPI, HGDPI e XHDPI), os HDPI são os que detêm a maior percentagem de utilizadores, com cerca de 65%.

Figura 3. Gráfico representativo do número de utilizadores Android de acordo com os ecrãs dos seus dispositivos.

 

 

 

Podemos concluir então que esta é uma escolha feliz, pois desta forma estamos a trabalhar para o grupo de dispositivos que tem o maior número de utilizadores Android, potenciando assim o impacto da nossa aplicação e alargando o seu raio de incidência.

 

 

 

Referências: http://developer.android.com/resources/dashboard/platform-versions.html

 

18 de Abril de 2012

Bom, após mais uma odisseia com o Professor Caixinha, conseguimos resolver todos os bug's (FINALMENTE!!) da comunicação entre o Titanium e o código PHP da aplicação. Quer isto dizer que está praticamente pronta para ser aqui colocada a demo técnica da aplicação.

Apenas para contextualizar um pouco os avanços efectuados, ficam aqui alguns prints da aplicação já a efectuar algumas pesquisas:

Figura 1. Nesta imagem é vísivel o ambiente do menu de pesquisa de ofertas, onde o utilizador insere os termos a pesquisar. Caso o utilizador não insira qualquer palavra na pesquisa, este será notificado na textarea.

 

 

 

Figura 2. Após o utilizador inserir as palavras-chave, é feita uma pesquisa na base de dados, devolvendo as ofertas existentes na textarea presente abaixo.

 

 

 

Figura 3. Caso as palavras-chave da pesquisa não correspondam a nenhuma das ofertas presentes na base de dados, o utilizador é notificado na mesma textarea.

 

 

 

Estas mesmas acções serão mais detalhadas e explicadas na demo técnica, que irá ser aqui postada o mais brevemente possível.

18 de Abril de 2012

Esta aula foi dada pelos professores Pedro Amado e Benjamim Júnior. Primeiramente, os professores estiveram a apresentar os objectivos pressupostos para a próxima entrega, o protótipo de alta fidelidade.

Posto isto, estivemos a mostrar ao professor Pedro Amado os avanços feitos na construção do logótipo final do WIP. O facto dos elementos gráficos serem comuns às três plataformas exige uma grande minuciosidade na construção dos próprios, pelo que este processo é feito de vários avanços e recuos. Depois desta fase, o professor Pedro Amado esteve ainda a dar algum feedback sobre a última entrega efectuada, sugerindo algumas correcções e chamando à atenção para alguns elementos menos bem construídos e consolidados.

Durante o resto da aula aproveitamos para efectuar alguns trabalhos a nível gráfico e também na demo técnica.

12 de Abril de 2012

Na reunião de ontem voltamos a juntar-nos com os outros dois grupos do WIP, sendo o principal objectivo desta reunião a análise dos três logos criados pelos grupos. Concluída esta etapa, passamos à discussão do logótipo final para implementar nas três aplicações.

Chegamos à conclusão que as propostas do grupo da Web e do grupo da iTV seriam as mais indicadas para implementar no projecto, mas no entanto tanto um como o outro não eram capazes de satisfazer todas as exigências necessárias. Assim, ficou decidido na reunião recorrer ao Professor Pedro Amado para este nos dar algumas indicações e dicas para tornar um dos dois logótipos o ideal para se implementado nas três plataformas, correspondendo assim às exigências de cada uma destas.

Na parte final da reunião,cada grupo reuniu-se com o seu respectivo orientador, onde aproveitamos para pôr o nosso orientador ao corrente dos avanços e recuos do WIP Mobile.

 

Abril 2012
Dom
Seg
Ter
Qua
Qui
Sex
Sab
1
2
3
4
5
6
7
8
9
10
11
13
14
15
16
17
21
22
23
25
26
27
28
29
subscrever feeds
arquivos
mais comentados
1 comentário
1 comentário
Colaboradores
WiP Web
WiP iTV
pesquisar
 
últ. comentários
Algumas notas de lembrete para a nossa reunião:- P...
Boa evolução gráfica!O blogue também está com um n...
Relativamente ao logo, sugerimos também que experi...
Em resposta ao comentário do professor:- relativam...
Algumas notas sobre a demo gráfica:- a demo tem um...
Copyright


Licença Creative Commons
Este trabalho foi licenciado com uma Licença Creative Commons - Atribuição - NãoComercial - SemDerivados 3.0 Portugal.

blogs SAPO