Ya hemos terminado las clases principales menos una. Paso a desceribirlas aqui abajo

*Configuracion: Clase que contrendrá la fecha inicial, la final y la ruta de la imagen a enviar.

*ControladorConfig: Clase que contiene una lista con todas las configuraciones. En el proceso de la aplicación, se irá recorriendo esta lista hasta que coincida las fecha inicial de alguna configuración con la fecha actual. (Nunca habrá dos configuraciones en la misma franja horaria).

*Dispositivo: Clase que contiene MAC, NombreDispositivo y ruta. Esto objetos van a almacenar los dispositivos remotos detectados.

*Detector: Clase que inicia el proceso de detección de los dispositivos encapsulandolos en objetos Dispositivo y almacenandolos en una lista.

* Comparador: Esta clase se encargara de decidir que dispositivos deben ir para enviarse al usuario final. Contiene una lista y una cola. La lista contendrá los dispositivos ENVIADOS y la cola contendrá los dispositivos NO_ENVIADOS. La idea es enviar a esta clase el Iterador que actúa sobre la lista de la clase Detector. Cada Dispositivo que cogemos de esa lista miramos si existe en la lista de ENVIADOS o en la lista NO_ENVIADOS.

Si el dispositivo no existe en las estructuras ENVIADOS y en NO_ENVIADOS, se almacena en NO_ENVIADOS para que Enviar vaya cogiendo los dispositivos de la cola e irlos enviando. Si el dispositivo existe en la lista ENVIADOS, se descarta el dispositivos y por último, si el dispositivo existe en la cola NO_ENVIADOS se descarta también puesto que ya esta listo para enviarse.

Un saludo — Thor the PowerHead–

Pues en la última reunión llegamos a un acuerdo sobre los últimos requisitos del programa. Paso a describirlos brevemente y adjunto el esquema hecho a mano que elaboramos:

Empezaré describiendo la interfaz gráfica. En ella el usuario introducirá un mensaje, una fecha de inicio y una fecha de fin. Mientras el sistema este entre esas dos fechas el programa enviará ese mensaje. La interfaz también tendrá una pantalla para ver las tareas que estan creadas, y la posibilidad de eliminarlas o modificarlas. Tendrá también una pantalla más para ver un log de sucesos.

El nucleo del sistema constará de tres partes principales, por eso el esquema parece la estrella de la muerte. La primera parte se encargará de detectar dispositivos e irlos agregando a una lista. La segunda parte comprueba que a los dispositivos detectados no se les halla enviado alguna vez el mensaje. La última parte se dedica a enviar indiscriminadamente el mensaje a todos los dispositivos que ya han sido filtrados por la clase que comprueba.

En principio todo está listo. Solo falta escribir, escribir y escribir código para que Hermod pueda correr por el Asgard cumpliendo su misión.

Un saludo!

—————————————————–

Well, at the last meeting we agreed on the latest requirements of the program. Step to describe them briefly and the attached diagram handmade that we produce:

Iĺl begin to describe the graphical interface. The user will introduce a message, a start-date and an end-date. While the system is between those two dates the program will send that message. The interface also will have a screen to view the tasks that are created, and the ability to delete or modify them. It will also display more to see a log of events.

The core of the system will consist of three main parts, which is why the scheme seems the Death Star. The first part will be responsible for detecting devices and adding to a list. The second part verifies that the devices were not detected lies ever sent the message. The last part is dedicated to indiscriminately send the message to all the devices that have already been filtered by the class which checks.

In principle everything is ready. Only have just write, write and write code for able Hermod run by Asgard fulfilling his mission.

Greetings!

Puedes ver el esquema aqui. You can see the scheme here

analisis1.jpg

Hemos diseñado una pequeño análisis del proyecto:

El proyecto va a estar dividido en 3 partes o capas:

· Interfaz

· Gestión de imágenes

· Proceso bluetooth

INTERFAZ

Está pensado hacer una interfaz con MONO y le metemos una cadena que irá a parar a la siguiente capa (Gestión de imágenes). Y recibirá la imagen totalmente hecha por parte de la capa de Gestión de imágenes.

GESTIÓN DE IMÁGENES

La capa de imágenes recibe la cadena y la procesamos para hacer el cartel completo para devolvérselo a la Interfaz.

Habrá que consultar ImageMagic ó SVG que es una especificación de imagen vectorial. Ésta última suena muy bien.

PROCESO BLUETOOTH

Esta es la parte más extensa. Vamos a hacerlo con C++ y por tanto manejo de objetos.

• Los dispositivos que se vayan detectando se irán encapsulando en objetos Dispositivo donde almacenaremos la MAC y la imagen.
• Conforme se vayan detectando y encapsulando, se van metiendo en una COLA
• Conforme vayan entrando en la COLA se van enviando y se almacenan luego en una estructura. Esta estructura se usará para que no se repitan los envíos a los mismos dispositivos comparando los que se van detectando con esa estructura y los que no estén repetidos se van metiendo en la COLA. Es decir, el proceso de comparación es anterior al almacenamiento en la COLA.

En principio esto tendría un Objeto que llamaríamos OBEX que contendrá el código para enviar al dispositivo y detectar dispositivo. Dentro de la función de detectar se establece el objeto con su MAC y la imagen. Y la función de enviar pues lo envía.

La imagen será otro Objeto que contendrá la ruta de la imagen.

Posible Clase (Pseudocódigo) :

Clase OBEX{

Public Dispositivo detecta(imagen){ // Devuelve un Dispositivo con MAC e Imagen.

//código de detección

imagen = miInterfaz.getImagen();

miDispositivo.setMAC(MAC);

miDispositivo.setImagen(imagen);

if(estructura.compare(miDispositivo)) //comparemos

cola.add(miDispositivo)//almacenamos si no está

{

Public boolean envia(dispositivo){

//código para envío

estructura.add(dispositivo);

}

}

Por encima esto es lo que podemos hacer, pero aún me parece que tiene lagunas, a ver que os parece.

Aqui hay un pequeño diagrama del proceso bluetooth

Un saludo, Thor the PowerHead

Saludos.

Esta tarde estuvimos discutiendo Jesús y yo(Ángel) un asunto sobre el alcance teórico-práctico de la señal bluetooth. El problema es que para nuestro proyecto sería necesario, para un completo funcinamiento práctico, que se difunda los más lejos posible. Teóricamente, si no me equivoco, el alcance es de 100 metros pero llevado a la práctica esa distancia se recorta considerablemente (15 – 20 metros) debido al entorno donde se propaga.

Así que me acordé que hace unos días estuve bicheando por unas páginas buscando si la señal de bluetooth se podría incluir (embebida) en la de wifi. Encontré una página http://www.aircable.net/host-xr.htm y http://www.aircable.net/industrial-male.html , en la que describe dos hardware uno para un host y otro como “punto de acceso” (o eso entendí). La cosa es que aumentan el rango del bluetooth en kilometros. Esta en inglés, si no lo entendeis bien podeis copiar el texto y pegarlo todo en el traductor de google (lo que yo hize, porque había cosas que no entendía ni papa).

Otro enlace relacionado era de incluir en un solo chip wifi y bluetooth, pero no se si esto beneficiaría el alcance del bluetooth, http://www.marvell.com/press/pressNewsDisplay.do?releaseID=603

Si alguno de vosotros podeis aportarnos más información sobre esto os lo agradeceríamos. Un saludo y gracias, Thor (The PowerHead) .

——————————————————————————————

Greetings.

This afternoon we were discussing Jesus and myself (Angel) an issue on the scope of the theoretical and practical signal bluetooth. The problem is that our project would be necessary for a complete funcinamiento practical, to disseminate the most far as possible. Theoretically, if I am not mistaken, the reach is 100 meters but implemented that distance is cut significantly (15 – 20 meters) because of the environment where spreads.

So I remembered that a few days ago I was bicheando around looking pages if the signal could include bluetooth (embedded) in the wifi. I found a page ( http://www.aircable.net/host-xr.htm and http://www.aircable.net/industrial-male.html ), which describes two hardware and one for a host another “point Access “(or so I understood). The thing is that increase in the range of bluetooth km.

Another related link was included in a single chip bluetooth and WiFi, but I do not know if this would benefit the scope of bluetooth, http://www.marvell.com/press/pressNewsDisplay.do?releaseID=603

If any of you, you can give us more information about it you appreciate it. Best regards and thanks, Thor (The PowerHead).

Hermod es el hijo de Odín y de Frigg y su nombre significa Ardiente en el Combate. Es el mensajero del Asgard y fue enviado al Hell por Odín para traer de vuelta a Balder, asesinado por el Dios ciego Hod que fué engañado por Loki.

Hermod es un proyecto de difusión de noticias via Bluetooth (Ordenador-Movil) que sirve de solución para que centros como Universidades y centros comerciales anuncien sus eventos. La idea es que cuando entres en cualquier centro, si tienes móvil con bluetooth activado, llegue un mesaje con alguna noticia referente a centro. Por ejemplo, si es en la facultad llegarían noticias del tipo “Examen de Álgebra en el aula 33 a las 12:00″.

El nombre que hemos elegido ha sido por dos razones. Primero, somos admiradores de la mitología Nórdica y Segundo, porque este ser era el mensajero de los dioses del Asgard y nuestro proyecto esta intimamente ligado con su trabajo

Esperemos que sea del gusto de “AllFather”

——————————————————————————————-

Hermod is the son of Odin and Frigg and his name means in Blazing Combat. He is the messenger of Asgard and was sent to Hell by Odin to bring back to Balder, the God blind murdered by Hod that was deceived by Loki.

Hermod is a project news via Bluetooth (PC-Mobile), which serves as a solution for universities and centers such as shopping malls announce their events. The idea is that when you enter any institution, if you have bluetooth mobile activated, a message arrives with some news regarding center. For example, news like “Review of algebra in the classroom 33 at 12:00.

The name we have chosen has been for two reasons. First, we are admirers of Nordic mythology and second, because this was to be the messenger of the gods of Asgard and our project is intimately linked with their work