Nuestro juego es el ahorcado. Decidimos hacer el ahorcado a raíz de la práctica 2, en el que nos pedían que hiciésemos uno según unas características determinadas, ese fue el que entregamos en la primera parte, pero después decidimos hacer un cambio radical. Cuando dimos swing y empezamos a aprender las interfaces gráficas, quisimos que el juego fuese totalmente diferente a lo que era, así que lo modificamos muchas veces, quedando como resultado esto:

PANTALLA INICIAL

Al ejecutar el juego, se inicia una pantalla con la imagen de Simpson.jpg (un ImageIcon). Sobre la imagen hay 4 botones JButton:

- Créditos, se muestran los créditos del juego. En el escuchador del FrameAhorcado hay un

If( evento= =”CREDITOS”)

{

(Llamamos a la clase que se encarga de eso)

}

Para que en el FrameAhorcado salga otra ventanita aparte,no hemos utilizado un Frame, sino que hemos creado unas clases internas que heredan de JDialog. El JDialog puede recibir como argumento un JFrame, entonces, en las clases de Instrucciones y Créditos, tenemos un método que se encarga de devolvernos un JFrame con un JPanel ya relleno con los elementos que queremos mostrar. El constructor de la clase Creditos, se encarga de leer desde un fichero externo el texto que presentaremos como créditos. Para salir tenemos que dar al botón Aceptar o pinchar el aspa.

- Instrucciones, la explicación de cómo jugar. Escribimos en un fichero las instrucciones que más tarde queremos que se vean cuando pulsemos este botón mediante la clase Instrucciones. Funciona igual que la clase anterior pero con diferente dimensión y texto. Para salir hay que pinchar en Aceptar o en el aspa.

- Opciones, aparece una ventana pequeña la cual hemos impedido que se pueda maximizar (con setResizable()) para evitar que se pierda el orden y la buena apariencia.También hemos bloqueado la opción de cerrar del aspa con frame.setDefaultCloseOperation(javax.swing.WindowConstants.DO_NOTHIN G_ON_CLOSE); así, la única manera de cerrar esta ventana, es pulsar el botón

Aceptar. Lo hemos hecho así para confirmar las opciones de configuración, de lo contrario, nos quedaríamos con la configuración por defecto y no con la que el usuario desea.

En la ventana se muestra los elementos en el siguiente orden:

· Una ventana desplegable, JComboBox, con diferentes temas a elegir para la palabra secreta. Los temas son: arte, ciencia, deportes, música, personajes, tecnología, programación y otros. De estos se puede marcar uno. Al abrir la ventana, por defecto se marca el tema de arte en la ventana desplegable.

· Se puede elegir la dificultad entre fácil, normal, difícil y muy difícil. Se elige gracias a 4 JRadioButton mostrando cuatro pequeños círculos, en los que si pinchas se rellenan con un punto negro. Sólo se puede elegir uno de los 4, por esta razón elegimos JRadioButton.

· Un botón Aceptar, JButton, para aceptar las opciones establecidas por el jugador.

- Iniciar Juego, si es pulsado inicia el juego. Al pulsarlo aparece una ventana que se compone de varias partes.

à PANTALLA DEL JUEGO

Estas partes están colocadas en columna obedeciendo el orden establecido por un GridLayout:

- Lo siguiente se logra gracias a la clase PanelBorder, el cual coloca un borde en un panel. En letras rojas colocamos JUGUEMOS!! poniendo un nombre al borde del panel. Mientras que el borde no se aprecia porque está en negro y no se distingue con el fondo.

- Botón denominado Menú principal, con el que puedes volver a la pantalla inicial. En el momento que el jugador esté situado en dicha ventana, se puede realizar todas las operaciones que ésta ofrece.

- La imagen del muñeco ahorcado es un ImageIcon. El juego está compuesto de 7 imágenes del ahorcado del clásico juego, y una carita feliz en el caso de haber ganado la partida. La primera vez que aparece, cuando empieza la partida, tan solo sale la soga. Si se pulsa una letra errónea, que no se encuentra en la palabra secreta, sale también la cabeza, después la cabeza y el cuerpo,… y así sucesivamente hasta completar todo su cuerpo, momento en el que se habrá perdido la partida.

- Un JLabel en el que se encuentra la palabra a adivinar oculta entre los asteriscos. Los asteriscos son de color blanco para que resalten sobre el fondo negro.

- Un JButton en amarillo, al pulsarlo se invoca a un objeto de la clase CompletaPalabra, apareciendo una ventana donde puedes introducir la palabra que se cree que es la correcta. Esta ventana sólo se cierra en el momento que se pulsa el enter. En el botón se puede ver escrito ¿sabes la solución? En la pantalla de juego, cuando se pulsa cualquier botón, esta pantalla se coloca sobre la de la palabra secreta, sólo está debajo cuando se inicia una nueva partida. De momento, está opción está deshabilitada.

- Un borde blanco que rodea el teclado en el que aparece escrito TECLADO en letras blancas. Esto se consigue gracias al PanelBorder.

- Y un array con 30 JButton, con las 27 letras del abecedario en color rojo, un botón para iniciar una nueva partida, otro para resolver la palabra y otro para salir del juego, éstos tres últimos en color negro. Hemos utilizado el constructor del JButton que permite poner un nombre y un icono al botón. Para que las letras se quedasen centradas, se empleó el método de JButton setHorizontalAlligment(int posicion);

à INTENTOS

En cada intento puedes pulsar una tecla correspondiente a una letra.

- Si la letra se encuentra en la palabra, la letra se descubre en la palabra de asteriscos en su correspondiente posición, actualizando el JLabel que la contiene.

- Si la letra no está en la palabra secreta, pierdes una oportunidad, y la imagen del ahorcado se actualiza, colocándose un miembro más del cuerpo del pobre muñeco.

- Si pulsas una letra ya pulsada anteriormente, no hace nada.

Pulsando el botón Nueva Partida, comienzas una nueva partida del ahorcado directamente preparado para jugar, sin aparecer en la pantalla de bienvenida.

Con el botón Resolver, se desvela la palabra secreta hayamos perdido, ganado o nos encontremos en medio de la partida, pero en el momento en que la pulses, ya no podrás seguir jugando con esa palabra, el jugador estará obligado a pulsar Nueva Partida si quiere seguir jugando.

Con el botón Salir, se sale de la aplicación cerrándose la ventana del ahorcado.

à PERDER Y GANAR

Se pierde si en los 6 intentos no has conseguido resolver la palabra.

De forma contraria, se gana si consigues resolver la palabra antes de que el muñeco aparezca totalmente ahorcado, es decir, antes de que se acaben los 6 intentos. Entonces, en el lugar en el que está la imagen del ahorcado, se verá una carita contenta en señal de felicitación.

Se puede jugar tantas partidas como se quiera pulsando el botón correspondiente a Nueva Partida.

à IMPLEMENTACIÓN DEL JUEGO. CLASES.

El juego se compone de las siguientes clases:

- Compara, implementa el algoritmo del ahorcado. En él situamos los arrays de String para cada tema con las posibles palabras a jugar, busca una palabra aleatoria, se escoge la palabra según la dificultad elegida (la dificultad se escoge acorde al número de letras de la palabra), oculta la palabra entre asteriscos,…

- FrameAhorcado, es la clase principal, la que engloba todas las clases. Se encarga de la interfaz gráfica de usuario. Contiene 4 clases internas: FrameConfigura, FrameCreditos, FrameInstrucciones y Configuracion. Las tres primeras llaman al método getFrame() con un objeto correspondiente a la clase Configura, Creditos e Instrucciones, respectivamente. Los 3 heredan de JDialog. Mientras que la clase interna Configuración, contiene a su vez otra clase interna llamada EscuchaBoton.

Se colocaron clases internas con el fin de reutilizar el código y buscando lo más cómodo y fácil para programar. Si no hubiésemos hecho clases internas, sería más complicado de programar. Al estar interna, podemos acceder directamente a los atributos y métodos de la clase que la contiene. En cambio, desde una clase externa, no se puede acceder a los atributos de otra clase de una forma tan sencilla, ya que siguiendo la encapsulación, están con el modificador de acceso private.

- Instrucciones, lee desde un fichero externo (llamado instrucciones.txt), las instrucciones que aparecen al pulsar dicho botón de la pantalla inicial.

- Configuración, se encarga de sacar las opciones de la pantalla de bienvenida, puedes elegir la dificultad y el tema del que tratará la palabra a adivinar.

- ComparaPalabra, hace que aparezca una ventana para resolver la palabra oculta. Si la palabra es correcta, se gana automáticamente. De lo contrario, se pierde. En estos momentos se encuentra deshabilitado.

- Créditos, la clase créditos es para mostrar lo que está escrito en el fichero créditos.txt. Al igual que la clase Instrucciones carga lo que vamos a mostrar por pantalla desde un fichero externo.

- PanelBorder, hereda de TitledBorder. En esta clase hemos construido 6 constructores diferentes para formar bordes según lo deseado en cada momento.

1. Constructor en el que se introduce el color del borde y la palabra que aparecerá en dicho borde.

public PanelBorder(Color color,String nombre)
{
super(new LineBorder(color),nombre);
}

2. Constructor al que se le pasa el color del borde, la anchura del borde y la palabra en él escrita.

public PanelBorder(Color color,int ancho,String nombre)
{
super(new LineBorder(color, ancho),nombre);
}

3. Constructor al que se le pasa el color del borde, el color de la letra de la palabra que se va a escribir en el borde y la palabra que desees colocar.

4. Constructor al que se le añade a los anteriores el ancho del borde.

public PanelBorder(Color color,Color letra,int ancho,String nombre)
{
super(new LineBorder(color, ancho),nombre);
super.setTitleColor(letra);

}

5. Constructor al que se le pasa lo del anterior pero en lugar de meter el color de la letra, pasamos la posición.

public PanelBorder(Color color,int ancho,int posicion,String nombre)
{
super(new LineBorder(color, ancho),nombre);
super.setTitleJustification(posicion);
}

6. Y el último al que se le pasan todos los parámetros anteriores.

public PanelBorder(Color color,Color letra,int ancho,int posicion,String nombre)
{
super(new LineBorder(color,ancho),nombre);
super.setTitleColor(letra);
super.setTitleJustification(posicion);
}

à RELACIÓN ENTRE CLASES.

Ver en página anexa por favor.

à VENTANA DE COMANDOS.

Para compilar el juego las imágenes (Homer y Bart, los distintas fases del ahorcado, las diferentes imágenes para los botones y la carita contenta) y los códigos fuente deben estar en la misma carpeta. Así, una vez que se haya colocado en la ventana de comandos la ruta en la que se encuentra dicha carpeta, escribir la sentencia javac *.java para compilar todos los archivos de una sola vez. Entonces, se formarán los .class de cada una de las clases. Una vez hecho esto, se ejecuta mediante java FrameAhorcado. Después, aparecerá la ventana principal del juego en el lado izquierdo de la pantalla del ordenador, y todo preparado para comenzar la partida.

à PROBLEMAS.

- Tuvimos muchos problemas sobre todo al comenzar desde cero.

- Los Escuchadores.

- Con el botón de Nueva partida: A la hora de activar este botón fue bastante complicado. Al principio cada vez que se le pulsaba, aparecía una partida nueva pero en un nuevo frame, de forma que cada vez que le pulsases se iban acumulando las ventanas una encima de otra. Esto no era lo que nosotros queríamos. Para llegar a que saliese en la misma ventana que en la que empezamos la primera partida, tuvimos que crear varios métodos, el NuevaPartida(), Panel(), Limpia(), …

- Para actualizar los paneles.

- Enganchar la GUI con el algoritmo del juego.

- Lectura externa desde un fichero.

à MEJORAS.

Siempre se puede mejorar. De hecho, podríamos estar años con él y años dedicaríamos a colocar mejoras, solventar errores,… Entonces, es imposible evitar que surja algún problema en algún momento de vida del juego, aunque nosotros hemos intentado controlarlos y dejarlo lo mejor posible.

Ideas que han ido surgiendo para innovar el juego a raíz de enseñárselo a gente y de jugar nosotros fueron:

• Pistas, dar pistas sobre la palabra a adivinar.
• Temas, colocar más temas a elegir.
• Más oportunidades para acertar la palabra.

à CONCLUSIÓN.

En un principio no íbamos a hacer el juego, porque necesita emplear muchísimo tiempo y queremos aprobar el mayor número posible de asignaturas, pero cambiamos de opinión con la práctica 2, y nos decidimos a ello.

Programar el juego nos ha servido, más que nada, a aprender a utilizar SWING y a surfear por el API. A cualquier duda, mirábamos en el API. Fue un gran amigo nuestro. El mayor problema era el idioma, pero entre los dos y el diccionario como nuestro aliado, después de largos ratos, se podían sacar cosas en claro.

Hemos aprendido mucho sobre SWING.

Para mostrar como ha ido evolucionando nuestro juego y su código, y nosotros con él, hemos hecho “un viaje” en el tiempo. En el anexo2 se puede apreciar los pasos que hemos dado, desde nuestro aprendizaje a la actualidad.

Descargar Código y Documentación

Descargar ejecutable ( Ahorcado.jar)

PD: Para ejecutar el juego se necesita que este instalado JVM en tu ordenador. Si no lo tienes lo puedes descargar de aqui.

Tchan, tchan, tchan, tchaaaaaaaaaaan!!

El simulacro no me ha ido muy bien. Yo necesito más tiempo para pensar las cosas. Además, mi visión espacial es nula y para imaginarme a la piececita dando vueltas, me ponía malaaaaaaaaaa…  ahora comprendo a los compañeros que están cursando de nuevo esta asignatura, cuando me decían que el juego del examen es imposible. Imposible no es, pero si creo que requiere de más tiempo para procesarlo, pensarlo, y escribirlo. También es bastante complicado el juego del examen. Para cuando quise empezar el segundo ejercicio SE ME HABÍA ACABADO EL TIEMPO. Lo desperdicié todo pensando en el dichoso tetris. Con lo que me gustaba a mi ese juego, hasta ahora que le he pillao’ “tirria”.

A Rodri le ha ido mejor, él tiene más visión espacial.

Yo me tiro todo el santo día con Java, es la asignatura a la que más hago caso, la que más empollo. Hay que tener en cuenta que para el simulacro de examen, nadie iba con todo aprendido a la perfección, pero con lo que he estudiado …. No era fallo de falta de estudio, de no saber sobre el tema, en mi opinión lo que a mi me pasó era falta de ideas, de comprender lo que piden y quedarte en ese bucle de: ”¿ésto se hará así? No, así no puede ser ¿entonces “asao”? ”, perdiendo todo el tiempo del mundo tan solo en pensar.

Ambos teníamos esperanzas de aprobar el examen de junio, pero con este simulacro nos hemos quedado por los suelos. Como dijo la delegada en clase cuando expuso su juego, esta es una asignatura que no se aprueba a la primera.

De la segunda parte, para que hablar. Por lo visto, dijeron los compañeros que en la solución que había por allí rondando, aparecía implementado con un vector. Pufff…vectores…

En clase nos preguntaron si volveríamos a hacer el simulacro de examen o no. En parte si y en parte no. En parte si, porque te enfrentas a lo que va a ser el examen para hacerte una idea. Pero por otra parte no porque salimos todos de allí muy desanimados. Los unos a los otros nos decíamos que si después de estudiar tanto no aprobábamos, una de dos, o nos pegábamos un tiro, nos íbamos a ADE o a un grado superior. Tanto currar para que después los de grado superior cobren más que nosotros y los prefieran. ¡¡¡¡QUÉ DESÁNIMO POR DIOS!!!!

Rezaremos para que una luz nos ilumine en medio de un aula oscura para poder aprobar…

Hasta pronto. Y suerte a todos.

Bienvenidos señoras y señores lectores a la …ÚLTIMA PRÁCTICA DE OCA!!! BIEEEEEEEEEEEEEEEN!!! Ahora tan solo… queda…empollarla….TAN SOLOOOOOOOOOOOOOO!!!

Pues bien, como anécdota comentar que tuvimos que empezar la clase a oscuras jaja, ya que se fue la luz en las aulas y el pasillo pero no en los ordenadores. Al poco tiempo, nuestras plegarias fueron escuchadas XD, Y SE HIZO LA LUZ. Momento en el que, aunque hubiese luz, llegó el infierno.

JMF nos resultó más raro que complicado. Resulta que es otra librería que hay que instalar aparte, e incluso tiene API PROPIO!!!

Lo primero que hicimos fue cotillear el API nuevo, muy parecido al de siempre, pero en el fondo, muy diferente.

Tras esto, para poder utilizarlo, hay que configurarlo en la máquina. Para ello se podía lograr de tres maneras.

Con javac –classpath…. se le dice a la máquina que use este nuevo classpath y se olvide del otro, pero el precio que pagamos es que esta sentencia, sólo vale para un uso del compilador.

En cambio, con la sentencia set CLASSPATH=”.;/ruta completa/jmf.jar;/ruta completa/sound.jar; la ventana se queda configurada mientras se encuentre abierta. En el momento que la cierres y la vuelvas a abrir deberás colocar la sentencia completa de nuevo.

La forma de dejarlo configurado ya para “jamás de los jamases”, es configurarlo en panel de control, bla bla bla, variables de entorno, variables de sistema, como cuando se instala el classpath de java desde cero. Ay (suspiro), aquella época en el que nuestro mayor problema era configurar el java en el ordena de nuestra casa, ay! Bueno, que como ya existe el classpath, le añadimos las nuevas rutas del JMF y santas pascuas.

El objetivo de la práctica, era crear mediante las herramientas que nos ofrece Java Media Framework, un VDCMediaPlayer, vamos, un programa que tenga botones de play, stop,… para el video, y un visualizador.

Para todo esto, hay que utilizar una ventana JFrame de Swing, extraer su contentPane y añadir sus componentes visuales mediante add. Es más fácil leerlo que hacerlo. En el API encontramos lo siguiente sobre él:

Teníamos constancia, por la clase teórica de Rueda, de que existía la interfaz Player, que contenía los métodos getVisualComponent() y getControlPaneComponent(), los cuales utilizaremos para esta práctica:

public java.awt.Component getControlPanelComponent()

public java.awt.Component getVisualComponent()

Para hacernos la vida más fácil también está la clase Manager. Clase que define métodos static y la puedo usar para apoyar el programa.

java.lang.Object
  |
  +--javax.media.Manager

Como no se puede hacer Player p = new Player(…); ¡¡ERROR!! ya que Player es una interfaz, por lo que nos ayudamos de la clase Manager para crear un objeto Player. Un método que contiene Manager es el createPlayer, al que se le puede pasar por parámetro un DataSource, un MediaLocator o una URL (un fichero local se puede escribir como URL), porque necesita un reproductor de algo.

createPlayer

public static Player createPlayer(MediaLocator sourceLocator)
                           throws java.io.IOException,
                                  NoPlayerException

public static Player createPlayer(DataSource source)
                           throws java.io.IOException,
                                  NoPlayerException

public static Player createPlayer(java.net.URL sourceURL)
                           throws java.io.IOException,
                                  NoPlayerException

Una URL se compone de protocolo://destino/recurso, en resumen, compañeros tenemos que escribir file://(la ruta completa). No es válido poner “video.mpg” ya que no sigue la sintaxis.

Uno de nuestro errores fue olvidarnos de Manager y de su createPlayer, de tal forma que dijimos implementamos Player y a saco. Pero era muy engorroso, pesado y nos daba bastantes errores al compilar. Hasta que le dijimos: “Profe, ayúdanos, esto no nos sale y nos estamos haciendo la picha un lío”. Son de estas frases típicas made in Spain, que no las piensas y las sueltas sin mas, a lo que él contestó sin ningún enfado (cosa que agradecemos): “Procura no mezclar las palabras profe y picha en la misma frase.”. Ahora lo recordamos y nos reímos, pero pensándolo fríamente…QUE HABRÁ PENSADO EL PROFE!!! Desde este honrado blog, las más sinceras disculpas.

Después de todo este berenjenal, nos ayudó a recordar, percatándonos de que la manera más fácil era escribir Player p = Manager.createPlayer(…);

En clase se nos recordó lo explicado en la teoría sobre que un Player tiene varios estados: unrealized, realized, prefetched y started. Realized es el estado en el que se encuentra un player cuando es creado por primera vez y no tiene ningún conocimiento acerca de la fuente de datos de entrada. Por esta razón, tardará un tiempo en arrancar desconocido para nosotros. Por lo que, antes de hacer el getVisualComponent, hay que colocar p.realized(), porque no podemos reservar un tamaño para el video si no sé su tamaño. p.realized() calcula varias cosas. Realized salta al estado “me he dado cuenta” y no puedo llamar al getVisualComponent() antes de pasar a realized. Para saber cuando ocurre llamo a un escuchador de eventos.

Al player le creamos un controllerListener y se lo añadimos al panel.

public void controllerUpdate(ControllerEvent event)

ControllerListener sólo tiene un método, que hay que redefinir en nuestra clase. Éste se lanza cuando ocurre un evento. Es un método para todos los eventos, entonces, dentro del método, hay que distinguir entre los diferentes eventos que nos pueden aparecer. Cuando ocurra un evento llegará un objeto que hereda de MediaEvent.

java.lang.Object
  |
  +--java.util.EventObject
        |
        +--javax.media.MediaEvent

public MediaEvent(java.lang.Object source)

Podemos hacer un instanceOf de tal forma que si llega un evento, ya se puede actuar, y sacamos el getVisualComponent(). El evento que de verdad nos interesa es RealizeCompleteEvent.

java.lang.Object
  |
  +--java.util.EventObject
        |
        +--javax.media.MediaEvent
              |
              +--javax.media.ControllerEvent
                    |
                    +--javax.media.TransitionEvent
                          |
                          +--javax.media.RealizeCompleteEvent

public RealizeCompleteEvent(Controller from,
                            int previous,
                            int current,
                            int target)

Otra forma de hacerlo es con hilos. Se puede colocar entre el método realized() y el getVisualComponent(), un Thread.sleep(..) a un tiempo, el que se quiera. Este es el camino erróneo, porque con el tiempo que se coloque en el sleep, si cojo tiempo de más, desperdicio tiempo de espera, y si cojo de menos, nos sale el tiro por la culata. Además de que hilos da mucho problemas.

Esta es una mala solución. En lugar de esperar un tiempo arbitrario, lo mejor es programar con el modo de controlar los eventos, el escuchador,… y toda esa parrafada.

¡¡CUIDADO!! Advertencia, el formato de video que se puede usar en JMF depende de la versión del JMF instalado. Si se intenta usar uno que no está instalado, saltará una popi excepción, UnableToHandleFormatException, o algo parecido.

Teóricamente sabíamos lo que había que hacer, pero después estabas frente al ordenador como si tuvieses un toro delante. Después de intentar implementar la interfaz Player, usamos a Manager. Llegados a este punto, nos perdimos. No sabíamos como seguir. Miramos en el API, le dimos muchas vueltas,… nada sirvió.

No paraban de saltarnos errores. Al principio tonterías de que faltaba importar paquetes. Hasta que llegó un momento que ni comprendimos los errores que salían. Intentamos seguir las instrucciones que se nos explicaron durante la clase, pero no sacábamos nada en claro, tan solo errores.

Hay que tener especial cuidado con el control de excepciones. A nosotros nos salieron el famosísimo IOException y MediaException, los cuales eliminamos rápidamente con un try y catch.

java.lang.Object
  |
  +--java.lang.Throwable
        |
        +--java.lang.Exception
              |
              +--javax.media.MediaException

No logramos programar la clase.

Cuando terminó la hora, una compañera nos ayudó muuuuuuuuuuuuuuuuucho. Ella nos explicó que debíamos hacer para resolverlo. Lo resolvió como decía el profe, como nosotros intentamos, pero hay veces que te atascas y no sale ni para atrás. Aun así, nos pareció una práctica muy rara más que complicada. Es que es como siempre, una vez que la ves hecho lo entiendes, pero sino, no sabes. Esperamos que con lo que aprendimos en el aula y con la ayuda de nuestra compi ahora seamos capaces de resolver los JMF.

PUES AHORA TOCA DESPEDIRSE…L

Hacer el blog ha sido de una gran ayuda. Nos dábamos cuenta, a la hora de intentar explicar las cosas, qué no sabíamos y qué debíamos estudiar más. Además del pique que nos traíamos para ver quien de la clase colgaba primero la práctica jaja, hubo gente que la colgó a la media hora de empezar la clase, sin ni si quiera acabar jaja.

Leer los blogs de los compañeros también ayuda bastante pero eso de dejarles comentarios, se nos olvidaba siempre la verdad.

El último post que colguemos será, seguramente para dar nuestras impresiones sobre el juego, y quizá, por qué no, sobre la asignatura. Quién sabe que futuro llegará a tener este blog.

HASTA PRONTO!!! J

Uff la última práctica de swing… NOS AUTO-DAMOS ÁNIMO Y TAMBIÉN LO MANDAMOS A LOS LECTORES!!! Ya están aquí los exámenes, así que estudiar bastante para estar todos juntos de nuevo el año que viene.

En fin, a lo que íbamos. Al hacer esta práctica nos percatamos de que SWING es un tema muy extenso, por esta razón es imposible aprenderse todos los métodos y clases que existen en este campo, que hace cada uno,… en definitiva, ES IMPOSIBLE APRENDER SWING PERFECTAMENTE!! Entonces, intentaremos enterarnos de todo lo que podamos hasta que ya nuestros cerebros digan: “Hasta aquí he llegao’ chabalita.”.

A continuación lo que entendimos y lo que no en esta sesión.

Esta práctica trataba básicamente de la programación orientada eventos. Para entenderlo hay que comprender que los medios que teníamos para comunicarnos con un programa no son ágiles, no son adecuados (el manejador de ventana, la entrada estándar, los argumentos,..), por ello se desarrollaron los eventos.

Volviendo al tema de los hilos. Los eventos salen del hilo raiz, main. El thread main ejecuta el programa. Todos los eventos que se van produciendo entran en una cola de eventos, los cuales salen de uno en uno hacia el hilo bifurcado, llamado Event-Dispaching Thread. El event-dispaching thread se activa en cuanto invocas a cualquiera de los métodos setVisible(), show(), o pack(). El hilo que procesa los eventos (event-dispaching thread) trabaja secuencialmente, mientras que el hilo del programa (main) procesa eventos secuencialmente también, pero son distintos.

Los eventos no hay que utilizarlos para cualquier cosa. JLabel es pasivo y no necesita un escuchador. En cambio, JButton es activo y sobre él puedo producir un evento el cual será procesado por un objeto actionListener. Hay que añadir un actionListener, uan interfaz, con un método actionPerformed. Tengo un objeto de la clase que implementa actionListener para el botón:

b.addActionListener(o);

Para el escuchador o bien:

- creo una clase interna,

- o una clase que lo implemente y mando el objeto.

Cuando sea necesario utilizar actionListener, hay que importar java.awt.event;

Uno de los errores que cometimos mientras programábamos, fue que queríamos importar este paquete entero con esa sentencia. ERROR!!! Recordad que para importar el paquete event entero hay que colocar la sentencia java.awt.event.*;

Al principio de la clase programamos una clase en la que se mostrase una ventana con un botón, cada vez se pulsase dicho botón debía aparecer un texto por la salida estándar. Después de habernos peleado con el juego esto fue fácil de hacer. Lo más cómodo para hacer una clase para que aparezca una ventana, es hacer que ésta herede de JFrame. También la hicimos implementar de la clase actionListener, el escuchador para el botón, así se provocar el evento deseado. Como implementamos de actionListener tan sólo hay que escribir un método, el único que tiene, actionPerformed:

public interface ActionListener
extends EventListener

void actionPerformed(ActionEvent e)

Después programamos una clase que presentase una ventana con un botón y una etiqueta, y cuando se pulse el botón, cambiar el color de la etiqueta. Así que, cogimos el programa anterior con un copy paste XD y lo modificamos para lograr el objetivo. Para colocarlo pusimos un GridLayout con dos filas y cero columnas, de tal forma que se colocarían el botón y debajo de él la etiqueta. Tuvimos que modificar el actionPerformed(). En él dejamos la sentencia colocada anteriormente, y añadimos un setBackground, para poner un color de fondo a la etiqueta, y un setOpaque a true. Pero no está muy bien hecho, ya que tan solo cambia de color cuando se pulsa el botón la primera vez, las siguientes veces ya no cambia. No sabemos que hacer para que se nos cambie de color la etiqueta cada vez que se pulse el botón.

Así nos quedó:

El último programa al que llegamos en esta sesión, fue en el que había que programar una clase que presente lo que se pedía en el ejercicio anterior, pero además, también se cambie de color la etiqueta cada vez que se pulse enter. Esta ya si que no llegamos ni si quiera a que nos compilase. El profe, al ver nuestro código cuando le hicimos una pregunta (bueno, en realidad unas cuantas jeje) nos aconsejó que el constructor tan solo inicializásemos los atributos y la parrafada la colocásemos en otro lado, verdad como un templo, por lo que para hacer esta clase lo pusimos como él nos aconsejó.

Para solucionar ésto, volvimos a pensar en los dichosos hilos. Debíamos hacer que se ejecutasen en distintas partes la interfaz gráfica y el teclado. Para hacer lo del enter, a última hora de clase se nos desveló el secreto, se hacía con un BufferedReader, como toda la vida. Cuando se haya ejecutado el readLine(), cuando se haya pulsado el enter, en el label se cambiará el color. Esto cambio de color queremos que lo haga el event-dispaching thread, principalmente con el método run(). El hilo main ha estado inactivo hasta ahora. Así, el main lanza los eventos gráficos a la cola de eventos y se procesará donde debe, el event-dispaching thread  procesa los eventos gráficos.

Este ejercicio nos resultó bastante “complicaillo”, veremos si ahora que ya tenemos esa “luz”, somos capaces de solucionarlo.

YA TAN SOLO QUEDA UNA PRÁCTICA, YUJUUU!!! Digo, uy que penaa!!

Hasta la siguiente y última compañeros.

Hola!! Sentimos habernos atrasado un poco…pero ya se acercan los exámenes y entre prácticas, el estudio, el agobio,… todo se junta. Aunque no os preocupéis, porque dentro de poco vendrá el día 1 de julio, ya veréis que está a la vuelta de la esquina.

Pues bien, la mañana en la que hicimos esta práctica se comentó que era una práctica importante,

Lo primero sobre lo que hablamos fue de los procesos. Acto seguido escribiremos lo que entendimos sobre lo que se dijo en clase. En el administrador de tareas se ven los procesos de un ordenador. Los programas necesitan procesos para funcionar. Un programa, en realidad, no se diferencia en nada de un proceso, son lo mismo. Son líneas de código compilado que se está ejecutando. Si tenemos 50 procesos, por ejemplo, ejecutándose en un pc, en realidad no están ejecutándose a la vez. En un sistema operativo multitarea tengo muchos procesos. Entonces nos surgió la duda, ¿es posible ejecutar 5 procesos al mismo tiempo? No, tan solo ejecuta un proceso en cada momento, pero los ordenadores trabajan en milisegundos, por lo que ni notamos que van de uno en uno. Tenemos 5 procesos pero se ejecuta uno cada vez. Un ejemplo es el antivirus, está ejecutando el rastreo del ordenata pero también lo hace si se cierra la ventana.

Después, comenzamos analizando el código de la clase Ding, bastante sencillo. Lo compilamos y ejecutamos. Cada vez que le des al enter, aparece por pantalla el mensaje DING! Realizamos la misma operación con la clase Dong, es decir, compilamos y ejecutamos. Con este programita, cada segundo se imprimía DONG! por pantalla. A la hora de entender el código de este ya tuvimos  que tirar del API porque no sabíamos que significaba la línea: Thread.sleep(1000); Buscamos la palabra thread, y su significado era hilo. Apareció lo siguiente sobre Thread en el API:

java.lang.Object
  java.lang.Thread

public class Thread
extends Object
implements Runnable

     class PrimeThread extends Thread {
         long minPrime;
         PrimeThread(long minPrime) {
             this.minPrime = minPrime;
         }
 
         public void run() {
             // compute primes larger than minPrime
              . . .
         }
     }
 

     PrimeThread p = new PrimeThread(143);
     p.start();
 

     class PrimeRun implements Runnable {
         long minPrime;
         PrimeRun(long minPrime) {
             this.minPrime = minPrime;
         }
 
         public void run() {
             // compute primes larger than minPrime
              . . .
         }
     }
 

     PrimeRun p = new PrimeRun(143);
     new Thread(p).start();
 

Nos quedó claro que Thread y Runnable iban dadas de la mano, pero eso lo miraremos más adelante. Ahora había que averiguar cuál era la función del método sleep.

public static void sleep(long millis)throws InterruptedException

Entonces entendimos porque aparecía un 1000 como parámetro, había que pasarle por parámetro el tiempo que quieres que cese la ejecución del hilo en términos de milisegundos, y como todos sabemos, un segundo son 1000 milisegundos.

Y pensamos, ¿por qué llama al método directamente colocando el nombre de la clase en lugar de llamarlo con un objeto? Esto se puede hacer porque dicho método es static.

Seguimos con la clase DingDongPoor, la cual probamos y no funcionaba de acuerdo con lo esperado. Esperábamos que cada segundo saliese DONG! y que cada vez que pulsábamos el enter dijese DING! Pero no. Pulsábamos el enter y aparecía

DONG!

DING!

DONG!

y esperaba a que el usuario volviese a dar al enter, sino no hacía nada. Parece ser que no podía hacer las dos cosas al mismo tiempo.

Hay sistemas operativos que establecen prioridades en los distintos procesos como Linux. Se pueden tener dos hilos de ejecución asociados al mismo proceso.

Para hacer que DING! y DONG! se ejecuten a la vez hay que tener en cuenta lo siguiente. Se puede resolver este problema de dos maneras. Una es implementando la internaz Runnable en la clase principal, y la otra es mediante la clase interna Runnable.

Existe una interfaz llamada Runnable que tan solo tiene el método public void run( ), y se crean instancias de él como Runnable r = new Runnable( );

public interface Runnable

void run()

De la primera manera, es crear una clase interna Runnable en la clase principal. Desde fuera de la clase no se ve, a no ser que sea un atributo public. r es un objeto más. Thread es el encargado de hacer la bifurcación.