Hoy ha cambiado el market de Android. Ahora se pueden ver estadísticas de uso de la aplicación que tengo publicada.
Se ven los tipos de dispositivo, nacionalidad e idioma del cliente. Voy a pegar aquí las nacionalidades. Aparece el país, el porcentaje del total de usuarios activos y el número que representa ese porcentaje:
United States
46.6% (409)
France
10.4% (91)
United Kingdom
7.4% (65)
Spain
5.0% (44)
Germany
4.2% (37)
Hong Kong
3.3% (29)
Canada
1.8% (16)
Austria
1.5% (13)
Argentina
1.4% (12)
Australia
1.3% (11)
¿Quién le iba a decir a mi triste cuerpo que su trabajo iba a ser usado en Australia o Canadá?
Mostrando entradas con la etiqueta java. Mostrar todas las entradas
Mostrando entradas con la etiqueta java. Mostrar todas las entradas
Traductores
Busco voluntarios traductores de español a cualquier idioma.
Contacten conmigo, si hacen el favor, eduyayo(at)gmail.com
Contacten conmigo, si hacen el favor, eduyayo(at)gmail.com
Y en la próxima actualización... Texto en 3d...
Qué ganas tengo de ponerlo en el mercado a ver qué dice la gente.
¡Ocupado!
Llevo unos días, demasiados, pero entre el curro y demás, no hay tiempo para todo.
Llevo unos días, decía, programanding otra vez para el androide. Jugar por correo electrónico es algo que no está muy explotado en el market. Problema gordo es que tengo cien mil ideas por minuto y sólo dos manos.
Tengo organizadas unas cosas chulas y lo que más me fastidia es no tener tiempo físico de llevarlas al mercado, cagonlaputa.
Estoy con un juego sencillo con el que poder probar todo el sistema, y hablo de todo el sistema porque en código la que estoy montando trae telar. Además toda la gestión de "eventos" en Android es un poco rara y entre sincronía, hebras, servicios, ventanas, bases de datos... Un jueguín de mierda toma entidad de proyectazo.
Esperemos que el primero duela pero el segundo vaya algo más fluido una vez montada toda la estructura.
Quería tener dos antes de sacar al Market algo para que la gente no se desespere a instalar una mierdecilla de juego que luego no les guste por aquello de que en la variedad está el gusto, quiero tener dos pequeños y luego meterme en unas cosas más complejas que tengo en la cabeza.
No quería publicar mucho, por ahora juegos por turnos, jugar por correo y cosas pequeñas.
Está muy bien la idea de la que no soy el padre porque jugar por correo se hace desde que se inventó el ajedrez o las damas. Aquí tenemos la posibilidad de que sea asíncrono como cualquier juego por correo (en inglis PBM, ahora se dice también PBeM por aquello del correo electrónico) y llevar el juego en el bolsillo para responder al contrincante cuando te salga. Está bien la idea, insisto, a ver cómo se lo toma el mercado.
Es importante para mí lo de tener dos juegos funcionando, carajo, a nivel personal o propio no es que sea un reto, que lo es, es que así probaré que todo el sistema funciona. Y ya a nivel de mercado, el problema es el que a la gente le parezca mal uno de los juegos y tenga un cierto apego al otro. La putada más gorda es tener que hacer otro más complejo (¡mucho mas!) que tengo perfilado en la cabeza pero que sólo en base de datos me va a llevar tanto o más tiempo que en la implementación completa de este.
Me daré una o dos semanas más para terminar este, ¡que aun no se mueve!.
Ver veremos. Que haya salú... Y ganas que, aunque no falten hoy, no vienen a diario tampoco.
--
O quam cito transit gloria mundi.
--
O quam cito transit gloria mundi.
Light Painting
La aplicación tiene 805 descargas... ^g^
Unas cien al día desde que salió. Tamos contentos.
Unas cien al día desde que salió. Tamos contentos.
El market
Muy util. Es una herramienta muys simple, pones la aplicación y una descripción y la gente se la descarga. Unos cienes de gentes se la descargan.
Además, cuando se produce una excepción, los usuarios pueden enviarte el log, la traza completa, y tu corregir y marcar la incidencia como vieja para que sepan que ya está corregida.
El equipo lo agradece. ^g^
¡pigdroid ya está en marcha!
Ya estamos aquí y queremos anunciarnos. Tenemos una aplicación publicada Light Painting. De uso muy específico pero que parece gustar al público, al menos esos son los datos que tenemos del primer día en el mercado.
Esperamos vuestras opiniones, saludos, insultos y demás en pigdroid@gmail.com
Salú y muchas gracias.
Text Lightpainting
Metido en movidas, a ver si sale una aplicación para pintar textos en fotografías de alta exposición. F... Me asesora, de momento ya pinto textos. La semana que viene probaremos en campo.
Disclaimer
De los mejores que he visto. Junto con esa frase que suele poner en los posts cuando publica una rom en alpha o beta diciendo que él no tiene la culpa de si tu teléfono se come a tu gato:
www.cyanogenmod.com
#include
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
www.cyanogenmod.com
Una mala idea
Vamos a ir cerranding esa amalgama de ideas que vengo escribiendo. Voy a proponer una aplicación mínima cliente-servidor que cumpla parte de los requisitos que dije antes.
Voy a recortar en todo lo posible, por ejemplo no se usarán bases de datos y el cliente no persistirá ningún tipo de información. La cuestión es que todo lo que no sea imprescindible para demostrar la viabilidad de un proyecto mayor nos lo saltemos a la torera. Partir de un tablero en el que se puedan mover fichas puede dar lugar a las damas, o a cualquier otro juego de tablero por turnos, con un poco más de lío con la lógica de negocio y la sincronía por red.
Añado requisitos técnicos más específicos del desarrollo o de tecnologías a emplear como la necesidad de pruebas unitarias, incluso la programación orientada a pruebas para poder desarrollar por contratos (se podría pasar a una persona un juego de pruebas y decirle que quieres el software que las cumpla).
A estas propuestas de calidad en desarrollo también se deberán ajustar los scripts de configuración citados anteriormente.
Cito las tecnologías que se usarán y las piezas de software y problemas que resolverán:
1) Servlet/Struts/Struts2/web services.
La centralización del servidor no necesita una conexión viva. Un cliente podrá ser identificado por una sesión web. Incluso se podría descargar al servidor de mantener sesiones si se hiciera un servicio web o se identificara unívocamente al cliente mediante algún oro mecanismo.
El que un cliente haga un “polling” para ver si existen actualizaciones se ve día a día con clientes de correo, rss, etc. Liberará al servidor de hacer un push en los clientes y la posible contratación de un servidor dedicado para realizar procesos batch.
Partidas, torneos, etc se podrían almacenar en base de datos así como configuraciones y sus posibles versiones.
Finalmente, diremos que se preferiría utilizar struts2, servicios web o servlets planos a struts… Soy así de cerdo o lo que sea… Tengo mis razones, una es que estoy hasta la coronilla de struts… Otra es que quisiera programar cliente y servidor sin depender de esa capa de abstracción que me obligaría a usar Struts para poder llamar al negocio. Los demás, hasta cierto punto, implementan una fachada de entrada al modelo más o menos directa.
Inicialmente aunque sea cliente servidor, se podrá hacer que el cliente se ejecute sin comunicación por red aunque sea esta simulada. De todas maneras para funcionar en junit no hará falta matarse.
2) Beanshell
Beanshell, tras mis pruebitas en una kvm y en la jvm completa, parece ser una potentísima herramienta de scripting. Se pueden crear clases enteras o instancias de clases definidas sin tipado…
Los scripts usan la gramática de Java así que si se diera el caso de que una mecánica programada en scripts madurase lo suficiente como para convertirse en parte de una aplicación, se podría compilar y unirse a ella. Se pueden distribuir en jar y un largísimo etcétera que me hace pensar que se podría tner un cliente mínimo y programar un Terminal desde el servidor.
3) Cliente Android
Sí. Me centro en esto. Se enchufa al ordenata y depuras diréctamente sobre la máquina, eso sin instalar rollos raros ni nada de eso.
El SDK pesa poco y es fácil de usar. La API, después de un golpe inicial contra esos conceptillos que se han sacado de la manga los chavales de google, resulta hasta cómoda y hay componentes para todo o pegas una patada a una piedra y salen cinco.
Las interfaces se pueden describir en documentos XML y éstos podrían estar en el servidor.
4) Junit
Hay un tipo de misiles, supongo que basados en la mente de la mujer, que se llaman “fire’n’forget”… Bromas aparte. Esto de junit, medianamente bien usado, hace que puedas programar una parte de tu lógica, probarla unitariamente, incluso hacer pruebas más grandes uniendo más piezas, y no volver a ellas hasta que rompas algo por otra cosa.
Te olvidas, eso está programado y funciona como esperabas.
Últimamente he descubierto algunas cosillas por ahí que me facilitarán la programación de pruebas respetando los estándares de encapsulamiento y herencia. Podré organizar mejor las pruebas.
Con junit se pueden probar los scripts beanshell… Depende de lo que quieras que hagan y todo eso, pero bien organizados se podrían probar. Incluso una serie de scripts pueden ser un proyecto en sí ya que al final no se distribuye una aplicación compilada sino una serie de ficheros .JAVA. Cada fichero Java se puede compilar, ejecutar con junit sus métodos, probar de mil formas y ver de mil maneras.
¿Por qué no actualizar la aplicación con las clases diréctamente? Porque es un engorro que se puede ahorra al usuario. Sin tocar más que una parte de toda esta maraña, se tendría al día el cliente y el servidor.
Quizá sea una muy mala idea. Pero puede intentarse.
Salú.
Voy a recortar en todo lo posible, por ejemplo no se usarán bases de datos y el cliente no persistirá ningún tipo de información. La cuestión es que todo lo que no sea imprescindible para demostrar la viabilidad de un proyecto mayor nos lo saltemos a la torera. Partir de un tablero en el que se puedan mover fichas puede dar lugar a las damas, o a cualquier otro juego de tablero por turnos, con un poco más de lío con la lógica de negocio y la sincronía por red.
Añado requisitos técnicos más específicos del desarrollo o de tecnologías a emplear como la necesidad de pruebas unitarias, incluso la programación orientada a pruebas para poder desarrollar por contratos (se podría pasar a una persona un juego de pruebas y decirle que quieres el software que las cumpla).
A estas propuestas de calidad en desarrollo también se deberán ajustar los scripts de configuración citados anteriormente.
Cito las tecnologías que se usarán y las piezas de software y problemas que resolverán:
1) Servlet/Struts/Struts2/web services.
La centralización del servidor no necesita una conexión viva. Un cliente podrá ser identificado por una sesión web. Incluso se podría descargar al servidor de mantener sesiones si se hiciera un servicio web o se identificara unívocamente al cliente mediante algún oro mecanismo.
El que un cliente haga un “polling” para ver si existen actualizaciones se ve día a día con clientes de correo, rss, etc. Liberará al servidor de hacer un push en los clientes y la posible contratación de un servidor dedicado para realizar procesos batch.
Partidas, torneos, etc se podrían almacenar en base de datos así como configuraciones y sus posibles versiones.
Finalmente, diremos que se preferiría utilizar struts2, servicios web o servlets planos a struts… Soy así de cerdo o lo que sea… Tengo mis razones, una es que estoy hasta la coronilla de struts… Otra es que quisiera programar cliente y servidor sin depender de esa capa de abstracción que me obligaría a usar Struts para poder llamar al negocio. Los demás, hasta cierto punto, implementan una fachada de entrada al modelo más o menos directa.
Inicialmente aunque sea cliente servidor, se podrá hacer que el cliente se ejecute sin comunicación por red aunque sea esta simulada. De todas maneras para funcionar en junit no hará falta matarse.
2) Beanshell
Beanshell, tras mis pruebitas en una kvm y en la jvm completa, parece ser una potentísima herramienta de scripting. Se pueden crear clases enteras o instancias de clases definidas sin tipado…
Los scripts usan la gramática de Java así que si se diera el caso de que una mecánica programada en scripts madurase lo suficiente como para convertirse en parte de una aplicación, se podría compilar y unirse a ella. Se pueden distribuir en jar y un largísimo etcétera que me hace pensar que se podría tner un cliente mínimo y programar un Terminal desde el servidor.
3) Cliente Android
Sí. Me centro en esto. Se enchufa al ordenata y depuras diréctamente sobre la máquina, eso sin instalar rollos raros ni nada de eso.
El SDK pesa poco y es fácil de usar. La API, después de un golpe inicial contra esos conceptillos que se han sacado de la manga los chavales de google, resulta hasta cómoda y hay componentes para todo o pegas una patada a una piedra y salen cinco.
Las interfaces se pueden describir en documentos XML y éstos podrían estar en el servidor.
4) Junit
Hay un tipo de misiles, supongo que basados en la mente de la mujer, que se llaman “fire’n’forget”… Bromas aparte. Esto de junit, medianamente bien usado, hace que puedas programar una parte de tu lógica, probarla unitariamente, incluso hacer pruebas más grandes uniendo más piezas, y no volver a ellas hasta que rompas algo por otra cosa.
Te olvidas, eso está programado y funciona como esperabas.
Últimamente he descubierto algunas cosillas por ahí que me facilitarán la programación de pruebas respetando los estándares de encapsulamiento y herencia. Podré organizar mejor las pruebas.
Con junit se pueden probar los scripts beanshell… Depende de lo que quieras que hagan y todo eso, pero bien organizados se podrían probar. Incluso una serie de scripts pueden ser un proyecto en sí ya que al final no se distribuye una aplicación compilada sino una serie de ficheros .JAVA. Cada fichero Java se puede compilar, ejecutar con junit sus métodos, probar de mil formas y ver de mil maneras.
¿Por qué no actualizar la aplicación con las clases diréctamente? Porque es un engorro que se puede ahorra al usuario. Sin tocar más que una parte de toda esta maraña, se tendría al día el cliente y el servidor.
Quizá sea una muy mala idea. Pero puede intentarse.
Salú.
La lógica de un evento que se convirtió en acción
Vamos a suponer que tenemos un cliente de damas. El cliente es tonto para pintar, siempre pintará el estado del juego y esta lógica nunca se actualizará. En pantalla se pintará el tablero y una superposición de las opciones del jugador después de que éste haya seleccionado una pieza.
Cuando el usuario selecciona una ficha en el tablero se genera un evento que se procesará mediante una entidad representada por un script que puede cambiar en tiempo de ejecución. Normalmente este script formará parte de la configuración del juego, bien sea de la aplicación o de la partida en curso (se podría jugar a las damas inglesas con la misma interfaz pero distinta configuración). Si la ficha está bloqueada no se cambiaría la interfaz. Si no estuviera bloqueada, el script podría activar distintas opciones a mostrar en pantalla y pedir un repintado.
Esta parte está un poco borrosa y sin definir. La entidad que ha resuelto el evento no pasa de ser un EventHandler normal y corriente de los de toda la vida, en ella no intervinen lógica de negocio, sólo presentación. La parte en la que cito “ficha bloqueada” sería lógica de negocio. Ahí entraría una acción que sería, por ejemplo, MoverFicha. La interfaz de las acciones permitirían al código que las llama unas entradas de “seguridad” o, más bien, de comprobación de la posibilidad de ejecución. Varios métodos ayudarían a esto. Un getOptions o algo así, podría, no sólo decir si es posible realizar esta acción sino realizar algún refresco en la vista añadiendo las opciones a un menú que se pueda pintar. En este caso de las damas, en una capa por encima del tablero que estaba pintado, podrían aparecer en sombreado dos fichas en los posibles lugares a los que se puede mover la actual. Si la ficha fuese una dama en las damas inglesas esas casillas serían hasta ocho en un movimiento simple en el que no coma… La configuración lo variaría todo.
Esta acción se convertiría en comando cuando se ejecute. Por ahora estamos en la posibilidad de que se ejecute. El usuario la podría cancelar, la tenemos en cola para un posible fin de turno, es la acción actual y el botón volver la puede deshacer. El usuario confirma, la acción se ejecuta y repintamos el modelo en pantalla con el nuevo tablero… Se ha hecho cambiar el proxy del modelo en el cliente. Incluso, con ser este un juego de damas y sólo podemos mover una ficha cada turno, se podría comunicar al servidor el fin de turno o desencadenar una acción que permita al usuario aceptar para finalizar su turno. Entonces se enviarán los datos al servidor para que se actualicen el resto de clientes.
Ese paso, el de actualizar el resto de clientes, se puede independizar de la arquitectura, del método usado, etc. Habría que ver si hacemos PULL o PUSH desde el terminal. Un límite de tiempo y refresco a petición del cliente sería lo más óptimo a mi entender.
En próximos capítulos, el milagro del remote scripting ^^
Cuando el usuario selecciona una ficha en el tablero se genera un evento que se procesará mediante una entidad representada por un script que puede cambiar en tiempo de ejecución. Normalmente este script formará parte de la configuración del juego, bien sea de la aplicación o de la partida en curso (se podría jugar a las damas inglesas con la misma interfaz pero distinta configuración). Si la ficha está bloqueada no se cambiaría la interfaz. Si no estuviera bloqueada, el script podría activar distintas opciones a mostrar en pantalla y pedir un repintado.
Esta parte está un poco borrosa y sin definir. La entidad que ha resuelto el evento no pasa de ser un EventHandler normal y corriente de los de toda la vida, en ella no intervinen lógica de negocio, sólo presentación. La parte en la que cito “ficha bloqueada” sería lógica de negocio. Ahí entraría una acción que sería, por ejemplo, MoverFicha. La interfaz de las acciones permitirían al código que las llama unas entradas de “seguridad” o, más bien, de comprobación de la posibilidad de ejecución. Varios métodos ayudarían a esto. Un getOptions o algo así, podría, no sólo decir si es posible realizar esta acción sino realizar algún refresco en la vista añadiendo las opciones a un menú que se pueda pintar. En este caso de las damas, en una capa por encima del tablero que estaba pintado, podrían aparecer en sombreado dos fichas en los posibles lugares a los que se puede mover la actual. Si la ficha fuese una dama en las damas inglesas esas casillas serían hasta ocho en un movimiento simple en el que no coma… La configuración lo variaría todo.
Esta acción se convertiría en comando cuando se ejecute. Por ahora estamos en la posibilidad de que se ejecute. El usuario la podría cancelar, la tenemos en cola para un posible fin de turno, es la acción actual y el botón volver la puede deshacer. El usuario confirma, la acción se ejecuta y repintamos el modelo en pantalla con el nuevo tablero… Se ha hecho cambiar el proxy del modelo en el cliente. Incluso, con ser este un juego de damas y sólo podemos mover una ficha cada turno, se podría comunicar al servidor el fin de turno o desencadenar una acción que permita al usuario aceptar para finalizar su turno. Entonces se enviarán los datos al servidor para que se actualicen el resto de clientes.
Ese paso, el de actualizar el resto de clientes, se puede independizar de la arquitectura, del método usado, etc. Habría que ver si hacemos PULL o PUSH desde el terminal. Un límite de tiempo y refresco a petición del cliente sería lo más óptimo a mi entender.
En próximos capítulos, el milagro del remote scripting ^^
Servidor filosofando de clientes
No es que quiera pegar estos pensamientos a una tecnología en particular, pero no está de más centrar la finalidad del proyecto para acotarlo de algún modo. La idea no es hacer el DooM entero y ejecutarlo a ver qué pasa. Hacer un cliente capaz de ejecutar pequeñas lógicas de negocio para descartar eventos de usuario y un servidor que sincronice partidas es ya un trabajo suficientemente grande para una persona. Añadir capas a esta estructura o ampliar esta lógica de negocio sería lo mismo que construir una aplicación sobre un buen framework en el que cada acción de usuario se pueda implementar independientemente. Añadir datos al modelo incluso nuevas reglas de negocio…
Sobre nuevas reglas de negocio, vamos a centrarnos ya en Android. Android es lo que quiero que implemente el primer cliente de la aplicación. Sin quitar que luego haya cliente web o lo que venga. Al tener una aplicación desplegada en un aparato con android, se puede actualizar esta arbitrariamente cuando el desarrollador quiera dentro del Market. Una pega bastante gorda de esto es que el cliente tiene que tener la voluntad de actualizarla porque debe activar él mismo la descarga e instalación de la nueva versión.
Quisiera poder esquivar este tema. Las acciones de usuario deberían tener consecuencias distintas según el modo de juego, incluso si se me apura, poder cambiar dinámicamente. Habría que tener un cliente lo suficientemente inteligente como para decir que no se puede mover una ficha del juego de damas en vertical u horizontal. Se me ocurre flexibilizarlo aun más y poder, desde el servidor, introducir nuevas modalidades de juego de damas distintas a las que yo conozco. Los ingleses juegan con las damas (cuando son damas y se le da vuelta a la ficha que por el otro lado les ponen una cruz negra) con un tipo de movimiento particular, pueden mover en cualquier dirección (incluso vertical u horizontal) pero de uno en uno.
Esto de flexibilizar las reglas de juego no es un problema en sí, se podría anunciar una actualización y decir al cliente que si no se actualiza no podrá jugar a las damas a la inglesa… Pero preferiría que si se actualiza el cliente sea por corregir bugs o añadir algún tipo de funcionalidad que, de veras, no se pueda desde el servidor. Además este nuevo requisito se une al depender en dos aplicaciones (cliente y servidor) de un cambio que se podría dar en una.
Me lleva a pensar esto en distribuir la computación y hacer que el cliente pida “permiso” al servidor para mover de a3 a a4 en un juego de damas. Esto usaría red. Un defecto de los informáticos es que pensamos en el usuario y en sus aparatos. Al programar para una consola portatil se pausa de vez en vez la cpu o los sistemas de sonido mientras no se vayan a usar para ahorrar batería. Parece mentira, pero como usuario te acabas dando cuenta de qué juegos o aplicaciones se comen la batería y cuales no. Así que vamos a descartar eso de tirar la énergia y usar la red sólo cuando se necesite.
Esto del ahorro nos descarta de un juego en tiempo real aunque también es posible algún tipo de juego que ya he pensado en el que los eventos de usuario sean bastante espaciados. Al final, lo que me interesa es hacer un juego por turnos que sea “atemporal” no que exista por siempre si no que se pueda jugar en cualquier momento, incluso flexibilizar los turnos para limitarlos a un tiempo o no tipo civilization.
Como soy medio masoca pa todo esto, lo que más me pone es preparar estas milongas que hay por debajo.
Vamos a hacer un proxy del servidor. El proxy deberá contener la lógica de negocio que decida qué acciones son permitidas al usuario y cuales no. Es absurdo preguntar al servidor cuando el usuario pincha sobre una casilla en blanco. En un cliente Ajax ni siquiera se generaría un evento javascript para esa celda del mapa. Pues un cliente algo listo, debería detener la ejecución antes de pedir por red al servidor que le describa qué mostrar o qué hacer. Parte o toda la lógica de negocio podría almacenarse en scripts o en clases que se puedan servir al cliente (ya me estoy limitando a una tecnología), al menos aquella lógica que diga qué eventos del usuario superan el ámbito del cliente y tienen que pasar como un comando al servidor: Al final de un turno, por ejemplo, el cliente no debería haber contactado con el servidor para nada y entonces enviar un lote de acciones que gestionar de las que ha hecho el usuario. En un juego como el poker llegarían todas las cartas que ha tirado el usuario al final de su turno pero no de una en una sino en un solo comando.
El proxy del cliente actuará como si ya se han movido sus fichas y podrá ver el tablero actualizado con sus movimientos incluso deshacerlos antes de terminar su turno salvo que las reglas no permitan deshacer… “Carta en la mesa” o como se diga en cada sitio.
Evento: será un gesto del usuario ante la interfaz que se le presenta o cualquier tarea repetitiva o programada que desencadene una acción contra la aplicación, cosas del tipo un click de usuario, arrastrar, o un timer que haga el tick de una animación.
Accion: un evento pasará a ser una acción cuando la lógica de negocio tenga que responder a él bien sea cambiando la vista, el modelo o comunicando cualquier cosa a un posible servidor de la aplicación.
Proxy: Un proxy es una representación de un objeto que no esxiste realmente como tal o que es un modelo sobre el modelo. Explico esto diciendo que si se centraliza un servidor con toda la lógica de negocio, por ejemplo, es bastante absurdo para un cliente que no sea tonto (osea que haya que programar cierta lógica en el cliente) el tener que consultar qué hacer con un click del usuario o con un tick de las animaciones. Ver proxy pattern en wikipedia o donde sea.
Comando: Una acción pasa a ser un comando cuando modifica un proxy o el modelo.
Continuará...
Sobre nuevas reglas de negocio, vamos a centrarnos ya en Android. Android es lo que quiero que implemente el primer cliente de la aplicación. Sin quitar que luego haya cliente web o lo que venga. Al tener una aplicación desplegada en un aparato con android, se puede actualizar esta arbitrariamente cuando el desarrollador quiera dentro del Market. Una pega bastante gorda de esto es que el cliente tiene que tener la voluntad de actualizarla porque debe activar él mismo la descarga e instalación de la nueva versión.
Quisiera poder esquivar este tema. Las acciones de usuario deberían tener consecuencias distintas según el modo de juego, incluso si se me apura, poder cambiar dinámicamente. Habría que tener un cliente lo suficientemente inteligente como para decir que no se puede mover una ficha del juego de damas en vertical u horizontal. Se me ocurre flexibilizarlo aun más y poder, desde el servidor, introducir nuevas modalidades de juego de damas distintas a las que yo conozco. Los ingleses juegan con las damas (cuando son damas y se le da vuelta a la ficha que por el otro lado les ponen una cruz negra) con un tipo de movimiento particular, pueden mover en cualquier dirección (incluso vertical u horizontal) pero de uno en uno.
Esto de flexibilizar las reglas de juego no es un problema en sí, se podría anunciar una actualización y decir al cliente que si no se actualiza no podrá jugar a las damas a la inglesa… Pero preferiría que si se actualiza el cliente sea por corregir bugs o añadir algún tipo de funcionalidad que, de veras, no se pueda desde el servidor. Además este nuevo requisito se une al depender en dos aplicaciones (cliente y servidor) de un cambio que se podría dar en una.
Me lleva a pensar esto en distribuir la computación y hacer que el cliente pida “permiso” al servidor para mover de a3 a a4 en un juego de damas. Esto usaría red. Un defecto de los informáticos es que pensamos en el usuario y en sus aparatos. Al programar para una consola portatil se pausa de vez en vez la cpu o los sistemas de sonido mientras no se vayan a usar para ahorrar batería. Parece mentira, pero como usuario te acabas dando cuenta de qué juegos o aplicaciones se comen la batería y cuales no. Así que vamos a descartar eso de tirar la énergia y usar la red sólo cuando se necesite.
Esto del ahorro nos descarta de un juego en tiempo real aunque también es posible algún tipo de juego que ya he pensado en el que los eventos de usuario sean bastante espaciados. Al final, lo que me interesa es hacer un juego por turnos que sea “atemporal” no que exista por siempre si no que se pueda jugar en cualquier momento, incluso flexibilizar los turnos para limitarlos a un tiempo o no tipo civilization.
Como soy medio masoca pa todo esto, lo que más me pone es preparar estas milongas que hay por debajo.
Vamos a hacer un proxy del servidor. El proxy deberá contener la lógica de negocio que decida qué acciones son permitidas al usuario y cuales no. Es absurdo preguntar al servidor cuando el usuario pincha sobre una casilla en blanco. En un cliente Ajax ni siquiera se generaría un evento javascript para esa celda del mapa. Pues un cliente algo listo, debería detener la ejecución antes de pedir por red al servidor que le describa qué mostrar o qué hacer. Parte o toda la lógica de negocio podría almacenarse en scripts o en clases que se puedan servir al cliente (ya me estoy limitando a una tecnología), al menos aquella lógica que diga qué eventos del usuario superan el ámbito del cliente y tienen que pasar como un comando al servidor: Al final de un turno, por ejemplo, el cliente no debería haber contactado con el servidor para nada y entonces enviar un lote de acciones que gestionar de las que ha hecho el usuario. En un juego como el poker llegarían todas las cartas que ha tirado el usuario al final de su turno pero no de una en una sino en un solo comando.
El proxy del cliente actuará como si ya se han movido sus fichas y podrá ver el tablero actualizado con sus movimientos incluso deshacerlos antes de terminar su turno salvo que las reglas no permitan deshacer… “Carta en la mesa” o como se diga en cada sitio.
Evento: será un gesto del usuario ante la interfaz que se le presenta o cualquier tarea repetitiva o programada que desencadene una acción contra la aplicación, cosas del tipo un click de usuario, arrastrar, o un timer que haga el tick de una animación.
Accion: un evento pasará a ser una acción cuando la lógica de negocio tenga que responder a él bien sea cambiando la vista, el modelo o comunicando cualquier cosa a un posible servidor de la aplicación.
Proxy: Un proxy es una representación de un objeto que no esxiste realmente como tal o que es un modelo sobre el modelo. Explico esto diciendo que si se centraliza un servidor con toda la lógica de negocio, por ejemplo, es bastante absurdo para un cliente que no sea tonto (osea que haya que programar cierta lógica en el cliente) el tener que consultar qué hacer con un click del usuario o con un tick de las animaciones. Ver proxy pattern en wikipedia o donde sea.
Comando: Una acción pasa a ser un comando cuando modifica un proxy o el modelo.
Continuará...
El monstruo de las galletas
Como se sabe, Internet explorer es el navegador más usado. También tenemos la puñeta de que los clientes lo suelen tener como un estándar en sus oficinas, así que definen una consola sobre la que deban las aplicaciones funcionar y siempre aparece esa puta mierda de chapuza con capas encima. Cada nuevo release es un paso dentro del mundo del dolor, nunca una versión es compatible con la anterior, es como si otra marca decidiese crear un nuevo navegador pero conservando todos los fallos del anterior, eso sí. Y también, anuncian que, esta vez de verdad, lo han reescrito desde cero. Ja. Ja... Ja...
Bien. Uno de esos fallos se comenta en esta página:
http://stackoverflow.com/questions/1324181/ie8-losing-session-cookies-in-popup-windows
Consiste, y se habla mucho en la internez sobre ello, en que, cuando le da la gana, al abrir un popup no envía las cookies del padre. Para algunos servidores web esto es una cerdada porque conservan la sesión del usuario en una cookie. No digo que guarden datos importantes, pero el identificador de la sesión si que se guarda en una cookie.
En mi caso, es Java, hay un "jsessionid" que se va pasando en cada petición web para que el servidor reconozca a ese cliente como el dueño de la sesión que él tiene por allí almacenada. Por tanto hay una cookie jsessionid. Pues por javascript o con un simple enlace, abres otra ventana. Es muy común eso de poner lupas para buscar valores, un popup de alerta o lo que sea. Se abre la ventana y pumba, pantalla de login porque el servidor no reconoce la sesión...
Mi solución: Mi solución es poner una página en blanco con un javascript para solucionar el tema este. Es javascript porque se tiene que ejecutar en el cliente. A esta página se le envían los parámetros y la acción que queremos ejecutar en el popup, se carga, se ejecuta este javascript y, después, se recarga la página con la acción que se quería hacer desde un principio.
Mi javascript es muy muy sencillo, lo que hace es copiar las cookies de la ventana padre en caso de que sea Internet Explorer. Al ser IE el objeto window tiene opener:
if (window.opener) {
document.cookie = window.opener.document.cookie;
}
//TODO reload here!
Probado, funciona.
--
Nescit vox missa reverti.
Bien. Uno de esos fallos se comenta en esta página:
http://stackoverflow.com/questions/1324181/ie8-losing-session-cookies-in-popup-windows
Consiste, y se habla mucho en la internez sobre ello, en que, cuando le da la gana, al abrir un popup no envía las cookies del padre. Para algunos servidores web esto es una cerdada porque conservan la sesión del usuario en una cookie. No digo que guarden datos importantes, pero el identificador de la sesión si que se guarda en una cookie.
En mi caso, es Java, hay un "jsessionid" que se va pasando en cada petición web para que el servidor reconozca a ese cliente como el dueño de la sesión que él tiene por allí almacenada. Por tanto hay una cookie jsessionid. Pues por javascript o con un simple enlace, abres otra ventana. Es muy común eso de poner lupas para buscar valores, un popup de alerta o lo que sea. Se abre la ventana y pumba, pantalla de login porque el servidor no reconoce la sesión...
Mi solución: Mi solución es poner una página en blanco con un javascript para solucionar el tema este. Es javascript porque se tiene que ejecutar en el cliente. A esta página se le envían los parámetros y la acción que queremos ejecutar en el popup, se carga, se ejecuta este javascript y, después, se recarga la página con la acción que se quería hacer desde un principio.
Mi javascript es muy muy sencillo, lo que hace es copiar las cookies de la ventana padre en caso de que sea Internet Explorer. Al ser IE el objeto window tiene opener:
if (window.opener) {
document.cookie = window.opener.document.cookie;
}
//TODO reload here!
Probado, funciona.
--
Nescit vox missa reverti.
...Y se llama Android
Si, chaval... Hice un cliente de blogger para Android... Dándole estoy retoques, por ahora es completamente funcional a falta de algunos Strings sin internacionalizar. Pagaré una cuenta de desarrollador y lo dejaré en el market gratix para ver qué tal se mueve el mercado.
Sí, este iba de prueba. Quiero hacer cosas más grandes y ambiciosas, pero necesito más gente.
Voluntarios a mi correo que, hace tiempo, estaba por ahí pegado en una columna a la derecha o a la izquierda.
Suscribirse a:
Entradas (Atom)