Aquellos que habemos programado alguna que otra vez, sabemos lo que es bloquearse con un código que no funciona y darle vueltas y vueltas hasta llegar a la extenuación. Además, sabemos que muchas veces ese esfuerzo parece no dar el resultado rápidamente, sino que lo que nos pasa es que cada vez estamos más y más confundidos, y por mucho que nos concentremos y miremos el código, no aparece la causa del problema, al menos en un tiempo razonable. El resultado puede ser el aumento del nerviosismo, sobre todo si esa pieza tiene que entregarse lo antes posible.

Comentando este tema con algunos de mis alumnos, expuse algunos “trucos” que pueden ayudar a desbloquearnos cuando estamos en uno de esos casos. Me gustan sobre todo dos:

1. Verbalizar el código: consiste en buscar a alguien (no es imprescindible aunque recomendable ya que alguien podría pensar que estás loco/a al hablar solo/a) y explicarle el código en voz alta (es importante que sea verbalizado). En la mayoría de los casos, tú mismo verás dónde estaba el problema. Y si no es así, la persona a la que lo explicas quizá lo vea. Hace unos años tuve el privilegio de tener como profesor de matemáticas a Gil Panadés. Me sorprendió como Gil verbalizaba aquellos problemas matemáticos cuando había algún atasco. Además de sus explicaciones matemáticas, esa fue una lección que nunca olvidaré.
2. Déjalo un momento y haz algo que te guste: lo del momento es variable, pero tampoco se trata de irse de compras durante toda la mañana. Si fumas, sal y fúmate un cigarrillo, da caminando una vuelta a la manzana, cualquier cosa que te haga dejar la pantalla y el teclado. De todos es sabido que los momentos “ajá” o “eureka” ocurren cuando nuestro cerebro exprimenta sinapsis, conectando neuronas. Como dijo uno de mis alumnos: “Para conectar hay que desconectar“.

Estos puntos no son nada nuevo. En su ensayo (que recomiendo) “Una técnica para producir ideas“, James Webb Young nos cuenta cómo, después de hacer el esfuerzo y ver que ya no podemos seguir más, es necesario desconectar para dejar que nuestro cerebro nos muestre las ideas creativas que estamos buscando. Si, he dicho ideas creativas. La creatividad es una palabra que se intenta asociar a unas disciplinas artísticas, pero yo no lo creo así. Para mí, la creatividad está en todas partes, desde fregando los platos hasta las matemáticas de alto nivel, y cómo no, al codificar nuestros programas también.

A partir de los siguientes posts se tendrá en cuenta este cambio. Dentro de poco saldrán a la luz nuevos posts, de un nuevo proyecto a desarrollar para Android.

Saludos.

En la columna derecha de este blog encontrarás el link de descarga del documento en .pdf. Siéntete libre de bajarlo y compartirlo con todas aquellas personas a las que les pueda ser útil. Está licenciado como Creative Commons. Si, una vez leído, te ha gustado y lo quieres en papel o en formato kindle, también podrás adquirirlo a partir de los enlaces incluidos.

Desde aquí te recomiendo su lectura, que creo que te será beneficiosa si tienes inquietud sobre las bases teóricas de la programación. Siéntete libre de comentar tus impresiones sobre este libro en este mismo blog.

Un saludo.

Veamos los cambios.

Clase monigote.java.

• Se ha añadido el método getError_pizquierda(), para poder consultarlo desde el objeto de la clase Escenario.

Clase juego.java.

En esta clase se han efectuado cambios que afectan a lo descrito en el post anterior, debido al funcionamiento interno de invalidate(). Si nos acordamos, invalidate() fuerza el repintado del juego, controlado por la clase Escenario. El tema es que invalidate() funciona de manera concurrente, por lo que se daban casos en los que se acababa el juego, pero no salía el mensaje correspondiente. Se ha optado por cambiar la lógica del código de forma que las comprobaciones de fin de juego se hagan forzosamente cuando haya acabado el repintado, así que se han trasladado como líneas de código al final del método onDraw() de la clase Escenario.java.

Este cambio ha supuesto modificar la visibilidad de los métodos palabra_acertada() y dialogo_fin_juego() de la clase juego.java, cambiándolos de private a public.

Además se ha añadido otro método, de nombre monigote_entero() y con visibilidad public, cuya finalidad es ayudarnos a saber si el monigote se ha completado, como parte del proceso de comprobación. Queda de la siguiente forma:

public boolean monigote_entero()
{
return escenario.getPalabra_juego().getLetras_falladas().length() >= escenario.getMonigote().getError_pizquierda();
}

Clase Escenario.java.

• Se ha añadido el método getMonigote():

public Monigote getMonigote() {
return monigote;
}

• Se ha incluido, como ya se ha explicado antes, la lógica del control de fin de juego, al final de onDraw(), quedando así:

…

if(juego.palabra_acertada())
{
juego.dialogo_fin_juego(true);

}
else
{

// Control del fin de juego cuando se completa el monigote

if(juego.monigote_entero())
{
juego.dialogo_fin_juego(false);
}
}

…

Ahora, cuando completamos el monigote, nos sale el siguiente mensaje:

Si quieres, puedes descargar los fuentes de este desarrollo, hasta este nivel, haciendo click aquí.

¡Hasta el próximo post!

¿Qué es Robiol.org?.

Robiol.org es un proyecto colaborativo. La idea es que, a semejanza de los proyectos de desarrollo de software libre, personas con la única intención de ayudar en algo que redunde en beneficio de la comunidad libre quieran formar parte de él.

¿En qué consiste exactamente este proyecto?.

Consiste en generar información sobre el desarrollo de software en entornos Android. Ese es el objetivo: información útil.

¿Quien puede formar parte de este proyecto?.

Cualquier persona con ganas de compartir conocimientos útiles sobre el desarrollo de programas para Android.

¿Que cómo se forma parte de él?.

De varias maneras:

• Generando artículos, notas interesantes, tutoriales, videotutoriales,… sobre desarrollo en Android.
• Traduciendo textos existentes a otros idiomas.
• Difundiendo la existencia de este proyecto o de su información por la red.
• Cualquier otra manera que ayude a que más personas puedan beneficiarse de la información publicada.

Por supuesto, seguro que surgirán nuevas ideas. Eso sería agradecido por la comunidad.

¿Existen algunas bases?.

Son pocas:

• Todos los artículos, notas interesantes, tutoriales, videotutoriales,… u otra información que se publique estará moderada antes de hacerse pública.
• Los documentos publicados se licencian bajo Creative Commons (by-nc-sa) 3.0. El hecho de enviarlos para su publicación supone la conformidad por parte del autor sobre este punto.
• El autor será libre de retirarlos si así lo desea, en cualquier momento.

Si alguien se ha decidido, ¿cuál es el siguiente paso?.

Muy sencillo. Simplemente envía un mail a isidro@robiol.org.

Un saludo.

Veamos las modificaciones…

Clase palabra.java

• Se ha creado un nuevo atributo de clase, de nombre ocurrencias_acertadas, cuyo objetivo es ir almacenando la cantidad de letras (repetidas o no) acertadas por el jugador. Este atributo nos permitirá saber si el jugador ha conseguido acertarlas todas. Ha sido necesario crear los métodos get… y set… para la manipulación de este atributo.
• Se ha modificado el método pinta_letra() para poder actualizar el atributo ocurrencias_acertadas. Lo que se ha hecho es inicializarlo a cero justo antes del bucle for y sumarle + 1 dentro del bucle while. Para estas actualizaciones se ha utilizado el método set… creado antes. El método pinta_letra queda así:

public void pinta_letra()
{

// método que “pinta” todas las ocurrencias de una letra

int inicio=0;
int i = 0;
boolean letra_pintada = false;
String letra_actual;

posicion_inicio =  munyeco.getdatosmonigote().getPdinfder();
setOcurrencias_acertadas(0);

for (i=0;i<getLetras_acertadas().length();i++)
{

letra_actual = letra_de_acertadas(i);
letra_pintada = false;
inicio = 0;

while(!letra_pintada)
{

inicio = getPalabra_en_curso().indexOf(letra_actual, inicio);
if(inicio == -1)

{
letra_pintada = true;
}
else
{

lienzo.drawText(letra_actual,
posicion_inicio + ((tamanyo_linea + espacio_entre) * inicio),
munyeco.getdatosmonigote().getPdinf() + espacio_abajo,
pincel_linea);

setOcurrencias_acertadas(getOcurrencias_acertadas()+1);

inicio++;

}

}

}

}

Clase Juego.java

• Se ha creado el método palabra_acertada(), para que devuelva verdadero si se comprueba que es así y falso en el caso contrario. Queda así:

private boolean palabra_acertada()
{

return escenario.getPalabra_juego().getPalabra_en_curso().length() == escenario.getPalabra_juego().getOcurrencias_acertadas()+1;

}

• Se ha modificado el archi-conocido método onKeyDown(), para controlar el proceso de comprobación. Se ha añadido el siguiente código al final:

…

if(palabra_acertada())
{
dialogo_fin_juego(true);
}

…

• Se han añadido dos atributos de clase para el mensaje de alerta. Son especialmente importantes, por los que los detallo:

private AlertDialog.Builder creador;
private AlertDialog alerta_finjuego;

Estos dos atributos utilizarán AlertDialog (predefinido), para mostrar el mensaje. El primero (creador), lo necesitamos para “configurar” la alerta, mientras que el segundo es el que utilizaremos para mostrarlo una vez configurado.

• Se ha creado el método dialogo_fin_juego(). Este es el método que hace el trabajo de presentar la alerta, utilizando los atributos de clase anteriores. Su aspecto es el siguiente:

private void dialogo_fin_juego(boolean ha_ganado)
{

if(creador == null)
{

creador = new AlertDialog.Builder(this);
creador.setPositiveButton(“Aceptar”,
new DialogInterface.OnClickListener()

{

public void onClick(DialogInterface dialog, int id) {

Juego.this.finish();

}

});

}

if(ha_ganado)
{

creador.setMessage(“¡Enhorabuena!”);

}
else
{

creador.setMessage(“¡Inténtalo de nuevo!”);

}

if(alerta_finjuego == null)
{

alerta_finjuego = creador.create();

}

alerta_finjuego.show();

}

Ahora, cuando se acierta la palabra, aparece el siguiente mensaje:

Si quieres, puedes descargarte los fuentes a este nivel de desarrollo haciendo clic aquí.

¡Hasta el próximo post!.

He elaborado este libro a partir de una inquietud personal. Las tarjetas CRC son una herramienta muy útil a la hora de comprender el paradigma de la programación orientada a objetos, pero curiosamente hay poca información, sobre todo si la comparamos con otras. A eso le añadimos que en castellano hay menos.

Espero que sirva de ayuda a muchas personas, cuantas más mejor.

Si quieres puedes descargar el libro desde scribd haciendo clic aquí.

¡Un saludo y hasta el próximo post!.

Saludos

http://www.sgoliver.net/

¡Hasta el próximo post!.

Después del último post, en la clase palabra han quedado dos métodos que tienen código redundante. Vamos a unificarlo:

Si echamos un vistazo a la clase palabra, encontramos los dos siguientes métodos:

…

private int palabra_aleatoria()
{
return (int) Math.ceil(Math.random()*palabras.length);
}

…

public String get_letra_aleatoria_ayuda()
{
int posicion_aleatoria = (int) Math.ceil(Math.random()*tamanyo_palabra_en_curso());

return getPalabra_en_curso().substring(posicion_aleatoria, posicion_aleatoria + 1);
}

En ambos método se hace uso de: (int) Math.ceil(Math.random()*… para conseguir un número aleatorio. Vamos a unificar este proceso en un nuevo método, al que llamaremos desde estos dos.

El nuevo método queda de la siguiente forma:

private int numero_aleatorio(int limite)
{
return (int) Math.ceil(Math.random()*limite);
}

y los métodos anteriores de la siguiente forma:

…

private int palabra_aleatoria()
{
return numero_aleatorio(palabras.length);
}

…

public String get_letra_aleatoria_ayuda()
{
int posicion_aleatoria = numero_aleatorio(tamanyo_palabra_en_curso());
return getPalabra_en_curso().substring(posicion_aleatoria, posicion_aleatoria + 1);
}

¿Qué conseguimos con este cambio?

El programa sigue funcionando de la misma forma. Lo que ha cambiado es el diseño de la implementación. Hemos eliminado la redundancia del random, “sacándolo” fuera de los métodos, con lo que, a esos métodos, se le está “ocultando” la manera de conseguir el número aleatorio.

Puede parecer que no se gana mucho, pero lo importante es que las redundancias no son deseables. Sin embargo, la ocultación sí. Con cambios como éste conseguimos que nuestro programa sea más fácil de modificar en el futuro. Por ejemplo, si quisiésemos cambiar la manera en la que el programa genera el número aleatorio, con este cambio bastaría cambiar el cuerpo del nuevo método. Con el código anterior, deberíamos cambiarlo en dos sitios. Puede no parecer mucho esfuerzo, pero los programas “de verdad”, de tamaño y complejidad industriales, no tendrán dos pequeños métodos a cambiar, sino que el impacto será mucho mayor.

¡Hasta el próximo post!