JMF(Java Media Framework)

Introducción:

Los paquetes principales que debemos tener presente en JMF son aquellos de los que haremos uso de sus clases principales , por ejemplo para data source que es una clase del paquete de javax.media.protocol, clases Player y Processor que son interfaces de javax.media, clase Data Sink que es una clase del paqiuete  javax.media.

Las clases principales del JMF son la adquisición de datos (captura desde un dispositivo físico, lectura de un fichero o recepción desde la red), procesado (aplicación de efectos como filtrado o realces, compresión y/o descompresión, conversión entre formatos) y la salida de datos (presentación, almacenamiento en fichero o transmisión a través de la red). :

Clase DataSource.- Esta clase se encarga de encapsular la localización, el protocolo de transferencia y el software necesarios para la adquisición. Por lo tanto una vez obtenido un DataSource no se puede asociar a otra fuente de datos.

Player.- Un Player es un objeto encargado de procesar cierto flujo de datos multimedia y presentarlo en su preciso momento.

DataSink.- La función de este objeto es obtener el media stream y almacenarlo en un fichero local, a través de la red o transmitirlo mediante RTP. 

EJERCICIO 1 Y 2

Ponemos los 2 ejercicios juntos ya que lo único que había que poner en el ejercicio 2 era un botón que hace que si se pulsa una vez, cuando finaliza el video se para la reproducción y al pulsarle de nuevo, cuando finaliza el video se repite una y otra vez.

Hemos creado una clase que implemente ControllerListener para poder crear el reproductor y el ActionListener para los eventos del JButton. Lo que hemos necesitado para crearlo a sido un Player, JButton y un Componente.

Para crear el player lo hemos hecho a través de una URL que carga el archivo pasándole el nombre del fichero como un String. El player se crea a través del Manager.createPlayer(URL url) y luego le añadimos su escuchador: addControllerListener(this) (this porque lo creamos en la misma clase).

Implementamos el método ActionPerformed, que simplemente nos cambiará un boolean para que se repita o no la reproducción cuando se detecte un evento de ratón sobre el botón.
También implementamos el método controllerUpdate y utilizamos los eventos RealizeCompleteEvent para poder añadir los componentes, ya que solo se pueden añadir cuando el player esta realizado; y el evento de EndOfMediaEvent para que se repita o no cuando finaliza la reproducción.

 Os añadimos nuestro código para aquellos que os interese:

SWING Y EVENTOS…

En esta práctica solo hicimos en clase hasta el apartado 3..

APARTADO 1

Más o menos nos defendimos bien y ya con el juego teniamos idea de como hacerlo.
Nosotras implementamos el ActionListener ya que solo tiene un método y nos parecía la forma más fácil de hacerlo. Tambien se podía hacer heredando de MouseAdapter, porque si se implementa, tiene muchos métodos que no se van a utilizar.
Este es nuestro código:

EJERCICIO1

Qué es un proceso y un programa, qué diferencias existe entre ambas?

Si vamos a una descripción teórica un PROCESO es dinámico, su estado cambia con el tiempo, según la CPU va ejeucutando las diversas opoeracines que se enumeran en un programa. Un PROGRAMA es algo dinámico, es el conjunto de instrucciones máquina que ha generado el compilador a partir del código fuente.

En clase se dijo que es complicado dar una diferencia entre un proceso y un programa, lo que se  explicó es que solo se puede ejecutar una tarea por proceso, repartiendo el tiempo en instanates pequeños para cada proceso, el cpu los trata por vez. Utilizando una cola para asignar prioridades.

Los primeros apartados nos dicen que compilemos los programas que nos dan Ding, Dong, DingDongPoor

Ding -> al dar un enter se lanaza por cmd mensajes de DING!. Al revisar el código no encontramos nada fuera de lo común un try para tratar las excepciones que que se pueden dar con Sistem.in.read

Dong -> cada cierto tiempo se imprime por pantalla DONG!. Al ver el código, la sentencia que no s llamó la atención fué “Thread.sleep(1000)” y la explicación que se dio es que sirve para asignar un tiempo de espera para qeu se realize luego algo.

DingDongPoor-> el código es la unión de los dos programas anteriores, funciona mal ya que hay un ‘cruce’ en el tiempo de ejecución del mismo, no sabe cuando esperar por el enter o cuando estar en estado de dormir para cada Dong!.

Al lanzar simultaneaente Ding y Dong comprobamos que es compòrtamiento es como el de DingDongPoor, En linux pueden ejecutarse los dos programas a la vez y realizando llo que el ususario realmente espera, que a cada enter aparez el DING! y cda cierto tiempoel DONG!.

EJERCICIO 2

En esta parte hablamos sobre los hilos de ejecución conocido s como THREADS, son hilos asociados a un mismo proceso, de esta manera podremos hacer que en el sistema operativo  realice varias tareas a la vez. Para lanzar nuevos hilos necesitamos de: Thread->start() y Runnable->run(), que es cada cosa?

Runnable.- Es un interfaz, por tanto no podemos crear un objeto de tal tipo. Contiene un método llamado run(), que es lo que se hará en el programa.

Thread.- Hilo,  de tal forma que  mediante Thread t  = new Threads (r)  obtengo un hilo que está relacinado con Runnable.

start()-> crea un thread y luego llama a run para hacer lo que dice run.

Existen dos formas de conseguir threads en java, Una es implementando la interface Runnable, la otra es extender la clase Thread.

Algo a tener en cuenta muy importante es que no puedo invocar a run directamente, ya que no está lanzada la bifurcación(instrucción que crea una copia de un proceso en sistemas operativos) y eso lo hace start().

EJERCICIO 3

Vimos tambien las condiciones de carrera, RaceCondition. Las condiciones de carrera se producen cuando 2 hilos intentan acceder al mismo recurso al mismo tiempo. El código que tuvimos que ejecutar lanzaba 2 hilos y lo primero que te esperas es que salgan 10.000 ceros y luego 10.000 unos y no es así. Lo que obsevamos es que salen los ceros y los unos aleatoriamente, es decir, sale por pantalla el primero que llega al recurso.

Una de las formas que pensamos para evitar las condiciones de carrera de este código es añadir un Thread.sleep(1000); por ejemplo, entre la llamada al start() de los 2 hilos para que el 2º hilo espere el tiempo necesario para que se impriman antes los ceros.

El siguiente código que vimos, RaceConditionSolved,  nos soluciona las condiciones de carrera utilizando un Vector. Viendo el código vimos que añaden una ‘z’ que realmente, si la quitamos, el programa se ejecuta de igual manera.
Le preguntamos al profesor el porqué de esa ‘z’ que se añade y nos dijo que es un valor por defecto que se suele añadir a la hora de programar y se utiliza como “control” y, efectivamente, no influía en nada.

Estamos en la parte más interesante de la asignatura, la parte donde podemos ver más real nuestros programas…. Para los que asistíamos con Alberto tenemos nuevo profesor.

Empezamos con un concepto básico: Qué es una GUIs(interfaz gráfica)? Podríamos pensar que es representar gráficamente un programa; pero es un concepto no del todo acertado ya que es la manera en la que el programa se comunica con el usuario, en busca de respuestas que el usuario puede introducirlas por medio del ratón o del teclado. En la parte teórica viene conceptos básicos sobre las interfaces que valen la pena revisar y entenderlas.

Ejercicio 1:

Tenemos que importar nuevas clases, adaptadas cada una según para lo que el usuario necesite.

JFrame-> Usada para ventanas       JPanel-> Usada para contenedores        JLabel->Usada para etiquetas

Resolviendo cada guión del ejercio 1, lo hicimos en conjunto, deteniéndonos para analizar el comportamiento de cada método.

En el guión 5 para modificar el tamaño  tenemos que hacer uso de frame.setSize(400,200);Para cambiar el color de fondo(guión 6) usamos label.setBackground(Color.BLUE) y label.setOpaque(true), ya que el Api de Java nos dice que si la etiqueta no es opaca, el color no se visualiza.

 Ejercicio 2

Ejercicio 3

 

TablaHash

Java nos la ofrece de manera gratuita, solo tenemos que hacer uso de ellos. Como sabemos una tabla nos sirve para introducir o sacar objetos.

Un punto muy importante es el comentario que Alberto planteó en clase. ¿De todas las estructuras de datos vistos en clase (arrays, listas, pilas, colas y tablahash) en cuál cuesta menos encontrar un objeto?

Arrays.- En algún momento tendré que recorrer el array, Si está vacío tardaré menos en encontrar una posición y si está lleno a menos que no utilice una variable que me vaya indicando la posición actual en la que me encuentro tardaría más. Por tanto el tiempo que tarde en encontrar a una persona (hemos supuesto el  ejemplo de una agenda) será : n/2 -> tiempo promedio, ya que en el mejor de los casos, si está al principio no tardaré tanto, y en el peor de los casos si está al final ‘n’. En resumen en insertar a una persona utilizando arrays tradaré una constante y en encontrarla n/2. Tengo un desperdicio de memoria.

Lista.- Igual que los arrays en un determinado momento tendré que recorrer el array. Tardaré en insertar una persona a la agenda una constante y en encontrar  (n+1)/2 = n/2 cuando tendo varias personas.

Cola .- No depende de lo que se tenga anterior, recordar que para estos algoritmos el api nos ofrece unos métodos (peek,enqueue,dequeue) qu enos faciltian el trabajo. En insertar una persona tardaré una constante y en encontrarlo tardaré ‘n’ ya que para una cola primero los introduzco y luego tendré que hacer uso de una temp para volverlos a recorrer y encontrar lo que buscamos. Caso muy similar para la Pila. Por lo que en términos de eficiencia temporal no es muy aconsejable utilizar pilas y colas.

TablaHash.- En encontrar una persona una constante y en buscarla también una constante, ya que No tiene en cuenta lo que anteriormente esté insertado y a cada nuevo objeto le voy asignando un número. Una tablahash hace uso también de listas enlazadas de una o dos  que subdividen en otros nuevos grupos. Por ejemplo en el caso de  listas si tenemos más nombre con  la misma letra, luego mediante una nueva lista(sublista) los subdivide en nuevos grupos por ejemplo masculino y femenimo , por lo que la búsqueda se acorta. Haciendo un ejemplo, si se desea encontrar a una persona que se llame Isabel iré al número asiganado para las ‘I’ y luego tardaré el tiempo que esté en la lista enlazada n/2 que como será grupos de 1 0 2 listas no se tendrá en cuenta ->constante.  No útil para agendas de teléfono móvil.

Ya en desarrolo de la práctica:

Ejercicio 2 :

Está parte hay que entender RECURSIVIDAD , que son métodos que se llaman a sí mismo hasta terminar. No era complicado excepto la parte de fibonacci que nos costó un poco más; pero con ayuda de  compañeros nos aclararon las dudas.

Realmente es complicado de explicarlo pero si hacemos uso de un ejemplo se facilita:

Empezamos pasando como parámetro el 10 como la fórmula de fibonacci nos dice que es  fibonacci(n-1) + fibonacci(n-2), lo que se trata es de llamar dos veces al mismo método en la primera llamada tendré fibonacci (9)+fibonacci( 8 ) y estas a su vez vuelven a llamar a su fibonnacci respectivo es decir que fibonacci (9) llama a fibonacci ( 8  )+fibonacci( 7 ) y así voy creeando un arból hasta llegar a 1,  luego debo sumar todos los resultados. Esperamos que la explicación haya sido un poco clara :S

Ejercicio 1 :

Buscamos en el api TableHas y encontramos dos métodos que nos facilitan el trabajo. Put y get

put(K clave, V valor)  en la práctica ht.put(“vidInf”, “Vidas infinitas”);

Empezamos escuchando la explicación de Alberto, como siempre nos viene bien para saber lo que hay que realizar durante la práctica. Lugo buscamos en google sobre listas dinámicas…. no encontramos nada claro, entramos al Api y buscamos en Queue; pero nos explicó Alberto que java nos ofrece una cola dinámica ‘fácil de utilizar’ ; pero el objetivo de está práctica era precisamente elaborar esa cola dinámica que java nos afrece, claro con nuestros propios métodos.Nos explicó que para realizar nuestra cola dinámica, no hace falta utilizar array, ni la cola anterior(que tenía un tamaño fijo) y está es adimenisional.

Como punto de partida, tomamos la cola de la práctica 6 y eliminamos el método de está lleno. ya que como sabemos en está nueva cola no hay tamaño, luego el array anterior “Pieza elementos[ ]“ lo reeemplazamos por nuevos atributos de tipo Object y Nodo, ya que pensamos en la idea explicada en clase cuando teníamos Nodo y nodo siguiente.

El método dequeue (desencolar) y queue(encolar) los rellenamos, aunque no sabemos si están bien ….

Luego había que declarar la Clase Nodo; que tampoco supimos desarrollarla del todo…

En conclusión un poco desastre esta práctica esperamos tenerla clara más adelante, por que en estos días con el juego en marcha poco tiempo tenemos de continuar con ella.

Nos gustaría que se publique la solución de está praáctica, siempre y cuando sea factible…, por que estamos un poco perdidas con el tema….

El enunciado nos indica que hay aplicaciones para utilizar una cola, tema que habíamos discutido en clase, por que no encontramos uan explicación clara para ver el uso de una cola…con está práctica vemos que mediante una cola podemos acceder a las piezas que se necesita en el tetris.

Ejercicio 1 y 2

Primeramente hemos revisado en los apuntes de teoría como funciona la cola. Necesitamos los métodos vacia(), llena(), imprimir(), encolar() y desencolar().
La unica diferencia con la Cola de teoria es que el array tiene que ser de tipo “Pieza” y no de “int” y en principio no habría que modificar más. Os adjuntamos el código:

Cola.java – Parte 1
Cola.java – Parte 2

Hemos creado la clase Pieza con 2 atributos:
- char letra;
- int posicion;
Hemos creado un constructor que inicialice las 2 variables, y el método mover que nos actualiza la posición.

Hemos reutilizado el método toString para que nos devuelva el valor del char. Esto significa que en el método imprimir de la clase Cola se puede añadir opcionalmente. Lo pusimos porque sino imprime cosas raras… De todos modos os adjuntamos una imagen de nuestro código por si os viene bien.

Pieza.java

Despues hemos creado otro método llamado PruebaCola que es el que contiene el main para comprobar que todo funciona correctamente.

Nosotras hemos hecho que la cola se inicialice con el tamaño de los parámetros que metamos por consola (args.length). Utilizamos los métodos de la clase Cola y vamos encolando las piezas siempre que esta este vacia (en nuestro caso entra todo lo que metamos). Nos dimos cuenta de que args es de tipo String y necesitamos un char a la hora de crear la pieza, por lo que hemos puesto args[i].charAt(0) (suponemos que hay alguna forma mejor de hacerlo…) y la posicion a 0 en todas, es decir, la inicial. Luego lo imprimimos para ver que funcionaba. Os adjuntamos el código tambien:

PruebaCola.java

En principio pensábamos que tendríamos una práctica sobre pilas y colas que es lo que se había visto en clase… pero no ha sido ásí !!! y creeemos que nos haría falta para entenderlo mejor y ya que en el examen suele caer alguna pregunta por ahí.

Como de costumbre se refuerza los conocimientos teóricos, explicándonos que es el polimofirmo, clases , métodos abstractos y las interfaces que pueden implementarse o extenderse.

 Polimorfismo:

No sabemos explicarlo muy bien, en las prácticas se dijo lo siguiente :

Existen dos tipos (clase y método) y no tienen que ver uno con el otro.

Clase.- cuando un objeto puede comportarse como otro objeto de otra clase “tiene que ver con la herencia”.

Método.- tiene que ver con los constructores, son métodos que tienen el mismo nombre pero distintos argumentos “sobrecarga de métodos” es por esa razón que java puede distinguir uno de otro. Podemos entender con el siguiente ejemplo:

Clases y métodos abstractos:

Las clases y métodos abstractos se declaran añadiendo el modificador “abstract”. Los métodos de las clases abstractas no tienen porqué estar implementadas. Si otra clase hereda de una clase abstracta, esta debe implementar los métodos que se han declarado como abstractos. Si no se quieren implementar, la clase hija deberá declararse abstracta tambien.

Interfaces:

Puedo implementar tantas veces considere, lo contrario a la herencia que solo se puede heredar una vez. ( “class NombreClase extends NombrePadre implements nombreInterfaz1 …. implements nombreInterfazN” )
Esto quiere decir que la HERENCIA MÚLTIPLE NO EXISTE EN JAVA y para solventar este “problema” se utilizan las interfaces.

Nos quiere decir que se implementan con el nombre “implements” o se extienden “extends”.

Cuando hacemos uso de las interfaces,  sus métodos son abstractos(no se implementan). En el caso de invocar a una interfaz”implements”, debemos implementar aquellos métodos que la interfaz ha mencionado y que en principio no se han “rellenado”, es decir:

interface nombreDeLaInterfaz {
    tipo_retorno nombreMetodosInterfaz();
    }

class nombreClase implements nombreInterfaz {
    tipo_retorno nombreMetodosInterfaz(){
      implemento el método
      }
    }

Vamos a tratar de explicar el ejercicio relacionado con awt, más que nada porque un compañero nos lo ha sugerido… y lo que más nos ha costado.

Ejercicio 3.1

Para hacer este ejercicio tuvimos que consultar obligatoriamente el API para ver que métodos teniamos que usar.

Vimos que para rellenar el rectangulo existe un método que se llama fillRect(int posX,int posY,int ancho,int alto) y para dibujarlo drawRect(int posX,int posY,int ancho,int alto).

Y para establecer el color, setColor(Color c).

Pusimos los métodos como g.metodo(); y vimos que nos pintaba mal… y comiendonos un poco el coco, nos dimos cuenta de que primero pusimos el fillRect y luego el setColor, y el método paint va pintando en órden de que van apareciendo los métodos escritos en él. Esto significa que primero nos relleno el rectángulo y luego seleccionó el color (por lo que relleno por defecto el rectángulo de negro).
La solución fue poner primero el color y luego rellenarlo (del revés…).
Por la misma razón, hay que poner primero el relleno y luego el borde porque sino el borde quedaría por debajo del relleno y no se vería.

Ejercicio 3.2

Nosotras ya habiendo entendido el anterior (que nos costo…), la clase Boton y Menu era más de lo mismo… pero en el método paint hay que pintar el boton utilizando el paint de la clase padre:

   super.paint(g);

y para añadir el texto, tanto al botón como al menú, hay que utilizar el método setText(String texto).

Para añadir las opciones del menu nosotras hemos utilizado un for con una variable auxiliar, que vaya añadiendo las opciones del menu.

Ejercicio 3.3

Este es el último apartado que nos dio tiempo a realizar. No sabemos si exactamente lo hicimos bien porque no tenia ningun main y no pudimos comprobarlo… por lo menos al compilar no nos dio error.

Nosotras inicializamos el componente en el constructor con numComponentes:

componente = new ComponenteGrafico[numComponentes];

En el método añade pusimos un for del tamaño del componente y fuimos añadiendo el componente c a cada posición del array.

Y por último, en el método paint volvimos a llamar al paint de la clase padre y añadimos un for para ir pintando los componentes.

Ejercicio 1

Suponemos que no hay mucho que contar en este apartado, ya que es implementar el constructor y en el método toString() retornar una sentencia (recordar que para los modificadores hay que hacerlos como la práctica anterior).

- ¿Qué pasaría si se cambiara protected por private en nuestra jerarquía de clases?
Para los que no sabian responder esta pregunta, si se cambia protected por private, las clases derivadas de esta, solo podrían acceder a sus atributos a tráves de sus métodos de acceso y no se heredaría.

Ejercicio 2

Este ejercicio es igual que el anterior con la unica diferencia que hereda de la clase Miembro, y hereda sus atributos. A la hora de crear el constructor, debemos llamar a los atributos heredados mediante super, y a los parámetros propios de la clase, llamarlos normalmente(this.).

Ejercicio 3

Para los que estuvieron en el grupo de Alberto Cortes, nos explicaron para que servía StringBuffer().

StringBuffer ret=new StringBuffer();
            ret.append(” TIPO = “+ tipo);
        return ret.toString();

Todo este código puede ser reemplazado por:

return “TIPO = “+tipo;

como lo hemos hecho en los apartados anteriores.

- ¿Para que sirve entonces StringBuffer?
A nivel usuario, hace lo mismo que poner lo explicado anteriormente, pero a nivel computacional, cuando tiene que concatenar 2 Strings, no los suma, sino que crea un tercer String del tamaño total de la suma de los 2 anteriores, y los añade… por lo que al compilar, la máquina tarda más.
Lo que hace StringBuffer es crear un String variable de tamaño, por lo que al concatenar Strings, este se hace más grande y añade el siguiente… por lo que la máquina tarda menos en compilar y no crea Strings adicionales.

La clase método se realiza igual que la clase Atributo, solo que en toString() hay que añadir un for e ir metiendo todos los parametros. (Creemos conveniente utilizar el StringBuffer aquí, que existen muchas concatenaciones). Nosotras lo hemos hecho asi para quienes os sirva:

public String toString() {       
         StringBuffer ret = new StringBuffer();
         ret.append(“Nombre: “+nombre+”, Modificador: “+Modificador.toString(modificadores)+”Tipo Retorno”+tipoRetorno);
         if (parametros != null)
            for(int i =0;i<parametros.length;i++)     
               ret.append(“Parametro “+i+ “: “+parametros[i]);
         return ret.toString();
      }

Ejercicio 4 

La clase Constructor hereda de Método, según se nos da en el enunciado. Pero nos encontramos con un problema, Constructor no tiene tipoRetorno, por lo que a la hora de heredarlo, tendríamos que añadir “” en el espacio que corresponde a tipoRetorno de la clase Metodo.

Alberto nos ha recomendado que no hagamos esto porque a parte de que requiere más trabajo, un constructor no es un método (suena mal) y lo ideal, es que Constructor herede de Miembro aunque sea redundante.

Se haría como la clase Metodo pero sin tipoRetorno.

Ejercicio 5

Esta clase hereda de la clase Object. Es de la que heredan todas por defecto cuando el usuario no especifica de que clase se hereda.  (Se explicó en clase)

Este ejercicio no nos ha dado tiempo a terminarlo, no porque sea extenso, sino porque hay que entender bien el código haciendo uso del API, para poder entender para que servía cada método.

Nos encontramos con cosas “extrañas” como esta: o.getClass().getName() ; (que quiere decir, que el objeto “o”, el nombre (get.Name()) de la clase donde nos encontramos(getClass())… y asi todos… que nos ha llevado su tiempo descifrarlo…), aún así no podemos decir mucho porque no estamos muy seguras…

Por lo tanto, solo nos ha dado tiempo ha realizar hasta el ejercicio 2.

Ejercicio 0

Este ejercicio ha sido teórico, del cual, Alberto ha dedicado mucho tiempo en dejar claras las cosas por ser conceptos básicos que deberíamos saber.

La pequeña práctica que tenía este ejercicio simplemente era para familiarizarse en manejar los métodos y como acceder a ellos si los atributos son privados o públicos.

Una breve explicación para acceder a estos es la siguiente:

-> Si el atributo es privado, solo se puede acceder a él mediante sus métodos de acceso (get y set).
Ejemplos: p1.getX(); //devuelve el valor
p1.setX(x); //pone un valor

-> Si el atributo es publico, se puede acceder a él con el operador “.” y seguido el atributo.
Ejemplo: p1.x=3;

El último punto de este ejercicio era muy interesante, ya que para llamar a contador (que era static), se puede llamar tanto desde p1, p2 o Punto que nos dará el mismo resultado, ya que al ser static, si su valor se modifica, se queda modificado para todo el programa.

Ejercicio 1

Este ejercicio es para familiarizarse con java.lang.reflect.Modifier. Hay que comprenderlo bien ya que hay que usarlo para los demás ejercicios.
Nosotras pensamos que funciona asi:

-> Los atributos tienen un valor fijo (static final) que no se podrá modificar en todo el programa.
-> Modifier.toString(valor), que ya esta implementado, nos devuelve el nombre del atributo, según el valor que le dimos al inicializarlo.

Ejercicio 2

En este ejercicio, hay que rellenar el constructor (el de toda la vida, utilizando el this) y rellenar el método sustituyendo el “null” por un String en el que incluimos el nombre, el tipo y los marcadores. Para que nos devuelva el tipo de modificador, los modificadores hay que pasarlos por parámetro utilizando la clase Modificador.

-> Modificador.toString(modificadores)