pello.ioPosts
Con eso de escribir acerca de linux y de hacer bromas sobre lo horrible que es windows es muy común que de forma inmediata te encasillen como talibán linuxero. Más aún si eres fiel a Debian y despotricas de Ubuntu por estar hecho para ser fácil. Pero lo cierto es que ante la típica pregunta de un comercial de ¿Qué sistema es mejor? o ¿qué lenguaje es mejor? para mí la respuesta es tan clara como inconcreta: depende. Depende para qué. ¿Qué ordenador me compro? pregunta el cuñado, pues lo mismo, depende para qué: ¿es para navegar por internet o para despiece de utillajes industriales y simulación de fatigas en 3D? Así como entre el colacao y el nesquick la opción está clara entre Windows y Linux pasa lo mismo ¿cuál es mejor? depende para qué los quieras. Además, hay muchos Windows...
Como decía en la sección de proyectos, aunque algunos no estén desarrollados si la idea te sirve pues adelante. Este es uno de esos proyectos que querría haber terminado pero al menos de momento será complicado. Es el típico que si le dedicas un finde a saco lo sacas pero por desgracia no cuento con ese lujo. Lo que ahora mismo funciona no tiene nada de novedoso, pero lo que quiero añadir igual sí. Se trata de un editor de código web para navegador (hasta ahí nada novedoso):
Otra de las novedades que trae HTML5 es la de los famosos websockets. El protocolo HTTP funciona de tal manera que no existe una conexión fija entre el cliente y el servidor; el navegador y el servidor se están continuamente lanzando piedras con mensajes, y a veces para simular que la conexión es permanente (una sesión) se acompaña de alguna marca como una cookie. Los websockets nos dan la posiblidad de establecer una conexión fija entre cliente y servidor como la que hay en un IRC o en los servicios de juegos; en el navegador podemos conectarnos a un servidor de websockets con una especie de Sockets ultrasimplificados y por supuesto orientados a eventos.
Esto nos abre puertas a muchas aplicaciones, desde información en tiempo real, el obvio chat, juegos HTML5 multijugador, etc... . Una pregunta que en buena lógica atormentaría a cualquier sysadmin con canas que oye hablar de esto por primera vez es pero chacho ¿qué servidor va a aguantar ahora la tralla de conexiones permanentes? Un servidorcillo web con su apache y su php si encima le exiges mantener conexiones permanentes reventará. Ahí es donde entran en juego tecnologías como Node.js, que con un solo hilo y con eventos te aguantan lo que sea.
A la hora de desarrollar aplicaciones web tenemos muchos lenguajes donde elegir. Todos ellos funcionarán perfectamente en nuestro equipo local pero claro, ¿qué pasa si queremos publicar nuestra aplicación? ¿Y si además queremos hacerlo gratis? Una de las cosas que más atractivas de lenguajes como php es que lo tienes disponible para todos los sistemas, para todos los sabores de linux y lo que es mejor en infinidad de alojamientos gratuitos, con mysql incluido. Además php funciona de manera muy simple, ya que basta con subir los ficheros al servidor por FTP y apache hace el resto.
Un ContentProvider de Android es una especie de BD que una aplicación abre al resto de aplicaciones. Por ejemplo, si hacemos una aplicación con una BD SQLite está solamente estará disponible para la propia aplicación pero la podriamos abrir/ofrecer al resto del sistema a través de un content provider. Pero ojo¿solamente bases de datos? No, los content providers pretenden como su nombre indica proveer contenido y lo mismo puede ser una BD que unos ficheros, que unos datos arbitrarios. Lo peculiar del Content Provider es que la clase que ofrece para ello es prácticamente clavada a un CRUD de SQLite. Pero insisto no tiene por qué ser una base de datos lo que haya detrás.
... que acaba siendo un lector RSS
La idea de este proyecto era simplemente probar un poco la personalización de los elementos de un ListView. Pero como eso no es bastante y uno se lía y luego se viene arriba pues lo que he hecho es el típico lector de RSS que carga el contenido del ListView con las últimas noticias de una web. Y la petición y el parseo se hace a la manera de Android, con un AsyncTask. Esto es un poco como cuando haces una ensalada, que dices igual le añado esto, y esto otro, y ese trozo de queso y esa media manzana. Al final la lechuga queda enterrada en complementos. Pues bien, el BaseAdapter que extendemos para personalizar el ListView es la lechuga de esta ensalada de Android.
Un BroadcastReceiver es un componente de Android que una vez registrado reacciona cuando el sistema envía los Intent para los que estaba preparado. Un caso muy típico es el del Receiver que se registra para que reaccione cada vez que se recibe una llamada de teléfono o un SMS. Ese BroadcastReceiver capta el Intent y en un método onReceive hace lo que tenga que hacer. Se supone que es muy fácil y todo muy bonito.
Alrededor de Node.js existen infinidad de proyectos en plena ebullición, y prueba de ello es que solamente para desarrollar webs existen varios frameworks, algunos basados en el clásico MVC y otros más orientados a servir recursos REST. Ese es el caso de Express, uno de los frameworks más populares disponibles para Node.js. En este post veremos cómo crear un servidor que ofrezca recursos REST a un frontend. Si no te gusta javascript, amijo, jejej, no sé: deja la web y vuelve al Cobol, porque esto va a ser una fiesta.
Desde que los navegadores tenían soporte para Javascript, su código siempre se ha ejecutado en un único hilo. Los scripts que se desarrollan para el navegador están orientados a eventos y estos se van ejecutando en una especie de cola. Es decir, conforme se van generando los eventos estos van a una cola de tareas y Javascript los va procesando de uno en uno en un bucle.
En Android no solamente hay aplicaciones de ventanas o activities. Hay muchos otros tipos de elementos como por ejemplo los Services. Los servicios nos permiten dejar un programa residente en la memoria y disponible para cualquiera que lo necesite. Los servicios no tienen interfaz gráfico ni nada, son programas pensados para ser utilizados desde las Activities o incluso desde otros servicios. Un service puede crearse para dar servicio -privado- a una sola aplicación o puede hacerse público (a través del manifest) para que cualquiera pueda usarlo. Al igual que las activities los services tienen su propio ciclo de vida. Pero cuidado, no hay que dar por sentado que a un servicio se le pueda mandar cualquier cosa.
subscribe via RSS