No me toques los Weblog’s

Buenas tardes amigos, por fin llegamos a Swing y parece que la cosa se va relajando, por lo menos en esta práctica. La hacemos hoy para así tener un puente sin preocupaciones de prácticas que si no luego es una agonia xD.

Ejercicio 1

No los vamos a resolver, son simplemente de añadir o cambiar cosas para ver las diferencias en la ventana que aparece al compilar y ejecutar. Lo principal era aprender a usar los métodos para variar aspectos de Frame’s, Label’s y Panel’s. Aquí descubrimos la mayor virtud del API, recordad que las clases en Swing empiezan siempre por “J”. Para ello comenzamos con el entrañable “Hello World”.

Los métodos más importantes respecto a los Frames (ventana en sí) fueron (todos a partir del objeto frame.* ):

setDefaultCloseOperation() : Este método te permite realizar hasta 4 operaciones distintas, en este caso fue “EXIT_ON_CLOSE”, para cerrar la ventana que aparecía.

setSize(int width, int height) : Para dar el tamaño a nuestra ventana, primero el ancho y luego el alto.

setVisible(boolean b) : Este es el método más importante (o eso creemos), ya que si “b” es false, la ventana no se mostrará, tiene que estar obligatoriamente en true

En cuanto a Label (etiqueta), a partir del objeto label.* :

setOpaque(boolean b) : Otro parecido a setVisible() pero que lo que hace es que puedas cambiar el color de la etiqueta, “volviendola opaca” por así decirlo, ya que por definición es transparente.

setBackground(Color bg) : Da color a la etiqueta, a partir de una serie de colores que puedes importar: red, blue, green… o a partir de coordenadas que des (el negro es 000000 y el blanco FFFFFF por ejemplo)

Respecto a Panel, existen dos métodos (tengo mis dudas pero creo que ambos pertenecen aquí):

getContentPane() : Para meter el contenedor o “Panel” dentro de la ventana o “Frame”

add(label) : Para añadir al “cosas” al contenedor, en este caso una etiqueta o Label.

En cuanto a la clase HelloWorldGUIDelayed, el efecto que causa es un retardo en la aparición de la ventana, y al cambiar SystemExit(1) por SystemExit(0) lo que hace es bloquear la aparicion de la ventana.

Ejercicio 2:

El ejercicio comienza pidiendo crear una clase “HelloWorldGUIDeaf” que omita usar el método del manejador de ventanas que explica la teoria. Quitando el método setDefaultCloseOperation(), no existe ninguna modificación, al ejecutar aparece la misma ventana y se cierra “clickeando” en el aspa como siempre.

La clase “HelloWorldGUIUndecorated” crea un cuadro gris sin bordes ni nada en donde esta colocada nuestra etiqueta “Hello World”. Para comprobarlo hay que instanciar el método setUndecorated(true) a Frame… Una cosa, hay que colocarlo antes de setVisible()!!!

Por ultimo, el uso del “Look&Feel” no se muestra claramente, ya que a nosotros nos sale siempre el decorado por defecto de Java xD.

Ejercicio 3:

Vamos a crear nuestra ventana con fondo negro y tamaño máximo y letra blanca. Lo primero sin problema, ya lo hicimos en la primera parte de la práctica usando setOpaque(true) y setBackground(Color.black) habiendo importado previamente la clase java.awt.Color; la segunda parte, es decir el tamaño máximo nos llevo más problemas, ya que no encontramos ningún método, y tiramos por la cuenta de la vieja… si la resolución es de 1024 x 768, probemos así y… Eureka!! salio bien!!

Aquí está lo más adelantado a lo que hemos llegado, ni sale el texto blanco, ni centrado ni nada, pero tras incontables horas es lo más avanzado que hemos logrado y estamos muy orgullosos… asi que os toca verlo xD. Pulsando en la imagen, aparecera en grande y podreis observar esta chapuza/obra de arte en todo su esplendor

Os dejamos amigos, no sin dejar nuestra frase habitual…

Frase de la semana: A caballo regalado, ya tenemos un caballo Variación de la frase hecha en mi pueblo, muestra que lo importante es la intención en los regalos, no realmente su valor como tal…

Muy buenas queridos lectores. Vaya con el tetris, los arrays, las colas, pilas, videojuego, prácticas…. Nos está empezando a doler la cabeza. Poco a poco se nota como esto ya no es tan fácil y que es esencial manejar bien los conceptos dados en clase y desenvolvernos bien en el API porque sino….

Pues bien, en la práctica 6 manejamos colas y pilas utilizando memoria estática (arrays). Ahora, el objetivo principal de la práctica 7 es comprender el funcionamiento de la memoria dinámica y las posibilidades que nos aporta en java. Básicamente tendremos que coger todas las partes donde utilizamos arrays en la practica 6 y sustituirlas por una nueva forma de plantear el problema, utilizando estructuras dinámicas. Por lo menos todo el código ya está escrito, aunque me temo que en este caso, había que usar el cerebro un poco más de lo normal.

Desde luego para afrontar las cuestiones deberíamos de tener claro que los tamaños van a ser dinámicos con lo cual no tendremos que preocuparnos de definirlos con anterioridad pudiendo meter lo que queramos.

Una de las principales ventajas de la memoria dinámica es que no ocupa recursos ya que no tiene que prevenir reservando memoria que cree que va a necesitar de modo que aprovecha mejor la memoria.

Saludos y hasta otra amigos!!

Frase de la semana: El hombre ha de fijar un final para la guerra. Si no, la guerra fijará un final para el hombre. John F. Kennedy

Cada vez nos va costando más, esto empieza a ser difícil, creimos que sería facil pero nada de nada…

Esta semana, la práctica trataba sobre pilas y colas y en ello andamos liados. Esta enfocada hacia la creación de un Tetris, no entero, su algoritmo sin la parte gráfica.

Lo primero que hicimos es atacar a las piezas, lo cual vimos más fácil ya que creimos que se podia hacer mediante char ya que las piezas tienen forma parecida a diversas letras… la “L” , la “I”, y demás…

Utilizamos un sistema de coordenadas “x” e “y” para saber donde colocar cada pieza :

//Variables de coordenadas

private int x;

private int y;

//Inicio a 0, ya que no hay ningun lugar para las piezas en el inicio

public Pieza() {
x = 0;

y = 0;

}

//Método para mover las piezas

public void mover(int x, int y)
{
this.x = x;
this.y = y;
}

Luego creamos una cola a modo de “contenedor” para así almacenar las piezas creadas anteriormente, con sus límites incluidos (es decir, avisos por si la cola está llena y quiero introducir algo, si está vacia y quiero sacar algo… ). Esto lo logramos ver a nivel teórico, ya que en el práctico nos enrevesamos un poquito y no nos dejaba aplicar el método desencolar de manera correcta, os le colgamos aquí a ver si veis el fallo que tiene…

//Creamos nuestro contenedor llamando a los objetos de la clase Pieza.

public Pieza elementos[];

//Constructor (para crear nuestro contenedor y poder maniobrar con él)

public Contenedor (int elementosTotales) {

elementos = new Pieza (elementosTotales);

}

// Método desencolar (creemos que aquí está el fallo)

public void desencolarPieza() {

int primerElemento;
Pieza elemento = elementos[primerElemento];
return elemento;
}

A partir de aquí no pudimos seguir más, pero os dejamos una respuesta a la pregunta de si se puede usar la Programación Orientada a Objetos (POO). La respuesta es que sí, ya que las piezas son consideradas objetos.

Esperemos haber servido a alguien de ayuda, nos despedimos hasta la semana que viene. Un saludo a todos.

Frase de la semana: Cuando quieras que otro no hable, calla tú primero. Lucio Anneo Séneca

Disculpadnos, pero tuvimos un error de pardillo, en vez de publicar dimos a guardar y nuestra practica quedó en el olvido.

 Aunque sea a destiempo colgaremos los códigos por si a alguien le vienen bien…

 Clase miembro:

public class Miembro { 

    protected String nombre; 

   protected int modificadores = 0;

          this.modificadores = modificadores;

    public String toString() {

public class Atributo extends Miembro { 

      public Atributo(String nombre, int modificadores, String tipo ) {

            this.tipo = tipo;

     public String toString() {

public class Metodo extends Miembro {

       Parametro[] parametros = null;

              this.tipoRetorno = tipoRetorno;             this.parametros = parametros;

        public String toString() {

                return null;

Buenos días a todos.

Os escribimos en la más cruel desesperación, se nos está atragantando esta práctica, un poquito bastante por ser suaves.

 En esta práctica tratamos básicamente el concepto de herencia, característica esencial de la programación orientada a objetos. Utilizaremos las clases de la práctica anterior, (atributo.java, método.java y constructor.java) con el fin de aplicar herencia entre ellas. Lo que hay que hacer está claro, pero el problema viene cuando tenemos que implementar el método toString ya que no sabemos si lo estamos haciendo bien o no.

Implementamos los constructores y los métodos toString() de atributo.java, metodo.java, constructor.java, acorde con el enunciado de la práctica y siguiendo el mismo patrón para todos los constructores. Como ejemplo, el constructor de Metodo.java:

public Metodo(String nombre, int modificadores, String tipoRetorno, Parametro[] parametros) {

El método toString de la clase Metodo nos está “Tocando los Weblogs”, como dice el título de nuestro blog, y lo peor de todo es que la solución sera una cosa sencilla, pero estamos desquiciados ya, hemos probado de todo, con un bucle for que recorriera el array parametros, pero luego no sabiamos como introducirlo dentro del return; también usando la sentencia parametros[i];y la que más nos convenció de todas, el uso de la sentencia Modifier.toString( modificador ); ……pero no sabemos como usarlo… Conclusión: Ó esto es muy difícil ó somos unos zotes. Nos inclinamos por la segunda, si alguien pudiera resolvernos la duda, nos haría sentirnos muy humillados y al mismo tiempo felices.

 Y después queda nuestra segunda gran duda, no entendemos la “definición” del método java.lang.reflect.Field; es un inglés muy técnico para nuestras capacidades.

 Bueno amigos, os dejamos por esta semana, lamentando no poder servir de ayuda y tener que ser ayudados… pero esperemos que otra semana seamos nosotros los que os ayudemos.

Un saludo a todos

Postdata: Creemos que sería interesante poder disponer de las soluciones de cada práctica, aunque fuera con un margen de 10 o 15 días para evitar trampas al redactar los blogs, pero ahora mismo, las realizamos con nuestra mejor intención y no sabemos si están perfectas, regulares, o son un desastre…

Frase semanal: Cuando un millonario pasa a mejor vida… sus herederos también Steve McCallaghan

Buenas a todos……..

Segunda practica realizada y algunas dudas aunque en rasgos generales creo que algo hemos avanzado debido a que la gran mayoría de los apartados los entendimos…

EJERCICIO 1.

Para empezar, tratamos las carpetas que nos pedía el ejercicio 1 y en los siguientes apartados de este ejercicio no hubo problemas ya que se limitaba saber utilizar los métodos pow() y sqrt() de la clase Math y la clase java.lang.Random para generar un numero aleatorio.

EJERCICIO 2.

El ejercicio 2 ya nos comenzó a plantear serias dudas tanto en aserciones como en trazas de definición, que fueron resueltas por el profesor de prácticas, lo primero, no entendiamos la diferencia entre poner “System.out” o “System.err” ya que ambas se mostraban por pantalla. Al final concretamos que la diferencia básicamente era que “System.err” además de imprimir el mensaje por pantalla (solo si añades “System.err.PRINTLN”) te da la posibilidad de redirigirlo a otro punto. Es lo que hemos llegado a entender y nos parece lógico, pero no estamos al 100% seguros de su veracidad por eso nos gustaría saber si hay más gente de acuerdo con esto. Los conceptos de traza de depuración y aserción con las explicaciones de la práctica nos quedaron bastante claros.

EJERCICIO 3.

Os lo resolvemos a continuacion para que podais comparar con los vuestros. Nosotros lo hemos probado y funciona, eso si, tienen que estar archivo a copiar y el programa en el mismo directorio…

import java.io.*;

public class Cp{

public static void main(String args[]) throws IOException {
//pedir los ficheros de fuente y destino
String fuente, destino;
System.out.println(“Introduce el fichero fuente:”);
BufferedReader teclado = new BufferedReader(new InputStreamReader(System.in));
fuente = teclado.readLine();
File src = new File(fuente + “.txt”);
System.out.println(“Introduce el fichero destino:”);
destino = teclado.readLine();
File dst = new File(destino + “.txt”);

Cp cp1 = new Cp();
cp1.copy(src,dst);
System.out.println(“fichero copiado”);
}

void copy(File src, File dst) throws IOException {
InputStream in = new FileInputStream(src);
OutputStream out = new FileOutputStream(dst);

// Transfer bytes from in to out
byte[] buf = new byte[1024];
int len;
while ((len = in.read(buf)) > 0) {
out.write(buf, 0, len);
}
in.close();
out.close();
}
}

Ahora os lo explicaremos brevemente porque nos parece bastante interesante ya que estamos utilizando un programa hecho por nosotros que interactue con ficheros que tengamos:

Como en todas las prácticas de java, nos dan una estructura en este caso del método el (copy), y a partir de ahí tendremos que añadir código, consultando hasta la saciedad el API. (API = diccionario de java).

El método “copy” realiza la siguiente función: copia los datos de un fichero a otro. Lo que debiamos hacer era hallar el camino para duplicar el fichero.

Pasos que seguimos para realizar el programa:

1. Para capturar los nombres del fichero que se quiere copiar (fuente) y el que será copiado (destino) utilizamos la clase BufferedReader. (Recordad lanzar excepciones al introducir datos por pantalla)

2. En el API consultamos como crear el fichero y llegamos a la conclusión de usar el siguiente constructor: public File(String pathname). En este ejercicio crearemos el fichero fuente como File src = new File(fuente + “.txt”); y el fichero destino como File dst = new File(destino + “.txt”);

3. Para hacer la prueba probamos a meter Cp.java en Mis Documentos y crear el archivo prueba.txt en la misma carpeta. Compilamos y ejecutamos el programa introduciendo como fichero fuente “prueba” y como fichero destino “pruebaSuperada”. Aparecerá en el mismo directorio el archivo “pruebaSuperada.txt”.

EJERCICIO 4.

Básicamente era un ejercicio de tratamiento de excepciones con las estructuras try y catch.

Esto es todo amigos, esperamos haber servido de ayuda. Lo único negativo es que no hemos conseguido hacer el ejercicio 5, el ahorcado, ya que tenemos problemas a la hora de plantearlo. Un saludo

Frase de la semana: “Siempre recordare esa noche en la cual Mike y yo nos compenetramos para meter 70 puntos entre ambos” Stacey King (Después del partido Cleveland-Bulls en el que Jordan metio 69 puntos).