Archivo

Archivo del autor

Cómo pagar Whatsapp para Android vía PayPal (Aunque parezca que ya no se puede)

Martes, 5/Mar/2013 33 comentarios

WhatsApp para Android se ha vuelto de pago definitivamente

Desde marzo de 2013 el popular servicio de mensajería Whatsapp ha dejado de prorrogar su uso gratuito en la plataforma Android. Hasta esa fecha, cuando el servicio llegaba a la fecha de caducidad de 1 año, siempre se nos enviaba un mensaje diciendo algo así como: “Su cuenta de WhatsApp va a caducar, pero prorrogamos su uso gratuito para su nº de teléfono por N meses más”.

Dependiendo del usuario, y sin criterio aparente, las prórrogas iban hasta 2014, 2021 e incluso hasta 2030 (para los usuarios más suertudos). También podía pasar que la gente que se dio de alta en el servicio usando un iPhone, al migrar su teléfono a Android veían contentos como el servicio ponía “No tiene caducidad”. Tiene sentido porque es gente que ya pagó 0,69 € al bajarse la app de la Apple Store. Pero los usuarios de Android nunca habíamos pagado nada, hasta ahora.

En cualquier caso, y después de este resumen: A partir de marzo de 2013 si tienes Android y te ha caducado Whatsapp, no podrás seguir recibiendo o enviando mensajes hasta que no pagues la renovación del servicio por otro año. Mucha gente dirá “hay alternativas gratuitas, etc…” Bien, ESTE ARTÍCULO DE HOY NO VA SOBRE LAS ALTERNATIVAS A WHATSAPP. Internet está llena de artículos describiendo esos otros programas, sus pros y sus contras. De lo que sí que va este artículo es de “cómo renovar la licencia de uso anual de Whatsapp vía PayPal” en vez de dando un número de Tarjeta de Crédito a Google. Y es muy fácil conseguirlo…

De nuevo mucha gente dirá, “no es tan malo que Google tenga tú número de tarjeta” (no, claro, y qué más!!) Básicamente “es lo último que les falta ya tener”, y sea por lo que sea, porque no tengas tarjeta de crédito, porque te da escalofríos que Google tenga otro pequeño trozo de tu privacidad, o porque te manejas mejor con PayPal, este artículo te explicará cómo efectuar el pago de la aplicación con este método.

Qué hacer

Lo primero que hay que hacer es comprobar que la versión de Whatsapp que tenemos instalada en nuestro Android SÓLO permite pagar via “Google Play”. Para ello, desde dentro de la aplicación,  vamos a Menú -> Configuración -> Info de cuenta -> Información de pago.

Una vez allí, lo que veremos será algo así como nuestro nº de teléfono (que es nuestro identificador dentro de la red Whatsapp), la fecha de caducidad del servicio, y un botón de “comprar en línea“.

Si no vemos más opciones ni botones, entonces efectivamente no podemos pagar con PayPal con la versión de WhatsApp que tenemos instalada. Si intentamos pulsar ese único botón que sale en pantalla, “Comprar en línea“, nos remitirá a una página donde el único método de pago será vía “Google Wallet” (o nombre similar), y que en cualquier caso nos exigirá que introduzcamos un número de tarjeta de crédito. Así que si no queremos o no podemos pagar con este método, tendremos que hacer que aparezca la opción de “pago con PayPal” por algún lado.

Descargar “otro” WhatsApp

Para conseguirlo, lo que yo hice es ir a la web de Whatsapp/Android con el móvil. (Sí, con el móvil), http://www.whatsapp.com/android/

Una vez dentro de la página, veremos que se nos ofrece bajar la aplicación WhatsApp de nuevo. Como no tenemos muchas más opciones, eso haremos, bajarla con el navegador del móvil desde esta web. Y esto lo haremos aunque ya la tengamos instalada en el móvil. Alguien dirá, “no será lo mismo bajarla desde la tienda de Google? Si hasta el número de versión es el mismo“. Veremos que no es lo mismo y si seguimos leyendo, sabremos por qué.

ACTUALIZACIÓN: Desde el 8 de marzo de 2013, a algunos usuarios (no a todos) les pasa que son redirigidos a la web de Google Play cuando intentan descargar la aplicación desde la propia web de WhatsApp (con el link mencionado arriba).  Si así nos pasara, se puede bajar el fichero .apk alojado en la web de WhatsApp si hacemos que el navegador móvil vaya a la siguiente dirección:

http://www.whatsapp.com/android/current/WhatsApp.apk

Instalar este “nuevo” WhatsApp

Bien, una vez nos haya bajado el fichero .apk desde la web de WhatsApp en la carpeta de descargas de nuestro navegador, pasaremos a instalarlo. Instalar una aplicación es muy fácil, sólo hay que pulsar encima del fichero .apk que vemos en pantalla. Al hacerlo, seguramente nos diga algo así como: “Se va a sustituir la aplicación Whatsapp actualmente instalada por una nueva”. Ningún problema, es lo que queremos. Le decimos que sí (yo lo hice y no pasó nada grave, es como cuando uno actualiza una aplicación sin más). Quien sea un poco paraonico, puede crear antes una copia de seguridad de sus mensajes de WhatsApp en la tarjeta SD (desde dentro de la misma aplicación se puede hacer con comodidad).

Descubrir la página de pago de PayPal para nuestro nº de teléfono (*)

Una vez esté instalada la “nueva” versión de WhatsApp, la arrancaremos y veremos que aparentemente todo es igual que antes (más allá de algún estilo de letra en los menús más vistoso). Ahora es cuando comprobaremos dónde está la diferencia. Si vamos a las opciones de pago de la misma manera que antes (Menú -> Configuración -> Info de cuenta -> Información de pago ), veremos que ahora debajo del botón “Comprar en línea“, nos aparece otro botón nuevo que es “Enviar dirección de pago“. ¿Qué pasa si pulsamos este botón? Lo que pasará es que podremos enviar(nos) un e-mail a la dirección de correo que queramos. Para no complicarnos la vida, nos lo enviaremos a nosotros mismos. El contenido del mail es un enlace web que tendrá una forma parecida a esta: htttp://www.whatsapp.com/payments/XXXXXXXXXXXXXXXXXXXXXXXXXXX con una serie de números y letras.

OK, pulsamos “enviar mail“, nos lo enviamos y comprobamos que nos llega a la dirección que hayamos elegido. Una vez nos ha llegado,  recomiendo hacer el resto del proceso (es decir el pago con PayPal) delante de un ordenador, ya que siempre es menos engorroso que desde el móvil. Una vez delante del ordenador, abrimos el mail, y vamos a la dirección web que contenía. Esta dirección no es más que una mini página de pagos dentro de la propia web oficial de WhatsApp donde vuelven a aparecernos las típicas “opciones de pago asociadas a tu número”. Pero oh sorpresa, a parte de las opciones que implican usar sólo tarjeta de crédito (Google Wallet/Google Pay/etc…), en la parte derecha nos aparecerá también la opción de pago vía “PayPal“. Es con ese botón de PayPal con el que podremos acabar de gestionar la renovación del servicio. El día que yo lo hice, el precio era de 0,99$ por un año (que al cambio serían 0,8 € ). Sólo nos queda pulsar el botón PayPal, decir que sí en el proceso de pago, y en cuanto reiniciemos el móvil, WhatsApp resucitará en nuestro móvil.

(*) ACTUALIZACIÓN: Desde el 14 de marzo de 2013, cuando bajemos el fichero .apk de WhatsApp para Android desde su web (versión 2.9.3802), veremos que permite todavía más opciones de pago que las que se comentan en los párrafos anteriores. Con esta nueva versión aparentemente ya se puede pagar con PayPal de manera nativa, asi como seguir enviando la dirección de pago por e-mail (para que otra persona nos pague por nosotros, por ejemplo). También se nos da la oportunidad de suscribirnos no sólo por 1 año, sino por 3 ó 5 (con un descuento casi inexistente).

Conclusiones

Moraleja: Sigo teniendo WhatsApp, lo renové usando PayPal y “Google sigue sin tener mi número de tarjeta de crédito”. No sé hasta cuando, pero de momento en mi pequeña paranoia, yo soy feliz.

Saludos.

Compártelo en Facebook
Share it with Twitter!Menéalo!

_________________________________________________________________________________________

Dropbox, por qué es imprescindible

The Binding of Isaac (Wrath of the Lamb): Chest achievements havoc explained.

Jueves, 27/Sep/2012 Deja un comentario

Lately, I’ve became a fan of “The Binding of Isaac” video game. No big surprise here, it’s a nice rogue game, which rewards you with achievements and items once you accomplish certain conditions along the game. With these extra items, game experience becomes still funnier. Besides, some time ago, BoI creators released “The Lamb of Wrath” as a DLC on Steam, filled up with with extra contents, toys, mechanics, items and achievements.

Now I’m near the end, that meaning I’m only 2 or three achievements away from getting “Platinum God”. Once I’ll get it, I’m sure the game will lose its purpose as I will have acquired all items, all characters, etc. Anyway, something seems not to be properly working inside the achievements engine, as some bug blocks me from getting my well deserved Platinum God badge, because some previous achievements seem impossible to get…

Let’s see what’s happening here:

When you get one achievement via “certain action done”, several things happen. If that achievement grants you an item, the item becomes visible inside the game engine locally, and then you can use it in future games whenever it appears. But not only it’s granted inside your local copy of the game, but gets also “uploaded” onto your steam account profile, so everyone can see it there. So these are 2 apparently linked actions.

The problem arises when you get one item/achievement (inside your local copy of the game), it doesn’t correspond to what you expect, and even worse, A TOTALLY UNRELATED and different item/achievement gets uploaded onto the steam achievements cloud engine.

I’ve identified 5 items/achievements which seem impossible to get, at least if you follow common sense. All of them are Wrath of The Lamb items, and all of them appear when you beat “???” inside “The Chest”. Sorry for the “spoiler”.

__________________________

Here is the data I’ve discovered so far when killing ‘???’ inside the Chest:

-Using “???”, you get “Eve’s Bird Foot” in-game, and “Samsons’ Lock” appears on Steam.
-Using “Cain”, you get “Cain’s Eye” in-game, but “???’s Soul” appears on Steam.
-Using “Eve”, you get “???’s Soul” in-game, and “Judas’ Tongue” appears on Steam.
-Using “Judas”, you get “Judas’ Tongue” in-game, but “Cain’s Eye” appears on Steam.
-Using “Samson”, you get “Samson’s Lock” in-game, but “Eve’s Bird Foot” appears on Steam.

__________________________

I hope this info might be useful for anyone stucked trying to discover what really happens between their local and Steam cloud achievments, specially with these buggy ones.
I wish I could have read it before, as I’ve spent HOURS, performing many useless runs with the worst characters (Samson (!!), ??? (!!!)), to end up getting nothing.

_________________________________________________________________________________________

Share it with Twitter!Menéalo!Like This!

Dropbox, por qué es imprescindible

Dear UX/Designers. STOP THIS NONSENSE!!

Jueves, 19/Abr/2012 Deja un comentario

Please UX/Designers of the world:

STOP MAKING BUTTONS APPEAR OUT OF NOWHERE WHEN HOVERING EMPTY AREAS OF WEB PAGES/PROGRAMS. PLEASE.

Empty areas are used to click on them to gain the focus of an application. Imagine the horrid side effects of clicking on random buttons scattered like mines all over the place, which fade in when you hover them. Have you imagined it? Ok. I’ve also experienced it and believe me, it’s not funny.
Last time you do it, please.

Thanks and have a good day.
____________________________

Por favor, UX/Diseñadores del mundo:

PARAD DE HACER APARECER BOTONES DE LA NADA CUANDO SE PASA EL RATÓN POR PARTES VACÍAS DE PÁGINAS WEB/PROGRAMAS. POR FA VOR.

Las áreas vacías se usan para hacer click en ellas y así obtener el foco de la aplicación. Imaginad los horripilantes efectos secundarios que podría conllevar hacer click en todo tipo botones, escondidos aleatoriamente como minas por todos lados, en cuanto pasas el ratón por encima ellos. Lo habéis imaginado? Sí? OK, yo lo he vivido, y en serio, no es nada gracioso.
Que sea la última vez que lo hacéis, por favor.

Gracias y que paséis un buen día.

_________________________________________________________________________________________

Post to Del.icio.usShare it with Twitter!Menéalo!Like This!

Dropbox, por qué es imprescindible

“Dead” pixels in my IXUS digital camera (And a fix using CHDK !!)

Lunes, 27/Feb/2012 Deja un comentario

Some days ago, I made a nice trip to Thailand, and, as always, I take my IXUS 80 IS with me, to enjoy the typical photo sessions I usually do: some long exposure ones, some random shoots, etc… CHDK is installed in my SD card, so all the bunch of extra features it offers, was there for me to enjoy also.

Anyway, when coming back home, I started downloading and processing all the pics I took. Then suddently something caught my eye: Some dark (and mainly slow) photographs showed pure red and or blue pixels where they should show black colours. I checked it against 4-5 pics and then I could confirm it: These misbehaving pixels were exactly the same ones across those pics, as they appeared in the very same location on every photograph.
One extra thing that confused me a bit more, was that on some long exposure pics I also took, those rogue pixels WERE NOT THERE!!

I thought, “oh no, my wonderful IXUS’ CCD is broken, and in a very funny way!!”. As always, when something like this happens, I just google some info to see if I could do something about it. In yesterday’s googling I’ve learned some things:

1.- These pixels that show up randomly coloured, are not really broken. They’re “over sensitive” (Oh boy!)
2.- This oversensitive behaviour shows up in dark areas, and mainly doing “slow shots”, (1/3 s. etc…)
3.- All cameras aparently have this kind of pixels (there’s no warranty of a 100% funny pixel free camera).
4.- There’s a nice fix for it!! CHDK itself…

As I said before, when doing long exposure shots, these funny pixels didn’t show up. Then I started thinking, “what’s the difference between a “slow dark shoot” (night shoot against people in a club, for example) and a ULTRA SLOW shoot (+3 minutes) using a tripod against the night sky ? ”

Then some pieces of the puzzle gently fitted on my mind:
-When doing long exposure shots, I could remember the tedious “Wait, processing…” banner appearing after each exposure. That means 1 min exposure means 1 min black frame noise reduction calculation time. 5 mins exposure, 5 mins noise reduction against a black frame. And so on.
Apparently, “those funny pixels” are included in the noise reduction calculation, and thus, when substracting them from the real shot, they just disappear from the final .jpg file, as expected, and as I confirmed. Yay!!

So, when I take “normal slow shoots” at night (not long exposured ones), the “noise reduction process” is not peformed at the end of every shoot. Shouldn’t it be nice if I could force it somehow? And then, reading some CHDK forums here and there, someone hit the nail claiming a strange solution buried in the “RAW Options” submenu. Read on:

Apparently, if you enter onto that submenu (RAW Options), there’s one option there named “Black frame noise reduction” (Or similar name, mine is in Spanish) which is set to AUTO by default. Apparently, AUTO means “Noise reduction post processing will be used in long exposure shoots only”, and nowhere else.
Someone could say, OK, but why is this option “hidden” in the “RAW Options” submenu? I have no idea at all, because setting it to ON forces “Black frame noise reduction” post processing on EVERY shot, not only RAW ones, and not only “long exposure ones”.
That means, even I’m NOT enabling RAW file creation when taking pics (just HQ jpg files are OK for me right now), and even though CHDK reads and uses “RAW Option” submenu settings (even I told it not to store RAW pics on my SD card), I get bad pixel free pics (!!), even when saving them as JPG files!! And all because of the “ON” setting instead of “AUTO”.

Is there some known caveat? Well, “yes”: Now every pic gets “Black Frame Noise Calculation” times after every shoot. But there’s something nice about it: 1/3 s. pic gets 1/3 s. processing time, which is completely affordable in terms of patience waiting for the camera to be ready for the next shoot.

Now EVERY (dark) photo is JUST BLISS, with no random coloured piexels around, (and I would even say generic noise amount is lowered just a bit, I hope it’s not some form of CHDK Placebo 🙂 …

As always, CHDK: Giving proper solutions to everyday (1st world) problems!!

_________________________________________________________________________________________

Share it with Twitter!Menéalo!Like This!

Dropbox, por qué es imprescindible

Categorías:Uncategorized

¿Qué pagaríamos si pagáramos 5 € al mes por Spotify?

Sábado, 16/Abr/2011 19 comentarios

Spotify, desde el 1 de mayo de 2011, se habrá convertido en un programa completamente inútil para quien no actualice su cuenta gratuita a alguna de las dos modalidades de pago (Premium o Ultimate) existentes. (Todo ello explicado en el infame anuncio de mediados de abril de 2011, aquí).

Lógicamente, dos grupos claros (y previsibles) de gente han aparecido llenando los blogs de los países donde Spotify opera(ba):

1.- Los que dicen: “Adios Spotify, hasta aquí hemos llegado”.
2.- Los que dicen: “Pagar 5/10 € al mes es baratísimo, no me creo que haya gente tan llorona por el mundo”.

Yo soy un ferviente defensor de la primera opción. Y no por el típico lloriqueo de “todo lo queremos gratis”, (que es una de las banderas que mucho descerebrado está aprovechando para enarbolar). Nadie está hablando de “los músicos no merecen ser pagados”. Al contrarísimo

En cualquier caso, la versión gratuita de Spotify, “no es tan gratis como ellos quisieran”, aunque lo parezca, ya que se nos obliga a escuchar anuncios que más o menos a regañadientes uno ya se ha acostumbrado a ignorar (o no, Melendi sé donde vives! 😀 ).
Es más, son anuncios que están más o menos geolocalizados, es decir, son anuncios con punto de mira, dirigidos a targets objetivos y acotados, etc… Anuncios “de calidad” por así decirlo.

Algún listillo dirá: “Pero bueno, el ancho de banda que le supone al señor Spotify ir sirviendo canciones por un tubo día tras día, ¿eso quién lo paga? El señor Spotify debe estar ahogado bajo una montaña de facturas de su proveedor de internet, ¿no?”. Pues no, porque el protocolo de comunicaciones del programa Spotify (que es una auténtica maravilla, todo hay que decirlo, that is, el protocolo. Y también el programa, va), está basado en tecnologías P2P. Sí, como el sempiterno, confiable y robustísimo emule, como el demasiado mainstream bittorrent, como ver los partidos de la liga por ‘los chinos’, etc…

Los datos que componen las canciones que yo escucho y que son bajados desde otros usuarios de Spotify que escucharon esas canciones antes que yo, en cuanto los oigo, el programa los reprocesa y los reentrega a la nube Spotify otra vez, para que más usuarios quieran escuchar esas canciones después de mí, lo puedan hacer.
Es decir, el protocolo Spotify está usando el ancho de banda de los usuarios, por tanto somos nosotros, los usuarios, quienes estamos pagando este ancho de banda al señor Spotify de manera altruista sin recibir nada a cambio. Bueno, sí, recibimos canciones, pero éste era el trato no?

Resumen: Yo ya pago a mi proveedor de internet (Teléfonicas/Jazzteles/Oranges/Ono’s/Yacoms/nosentendemos… no?), señor Spotify, no sea tan gorrón, va.

Se puede deducir entonces que el ancho de banda (lo que la gente populachera llama “los megas”) que usa el programa Spotify se compone en un 95% (por decir algo, es para entenderse) por tráfico que generan los usuarios al escuchar las canciones y al usar el programa. Efectivamente, sí, el señor Spotify, sirve la primera versión de la canción a la red desde sus propios servidores que él paga, pero una vez ha sido entregada esa primera versión, la que él alojaba, raramente ésta volverá a ser usada para servirla a otro usuario de nuevo. Este usuario la obtendrá de algún otro que la haya escuchado antes.

De esta manera el gasto en entregar canciones a la red desde los servidores del señor Spotify es marginal. No sería marginal si el señor Spotify tuviera que entregar todas la canciones directamente a cada usuario una por una, (que el señor Spotify no es tonto), pero eso no es lo que está pasando.

Otra cosa genial que pasa con el programa Spotify, es que en el disco duro local de cada usuario que lo usa, quedan almacenadas copias (cifradas y “poco usables”, tranquilos) de las canciones que se van escuchando. Esto tiene el interesante efecto de que, si nos ponemos a escuchar una canción por 10 veces seguidas (por ejemplo con la típica opción Repeat1 o similares), la primera vez, la canción bajará de “la nube Spotify” (recordemos, conformada al 99% por otros usuarios, casi nunca por los servidores centrales de Spotify). Pero qué pasará la 2ª, 3ª, y siguientes veces que oigamos esa canción? Pues que se reproducirá la copia local cifrada que habrá quedado en la caché local del programa, alojada en nuestro disco duro, con lo que el gasto de red para el señor Spotify (y de paso también para nosotros), tiende a 0.

En este punto, los partidarios del “pagar 5/10 € no es tanto”, todavía podrían decir: “Pues mira chaval, motivo de más, mis euros se van directamente a los autores(je)/discográficas/SGAE’s de turno, en vez de al señor Telefónica, ¿no es lo deseable?”. Y yo diría, “bueno sí, si yo fuera un megamelómano que escucha milones de canciones, discos, autores, etc… no te digo yo que no”. Pero resulta que no es así; en mi caso, y en el de la mayoría de gente que conozco. Simplemente “queremos escuchar un grupillo de canciones de vez en cuando para matar el rato mientras trabajamos”.

De todo esto yo deduzco lo siguiente además: Resulta que si cada uno estudia los hábitos particulares de uso de cada uno en Spotify, cuando se van añadiendo canciones y se crean listas y demás, siempre hay una cierta “efervescencia” en los primeros meses de uso del programa. Esta efervescencia se traduce en “añadir canciones a saco”, “crear listas como locos”, “crear carpetas”, y en general, “aterrizar en el programa”.
Pero en cuanto pasan 5-6 meses (o el tiempo que sea), las canciones que uno acaba escuchando acaban siendo un conjunto más o menos cerrado que no crece. Vale, sí, uno siempre puede añadir alguna canción nueva muy de vez en cuando a las listas, pero ya no es la locura de los primeros momentos. Yo al menos no tengo el tiempo para currármelo tanto.

Con esta explicación dónde quiero ir a parar? Pues a que “una vez yo pago mis 5/10€ al mes“, si no voy añadiendo muchas canciones nuevas a mi repertorio de listas y carpetas (en mi caso, insisto, noto que es lo que me pasa), estaría pagando por escuchar canciones que ya están localmente alojadas en mi disco duro, ya que al ser mis canciones favoritas, por el hecho de escucharlas con frecuencia, se quedan en la caché local en vez de bajar de internet.
Y aquí es donde me chirría todo, es decir, mis 5/10 € exactamente ¿”qué están pagando”? “Mi canción favorita ya se bajó hace meses, el autor ya cobró de mis 5 € (je), y aún así sigo escuchando esa canción porque me gusta mucho, el resto de sus canciones son un truño, pero esa en particular me gusta mucho… Sólo por eso, ¿tengo que seguir pagando al autor 5/10 € cada mes?

Y bueno, ¿qué pasaría si el señor Spotify decide dar otra vuelta de tuerca con las cuentas de sus usuarios? Ya no a nivel de precio, sino a nivel de que, de repente, te das cuenta de que la estructura de listas/carpetas que te has currado tras años, aunque parezca que esté alojada en tu máquina, realmente es una abstracción que vive en la nube del señor Spotify. Como tal, quién te dice que no se sacan de la manga en el futuro, por el motivo que sea, algo así como: “Nuevo tipo de cuenta: si quieres opción de gestionar carpetas, adquiere ya Spotify megamulti! por 15 euros”.

Que no, que de repente, uno le ve las orejas al lobo, y “conmigo que no cuenten” para sus experimentos con gaseosa. Suerte en su cercana e incipiente singladura por EEUU señor Spotify, pero esta vez “no tiene razón”.
Alabo el EXCELENTÍSIMO sistema de listas/carpetas/demás (porque es de auténticos maestros no puedo concebir nada más genial).
Me quejo de la cutrada que es que “no estén ciertos grupos” de manera incomprensible.
Pero a día de hoy, GrooveShark (es lo más parecido a Spotify que conozco, otras sugerencias serán bienvenidas), es donde he abierto una nueva cuenta y donde estoy creando mis nuevas listas poco a poco. Vale que GrooveShark es vía web, vale que no tiene carpetas y la usabilidad “no es tan fresca como la de Spotify”. Vale que cada vez que bajas una canción, aunque la hayas oído antes, vuelve a bajar de nuevo desde internet, entera. (El señor GrooveShark la verdad no sé de dónde saca para pagar tanto ancho de banda).

Pero aun así, Spotify Free/Open va a mutar en algo completamente inútil (para mí y para la mayoría). Y si decidiera cambiar mi cuenta por alguna de las versiones de pago, en mi caso, me hace preguntarme qué estoy pagando exactamente, ya que siempre acabo escuchando “las mismas canciones”, “mis favoritas”, una y otra vez.
Yo no soy un musicófago, ni un melómano, ni nadie con pretensiones de “descubridor de grupos y talentos”.
Soy tan normal como tú.

Tristemente, bye bye, Spotify.

 

Diciembre de 2013 EDIT:  Señor Spotify… ejem: Viene usted a las mías 🙂

_________________________________________________________________________________________

Post to Del.icio.usShare it with Twitter!Menéalo!Like This!

Dropbox, por qué es imprescindible

Categorías:Uncategorized

Creating folders inside Spotify

Jueves, 3/Mar/2011 1 comentario

Some time ago, Spotify added a nice feature to help managing the big amount of lists everyone eventually creates. This feature has a name: Folders.

The utility of these folders is similar to everyday “hard disk folders”, that is “creating a tree structure to manage and keep in place all the songs and lists we’ve added to our Spotify profile”.

How to create a folder? It’s very easy. On the top left part of Spotify main interface, there’s a “+” button, right to our username. If we click it, a small menu appears:

-New Reproduction List
-New Folder

Ok, there it is: “New folder”. Let’s choose this option and create a folder. Let’s name it “hello”.

Once we do it, we’ll see it appear on the left panel, among the already existing lists. And that’s it. No more magic when creating a folder.

What can we do with our brand new and shiny folder? Well, we can just fill it with lists (not songs). How? Dragging, (thus, moving), our songlists onto it. Once we do it, the folder will contains a new song list.

Ok, one could now say that no new functionality has been added if we just put one lists inside a folder, but let’s do something nice: Let’s add more than one list into a folder, (for example, 3 or 4 of them).

Once we do it, we still can click onto these lists (as we did on the old days), and their contents will appear onto the main panel.

But what would it happen if we clicked ON the folder, and not on its individual lists? Well, a big “virtual list” consisting of a merge of the folder lists songs will appear now on Spotify main panel. And that’s the real power of folders: we can crate “thematic” folders like, I don’t know, “Queen”, and then adding different “Queen” lists inside, “Greatest Hits 1”, “Greatest Hits 2”, “Favourites”, “Terrific Queen songs”, etc…
We would still be able to play these individual lists (clicking on them individually), but if we wanted a medley consisting of ALL these Queen songs inside our lists, we would just click onto the folder, and “voi là”, all songs appear properly merged on the main screen, ready to be played by the “Shuffle” engine of Spotify.

Of course, and, as every other folder system in computers, we can create folders inside folders, a.k.a sub folders, and sub sub folders, with no problem. We can also rearrange their structure just dragging their contents up and down, in and out.

But real inspiration came to me the other day, when I was just walking on the street. The bulb lighted and I thought: “What would it happen if I created a MASTER folder from where I could hang ALL my lists, sublists, folders and subfolders?”. And I did precisely that: I created a “root folder” (and I named it “Everything”).

The result has become wonderful, as ALL MY LISTS (the ones I’ve been patiently creating over the last years), as well as ALL the lists I’m also subscribed to (friends’ and such), folders, subfolders, and the rest of my “songs tree”, now appear under “Everything”, properly nested.
Why is it wonderful? Because if I click on the “Everything” folder, on the top part of the screen, a BIG merge of ALL my songs, lists, and folders will start to be played by Spotify.

And for me, and for the rest of people who get quickly tired of listening to the very same music all the time, that’s just pure bliss.

_________________________________________________________________________________________

Dropbox, por qué es imprescindible

Post to Del.icio.usShare it with TwitterLike This!

Categorías:Uncategorized

How to properly crop and resize for maximum crispness in retina screens. It wasn’t so obvious…

Domingo, 27/Feb/2011 Deja un comentario

Since October 2010 I became an Xcode developer, starting to build apps for all the 3 Apple available display sizes as of today: iPad, iPhone “old” and iPhone “new” (retina). The funny thing is, I had 0 experience at all in the mobile development world.

Ok, once you cope with the nice dpi boost in retina screens (as an user), you need also to take care of things you never thought you had to deal with as a coder.

One of these (I thought) obvious things was creating images and contents for the typical iOS on-screen widgets (buttons, labels, etc…). Some may say, “you don’t need to, Cocoa is pretty enough”. Well, for an uncomplicated application, it might be the case, but if your workteam has a GOOD designer, soon you start to spend some time not only coding, but also using your favorite cropping/editing/trimming/resizing program (typically paint.net, gimp, photoshop, etc…) to port his nice and professionally designed interface elements.

When I started trimming images from the shiny designs my coworker created, I somewhat put myself onto “autopilot mode”. That was: You opened the retina master image file (with the full UI on screen), cropped the screen area you wanted, saved it as a @2x version filename, resized the same image file to exactly 50%, then saved it into another file (without the @2x in the filename), and then you took care (just typing it down onto a notebook) of the image dimensions you just created, for a latter usage.

This process shouldn’t be tricky except for quite a common case: Retina buttons you crop from the big UI image, sometimes have odd resolution (here “odd” meaning “not a multiple of 2”).

Imagine you crop a button (in a coarse way), then you refine the crop using some “trim transparent pixels from around the button” tool to just fit the image size to pixels with content (we don’t want to store silly transparent areas surrounding your 24/32 bit png files). Now, look at the new trimmed image size, and type down the resolution you’ve got now (for this article, we’ll suppose our @2x image file measures 157 x 97 pixels).

Then, we might save it to our disk with this filename “some_button@2x.png”. Ok, done.

Now, we need to create the “non-retina” version, for older iPhones, which obviously can only show half the resolution on the same screen area… But wait a moment… The original image resolution wasn’t a multiple of 2, so what does “half” mean in this case? Well, it means “bad news”.
In our case we have to decide which will be our “half resolution”. If the original image was 157 x 97… Half resolution would be 78.5 x 48.5 pixels, but as everyone knows, screen resolutions “don’t have half pixels”, so we have to make an intelligent guess: Do we choose (78 x 48) or (79 x 49)?

Fast answer: Both will give us headaches (in terms of retina display), and I’ll show you why just below.

Anyway, let’s choose the first one and let’s downsize the original retina image (157 x 97) onto a 78 x 48 pixel version. We’ll call it “some_button.png”.

In terms of image quality, when downsizing, we NEVER have to worry (no matter the resolution), because we’re losing resolution no matter what we do. IT’S NOT OUR PROBLEM (today). We should anyway use interpolation, and then our half sized image will be recreated from the bigger resolution one, yielding more than satisfactory results. We would have a problem if we were doing it the other way back: upsizing from low-resolution to high-resolution… But that’s not the case.

OK, right now, we have the 2 necessary versions: “some_button@2x.png” (157 x 97) and “some_button.png” (78 x 48). Now we should import BOTH files inside XCode. Then, when we launch Interface Builder, our new image button appears as a the “named resource” “some_button.png”, ready to be used.
One of the nice things about this process, is that even we imported both PNG files into XCode, we only have to use the “non-retina” filename inside our source files. Why? Because the one dealing with the “which version of the file should I choose” question will be iOS runtime, once our code gets executed on the physical device (iPhone, iPad, iPhone-retina). And even more: all this stuff gets transparently done without our intervention.

In more detail, if iOS detects it’s been run inside a retina iPhone, it automagically chooses to show the @2x version of our image, even in our code we just wrote something like: load my image named “some_button.png” (without the @2x) part.
Ok, once we’ve roughly described how iOS deals with retina images, our problems might start now:

iOS runtime image manager is able to pick high resolution images for being used on the render process, BUT iOS screen resolution, at least “logically” is not 640 x 940 (the new dpi boosted one), but 320 x 480, the “crappy” and old iPhone3 one… That is, in Interface Builder we DESIGN our UI with non-retina resolution, expecting that in runtime, iOS-retina will deal with the pixel doubling process.

And what does it have to do with our image files? Well, here comes the funny part.
I said we were forced to choose among 2 “wrong” resolutions. In our first example, I said: “lets choose the 78 x 48 version”.

If we do that, iOS will build a 78 x 48 container on screen, which will be filled with the 78 x 48 version of our “some_button.png” file. So far so good: our low resolution button gets 100% perfectly shown on screen, no distortion, no nothing. Just crisp pixels (reduced, but crisp).
But if we run the very same code on a retina display, the logical container size will be 78 x 48 (as I said, that is iPhone 3 size), BUT this container will be doubled before rendering anything into it. So our logical 78 x 48 container becomes a physical 156 x 96 container, once it appears onto the retina screen. And now, that’s the point where our @2x file (157 x 97) gets rendered onto the actual screen pixels, inside this 156 x 96 container. And as you might think, yes, this creates UGLY resampling of our image, even the rendering process is only shrinking our image file by just a mere pixel.
One might say: “really? is it SO ugly to the eye?” Without any doubt I say, YES! and I invite you to do the test.
(TO DO: I’ll create a demo webpage to show all this in the near future).

So, first option, downsizing to half size -0.5 pixels was a bad choice. Let’s see what happens if we take the +0.5 pixels version for our “non-retina” file size: 79 x 49 (of course, keeping the retina file size 157 x 97, as it was/is the original resolution our designer created for our button).

If we do ALL the process again, we arrive to the very same conclusion, that is:
-Our non-retina container will now be 79 x 49 pixels.
-Our physical retina container on screen will measure 158 x 98 (doubling the size of the logical container, 79 x 49), and again our big file in disk is still 157 x 97, and then when iOS retina places the image into the container, it will suffer a resample of 1 pixel bigger in both directions: Result? Visual distortion again, and our beautiful and crisp button becomes absurdly blurry.

So, is there a solution for all this? Yes it is (probably more than one), but the one I like most is thinking a bit BEFORE SAVING our first @2x retina image file:
-Instead of just blindly saving it, we should check its canvas size, and we will INCREASE ALL DIMENSIONS (width and/or height) SHOWING odd numbers. In our example, our 157 x 97 file will be upgraded onto a 158 x 98 file, JUST ADDING a row and a column of transparent pixels (on the right and bottom sides of it for example).

Will it visually interfere? Not really, (assuming we’re using PNG-32/24 files), because transparent pixels, as its name say, are transparent.

OK, the second half of my “workaround”, just after having saved the @2x version of our retina button, is halving our new image dimensions to achieve half the resolution with no decimal numbers. In our case we get a 79 x 49 small file. One might say: “hey, that’s the same than the second choice of the wrong examples you showed us”. Well, “yes”, resolution is the same, but built up from a different (1 pixel bigger) master file. If you compare carefully, even resolution is the same, contents won’t.

Are we done yet? Absolutely.

We only need to update our Interface Builder UIButton/UIImageView dimensions container, setting it to 79 x 49.
That’s it? Yes it is. Because whenever iOS retina will render this button on our live application, it will create a (79 x 49) x 2 container size, that is 158 x 98, and now our carefully created @2x image file will EXACTLY match this resolution, rendering a sharp and crisp 1:1 image file with the contents of the @2x some_button.png file we carefully created.

I hope my explanation is kind of understandable, I’m open to corrections and suggestions, so feel free to ask.
I just wanted to write all this personal experience, hoping people will be able to create proper image buttons from day 1, and not from day 100, as it happened to me 🙂

NOTE: This method I described, is 100% valid also if you want to create “universal mobile web pages”. That means, “with the same .html file you create both normal and high resolution webpages at once”. Safari under iPhone retina will treat ALL measurements as “low resolution”, except for image files. Feed your webpage with “high resolution” images only, and you’re done (your low resolution webpage version will resample bigger resolution images on runtime).
BTW, I’ve made some preliminary tests on my own, and even Android high resolution display devices treat document dimensions as “low-res”, even image files can be “high-res”, so you kill many birds with just one stone.

Greetings

Post to Del.icio.usShare it on TwitterLike This!

Dropbox, por qué es imprescindible

Categorías:Uncategorized