pello.ioPosts
Lo del servidor web con pocas líneas o refactorizado para que tenga forma de clase va quedando más o menos apañado. Pero en cualquier proyecto que vaya creciendo vamos a necesitar bastantes más cosas y claro, ir metiendo todo el programa en un único fichero, aunque algún programador bajeril pueda decir que es más simple, pues está muy feo. Como en cualquier otro lenguaje y sea el tipo de programación que sea, como mínimo para facilitar la gestión del proyecto conviene separar. Una clase un fichero. Y en el caso de Node.js se les suele llamar módulos.
Los AsyncTask están recomendados para tareas concretas y finitas, como por ejemplo descargar el contenido de una URL. Si lo que necesitas es una especie de Hilo que esté ejecutándose contínuamente tendrías que usar los Thread convencionales (no se detienen ni al pulsar home ni al pulsar Back) o directamente crear un Service de Android.
Toda aplicación de Android tiene al menos un hilo o thread de ejecución. Ese thread es el encargado de la pantalla que tienes ante ti y es imprescindible por la manera en la que Android gestiona los cambios en el interfaz: a través de una cola de mensajes. Es decir, cada vez que aplicamos algún cambio en algún View no se aplica directamente sino que se deja la petición en una cola. Y ese hilo, el UI thread o el hilo principal de la aplicación es quien precisamente se encarga de procesar esa cola y aplicar los cambios solicitados.
Sí, seguro que el primer código que has visto de Node.js es uno de esos milagrosos servidores web hechos con pocas líneas. Olvídese de aparatosos sockets, de punteros o de BufferedStreamsWriters, un módulo, unos callbacks, eliges un puerto y a dar servicio. Bueno, uno trata de ser un good Node.js citizen y este código se entiende y mola, pero a la larga, si lo queremos ir mejorando y añadiendo otras funcionalidades cada vez va a ser más complicado mantenerlo. Lo que propongo en este post es tomar este código y refactorizarlo a un estilo más POO. Igual es una herejía pero bueno, supongo que es un tema que habrá que hablar con los guruses. Veamos el ejemplo típico de servidor web, sacado de un libro:
/**
* httpserver.js
* simple web server from O'Reilly Learning Node, Chp 6.
*/
var http = require('http'),
path = require('path'),
fs = require('fs'),
Backbone es un framework MVC de javascript para clientes web que facilita el desarrollo de aplicaciones de una sola página. El hecho de aplicar MVC permite separar los datos de la presentación y Backbone lo hace sin invadir la página y con una serie de funciones que permiten la persistencia de datos en el servidor. Dicho de otro modo, podemos hacer páginas web que manejen registros de una BBDD sin estar recargando la página todo el rato, que es lo que ahora mola. También facilita las pruebas unitarias, permite aplicar distintos sistemas de plantillas, bla bla somos los mejores. Te recomiendo seguir la web oficial porque ha habido cambios (por ejemplo en el tema de validación, antes se hacía por defecto) y te puedes encontrar por ahí blogs desfasados (como este) que te confundirán. Si juegas con Backbone que no se te olvide incluir en la página el jquery, el underscore (backbone se apoya mucho en él) y por supuesto el backbone. Y en ese orden.
Android tiene una forma peculiar de gestionar las aplicaciones que choca un poco con los sistemas operativos tradicionales. Pese a estar montado en un linux con el kernel 2.6, Android no tiene por costumbre matar las aplicaciones cuando las cerramos. La clave está en que igual lo hace o igual no, según las necesidades o lo que Android considere oportuno. La cosa es que no hay que empeñarse en tener un botón para matar la aplicación, oficialmente no se recomienda y se todo se resume a un tranqui, Android se preocupa.
El estilo nodejs
Yo pensaba que sabía -algo- de javascript hasta que descubrí Node.js :P. En fin, espero ser siempre
un aprendiz. Conforme te vas asomando a nuevas tecnologías tratas de hacer las cosas correctamente y
como recién llegado aplicas lo de donde fueres haz lo que vieres. ¿Existe algún documento con
las convenciones de Node.js? Sí, Node.js tiene una guía de estilo aunque no es oficial. Pero ojo porque como se suele decir old habits are hard to break, y habrá cosas que igual te cuesten un poco, cosas tan simples como eso, las comillas simples/dobles, en fin... supongo que mucho de esa guía es debatible pero es lo que hay.
De lo que si se habla es del preferred Node.js style que supongo que se resume seguir a los pros y a la comunidad en general. Cómo dice Felix, el autor de esa guía algunos de estos temas son religiosos. Todavía me parto con el inicio de la guía:
Let's start with the religious problems first. Our benevolent dictator (el pro de turno) has chosen 2 space indention for the node core, so you would do well to follow his choice..
Toda la guía se jaja de las discusiones y de los talibanes (también la guía tiene un tono ultra-ortodoxo) lo cual la hace muy simpática, a mi parecer. Otra perla:
Do not extend the prototypes of any objects, especially native ones. There is a special place in hell waiting for you if you don't obey this rule.
En fin, este tipo de polémicas entre programadores siempre han provocado oceanos de sangre...
Cuando en Android queremos abrir una nueva pantalla o Activity se hace de una manera muy curiosa: se crea un Intent. Los Intent son eso, intentos. No garantizan que el resultado vaya a ser el correcto ni si quiera que alguien vaya a responder, y es que los intents se pueden usar tanto para abrir Activities como para solicitar cualquier cosa (iniciar una llamada, mandar un mensaje, etc... ).
HTML5 trae un montón de nuevas posibilidades al navegador. Se ha hablado mucho del formato de vídeo,
del canvas, los websockets, de los nuevos controles de formulario pero a mí en particular me ha interesado
especialmente aquello de una BD en el cliente. Es un tema que no está tan documentado como el resto
y que en muchos libros de HTML5 o ni se menciona o se hace de pasada. Y lo que es peor, hay información
en blogs pero a nada que esté desfasada los ejemplos no funcionan como la llamada a setVersion(). Así que mucho ojo, si lees sobre este tema, procura que sea información reciente.
NodeJS está orientado a eventos por tanto disponer de mecanismos para definir nuestros propios eventos es algo fundamental. Como vamos a ver no tenemos más que importar el módulo events y a partir de ahí ya podremos trabajar con instancias de EventEmitter. Y como disponemos de herencia, podemos agregar la emisión de eventos a nuestras clases.
subscribe via RSS