Archivo de la categoría ‘Android’

Facebook, Facebook Lite, Servicios de Facebook, Messenger de Facebook… y como lidiar con todo ello

Share on Google+Share on FacebookTweet about this on Twitter

No, no estoy muerto, y lo cierto es que este año ni siquiera pude felicitaros a todos estas navidades pasadas ni este nuevo año. Así que antes que nada, un saludo a todos amigos, y mi promesa de intentar escribir de forma más habitual, desde luego no será por no tener material por el cual no hacerlo 😉

Hoy por lo que se ve la cosa va de Facebook. En realidad este artículo era uno de esos que estaban en el cajón del “ya escribiré”. Por desgracia la falta de imaginación me impedía escoger un mejor título para ello, pero en cualquier caso hoy quiero hablar un poquito de esa gran porquería que Facebook hizo (y hace) con su aplicación, concretamente para Android por su amplia mayoría, pero en gran medida es aplicable a iOS.

Sin duda Facebook se ha convertido para muchos en un diario, y me atrevería a decir que una amplia mayoría tenemos su “maravillosa” aplicación en nuestro terminales. Pero como todo, no es oro todo lo que reluce, y cuando hablamos de Facebook la cosa siempre es mucho peor de lo que uno piensa. Puede que alguno no esté de acuerdo y crea que la aplicación es una maravilla en todo su amplio aspecto, pero de eso se trata las letras de hoy, en ver cuan porquería estamos instalando en nuestros terminales… y algunas soluciones a ello. Que sea un tirón de orejas para los amigos de Facebook:

 

Hablemos de Tamaños

Quien realmente piense que el tamaño no importa… se equivoca de cabo a rabo, siempre importa… y mucho más aun cuando no se tiene la mejor maquinaria del mundo. No obstante en este caso, cuanto más pequeño sea (la aplicación) mejor será.

La memoria de cualquier dispositivo (ya sea de almacenamiento principal, RAM, o secundario, SSD/HHD) es finita. Sí, cada día salen dispositivos mejores con mayores tamaños de almacenamiento y con una mayor cantidad de RAM, pero seguramente la mayoría de los presentes ha tenido que enfrentarse a dicho delicado problema antes. Cuanto mayor sea el tamaño de una aplicación mayor capacidad necesitará de almacenamiento, y presumiblemente también de RAM. Cuanto es asumible?? Evidentemente hay que ser realistas, si queremos correr un juego con texturas HD y lleno de polígonos por descontado que requeriremos unos recursos altos. Pero no hablamos de juegos, hablamos de una sencilla aplicación de red social. En números?? Bien, esto es lo que origina una instalación limpia de Facebook:

APK: 35.5 MBytes
Dalvik/ART: 107.4 MBytes
Datos Applicacion: 8 MBytes
Tamaño Total: 151 MBytes (Aprox) Almacenamiento

Una instalación limpia de Facebook ocupa la friolera de 151MB de espacio, insostenible para dispositivos de gama baja que no poseen una partición de datos amplia. Además esto trae consigo un problema adicional doble, y es que todos esos datos son usados eventualmente, con lo que desde la carga de la aplicación, su manejo, su instalación y su desinstalación… TODO hace que sea torpe y lenta en comparación. En contraposición, para los que se pregunten si estos valores son altos o no, citar sólo que Google+ que además incluye toda la gestión de Fotos, localización y otros, su tamaño total se queda en los 64MB (aprox). Es decir, menos de la mitad y con muchas más funciones.

Y que podemos decir de la RAM??

La RAM es aun más crítica que el espacio en muchas ocasiones, porque los dispositivos de gama baja que posean 512MB o incluso 1GB pueden verse rápidamente con la RAM agotada en muchos casos. Es lo de siempre, a más aplicaciones/servicios en ejecución (y según su tamaño) más RAM necesaria. Cuando no hay RAM disponible para satisfacer todo, el terminal debe de ir cerrando aplicaciones/servicios, haciendo que el dispositivo se vuelva muy muy lento. De nuevo, como se traduce esto??

Quizás una de las mejores formas de ver esto es mirando el número de servicios de los que Facebook hace gala. Estos servicios son por así decirlo pequeños procesos dentro de la aplicación que se disparan (o no) en ciertas ocasiones (o de forma ininterrumpida). Evidentemente a más servicios más pesada es la aplicación. Lo sorprendente del caso es que Facebook es sin duda alguna la aplicación con mayor número de servicios que se haya visto… o al menos que haya visto yo claro está. La única que la supera es como es natural los servicios de Google que TODOS tienen instalado en su terminal, pero esto no es comparable, ya que los servicios de Google son núcleo principal de todo Android. De nuevo… en números?

Servicios de Facebook: 67
Servicios de Google+: 35

Por si fuese poco, por lo general Facebook mantiene en ejecución de forma constante un buen número de ellos.

——————-

¿Como lidiar con ello?

Podemos hacer algunas cosas. En primer lugar recomendaría a la inmensa mayoría a usar lo que Facebook ha llamado “Facebook Lite”. La aplicación FB ha llegado a tal extremo que incluso los propios desarrolladores se han dado cuenta que muchos terminales tienen problemas para hacerla funcionar por la inmensa cantidad de recursos que necesita, así que lanzaron hace poco de forma “sigilosa” y sin darle publicidad una versión reducida de su aplicación. En teoría eta aplicación SOLO podrían instalarla aquellas personas que dispongan de terminales realmente bajos, forzando así Facebook a tener que instalar la versión ordinaria en el 90% de los casos, aun cuando la versión Lite funciona mucho mejor en un % muy superior.

Está claro que Facebook quiere que se siga usando su versión ordinaria. Pero esto no quita el echo de que podamos instalarla por nosotros mismos, aunque no por canales oficiales desgraciadamente. La aplicación es oficial:

https://play.google.com/store/apps/details?id=com.facebook.lite&hl=es

No obstante quien intente instalarla posiblemente le diga que su terminal no es compatible. Para poder instalarla deberá de descargarla desde cualquier sitio el APK directamente e instalarla, ya sea a través del navegador, de un gestor de archivos, por ADB, enviándosela por correo electrónico… podría poner enlaces pero ya conocéis mi política sobre ello. Haced una simple búsqueda en google y listo. La versión más actual hasta la fecha es la 1.5.0.13.30 (a día 28/02/15). La aplicación es más fea que la ordinaria estéticamente, pero pensad que el APK no llega siquiera a los 300KB, y que la aplicación es prácticamente a todos los efectos igual funcionalmente, y ademas ES POSIBLE USARLA PARA LEER MENSAJES Y CHATEAR, sin necesidad de otras aplicaciones. Por otro lado no tiene servicios asociados a ella, y el consumo de RAM es infinitamente inferior, y la aplicación corre mucho más rápida.

 

Quien no quiera usar Facebook Lite, las alternativas son más escasas. Lo primero sería deshabilitar gran parte de los 67 servicios que requiere. Que la aplicación use 67 servicios no quiere decir que nosotros no podamos bloquear los que queramos. De echo os puedo asegurar que la aplicación funciona perfectamente aun cuando se bloquean la mayoría de ellos. Por desgracia la única forma de bloquear servicios de una aplicación requiere tener el dispositivo Rooteado. Si es así, podemos hacer uso de aplicaciones como por ejemplo Disable Service:

https://play.google.com/store/apps/details?id=cn.wq.disableservice&hl=es

La mejor forma de ver que servicios son necesarios es o por su nombre e inducirlo, o prueba error.

Screenshot_2015-02-28-16-15-26

 

 Hablemos de datos generados

El tamaño es algo preocupante, pero el problema de espacio va mas allá. Como cualquier aplicación que se precie (y más si es una aplicación “online”) hace uso de una caché de datos. Esta caché va almacenando datos temporales con el fin de reusarlos cuando se requieran sin necesidad de realizar de nuevo peticiones a los servidores y descargar de nuevo el contenido, y que de este modo todo sea más rápido. Es lógico, si veo A, un minuto después veo B y un minuto después vuelvo a ver A, si A estaba cacheado esto sería automático. La teoría es clara, el problema sucede cuando este cacheo de datos no es eficiente.

Cuanto más usamos el navegador Web o cualquier aplicación de redes sociales, el caché aumenta como es natural, pero igualmente importante es saber que contenido se debe de cachear, por cuanto tiempo y poner un límite a ello. Esto es lógico, no querríamos cachear por ejemplo contenido por el que se busca una actualización ni agotar el espacio en disco por un caché enorme, que además hace que toda la aplicación sea más lenta.

Facebook hace un uso muy extensivo del caché… el problema es que ni permite delimitarlo, ni parece a veces tener fijado períodos de validez (fecha tras la cual los datos en una caché son purgados) y parece quererlo cachear todo siempre. En números?? Lo siento… no puedo, cada usuario tendrá valores muy dispares, y dependerán de cada caso y uso. No obstante invito a cada uno que mire en sus dispositivo a cuanto asciende este montante: Ajustes/Aplicaciones/Descargadas(o todas)/Facebook -> Cache. No nos sorprenderá ver como el caché llega en muchos casos perfectamente a los 200-400MB.

Otro problema que añade Facebook a la ecuación, es que desde hace un tiempo incluyó en su propia aplicación “visor web,” para que los usuarios al darle a algún artículo o enlace externo en vez de hacerse en nuestro navegador (mucho más funcional e infinitamente más seguro) lo abra en su propio “visor web”, el cual usa por supuesto más caché.

——————-

¿Como lidiar con ello?

Es más complicado evitar esto. Por desgracia Facebook no posee ningún parámetro para controlar la caché máxima usada o incluso deshabilitarla. La única opción es regularmente acceder a los ajustes del terminal y eliminarla: Ajustes/Aplicaciones/Todas|Descargadas -> Facebook -> Limpiar Caché.

Paralelamente, podemos cada X en X eliminar también los datos de esta, aunque eso nos obligaría tener que volver a Iniciar Sesión, y la mayoría de los datos se volverían a recrear.

Por supuesto, otra opción a todo este problema sería en gran parte usar, de nuevo, Facebook Lite.

 

Hablemos de Permisos

 Como cualquier aplicación móvil que dispongamos a día de hoy, cada una requiere de ciertos permisos para poder así acceder a los diferentes recursos de nuestro dispositivo, y por supuesto a nuestra información privada. Esto es necesario ya que si se denegase de forma global nuestra información a las aplicaciones la variedad de estas sería mas bien escasa, a fin de cuenta de poco sirve una aplicación de Contactos o Calendario si esta no puede acceder a nuestros contactos o calendario.

La picaresca de todo ello es evidente. Si una aplicación tiene permisos para acceder a X y dicha aplicación tiene permiso para acceder a la red, en teoría NADA le impediría enviar los datos X a los cuales tenía concedido permiso a un servidor remoto… es decir, robarnos información privada. En un mundo idílico en el que TODOS actuásemos siempre de buena fe esto no sería un problema ya que interpretaríamos que las aplicaciones tan solo accederían a nuestros datos a los cuales tienen permiso cuando así lo necesitasen para nuestro correcto uso, y que jamás accederían a nuestros datos (con permiso o sin ellos) para ser usados con fines maléficos. El problema es que nuestro mundo dicta mucho de ser idílico, y la información es poder.

Dicho esto, es necesario ciertos permisos a las aplicaciones?? Sí siempre y cuando su uso sea justificado. No cuando dicha aplicación no tendría que hacer uso de la información que solicita. Vamos a ver ejemplos lícitos:

-Whatsapp acceso a contactos -> Es necesario, de lo contrario no podríamos conocer el estado de nuestros contactos, ni siquiera el nombre de ellos en la aplicacion.
-Whatsapp ubicación -> Necesario, pero la aplicación sólo debería de acceder a la ubicación CUANDO COMPARTIMOS NUESTRA UBICACIÓN CON UN CONTACTO, no antes, no después (actualmente es como lo hace)
-Facebook -> Acceso al almacenamiento -> Es necesario dado que podemos compartir fotos y otros, y por tanto la aplicación debe de poder acceder a nuestro almacenamiento
-Aplicaciones de Cámara -> Necesita acceso a la cámara porque de lo contrario serviría para poco..

La mayoría de los permisos de Facebook son realmente legítimos y su uso es justificado, el problema es que hay otros permisos que aun siendo justificados hace uso de ellos cuando él quiere, y otros que por descontado son peligrosos. No voy a listar todos los permisos, sólo los que nos interesan:

-Ubicación: Facebook en teoría hace uso de este permiso para poder establecer en las entradas la ubicación desde la cual se realiza la publicación, lo cual podría ser legítimo. El problema es que nuestra ubicación se está transmitiendo de forma constante a Facebook la queramos usar o no. Esto quiere decir que Facebook puede saber prácticamente en cualquier momento la ubicación, al menos aproximada, de cualquiera que no tenga dicho permiso bloqueado.

-Contactos: Facebook generalmente nada más arrancarlo nos permite si deseamos “compartir” nuestra agenda generosamente con ellos. Sí, tal como suena, nuestra agenda de contactos es enviada a Facebook. La excusa a esto es que así el usuario puede encontrar a amigos que no tengan en su facebook gracias a que Facebook cruza su agenda con números de teléfonos registrados en Facebook y demás. Personalmente me parece cuanto menos peligroso este tipo de prácticas.

-Llamadas: Es posible que en algún punto de Facebook este permita llamar directamente a un contacto de Facebook, cosa que ignoro, pero lo cierto es que Facebook tiene permitido el poder realizar llamadas desde el terminal, así como leer y mandar SMS. No pongo en tela de juicio el uso que hagan de él, y al contrario de lo que sucede con la ubicación no tengo constancia de que facebook haga uso de este permiso… pero si está para algo estará.

——————-

¿Como lidiar con ello?

Por lo general no podemos rescindir permisos de una aplicación. Podemos no instalarla si no estamos de acuerdo con ella, pero no seleccionar selectivamente estos a la hora de instalarla. No obstante, al igual que sucedía con los servicios, si el dispositivo está Rooteado o incluso en algunas versiones de Android JellyBean sin necesidad de rootear, podemos instalar/usar un gestor de permisos que sí nos permita de forma selectiva habilitar aquellos que deseamos o no. Algunas ROMs personalizadas así como algunas de algunos fabricantes TAMBIÉN permiten realizar esto de un modo similar.

Hay que tener no obstante cuidado cuando se restringe un permiso a una aplicación, ya que muchas veces podemos estar suprimiendo un permiso necesario para su correcto funcionamiento, y el eliminarlo supondría desde un comportamiento anómalo hasta el crash de la aplicación misma. Así que cuidado…

En este caso por poner un ejemplo podríamos usar la siguiente aplicación, inspirada a su vez a la funcionalidad nativa que Google implementó de forma secreta en JellyBean y eliminó más tarde:

https://play.google.com/store/apps/details?id=fr.slvn.appops&hl=es

 Lo más útil posiblemente de este tipo de aplicaciones es que te muestra incluso cuando fue la última vez que una aplicación hizo uso de alguno de los permisos listados. Por contra, no se listan TODOS los permisos que tienen las aplicaciones.

Screenshot_2015-03-01-19-14-41

Faltan un buen puñado más que está más arriba. En mi caso por ejemplo, tan solo tiene permisos para básicamente mostrarme las notificaciones y mantenerse la aplicación de fondo. Si pusiese una imagen la haría desde la cámara propia y no desde las funciones integradas de Facebook, así como si lo que quisiese fuese enviar un mensaje de voz… evidentemente al denegar el acceso a facebook a dichos permisos, es normal que algunas funciones no funcionasen correctamente. Por otro lado me aseguro que Facebook no pueda tener nunca ni acceder a mi agenda, a mi cámara, calendario, ubicacion… y otros.

Otra buena forma de combatir estos abusos es aplicar un planteamiento diferente. El problema es evidente el posible robo de información, o el no desear que otros tengan nuestros datos. Bien, en aquellas aplicaciones por tanto que no requieran realmente una conexión a Internet y que la usan ya sea para mostrarnos publicidad, reportar estadísticas y otros… se les puede denegar la conexión. Dicho de otro modo, podemos bloquear cualquier aplicación a que acceda a internet, y por ello accedan a la información que accedan es irrelevante, puesto que no puede comunicarla (a lo mejor por SMS u otros medios, pero no entremos en eso). Muchas ROMs e incluso aplicaciones de seguridad permiten hacer esto de forma sencilla, y podemos escoger a voluntad que aplicaciones tienen acceso y cuales no, ya sea por WIFI o por redes móviles.

Personalmente me gusta lo sencillo:

https://play.google.com/store/apps/details?id=com.googlecode.droidwall.free&hl=es

De cualquier modo esta aplicación requeriría Root, y en el caso de Facebook sería totalmente ineficaz, ya que Facebook requiere como es natural acceso a la red sí o sí. Pero la dejo de todos modos por su simpleza, comodidad y realmente utilidad.

 

Hablemos de duplicidades

Hace algún tiempo, cuando deseábamos hablar con un contacto o leer sencillamente un simple mensaje privado de Facebook lo podíamos hacer de forma sencilla a través de la propia aplicación. En algún punto Facebook decidió que para que permitir a los usuarios hacer eso, si podían sacar OTRA aplicación para poder hacer LO MISMO en esencia, con la pega de tener que instalar otra aplicación, con el consumo de espacio añadido, consumo de servicios añadidos, permisos añadidos… suma y sigue, suma y sigue.

Muchos podrán decir que es una idea muy adecuada para aquellos que no quieren usar Facebook para “hablar”, o para que aquellos que no usasen estas funciones tener una aplicación de Facebook más ligera eliminando de ella todos los servicios y funciones asociadas al chateo. El problema es que esto es falso.

La aplicación oficial de Facebook sigue estando totalmente equipada para funcionar de forma autónoma para chatear y leer mensajes privados, no solo no se ha eliminado sus funciones sino que se han seguido implementando en ella. Que la mayoría de las personas no pueda usar dicha función no radica en el echo de que se haya siquiera eliminado de Facebook, sino que estos por defecto impiden el acceso a dicha característica, para forzar evidentemente a instalar su Messenger.

No obstante la aplicación de Messenger no es la única duplicidad que Facebook quiere tener en su aplicación, y como ya comenté anteriormente un “visor” web incorporado para que el usuario en la medida de lo posible nunca abandone el uso de su aplicación, sin contar con que puede recuperar más información del usuario, publicidad…

En un principio la idea podría verse como positiva, pero tiene muchos más contras que pros. Para empezar, un navegador web (ni siquiera un visor web) nace de un día a otro. Son 3 las principales preocupaciones de los navegadores: Compatibilidad/Estándares, Seguridad y Rendimiento. Abrir un enlace en Facebook puede ser tremendamente peligroso, dado que los navegadores son el 1º foco de entrada a los exploits!! Si ya le cuesta mucho trabajo a Chrome, Firefox, IE… lidiar con ellos, un visor web mejor ni mentarlo. Por otro lado, rara es la semana que no me llama alguien o me comenta que cada vez que esta en FB e intenta ver algo desde él la página no se muestra correctamente o la aplicación se cierra o causas similares… y lo que no sabe ese usuario es que realmente FB está abriendo dicho enlace en la misma aplicación, no en su navegador web de siempre.

 ——————-

¿Como lidiar con ello?

 No podemos eliminar funciones integradas en Facebook, pero podemos ponerles coto. En primer lugar, pensar si realmente necesitamos la aplicación Messenger. Me encuentro a diarios terminales que tienen un elenco sin fin de aplicaciones de mensajería y de Redes Sociales. ¿Realmente se necesitan tantas? Personalmente me niego a tener instalada una aplicación de mensajería para cada ocasión o persona, y si a quien quiere comunicarse conmigo no le parece adecuado… pues que no lo haga. Estar comunicado SI, pero no a cualquier precio, hay que ser práctico, de nada me facilita la vida 100 aplicaciones. Messenger para Facebook?? No gracias. Sobre el “navegador” interno?? Más de lo mismo, pero eso lo trataré mejor en la siguiente sección, dado que esta opción si puede deshabilitarse directamente en Facebook.

El problema es que Facebook impide entonces el acceso a mensajes privados y a contactar directamente con ellos (cosa que me parece totalmente inaceptable). Por suerte este atropello sí podemos sortearlo de dos formas diferentes.

-La primera, pasa por usar Facebook Lite que SI PERMITE estas opciones
-La segunda pasa por modificar una pequeña variable en las preferencias internas de Facebook para poder habilitar de forma permanente el messenger QUE TIENE y que Facebook deshabilita para que instalemos su aplicación

Sobre la primera solución ya se ha citado, sobre la segunda habrá que hacer uso de nuevo de un terminal Rooteado. Por qué?? Porque en Android la única aplicación que puede acceder a sus datos es ella misma… y por supuesto el superusuario root. Con él podemos entrar, salir, modificar… a voluntad lo que queramos. En este caso es un proceso sencillo, y podemos hacerlo desde el propio terminal o desde un PC si lo preferimos. De lo que se trata es básicamente abrir la base de datos de las preferencias internas de Facebook, modificar la que deseamos, guardar los cambios y listo.

El archivo que necesitamos localizar está en la carpeta de datos de Facebook, esto es generalmente en:

/data/data/com.facebook.katana/databases/prefs_db

Es una base de datos estándar SQLite con un buen número de parámetros. El que nos interesa sin embargo (en la tabla preferences) es_

“/config/force_messenger/first_shown_1”

La tabla contiene 3 columnas, el parámetro (key) que es el que hemos indicado, Type que establece el tipo de dato (booleano, entero…) que dicho parámetro almacena, y la última columna el valor. El valor de dicha preferencia no es otra cosa que un timestamp (fecha) de cuando fue la primera vez que se abrió Facebook en esa instalación. Si lo pensamos, cuando instalamos de nuevas Facebook podemos de echo usar el messenger durante un tiempo. Internamente Facebook sencillamente hace una cuenta sencilla, si han pasado X días desde la instalación, se impide el acceso a los mensajes. Como arreglarlo? Sencillamente, estableciendo un timestamp absurdo futuro, de este modo esos X días nunca llegarán a pasar.

El valor es un timestamp Epoch linux estándar. Posiblemente el valor que cada uno tiene puesto actualmente sea aproximado al día que inició FB por 1º vez desde la instalación de la aplicación (o si se eliminaron los datos de esta). No voy ahora a explicar el significado de dicho número porque hay más que información en internet sobre ello, basta decir que si ese valor (que equivale a una fecha y hora concreta) lo modificamos por otra futura de amplio rango… problema solucionado. Por ejemplo, podríamos cambiar dicho valor por:

“2524608000”, que sería el 1 de Enero de 2050 a las 0.00.

Con guardar los cambios en la base de datos y actualizar el archivo original, el problema estaría solucionado, tendríamos acceso tanto a nuestros mensajes privados como a poder chatear con cualquier contacto sin necesidad de la aplicación externa.

 

 Hablemos del tráfico de Datos usados

 Datos, datos, datos… No, no tenemos planes de datos ilimitados. Por WIFI no hay problema, pero cuando pasamos a redes móviles muchos se dan cuenta que sus planes de datos actuales se van quedando cada vez con menor margen de maniobra, y en muchos casos obligados a buscar planes de datos mayores. Pero como es posible que antes con 1GB algunos pudiesen hacer MÁS de lo que ahora pueden hacer con 2GB?? No es un misterio, y no es siquiera un complot en nuestra contra!! Es el abuso de algunos desarrolladores que creen que todos los recursos son ilimitados, y aplican incorrectamente políticas en la forma de gestionar estos recursos.

Cualquier aplicación que pueda hacer un uso alto de datos, debería de aplicar por defecto reglas conservadoras en cuanto al uso de datos móviles, es decir, permitir por defecto si se desea los datos por WIFI, pero al menos PREGUNTAR si se desean ciertas características a través de redes móviles. Un ejemplo sencillo de una buena política aplicada a este aspecto es cada vez que descargamos desde Play Store una aplicación con datos masivos adjuntos… automáticamente nos pregunta (incluso aconseja) que los datos masivos de ese tipo se hagan por WIFI. Play Music?? Lo mismo, por defecto la calidad de Streaming para redes móviles es más baja, igual sucede por supuesto con YouTube. Aplicaciones que pueden exprimir en un momento nuestros datos.

Tenemos otros ejemplos de políticas mal aplicadas. El caso más sencillo es WhatsApp. Hizo falta MUCHAS actualizaciones para poder AL MENOS escoger cuando queríamos que las imágenes y vídeos se descargasen automáticamente. Y aun así, a día de hoy, la opción por defecto es descargarlo TODO ya sea por WIFI o Datos. Esto significa que por defecto podríamos de forma sencilla agotar el plan de datos de CUALQUIER usuario, y dado que por defecto WhatsApp permite la comunicación entre usuarios, eso se traduce en que podríamos agotar el plan de datos de la mayoría de cualquier usuario tan solo conociendo su teléfono, y mandando sin parar vídeos e imágenes desde nuestra red WIFI.

Volviendo al tema que nos concierne hoy. Pero, como está todo esto relacionado con Facebook?? Es solo una red Social, no debería de tener un uso tan excesivo de datos!! Sí, esa es la teoría. Invito a TODOS a mirar el consumo de datos que se está llevando mensualmente su Facebook… por favor, hacerlo: Ajustes/UsoDatos… Estoy convencido a que la mayoría que suela estar de un sitio para otro (y por tanto haga mayor uso de datos y no wifi) y use Facebook de forma habitual, ese consumo de datos puede llegar fácilmente al 1GB!! Y no, no es una broma.

Podéis creerme cuando os digo que tampoco es raro que alguien me venga diciendo que se ha comido todos los datos y no sabe como o donde o cuando… Ajustes, Uso de Datos… y sorpresa sorpresa: Facebook.

Esto se debe a dos causas principalmente, y no, no es por las fotos que se puedan cotillear, estas en su conjunto no ocasionan tantos datos. El problema principal es el modo en el que Facebook “precarga” los datos. Por un lado el stream pricipal del usuario en el que están todas las entradas, y en segundo lugar y causa PRINCIPAL, es que a los amigos de Facebook se les ocurrió la genial idea de que los vídeos que pone la gente se comenzasen a reproducir AUTOMATICAMENTE a medida que nos desplazamos por nuestro stream. Si se reproducen significa evidentemente que se están descargando… con lo que la gracia es importante. Abrimos FB, alguien ha puesto un vídeo y este automáticamente se descarga y ejecuta. Un vídeo no aporta mucho, pero a lo largo del mes que a lo mejor hemos tenido que lidiar con 20 0 30 de estos incluso sin saberlo nosotros, más todo lo demás… creerme que ese consumo absurdamente algo es debido en su mayor parte a esto. De nuevo, no me parece mal tener una opción que permita realizar esto, el problema es como cuando se hizo en WhatsApp aplicar incorrectamente las políticas por defecto, y en este caso dicho comportamiento está habilitado por defecto SIEMPRE!!

 ——————-

¿Como lidiar con ello?

Afortunadamente aquí lo tenemos más fácil. Tan solo debemos configurar bien Facebook para impedir que esto vuelva a suceder. En los propios ajustes de la aplicación está la opción para cambiar este comportamiento, el cual aconsejo simplemente en ponerlo en nunca. De paso, y como dije anteriormente, también disponemos de la opción para deshabilitar el visor interno de Facebook para Webs, que recomiendo igualmente desactivarlo (es decir, activar siempre el navegador Externo)

Screenshot_2015-02-28-16-16-07

Algo tan sencillo como esto puede ahorrarle a más de uno una cantidad sumamente elevada de datos, y eso en definitiva es dinero.


 

 

La manía que tienen las compañías de intentar meterte lo suyo por los ojos no beneficia a nadie… tan solo y a corto/medio plazo a ellos, pero a la larga lo último que te queda es confianza en compañías así. Otro ejemplo es Messenger, que confianza puede dar una compañía que obliga a sus usuarios a usar OTRA aplicación para usar las mismas funciones que su propia aplicación ya tiene… es absurdo cuanto menos. No digo que exista siempre una mano negra ni mucho menos, pero es más que evidente que aquí nadie da nada a cambio de nada, que muy pocas compañías miran realmente por las necesidades de sus usuarios y tan solo en como rentabilizar al máximo sus productos.

 

Hasta aquí por hoy amigos, un saludo a todos.

Google IO 2014: Analisis Keynote

Share on Google+Share on FacebookTweet about this on Twitter

Después de unas 2 horas largas, ha dado fin el keynote de este año. Este año no hemos tenido puestas en escenas espectaculares, y curiosamente tampoco con la presencia de Larry Page ni de Sergey Brin. Sin Vic, el peso de la conferencia calló en gran medida como era de esperar en el brillante Sundar Pichai, aunque sinceramente mucho menos carismático… Al igual que el año pasado se han centrado sobre todo a desarrolladores y fabricantes, y adelantando el contenido, no, no ha existido ningún lanzamiento de ningún producto, así como algunas interrogantes que se han quedado en el aire, temas que creíamos que serían aclarados y que no se han tocado.

De cualquier modo, esto no desluce del todo ni mucho menos el keynote, y es que no son pocas las novedades que han puesto los chicos de Google sobre la mesa… y cuando digo que no son pocas quiero decir que son un grueso más que considerable.

La idea es dividir las novedades según temática, aunque en algunos aspectos es complicado dada la interacción que la mayoría de productos/servicios tienen entre ellos. Empecemos.

 

Android

Como era de esperar, lo primero que se ha destacado ha sido la expansión de Android que continúa sin detenerse. Sabemos por estadísticas y estimaciones de otros que Android posee a día de hoy un share de un 80% del todo parqué de dispositivos tipo SmartPhones, pero no datos oficiales. Los datos oficiales no han hablando de porcentaje, sino de usuarios, y según los datos de Google, actualmente hay ACTIVOS (actividad en los últimos 30 días) más de 1.000 Millones de dispositivos. Es un número que da miedo siquiera imaginar. Por otro lado ha destacado el crecimiento específico de Tablets. Si el año pasado se estimaba un 46% de todas las tablets vendidas, en lo que llevamos de año ya se ha llegado al 62% del mercado.

Otro dato asombroso es el número de aplicaciones instaladas, que ha saltado un 236% con respecto el año anterior.

Algo que agradezco a compañías como Google y que siempre he criticado en Apple por ejemplo, es que tan solo se centran en sus productos, no en la competencia. Que quiero decir con esto?? Bien, no hace ni un mes que fue la conferencia anual de Apple, y en ella invirtieron más de 30 minutos comparando constantemente con Android, poniendo estadísticas y datos a los presentes (la mayoría por cierto erróneos por no decir que falsos) para venderles que su producto es el mejor. No hay mejor forma de medir la “salud” de una compañía que viendo las estrategias de márketing tan dispares… mientras que Apple todo lo que hizo fue forzarse a demonizar y atacar constantemente a Android, Google no usó en ningún momento ni una sola comparativa de ventas o de penetración de mercado o de… Sundar sencillamente se limitó a dar datos propios. Unos centraron su exposición en intentar dejar mal al otro, los otros sencillamente se centraron en informar y explicar sus novedades sin importar la competencia. Tan solo eso dice mucho de una empresa… y de la salud de ella. Digo todo esto porque cualquiera que viese o atendiese a la WWDC de este año se daría cuenta del interés desmedido por parte de Apple de intentar tirar por tierra a Google… en vez de preocuparse por sus usuarios y sus productos, que es lo que deberían de hacer…

 

Android One

Una de esas agradables novedades, de esas de las que nadie conocía rumores ni habladurías. Como si de la nada se lo sacasen, Google anunciaba una plataforma de hardware llamada “Android One” pensada para mercados emergentes. Sundar destacó que pese a ese 1.000 millones de usuarios, la mayoría de la población mundial no posee dispositivos inteligentes que disponemos en el primer mundo. Si mirásemos un mapa del mundo en el que se mostrase quienes no tienen están lejos de este tipo de dispositivos, tan solo podríamos soltar una tremenda exclamación. Y es que estamos tan acostumbrados a nuestro estilo de vida, a la tecnología que nos rodea… que muchas veces olvidamos que realmente nosotros somos una minoría de un conjunto mucho mayor.

Así nace Android One. Una plataforma hardware “base” que sirva para crear dispositivos Android de muy bajo coste, de modo que sea rentable también comercializarlo por parte de empresas. Estamos acostumbrados a Samsung, LG, Sony… y tantos otros, pero en los mercados emergentes a la inmensa mayoría de estas empresas no les es rentable comercializar dispositivos que posiblemente no podrán siquiera vender por el coste que tienen y por las circunstancias tan dispares. En cambio, Android One proveerá a una gran cantidad de fabricantes “independientes” a crear dispositivos Android muy interesantes a precios muy bajos. Como ejemplo mostraron un terminal creado por Micromax, con una pantalla de 4.5”, SIM dual, Radio… por un precio inferior a los 100$. Todo ello garantizando actualizaciones automáticas, acceso a los servicios de Google evidentemente… etc etc

No es de extrañar este tipo de movimientos de Google, hace ya mucho tiempo que trabaja de forma muy activa para acercar la tecnología a todas las partes del mundo. Esta visión tiene dos ventajas para Google. Por un lado está la visión solidaria con el tercer mundo, y es que no son pocos los gestos que Google tienen en todo el mundo en este aspecto. Pero paralelamente a Google le interesa igualmente estar en todas partes. Si eres capaz de dotar con terminales de bajo coste al tercer mundo ofreciendo al mismo tiempo terminales de calidad, estás mordiendo a lo mejor el 99% del mercado restante que existe y que aun no tiene dispositivos inteligentes.

 

Android L

Como era de esperar Google a anunciado su nueva iteración de Android, salvo con dos detalles que hasta ahora nunca se habían dado. El primero es que no se ha puesto a disposición inmediata ni mucho menos, ya que Android L estaría disponible para este otoño… teniendo en cuenta fechas y otros yo estimo que para Octubre.

El segundo detalle interesante es que en todo momento se usó el término Android L. Esto significa que el nombre en clave para la próxima versión de Android continúa en la incógnita, así como si será un Android 4.5 o más probable un Android 5.0. Muchos aun estarán con que será Lime Pie, pero lo cierto es que si internamente Google le ha puesto nombre, por ahora lo desconocemos. Esto le daría la ventaja a Google de poder modificar el nombre por cualquier motivo, recordemos que Android 4.4 originalmente no se llamó KitKat, y que fue aprovechando el boom medíatico y una acertada camapaña de márketing la que determinó finalmente su nombre.

Nombres aparte, sí se ha dicho que aunque Android L no se lanzará oficialmente hasta dentro de un tiempo, de forma casi inmediata se pondrán a disposición de usuarios Nexus  (al menos para Nexus 5 y Nexus 7) las imágenes “preview” de Android L, para quien quiera pueda instalarlas. Deberían de estar disponibles a partir de mañana. Lo que no ha quedado claro es si liberarán igualmente el código AOSP de mientras… que sería lo ideal… pero sinceramente lo dudo mucho. Una vez que las imágenes estén disponibles si podremos tener una visión mucho más real de lo que es y será Android L.

Cambios?? A gran escala. Android L incluye más de 5000 nuevas APIs, un diseño totalmente renovado y grandes mejoras en muchos aspectos, que ahora iremos viendo.

androidl

Diseño:

Lo primero que se nos ha mostrado ha sido una interfaz totalmente nueva y unificada. Google a llamado a esta interfaz o a este modo de diseñar aplicaciones “Material Design”, algo así como “diseño de materiales”. En realidad el concepto es un tanto confuso. La idea es básicamente crear una capa estandarizada en la que se apoyen todas las aplicaciones y que dotan a estas con efectos de todo tipo, diseño moderno y unificado. De este modo Google logra después de mucho tiempo algo que algunos puristas siempre se andaban quejando con cada iteración de Android (a veces con razón) y es la no existencia de una interfaz más o menos estandarizada. De echo esto sucede incluso en las propias aplicaciones de Google, que vemos incoherencias de diseño entre unas con respecto a otras. Con Materials, Google de un plumazo puede unificar de forma sencilla todo.

No se trata ni mucho menos tan solo de una unificación. Materials dota de algunos efectos realmente interesantes a cualquier aplicación, como por ejemplo sombreado e iluminación dinámica automática, animaciones y transiciones elásticas que dan sensación de fluidez constante mientras nos desplazamos por las diferentes aplicaciones… incluso a veces el cambio de tareas da la sensación de no ser tal. Otras veces los elementos parecen flotar ligeramente sobre otros dando un look moderno y profesional.

Otra cosa interesante por ejemplo es el ajuste automático de colores en función del contenido a mostrar. Así por ejemplo si estamos viendo una foto que predomina el rojo, a lo mejor la etiqueta que tenga alrededor tiene un color similar para que encaje perfectamente con el resto de la “estampa”. Los ejemplos que se han mostrado desde luego funcionan muy bien visualmente.

Personalmente es muy interesante y a priori me gusta la idea. No obstante no me ha gustado demasiado la “sobrecarga” de efectos a la hora por ejemplo de hacer un sencillo “touch” en una opción/selección. La pregunta es hasta que punto Android L permitirá o no la deshabilitación de ciertos efectos. Si permite cierto control sobre ellos, será perfecto, ya que aquellos amantes de la vistosidad podrán tenerlo todo activado, mientras que los amantes de los cambios rápidos podrían deshabilitar la mayoría de los efectos, sobre todo de transiciones y selecciones.

Aun con todo, lo cierto es que los cambios entre aplicaciones y algunas transiciones se ven muy naturales y “agradables”, y lo mejor es que Materials en realidad se integra en todas las partes del sistema, eso incluye notificaciones, opciones, aplicaciones… todo, y todo como digo con sus sombritas proyectadas, iluminación…

La idea no es solo quedarse ahí, sino que Google quiere extender este diseño a la propia web y en general a cualquier dispositivo Android. Así también a anunciado la puesta en marcha inmediata de Polymer (una API orientada a Web) y la URL que centralizará digamos todo el “nuevo diseño” de google, nos permite acceder a contenido de todo tipo, descargas de programas para diseñar webs… todo lo necesario:

https://google.com/design

 Aquí podemos ver también un vídeo

Recordemos que todo ello, siempre, bajo 60fps…

Mejora de notificaciones

Otra función que ha sufrido una fuerte remodelación han sido las notificaciones. Quizás la más inmediata es la inclusión de notificaciones en la pantalla de bloqueo (si, similares a las que vemos en iOS), pudiendo descargarlas igualmente desde la pantalla bloqueada y todas ellas de nuevo con el nuevo diseño Materials. Lo que no se ha especificado es si se permitirá especificar que aplicaciones pueden mostrar notificaciones en la pantalla de bloqueo y cuales no… es evidente, si quiero privacidad no voy a permitir que puedan verse en la pantalla de bloqueo.

Otra mejora es la inclusión de las llamadas Notificaciones HeadsUp. Esta función en realidad está ya implementada en Android 4.4.4, pero Google no la tiene habilitada. En muchas ROMs de terceros esta opción está habilitada y funcionando perfectamente. Las Notificaciones HeadsUp se mostrarían directamente sobre la pantalla en la parte superior, sin interrumpir absolutamente nada de lo que estuviésemos haciendo. De este modo se logra algo que antes era imposible: Cuando trabajamos con aplicaciones en modo inmersivo (pantalla completa) si nos llegaba una notificación teníamos que salir de dicho modo para poder leerla. Ahora las notificaciones caerán directamente sobre la pantalla si lo estamos usando, ademas de evidentemente en la persiana de notificaciones. Posiblemente no se habilitó en 4.4.4 porque aun tiene algunos flecos que pulir, pero en general funcionan muy bien.

Por último, se hace un mayor uso de la priorización de notificaciones. Es decir, si una notificación nos llega pero posee una mayor prioridad, ocupará una posición superior respecto a las otras. Así mismo podremos incluso ordenarlas si así lo deseamos.

Nuevo método de “desbloqueo”

Por lo que he podido sacar en claro, la idea es usar un modo pasivo de desbloqueo que funciona por reconocimiento de patrones vocales del usuario. Es pasivo porque si he entendido bien el teléfono detectaría si estamos presentes o no por la voz. Si lo estamos el teléfono sencillamente estaría desbloqueado, pero si abandonásemos la habitación y alguien quisiese usarlo estaría bloqueado siendo necesario un PIN, patrón… no lo tengo claro del todo ya que eso implicaría que el terminal estuviese constantemente “escuchando” todo alrededor, y eso consumiría mucha batería. Igual no es así y funciona de modo activo, y habría que desbloquearlo y decir cualquier cosa para que se abriese.

Nuevo indexamiento de aplicaciones

Android L tendrá un conocimiento muy superior de las aplicaciones que hay instaladas y de como interaccionar con ellas. Así por ejemplo si realizamos una búsqueda y tenemos aplicaciones relacionadas nos aparecerán para lanzarlas. Así mismo se nos ofrecerá lanzar la búsqueda directamente sobre la aplicación que sea. Por ejemplo si buscamos una dirección se nos ofrecerá enviar la petición a Maps o a Earth directamente. Esto puede ser muy interesante sobre todo en aplicaciones que por lo general funcionan comenzando por una “entrada”. Por ejemplo un recetario, frases célebres, traductores…

Rendimiento

Runtime

No solo de diseño se vive, y Google no ha parado en mejorar constantemente el rendimiento de su sistema operativo. El caso más llamativo es le de su runtime. Android no deja de ser Linux en esencia, pero todas sus aplicaciones se ejecutan sobre una máquina virtual llamada Dalvik. Las aplicaciones creadas en JAVA se compilan creando una aplicación y las clases en formato dex, que más tarde es interpretada por la máquina virtual Dalvik, usando un compilador JIT (desde Android 2.2). Esto ha dotado de gran seguridad y rendimiento a las aplicaciones Android, pero después de muchas pruebas y posibles mejoras Google ha decidido finalmente sustituirlo. En Android KitKat introdujo a modo experimental un nuevo rintime llamado ART (Android RunTime)

ART usa compilación AOT (Ahead-Of-Time), es decir, la aplicación en este caso no se interpreta a medida que se ejecuta, sino que en tiempo de instalación se compila específicamente para el dispositivo en cuestión, generando básicamente el código nativo resultante. Esto evidentemente extiende el tiempo de instalación de las aplicaciones, pero una vez instaladas las aplicaciones corren de forma más rápida. Además el colector de basura (Garbage Collector… el colector/reciclador de memoria) es muchísimo más eficiente, y si alguno ha leído alguna comparativa de navegadores realizada por este servidor sabe cual es el efecto de un buen GC… básicamente?? una ejecución más fluida, con menos saltos (pausas), que generalmente son causadas por la necesidad de que los GC hagan su función.

En Kitkat las pruebas realizadas eran dispares… algunos obtenían resultados mejores algunos ligeramente inferiores.. pero es evidente que el runtime de kitkat ART no estaba ni de lejos maduro, pero lo suficiente para que las pocas aplicaciones que causaban incompatibilidades se ajustaran a ellos. EL tiempo a pasado y parece ser que Android L tendrá una versión mucho más optimizada y activada por defecto de ART. Los datos mostrados por Google muestran por lo general un incremento entre el 1.2x y el 2.x en diferentes benchark.

Robando las palabras de un buen amigo, recordemos que Apple en el WWDC de este año anunció que había desarrollado un lenguaje de programación nuevo para su futura versión de iOS que permitiría mayor optimización y en consecuencia un mayor rendimiento. Los ingenieros de Google logran lo mismo (o un mayor rendimiento incluso) sin necesidad de cambiar de lenguaje, tan solo cambiando el runtime. Esto es una gran ventaja para usuarios y desarrolladores, dado que absolutamente TODAS las aplicaciones funcionarán exactamente igual bajo ART… tan solo más rápidas y mejor. Los usuarios verán un rendimiento importante mejorado, y los programadores no tendrán que hacer en el 99% de los casos ni un solo cambio, y mucho menos tener que cambiar de lenguaje de programación como en el caso de iOS…

 ART será totalmente compatible como es de esperar con ARM, x86 o MIPS

Gran rendimiento sobre Dalvik sin hacer absolutamente nada.

Soporte 64bits

Google ha incluido soporte integral para procesadores de 64bits. Hace unos 8 meses o así Apple lanzaba en su iPhone 5s el primer procesador de 64bits en dispositivos portátiles. En aquel momento expliqué bastante bien lo que esto supondría a efectos prácticos. El artículo lo podemos encontrar AQUI. Todo lo que dije en aquella ocasión es aplicable exactamente igual a Android. Resumiendo mucho, es evidente que a la larga todos los procesadores serán de 64bits, pero la transición al igual que se hizo en los PCs no estuvo ni estará marcada por un incremento en el rendimiento, dado que este será en el 95% de las ocasiones totalmente despreciable. El salto se dio por la necesidad fundamental de poder direccionar más de 4GB de memoria RAM. La diferencia es que lo que Apple anunció por todo lo alto, Google sencillamente es realista sobre lo que realmente influye y no, y aunque no deja de ser una novedad no es una GRAN novedad.

El paso a los 64bits es un paso lógico y gradual. Hasta la fecha no hay prácticamente terminales móviles de 64bits no por falta de innovación, sino porque su fundamento principal es poder direccionar por encima de los 4GB de RAM, y ahora mismo en terminales móviles no se ha alcanzado dicha cifra. Actualmente los terminales más modernos andan por los 2GB y algunos incluso con 3GB. Es más que posible que de aquí a un año empecemos a ver dispositivos con 4GB incluso!! con lo que en realidad el paso a 64bits es necesario, pero no son necesarias las prisas.

Es cierto que las aplicaciones corren más rápidas?? Si, lo que sucede es que a veces ese incremento puede ser totalmente inapreciable. Si ganas un 0.01%… no puedes decir que es una funcionalidad estrella cuando sencillamente por cambiar el runtime estás ganando un 150%. Los procesadores de 64 bis poseen registros más grandes y juegos de instrucciones más amplios… estas dos cosas dan un potencial incremento en la velocidad de ejecución. De echo es cierto que en aplicaciones concretas optimizadas en un procesador de 64bits puedan rendir con un rendimiento muy superior a una ejecutada en 32bits, pero como digo son las menos habituales, y menos aun dentro de los terminales móviles.

En cualquier caso el soporte será integral a partir de Android L, y estoy seguro que veremos aparecer este mismo año varios procesadores de 64bits, además del K1 de Nvidia que ya está disponible. No hace falta decir que el soporte en 64bits será transparente prácticamente al programador y al usuario, el SDK incluirá dicho soporte, multiplataforma y sin necesidad de modificar generalmente ni una sola línea de código.

Gráficos

No hace demasiado Google ya fue el primero en incluir OpenGL ES 3.0, pero parece ser que no se han quedado ahí. Esgrimen que el 75% de usuarios juegan de forma frecuente con sus terminales, así que es necesario potenciar al máximo el aspecto gráfico de los terminales de hoy en día. Evidentemente un téléfono o una tablet no tienen el potencial de cálculo que pueda tener un PC con una gráfica dedicada… pero aun así estamos viendo como año tras año aparecen cada vez títulos más realistas con gráficos cada vez más sofisticados.

En esta ocasión Google a aprovechado para actualizar OpenGL ES a 3.1, y a incluido lo que llaman “Extensions Packs”, algo así como funciones avanzadas de gráficos. Es evidente el trabajo duro que ha debido estar realizando Google con los chicos de nVidia, sin duda alguna los número uno mundialmente en cuanto a gráficos se refiere. Entre esas “extensiones” se han destacado por ejemplo la inclusión de Teselación (subdividir una malla poligonal en poligonos más pequeños), sompreadores geométricos y por PC (los Shaders son pequeños programas en si mismos que aplican diferentes efectos, filtros y otros a una geometría) y compresión de texturas ASTC.

Personalmente no soy muy fanático de los vídeo juegos en los móviles o tablets… pero para gustos colores. Siempre he dicho que si quieres disfrutar de un buen juego como dios manda, es necesario una gran pantalla y en consecuencia un buen PC. De cualquier modo siempre es bueno ver que los ingenieros se estrujan el coco, y también dará lugar seguramente a plataformas con procesadores de vídeo más potentes.

Batería

Supuestamente un foco de gran atención por parte de Google ha sido la batería. Como lograr maximizarla sin incurrir evidentemente en una pérdida en prestaciones. Nos dicen que gracias a la creación de herramientas de análisis, diagnóstico y otros han logrado ajustar al máximo el consumo, mirando evidentemente allí donde se puede ahorrar: WIFI, GSM/3G/LTE/, BlueTooth, GPS, CPU y pantalla. Hay que entender que estas optimizaciones siempre tienen un límite si quieres mantener una igual experiencia para el usuario.

Se crea el llamado “Project Volta” (les gusta poner nombre a las cosas) creado para mejorar todo el consumo en general, y con ello una nueva API llamada JobScheduler, que en teoría vendrá a ayudar a los programadores a que sus aplicaciones optimicen el consumo de batería.

Por último se incluye un modo de “Bajo consumo”, para evitar por ejemplo situaciones en las que Play Store le da por descargar una actualización grande o cualquier otra tarea más pesada cuando a lo mejor nuesetro nivel de batería está al 4%, y lo que se supone que deseamos es que aguante al máximo, sobre todo si estamos fuera.

Según sus datos, tomando de referencia un Nexus 5 sobre KitKat y sobre L, se ha podido extender la batería gracias a estos cambios en torno a unos 90 minutos adicionales. Sinceramente de ser verdad es una más que notable diferencia, una hora y media más de uso para el mismo hardware…  habrá que ver luego realmente como se comporta y si los datos son más o menos fiables o exagerados.

Seguridad

Con el fin de que los organismos oficiales puedan dar el visto bueno a los dispositivos Android en vistas de ser usados en entornos empresariales, Google a añadido mejoras sustanciales a sus dispositivos para que estén preparados ante la posibilidad de instalación de aplicaciones altamente sensibles por sus datos. Así implementa principalmente la separación de datos y seguridad entre diferentes “partes” del dispositivo, de modo que queden aisladas del resto del sistema, quedando por tanto totalmente protegidas.

Los desarrolladores pro otro lado no tendrán que preocuparse de nada, no será necesario modifica ninguna, siempre y cuando las aplicaciones sean compatibles desde ICS (android 4.0+). Por lo que se vee Google ha implementado en gran medida el sistema Knox de seguridad de Samsung, a los que dieron directamente las gracias por la contribución. El soporte será incluído como es natural en Android L, aunque dependerá de cada fabricante si da soporte hardware o no para ello.

 

Google Play Services

Ya dije hace tiempo que uno de los grandes cambios que Google hizo sin duda en Android fue la creación de lo que llamó Google Play Services. El principal problema que tienen absolutamente todos los smartphones del mundo son las actualizaciones de software, tanto dele sistema operativo como de las aplicaciones en general. El problema es que cuanto más dispositivos existen y las políticas de cada uno, es más complicado mantener actualizado todo. No es el sistema operativo ya en sí mismo, sino las aplicaciones que este trae con sigo.

Android fue y es aun criticado por muchos por la fragmentación, en la que dispositivos “antiguos” no pueden acceder a funciones avanzadas debido a que ya no disponen de actualizaciones por parte de su fabricante, mientras que Apple sí da un soporte mucho más largo. Esto lo he explicado muchas veces, y a día de hoy es al contrario incluso, el soporte de Android es mucho mejor a largo plazo, precisamente gracias a Google Play Services en un 50%, y el otro 50% gracias a que Google ha independizado prácticamente TODAS las aplicaciones del sistema operativo y las ha publicado en Play Store.

Google Play Services se encuentra instalado en más de un 93% de TODOS los dispositivos Android, y se actualiza regularmente cada 6-7 semanas aproximadamente, que es más o menos el ciclo de actualización que tiene Google para esto. Esta actualización es siempre totalmente transparente al usuario y sin importar que terminal posea, apartir de Android 2.2. Cual es el secreto?? Que Google implementa a través de Google Play Service toda las APIs que son viables de serlo, en vez de en el propio sistema operativo. Esto dota a Android de dos ventajas fundamentales: La primera, es que Google puede añadir funcionalidades constantemente a Android sin necesidad de sacar una versión nueva, y de echo es algo qeu viene haciendo desde hace ya años!! Y segundo que no afecta a la fragmentación dado que incluso los dispositivos más viejos si poseen soporte para Google Play Services pueden usar inmediatamente dichas funciones también. Dicho de otro modo, si Apple quiere implementar cualquier función nueva por pequeña que sea, ya sea a nivel de una aplicación o a nivel del sistema operativo, tiene que sacar una firmware nueva, y esta evidentemente no estará disponible siquiera para todos sus dispositivos, tan solo para los más modernos. Google en cambio solo tiene que distribuir una actualización de Google Play Services con las mejoras pertinentes, o incluso publicar a través de él parches de seguridad… y si es una aplicación lo que quiere mejorar tan solo tiene que lanzar la actualización en Play Store.

Esto no permite a dispositivos con versiones de Android más antiguas poder disfrutar de los últimos adelantos que sí encontramos en versiones más actuales, pero en una gran medida sí que disfrutan de las mismas capacidades. En realidad lo único que no es posible implementar por Google Play Services son aquellas funcionalidades más estructurales y complejas. Lo mismo sucede con las actualizaciones de aplicaciones. Si un usuario de iOS quiere una versión mejor de la aplicación Mapas de Apple, tan solo puede esperar a que lancen una firmware nueva y con suerte que incluya las mejoras de Mapas de Apple. Google solo tiene que mandar la actualización de Maps, de Hangout, de Gmail, de Mail, de la cámara, de la búsqueda de… a Play Store, y todos a disfrutarla. Esto ha permitido a Google estar renovando constantemente sus aplicaciones con mayores prestaciones… y como digo, disponibles para todos.

Como era de esperar por tanto, Google Play Services recibirá una fuerte actualización. Ya se ha empezado a distribuir de echo la versión 5.0, aunque aun no implementa todos los cambios que han sido anunciados en el keynote. Veamos las funciones más destacables que serán incorporadas A TRAVÉS de Google Play Services, y que por lo tanto TODOS podrán disfrutarlas:

-Malware Protection: Escaneo constante de todas las aplicaciones, pero fuera del propio dispositivo. Es decir, es Google en sus servidores quien monitorea las aplicaciones que tenemos instaladas y si alguna es dañina
-Parches de seguridad: Un modo mucho más profundo de poder realizar actualizaciones de seguridad a través de Google Play Services en caso de que se descubran vulnerabilidades importantes en el futuro
-Protección ante un restablecer de fábrica: Una función que permitirá deshabilitar (no se como) la posibilidad de que un ladron restablezca nuestro terminal. Por qué?? Porque si no puede restablecerlo podemos ubicarlo, localizarlo e incluso eliminar sus datos de forma remota. Es muy posible que se implemente también lo que se llama como un “Kill Switch”, es decir, una función que una vez “disparada” deje totalmente inutilizado el dispositivo para siempre, de este modo ante robos poder dejarlo totalmente fuera de servicio
-Control universal de datos: Parece ser un lugar unificado en el que poder controlar nuestros propios datos…
-Indexación y Busqueda de aplicaciones: Ya explicado anteriormente, permite una mayor integración entre las aplicaciones que tenemos y lo que buscamos
-Android Wear: Luego se hablará más de ello, pero un conjunto de APIs para sincronizar y manejar correctamente dispositivos Wear
-Retos Diarios en Games: Un nuevo servicio en Play Games que permite a los desarrolladores publicar “quest” (retos) temporales. Por ejemplo el típico reto diario o misión diaria a completar… un modo de notificar al usuario y de “distribuir” dichos retos.
-Android TV: Interoperatividad con Android TV (más tarde se explicará)
-Android Car: Interoperatividad con Android Car (más tarde se explicará)
-Otros: Añadidos a la API de Drive, añadidos a la API de Chromecast/Cast…

Screenshot_2014-06-26-01-53-54Screenshot_2014-06-26-01-54-02

 

Android Wear

Otra de las grandes novedades de todo el IO ha sido sin duda la irrupción de Android en los dispositivos personales, en los complementos personales que día a día lucimos generalmente como adornos o por su funcionalidad. Básicamente es un eufemismo para referirnos en su gran mayoría a “relojes Android”. En realidad no es necesariamente un reloj, puede hacerse un dispositivo de monitorización de cualquier tipo, zapatos, ropa… pero es cierto que la mayoría de los primeros dispositivos que saldrán al mercado de este tipo serán relojes y similares.

La idea no es sustituir ni mucho menos al teléfono, sino dotar a un complemento que ya de por sí muchos usan con funciones avanzadas. La idea es poder proyectar información allí donde tengamos una “pantalla”, y a fin de cuenta un reloj es una pantalla (literalmente en los digitales). Yo he sido el primero que ha sido muy reacio a este tipo de dispositivos, y tampoco estoy demasiado convencido ahora mismo, pero sí he podido ver algunos ejemplos de uso en el IO que la verdad puedes verle cierto uso y utilidad.

El concepto es sencillo, dispositivos con un conjunto de sensores que son capaces a través de ellos conocer el entorno en el que nos movemos, interaccionar evidentemente a través de BT por lo general con nuestro teléfono, y entre los dos dotarnos de más información no solo de nuestro entorno, sino de lo que queremos hacer. Mirar la hora es el ejemplo más sencillo… un usuario puede mirar la hora en su móvil, pero tiene que sacarlo. Muchos pensaron que los móviles terminarían de desplazar a los relojes pero hemos visto que no es así, y que son muchos los que usan relojes, además de la estética, para mirar la hora… a fni de cuenta es mucho más cómodo girar la muñeca que andar buscando el móvil.

Extrapolemos por tanto este ejemplo a tareas como por ejemplo seguir una ruta GPS mientras caminamos, o por ejemplo seguir una receta de cocina mientras cocinamos con las manos llenas de sangre/comida/agua ya que el reloj es fácilmente resistente al agua y otros. Imaginemos controlar la televisión de forma sencilla apretando la pantalla de nuestro reloj, o incluso realizar compras sencillas a través de él. Por otro lado el uso más evidente es el de mostrar información inmediata en la pequeña pantalla… quizás no es suficiente para realizar tareas complejas, pero para leer notificaciones, seguir indicaciones, ver avisos, alarmas, leer mensajes, controlar el reproductor de música de nuestro dispositivo, descolgar llamadas o rechazarlas… en realidad si hay un buen conjunto de funciones que pueden o podrían derivarse a un dispositvo en la muñeca a modo de reloj, de modo de que no sea necesario tener que echar mano al bolsillo y sacar nuestro terminal.

Tendremos que esperar evidentemente un tiempo y ver el soporte de los desarrolladores para ver como exprimen este tipo de dispositivos.

Quizás la demostración que más me impactó fue haciendo uso de la aplicación Lyft, una aplicación de transporte que pone en contacto usuarios con coches a modo de “taxi”. En la demostración, se acercaba los labios ligeramente al reloj y decia sencillamente: “Call a car”. a Los 2 segundos aparecía una notificación en el propio reloj confirmando el envío del coche y una foto con al conductora. Al llegar el coche a recogerlo una notificación de nuevo le informaba de que el coche estaba esperando. Al final del trayecto una nueva notificación le instaba a valorar al conductor. Todo eso solo con un “call a car” y 2 golpes en el reloj… realmente un sistema inteligente, y que como digo ya está disponible actualmente. Pena que en España no tengamos programadores ni empresas de servicios tan competentes… deberían de tomar partido los de BlaBlaCar o tantas otras que ahora están tan de moda por aquí, sería interesante…

Por supuesto no hay que olvidar dispositivos de este tipo que controlen el ritmo cardíaca, sean pedómetros y otros, y que la información la vayan transfiriendo a la aplicación correspondiente.

Esta inteorperatibidad ya está disponible, tan solo hay que disponer de algún dispositivo Wear y aplicaciones preparadas para ellas como es natural. Dado que Google Play Services se hará cargo de toda la API, todos podran disfrutar de estas funcionalidades prácticamente a partir de ya. Y por si había duda de posibles fabricantes, Google ya ha asegurado que está trabajando con todas las grandes marcas y bien conocidas por todos para lanzar dispositivos tipo wear…

El SDK para los programadores está ya disponible, así como la web específica con información relevante:

http://developer.android.com/wear

Como nota interesante, los dos modelos mostrados en el IO están ya disponibles en Play Store (en España también), aunque el precio es en mi opinión abultado, 200€… principalmente porque el dispositivo no cuesta eso ni de lejos

 

Android auto

Google no solo quiere poner Android en tu muñeca, sino que también quiere dominar el mundo de la automoción. Así lo ha dejado claro con Android auto.

Apoyado por la Open Automotive Alliance, Google lo ha visto claro. Dado que Android es de código abierto y TODOS pueden hacer uso de él, por qué no crear también una interfaz para los ordenadores de abordo de los coches?? A fin de cuenta los coches ya son de por si caros, e incluir este tipo de “interfaz” o sistema no debería de repercutir prácticamente en nada. Además así ganan todos. Por un lado, los fabricantes pueden unificar los diferentes sistemas cerrados y privados que existen para conexiones con GPS, mapas, llamadas, notificaciones… ahora mismo esto es posible gracias a interfaces complejas y propias de cada fabricante, y generalmente causan más incompatibilidades que otra cosa.

Apple ya anunció un sistema similar, y no es mala la idea, pero fracasará donde Google no por una razón muy sencilla. El 80% usa Android, y Android auto es y será compatible con cualquier terminal con Google Play Services, y los servicios que ofrecerá Android auto serán además superiores. Si vemos estos desde un punto de vista del fabricante, evidentemente a medio plazo la elección preferente será sistema Android auto. El fabricante le es rentable porque unifica sus servicios y con un 80% de mercado asegura una interoperatividad enorme con el usuario!! y los cambios a realizar no son de un gran calado. El usuario por otro lado sale ganando porque por fin logra en los ordenadores de abordo en los coches una interfaz unificada y reconocible, así como un buen sin fin de buenas funciones

Para que servirá esto?? Pues bien sencillo. Usando la pantalla del navegador de abordo del coche poder proyectar directamente nuestro Google Maps, control por voz gracias a Google Search/Voice de la mayoría de las funciones del teléfono, el uso evidente de manos libres, envío de mensajes, visualización de notificaciones en la pantalla, sintetización por voz de SMS/mensajes, control y reproducción de nuestra música, ubicaciones recientes, marcación de ubicaciiones, información del tráfico en tiempo real… y todo ello con la ventaja de que las aplicaciones en realidad no estarán en el propio ordenador del coche, sino se hará uso de nuestro terminal, con lo que cualqueir actualizacion de las aplicaciones se realizarán siempre sobre nuestro dispositivo. Las opciones son casi ilimitadas, y bien implementado puede ser un gran triunfo para todos!! Se acabaron los GPS deseactualizados, las eternas incompatibilidades de manos libres… y sin demasiado trabajo de fondo.

Como en el resto de las novedades, el SDK para los programadores para adaptar sus aplicaciones ya está disponible, y Google también a anunciado que prácticamente la totalidad de todos los fabricantes de automóviles están trabajando en ello. Eso no quiere decir evidentemente que todos los coches tendrán este tipo de funciones en el futuro… evidentemenete, pero sí que de aquí a un año es más que posible que un buen porcentaje sí. Ya veremos, tiempo al tiempo.

 

Android TV

Google no ha querido dejar un solo rincón del mundo sin ponerle la mano encima. Después del existo cosechado con ChromeCast, ha irrumpido de nuevo en las televisiones con Google TV. Al igual que en la industria automovilística, en las televisiones tenemos un gran problema similar. Prácticamente todas las televisiones que tenemos a día de hoy son SmartTV (las nuevas al menos), pero eso es un engaño en la realidad, dado que cada fabricante y muchas veces entre el mismo fabricante, la plataforma usada es diferente. Cada plataforma tiene sus aplicaciones diferentes, y los desarrolladores tienen que estar sacando aplicaciones para cada sistema si quieren que sus aplicaciones estén. Es decir… un auténtico infierno.

Que pasaría si de un día a otro se reunieran a todos los responsables y se les dijese: Mira… vosotros quereis que el usuario os compre, y todos estamos hartos de que las SmartTVs de hoy en dia sean una basura industral porque no hay ningún tipo de estándard. Que pasa si las dotamos de AndroidTV?? todas podran usar las mismas aplicaciones, todas podran manejarse a través de teléfonos de forma sencilla, adquirir funcionalidades de receptores de Cast (al estilo ChromeCast)… y por supuesto siempre se pueden incluir servicios Premiums de esos que os encantan, como servicios de videoclub a la carta, aparte de por supuesto Google Play Movies.

La idea es buena realmente. Es dotar a la televisión de unas prestaciones similares a las que podemso tener en un teléfono o en un tablet actual. LLevarlo todo ello a la gran pantalla básicamente. Desde búsquedas y acciones por voz, instalación de aplicaciones, juegos, reproductor multimedia, información de actores, sinopsis… lo que se quiera en realidad…

El futuro de esto en realidad es más incierto… aunque la mayoría de fabricantes les ha gustado la idea habrá que ver y esperar tiempo. Lo que está claro es que si el usuario al final lo demanda, se sumarán al carro, y es posible que lo hagan, si tenemos en cuenta lo que ha sido ChromeCast (el éxito que ha tenido)

El SDK también está ya disponible

 

Google Cast and ChromeCast

Un exito rotundo se le pregunte a quien se le pregunte, y las ventas hablan por si mismas. En Estados Unidos ha sido el dispositivo electrónico más vendido!! Sencillo, pequeño y extremadamente barato, es multiplataforma y ya tiene un aluvión de aplicaciones compatibles impresionantes.

Ante tal éxito no es de extrañar el nacimiento de Android TV, así como un especial miramiento por parte de Google con él, digamos algo así como un… “cariño” especial por ese pequeño dispositivo. Así pues no podían dejarlo sin algunas cuantas novedades… y de gran interés.

-Por un lado una sección específica dentro de Play Store donde encontrar aplicaciones que permiten hacer “cast” a nuestro dispositivo, para tenerlas todas más… a la vista.

-En segundo lugar la posibilidad de poder realizar Cast SIN NECESIDAD de conocer la red WIFI de nuestro hogar, pensado sobre todo para visitas que vienen a casa. De este modo si quieren compartir algo con nosotros en la televisión no tengan que acceder a nuestra red antes. Esto será posible gracias a una autentificación por PIN. La ventaja es que el dueño en todo momento podrá revocar el acceso si así lo desea a dichos usuarios “invitados”, teniendo siempre control total sobre él.

-En tercer lugar, se añadirá a la aplicación ChromeCast la posibilidad de poder enviar a la pantalla de Espera de Chromecast fondos personalizados. No solo con fotos, sino con cierto contenido activo como el tiempo y algunas cosillas más… no esta mal tampoco

-Y en cuarto lugar y quizás más importante y esperado, por fin la posibilidad de hacer de forma nativa Mirroring, es decir, proyectar en la pantalla directamente nuestra pantalla. En principio esta función podría no estar disponible para todos los móviles, aunque si han dicho que de momento será compatible con la mayoría de terminales de última generación. El ejemplo mostrado era la apertura y manejo de Google Earth… y he de decir que el retraso era mínimo, y la calidad excepcional. Como usuario de ChromeCast, deseando probarlo por fin, sin necesidad de aplicaciones de terceros (Lo siento Koush, aunque hiciste un excelente trabajo con Mirror)

Como lo demás, la actualización se realizará por medio de Google Play Services, y posiblemente ChromeCast reciba igualmente otra actualización de software. Esto debería de estar disponible para dentro de unas semanas para todos.

 

Google Fit Platform

Otro nuevo conjunto de APIs para mejorar considerablemente la interoperatividad entre dispositivos Android con dispositivos orientados al fitness,  como por ejemplo de nuevo pedómetros, pulsómetros… un modo sencillo de recoger todos los sensores e información de cualquier dispositivo “fitness” y poder enviar de forma sencilla dichos datos al terminal, donde gestionarlos de igual modo.

Soportará diferentes dispositivos, sensores, lectura simultánea de diferentes dispositivos… y también se anunciaron un buen número de fabricantes que ya estarían trabajando con ello.

Dicho de otro modo… máquinas de gimnasios y de todo tipo que suministran datos a nuestros dispositivos, entre otras muchas cosas.

Google Play Games

 Recibirá un par de buenas actualizaciones.

-La primera será la creación de perfiles personales donde “centralizar” nuestros juegos, logros, puntuaciones… esto no es nada nuevo para usuarios acostumbrados a plataformas de consolas

-La segunda, como ya se ha dicho, será la inclusión de “retos” que podrán “distribuir” los diferentes juegos a lo largo del tiempo.

 

ChromeBook

No soy fan de ChromeBook, veo que son dispositivos muy caros con prestaciones muy limitadas… pero no hay que negar que no tengan un buen diseño y la idea no sea buena. Lo cierto es que no se han vendido mal del todo, sobre todo en entornos concretos donde realmente lo que se necesita es un “PC” rápido, integrado con todo Google y tan solo funciones “básicas” de ofimática e Internet.

Pese a todo se han implementado alguns funciones realmente interesantes, entre ella la interoperatividad entre ChromeBook y nuestros dispositivos móviles. Así por ejemplo si nuestro terminal está cerca, automáticamente las notificaciones de este pasarán a nuestra pantalla de ChromeBook, así como indicadores de batería, señal… de este modo ambos dispositivos podrán “compartir” información, sincornizarla entre uno y otro por así decirlo

Se unificarán igualmente aplicaciones tipo PlayStore, de modo que si el usuario tiene ambas aplicaciones en cad adispositivo la apariencia será similar, aunque una será una aplicación Android y la otra será aplicación Chrome, pero de nuevo cumpliendo la máxima de este año: Unificación.

Google Play

Se crea un nuevo servicio de Google para desarrolladores de aplicaciones llamado “Appurify”, que viene a ser algo así como un testeador de aplicaciones que permitirá simular entornos reales de dispositivos sin necesidad siquiera de instalar la aplicación. Por ejemplo similar escenarios de pérdida de conexion de datos, de conexiones de wifi, de recibir una llamada… etc etc. No se ha explicado demasiado como será, así que tampoco puedo dar mucha más información. Seguro que a lo largo de los días todo va quedando mucho más claro

Otros

Además de todo ya explicado, las novedades no quedan ahí. Pero tampoco pueden detallarse todas. Aquí un pequeño resumen del resto:

-Actualización de Google Drive con nueva interfaz
-Añadido Google Slides para completar Docs y Sheets a Google Drive, permitiendo editar completamente también documentos de Word
-Mejora considerable y explicación de los servicos de Google Cloud Platform y muchas mejoras al respecto… básicamente quieren enterrar a Amazong en el negocio del Cloud Computing.

 

Seguro que me he dejado un buen número de cosas, pero creo que por hoy es ya más que suficiente.

Saludos compañeros.

 

Google IO 2014

Share on Google+Share on FacebookTweet about this on Twitter

 

Buenas amigos, un año más de IO. Esta tarde a las 18.00 peninsular comenzará el esperado Keynote que inaugurará el Google IO de este año.  En esta ocasión, Google dará cobertura en directo a prácticamente todas las sesiones que discurrirán estos dos días de frenesí tecnológico… y por supuesto frenesí de los propios programadores y desarrolladores… que recordemos que precisamente el Google IO es para ellos, y no para el usuario de a pie… aunque indirectamente recae en él a fin de cuentas.

Para mí, la gran ausencia que habrá este año sin lugar a dudas será la de el genial y carismático Vic Gundotra, el que fuera un alto cargo de Google al que personalmente le atribuyo ser el alma de Google+, gran parte de Maps y un comunicador innato. El año pasado fue Hugo Barra… este año Vic anunció su partida sin especificar realmente motivos concretos o atribuibles. Sea como sea, estoy seguro que más de uno lo echará de menos.

Desde hace ya semanas se tiene más o menos la agenda de las conferencias que se irán dando, así que podemos hacernos una idea más o menos de lo que nos espera el Keynote. A eso podemos sumarle la entrevista que se le hizo a Sundar Pichai, actual dirigente tanto del proyecto Android como de Chrome. Lo que podemos sacar más o menos en claro:

-Android 5.0 (Andorid L): Probablemente será lanzado en octubre/noviembre junto a un parece ser Nexus 9. En teoría en el Keynote veríamos una preview al menos de esto. Entre otras características estarían una interfaz totalmente renovada, integración mucho más profunda de Google Search/Now, soporte para 64 bits, API para cámaras nueva para permitir imágenes RAW y otros… un gran cambio en general
-Nuevo Play Services: Inclusión de una nueva API Para dispositivos orientados a la monitorización de las personas, como signos vitales, pasos, ritmo…
-Complementos personales Android: Relojes, pulseras, zapatos…
-Domótica: Desde la adquisición de Nest, Google ha ido metiéndose cada vez más en las casas de los usuarios para el control de ella…. veremos que se cuece realmente…
-Google Glass: Se cree que será anunciada su disposición inmediata en otros mercados además del Americano, sin contar con un hardware algo más avanzado
-YouTube Music: No está claro si Google lanzará su nuevo servicio de YT en el IO, pero desde luego se sabe que es algo que tienen muy muy avanzado…
-Dispositivo Nexus: A mitad de año es evidente que no veremos ningún Nexus 5 (2014), pero no estaba muy claro si vería la luz un Nexus 10. Finalmente parece ser que llegará un Nexus 9, pero tampoco es algo que podamos asegurar.
-Android Silver: Es posible que Google desvele si finalmente piensa o no crear o poner en marcha lo que se llamaría Android o Nexus Silver, un programa para fabricantes que puedan vender sus terminales prácticamente sin persnalizaciones y posiblemente a través de Play Store
-Android TV: El año pasado Google sorprendió con un inesperado ChromeCast, nadie había oído nada de ello y resultó ser un éxito a nivel mundial. Su bajo precio, sus posibilidades y el soporte de las aplicaciones hizo que realmente sea uno de esos gadgets que tener por casa. Pero ChromeCast tienes sus limitaciones, en parte no es más que un receptor. De confirmarse, Google estaría apunto de lanzar un setbox para las televisiones a modo de Android TV, un dispositivo posiblemente ejecutando una versión de Android en el que poder instalar aplicaciones y tener una interacción mucho mas directa con la televisión. No sustituye a ChromeCast ni mucho meno, son dos planteamientos totalmente diferentes.

Por supuesto son solo algunas de las cosas que muy posiblemente veamos en mayor o menor medida mañana. A todas ellas habría que sumarle actualizaciones aseguradas de la mayoría de los servicios de Google, cambios en las API, en las propias aplicaciones… intentaremos resumir las novedades del Keynote a medida que vayan apareciendo

Un saludo a todos amigos

Nexus 5 Vs iPhone 5s Vs iPhone 5c

Share on Google+Share on FacebookTweet about this on Twitter

Hace ya un tiempo que no aparezco por estos lugares, pero eso no significa ni que esté de brazos cruzados ni que haya dejado mi pequeña Alma Oscura a un lado. Muchos proyectos en la cabeza siempre, a veces más tiempo a veces con menos. Sea como sea, era evidente que tendría alguna palabra que decir tanto a los nuevos iPhone 5s/5c como el actual Nexus 5 (Sí, muchos 5 tenemos en esta ocasión). Que mejor forma de hacerlo y explayarnos bien en todo ello que una primera comparación a nivel de Hardware. Siempre he dicho que comparar hardware es más sencillo que comparar Sosftware porque son cosas que son cuantificables generalmente mucho más fácil. Eso no quita que podamos hablar igualmente largo y tendido tanto de iOS 7 como Android 4.4 (KitKat)… si no hoy, seguro que otro día podremos meternos en ello. La fuente de la que salen todos los datos técnicos son las respectivas páginas oficiales, Stores oficiales y demás, cualquiera podría verificarlas de forma simple (y siempre animo a hacerlo, a fin de cuenta cualquiera puede inventarse lo que le de la gana y escribirlo, sin que eso signifique que sea real o no)

Como la gran mayoría sabrá a estas alturas, tanto iPhone 5s/5c como Nexus 5 son a día de hoy una realidad, y todos han tenido bastante atención mediática. Para empezar por tanto, que mejor forma que dejar una imagen sencilla de especificaciones técnicas. Dicen que una imagen vale más que 1000 palabras, pero ya sabe la mayoría que para mi una imagen o unos datos que no se explican, valen para poco…. corrección! Si vale!! para que quien ponga la imagen pueda tergiversar o interpretar como le de la gana dichos datos. Y lo cierto es que la sociedad actual está totalmente condicionada por el marketing barato, es decir, te venden las cosas como les da la gana a ellos vendértelas, y nosotros que somos tan listos corremos como locos porque miramos solo lo que nos están diciendo (cuando a veces incluso es falso). Bueno, sea como sea, y como siempre amen de que haya cometido algún error en las hojas de características, esto es lo que tenemos cuando plasmamos en papel las especificaciones del iPhone 5s, iPhone 5c y Nexus 5 (con sus respectivos precios, por supuesto). Y sí, prometo que las próximas comparaciones, la imagen será mejor… justo debajo, comenzaremos a desgranar cada apartado, uno a uno, y dar realmente una lectura, explicación y matización a cada aspecto.

Como ya es habitual en mí, advierto que la lectura completa será larga, ya que aprovecharé no solo para comparar dispositivos, sino para arremeter contra compañías, operadores y otros, explicando un poco cada cosa a su paso. Creo que es interesante por una sencilla razón. Cualquiera puede decir A mejor que B en C, pero como no expliques realmente que es C y lo bueno y lo malo de C, no sirve de nada decir que A es mejor que B, porque si se sabe todos los pormenores y mayores de C, puede ser que entonces B sea mejor que A. Quien no tenga ganas de leer que se quede con la tablita, quien quiera leer… ya sabe lo que toca.

 

Comparativa Nexus 5, iPhone 5s*Nota: El Nexus 5 soporta en WIFI además el estándar 802.11 ac, los dos iPhone no

 

Precio

 Quien diga que el precio no importa… miente, la misma mentira de aquellos que aseguran que el tamaño tampoco importa (Y no, no estoy hablando de la virilidad de los hombres). El precio claro que importa, y para el 90% al menos de la sociedad actual uno de los factores más decisivos a la hora de comprar/renovar un nuevo terminal. Por otro lado, existe un porcentaje también muy alto de personas (alto al menos para mí) que piensa y tiene grabado a sangre en la cabeza que caro es sinónimo de bueno o de mejor, personas que piensan que si algo es más caro es indudablemente porque es de mejor calidad, o es más rápido, o… y es cierto que el precio evidentemente depende de dichos factores, pero a día de hoy a esa lista de factores habría que añadir otro factor que posee un impacto dramático en el precio de las cosas. Se llama Margen de beneficios… o si quiere llamarse de otro modo, el “Impuesto revolucionario” añadido al producto sencillamente porque sí, muchas veces precisamente porque el cliente cree que a mas caro, mejor.

Dicho esto, en esta ocasión tenemos precios muy dispares, y como suele ser natural en los productos de la manzana, llama la atención el sobreprecio… el sea razonable o no lo veremos a lo largo de estas letras. Pero vayamos a los datos.

Por un lado, el nuevo Nexus 5 mantiene exactamente el mismo precio que su predecesor, solo que elimina la versión de 8GB dejando tan solo 2 versiones, una de 16GB y otra de 32GB, siendo el precio 350€ y 400€ respectivamente. Apple por su lado ha dividido como sabemos su iPhone nuevo en dos, por un lado el modelo iPhone 5s y por otro el iPhone 5c, con la idea de servir un iPhone de bajo coste que sea asequible para las personas normales. En caso del iPhone 5s, se sirve en 3 modelos diferentes de 16, 32 y 64GB, con un precio de 650€, 750€ y 850€ respectivamente. Su iPhone 5c “económico” tan solo cuenta con dos versiones de 16 y 32GB, siendo su precio de 550€ y 600€.

Evidentemente los precios expuestos corresponden a terminales libres de contrato, el precio que nos costaría comprarlos para llevárnoslo  a casa con el SIM que queramos de la compañía que queramos.

La diferencia de precios es más que exagerada, y llama la atención 3 cuestiones realmente importantes.

Por un lado, el precio base, no hablamos de que el Nexus 5 sea algo más barato que la competencia, hablamos que el Nexus 5 cuesta casi la mitad de lo que cuesta un iPhone 5s, cuesta un 46% menos!!. Con respecto al iPhone 5c la diferencia es menor, pero aun así el Nexus 5 sería un 36% más barato que el iPhone de bajo coste de Apple. Dicho de otro modo, por el precio que una persona adquiere un iPhone 5s, otra podría adquirir prácticamente 2 Nexus 5. Por supuesto no todo es el dinero en este mundo, pero es evidente que para el usuario medio al menos, tendría que existir una diferencia enorme entre el iPhone 5s/5c para que le mereciese la pena, antes que decantarse por un Nexus 5, o muy malo tendría que ser el Nexus 5 para que no mereciese la pena. Quizás esto es interesante decirlo, porque como he dicho anteriormente habrá muchos que crean que un terminal que cuesta casi la mitad de lo que cuesta otro, debe de ser porque es muy inferior. Como veremos, no solo no es el Nexus 5 inferior, sino que es superior al iPhone 5s prácticamente en todo. Pero dejaremos que eso lo judge al final el lector.

En segundo lugar llama la atención el precio del iPhone 5c. Hace ya mucho tiempo se le pedía a Apple que compitiese en un mercado aun más grande en dispositivos móviles, como es el público medio que no es rico, dado que la mayoría optaban por terminales de gama baja Android. La respuesta llegó este año en forma de iPhone 5c. El problema fue cuando se desveló que su precio base sería de 550€. Mucho o poco no vamos a judgarlo, pero con lo que el lector estará de acuerdo es que 550€ está muy alejado de lo que podríamos considerar un terminal económico, teniendo en cuenta como digo que el Nexus 5 son 350€. Personalmente no se cuantos iPhone 5c se habrán vendido, pero cuando ni siquiera Apple ha dado cifras concretas con lo que le gusta darlas, podemos imaginar que la palabra “fracaso” se queda corta.

En tercer lugar llama la atención el precio por GB. En el Nexus 5 vemos que la diferencia de precio entre los diferentes modelos es de 50€, mientras que los modelos de Apple poseen una diferencia de 100€. Dicho de otro modo, Apple te cobra literalmente al doble el almacenamiento interno. Esto nos hace ver perfectamente lo que decía sobre el sobreprecio de los componentes, ese margen de beneficios. No nos engañemos, evidentemente ese doble almacenamiento que ofrece Apple no es diferente en NADA al que ofrece LG en su Nexus 5, es de la misma calidad, es del mismo tamaño el incremento y casi con toda seguridad una velocidad de acceso similar. ¿Por qué Apple cobra entonces el doble por lo mismo? Porque sabe que a sus seguidores le dará igual, así que si cobra 100€ en vez de 50€ su margen de beneficio continúa disparándose aun más. Son matemáticas sencillas.

Resumiendo, en cuanto a precio se refiere, el Nexus 5 ganaría por goleada, un dispositivo de última generación, actual, moderno y buque insignia de Android que cuesta la mitad que el buque insignia de Apple el iPhone 5s. Sobre el iPhone 5c mi opinión es aun peor, dado que es un terminal con tecnología vieja (recordemos que básicamente es un iPhone 5) con un precio de terminal de lujo, y a eso lo llama Apple su iPhone “barato”. Como ya he dicho, y mirando tan solo el precio, muy mal tendría que salir el resto de comparaciones para descargar el Nexus 5 como una buena compra.

 

Procesador y Sistema

 Otro punto clave… bueno, en realidad todos lo son, y si hablamos de el cerebro y los nervios que hacen funcionar a nuestros dispositivos, tenemos queramos o no que volver la cara hacia el conjunto de chips que lo gobiernan. No solo la CPU de este, también es interesante e importante mirar la memoria del sistema, la GPU (el adaptador de vídeo), la arquitectura en la que funcionan…

De nuevo aquí el marketing ha hecho mucho daño a la tecnología. Son muchos los que creen que un procesador por tener mas Megaherzios de velocidad es más rápido que otro procesador, o que tener 4 núcleos a 2GHz es por obligación el doble de rápido que otro que posee 2 a 2GHz. Esta creencia no viene porque el usuario medio se lie con el vocabulario técnico, sino porque las empresas en sus grandes campañas les encantan usar palabras o datos que el usuario medio no es capaz de comprender del todo, para así pasar algo por otra cosa. Con esto no quiero decir que el número de núcleos o la velocidad de reloj no sea importante, claro que es muy importante!! Pero lo que es evidente es que quien piense que por tener más núcleos o más frecuencia de reloj es mejor o más rapido… tiene que empezar a cambiar el chip de su cabeza y empezar a intentar ver las cosas desde otras perspectivas. Podemos afirmar que un procesador por ejemplo de 2 núcleos de 2GHz es “en bruto” el doble de rápido que otro que sea EXACTAMENTE IGUAL de solo 1Ghz. Cuando se comparan arquitecturas diferentes, procesadores diferentes… es totalmente absurdo comparar frecuencias o núcleos, porque ese dato no tendrá valor. Un ejemplo muy muy senecillo de esto… actualmente tenemos procesadores de 4 núcleos en muchos dispositivos móviles, en el caso del Nexus 5 por ejemplo tenemos 4 núcleos a 2.3GHz (nada despreciable), y sin embargo un solo núcleo de un procesador de intel usando arquitectura x86 (por ejemplo un sencillo Core i3 4330T de 2.4GHz ) no solo superaría al de cuatro núcleos del Nexus 5, sino que lo dejaría totalmente en ridículo. La explicación? Dos arquitecturas totalmente diferentes, dos plataformas diferentes, y evidentemente un consumo energético muy diferente.

Dicho esto, volvamos una vez más a los datos que tenemos.

El Nexus 5, esta vez se ha equipado con un procesador fabricado por Qualcomm, en concreto toda una bestia dentro del campo ARM, SnapDragon 800, un procesador de arquitectura ARMv7 Cortex A-15 (de 32bits). Posee un procesador de cuatro núcleos a 2.3Ghz cada uno de ellos. El problema para el público menos aficionado es saber si eso es mucho o poco… bueno, digamos que a día de hoy en el mercado de los terminales portátiles, SnapDragon 800 estaría prácticamente en la cima de la cadena alimenticia. ¿No ha quedado aun claro? Lo explico de otro modo, actualmente no hay un terminal móvil en el mercado con un procesador superior (al menos que yo conozca, aunque si los tenemos similares). Ademas, y no menos importante, es que monta 2GB de RAM, suficiente para cualquier aplicación por exigente que sea.

El iPhone 5s viene de nuevo de la mano de un procesador AX, en este caso el A7. Pese lo que creen muchos, Apple no fabrica hardware. Tal es así que aunque le suene raro a más de uno, estos procesadores en concreto los fabrica Samsung. Sí, su enemiga dentro de los terminales móviles, con la que legalmente se pelea día sí y día no por patentes… Sencillamente Samsung es uno de los mayores fabricante a nivel mundial de componentes electrónicos, tanto de procesadores ARM como de pantallas, memorias… Apple repito no es un fabricante de Hardware, no se dedica a eso. A muchos esto les choca, incluso Apple ha amenazado en alguna ocasión (y lo ha intentado) desvincularse de Samsung a la hora de la gran dependencia que tienen de ellos como fabricantes de hardware… pero nunca ha podido y ha vuelto siempre a ellos. Como ya he dicho esto no es algo azaroso, es que Samsung es un fabricante importantísimo de chips :).

En este caso el procesador A7 del iphone 5s (ojo, el iphone 5c posee OTRO proceador) salta de generación ARM a ARMv8a, que se caracteriza principalmente por usar ya una arquitectura de 64 bits (frente la arquitectura de 32bits de ARMv7). Al margen de la arquitectura de 64 bits que ahora hablaremos, viene servido con un procesador de doble núcleo de 1.3Ghz.

 

Permitirme que habrá en este punto un paréntesis para hablar un poco de arquitecturas de 32bits/64bits, hablar de la necesidad o no de una u otra. Quien conozca bien esto puede sencillamente evitar esta pequeña lectura.

Llamamos arquitectura de 8/16/32/64/128 bits (nos centramos solo en 32 y 64) de un procesador/arquitectura cuando estos poseen buses de dicho tamaño, cuando la memoria posee dicho número de líneas, cuando el procesador es capaz de operar con números enteros de dicho tamaño de forma natural. Esto es algo más complicado explicarlo de forma sencilla para todos, así que intentaré hacerlo de la forma más sencilla posible, aunque pierda exactitud a la hora de explicarlo.

Imaginad que el procesador posee una línea de datos (un cable) por cada bit que maneja, así un procesadro de 32bits tendría 32 líneas, uno de 64 tendría 64 líneas, que podríamos asemejar a carreteras por las que viajan coches. A nadie se le escaparía ver que por 64 líneas podrían circular muchos más coches, y además llegar a más sitios, tendrían 64 destinos posibles en vez de 32. Bien, aquí pasa algo similar. Lo más importante con diferencia a destacar son 3 aspectos:

 

-Precisión:

Cuando usamos números enteros de 32bits, podemos manejar como máximo de forma inmediata datos de 2 elevado a 32 (2^32) = 4.294.967.296, que efectivamente es un número bastante bastante grande. Si tenemos en cuenta los números negativos, podríamos manejar números de (-2147483647, +2147483647), es decir, más o menos la mitad. Eso no significa que un sistema de 32 bits no pueda manejar datos superiores, lo que significa que cualquier dato superior al citado no puede manejarse de forma simple o directa, porque el procesador jamás podría entender ni interpretar ni operar con un número con una profundidad mayor.

La primera virtud por tanto de un sistema de 64bits es la posibilidad de operar y manejar datos con una precisión y profundidad muy superior. 2^64 = 18.446.744.073.709.551.616. Como vemos el número es demasiado grande siquiera para poder imaginarlo. En realidad la principal ventaja que posee esto, es que si queremos operar en datos mayores a 32 bits, podemos hacerlo de forma igualmente sencilla, el procesador tan solo tiene que usar un registro de 64 bits para colocar el dato y operar con el/ellos, de forma directa, cosa que en 32 bits no sería posible, y por tanto el procesador de 32 bits tardaría más tiempo en computar un número superior a 32 bits.

 

-Acceso a Memoria

Esta ha sido siempre la razón principal por la que el PC dio el salto a la arquitectura de 64 bits hace ya algunos años. En crudo, hablar de 2^32 parece un número inmenso!! pero para un PC a día de hoy es “nada”. 32bits hacen que el procesador pueda acceder a 32 líneas de memoria, eso equivale a 2^32 posiciones de memoria diferentes, y si cada posición de memoria guarda 1 Byte de dato, tenemos exactamente: 2^32 = 4294967296 posiciones de memorias, si cada una posee un Byte 4294967296 Bytes que puede apuntar el procesador. De nuevo, ¿mucho o poco? Convirtamos los datos: 4294967296 Bytes -> 4194304 KBytes (1KB = 1024 Bytes) -> 4096 MBytes (1MB = 1024 KB) -> 4 GBytes (1GB = 1024 MB). Es decir, que un procesador de 32bits puede como máximo apuntar, usar, direccionar 4GB de RAM. Como todos sabemos a día de hoy, cualquier PC que se precie posee mínimo 4GB de RAM, y muchos tendran en sus casas sistemas con 6GB y 8GB. Si eso lo expandimos a los servidores que poseen ingentes cantidades (16, 32, 64…) es evidente que hace ya mucho tiempo que en los PCs el uso de la arquitectura de 32 bits era algo determinante por la sencilla razón de esta limitación. Un procesador de 32 bits no puede acceder ni usar nunca memoria por encima de los 4GB, las líneas que posee como máximo llegan a eso. Cualquiera podría aplicar los mismos cálculos para ver que cantidad podría manejar un sistema de 64 bits, que serían 16 Exabyte, y esa cifra como digo es algo que creedme es demasiado como siquiera imaginarlo: 1024GB = 1TB/ 1024TB = 1PB / 1024PB = 1EB.

 

-Mayor número de registros

Los procesadores (sin entrar ahora en diferencias CISC o RISC) usan registros para poder hacer sus cálculos. Veamos un registro sencillamente como un casillero en el que podemos colocar un número para operar con él dentro de la CPU, algo así como una mini memoria. Cuantos más registros posea la CPU mayor cantidad de datos puede retener en sí mismo la CPU sin tener que acceder a un dato que esté en memoria, porque la CPU solo puede operar con lo que tiene él, con lo que opera de forma mucho más rápida. Un ejemplo sencillo, imaginar una CPU que quiere sumar 3 números y posee 4 registros. Como lo haría?? Pues la forma más rápida sería colocar de golpe los 3 numeros en 3 de los 4 registros, por ejemplo con un solo acceso a memoria. Una vez realizado, la unidad de cálculo (ALU) sumaría registro1+registro2+registro3 = resultadoenregistro4. Si en cambio solo tuviese 2 registros, tendría primero que colocar dos numeros en ellos, sumarlos, descartar uno de los registros y cargar un nuevo dato en ellos, sumarlo a la suma parcial, descartar otra vez el registro y cargar el último dato y volver a sumarlo. Como vemos, tardaría bastante más, con independencia de que el procesador sumase más o menos rápido! requeriría más accesos a memoria, mayor movimientos de datos.

Cada vez que una arquitectura ha ido evolucionando, generalmente ha ido aumentando su número de registros. Podríamos hablar mucho mas de esto pero aquí las diferencias entre arquitecturas CISC y RISC son demasiado grandes como para entrar en ello. Así que resumiendo diremos que los procesadores de 64 bits poseen evidentemente registros de 64bits, además de por supuesto los normales de 32bits que pudiese tener. Eso dota al procesador con un mayor número de registros y por tanto en teoría una mayor capacidad de operación, aunque como diga la velocidad de cálculo sea en principio la misma.

 

Cerremos el paréntesis y volvamos a lo que nos interesaba. Decíamos que el nuevo procesador de Apple A7 posee una arquitectura de 64 bits, frente a la arquitectura de 32bits de la competencia. ¿Que implica esto? Si hemos leído lo anterior, es aplicable exactamente igual a este procesador, y vemos que aunque evidentemente otorga unas prestaciones a priori superiores, para el usuario (sea un usuario más exigente o menos) importará poco o nada, no notaría diferencia.

De cara a la mayor profundidad de bits/precisión o al mayor número de registros, es cierto que procesadores de 64 bits como hemos dichos pueden manejar datos más grandes y es cierto que potencialmente esto puede aumentar el rendimiento de una aplicación, sobre todo gracias al aumento de registros disponibles. Es cierto, “POTENCIALMENTE”. La gran mayoría de aplicaciones de todo tipo no requieren demasiados cálculos complejos en 64bits, no requieren de una precisión tan elevada ni hace uso de estas instrucciones, y eso por no decir que además para que las aplicaciones hiciesen uso de todo ello tendrían que diseñarse, prepararse, compilarse específicamente para ello. Eso no quiere decir ni mucho menos que sea en balde OJO!! pero aun cuando TODAS las aplicaciones existentes de App Store de Apple o del Play Store de Android se optimizasen compilasen y se programasen específicamente para hacer el máximo uso de esta característica, tan solo un reducido 5% quizás de esas aplicaciones podrían ver un incremento a lo mejor de un 10% max en su rendimiento. No quiero decir con esto que sea inutil y cualquier mejora es positiva, solo quiero poner los puntos sobre las ies. Como comparación, creo que todos o la infinita mayoría de todos mis lectores poseen en sus casas equipos de 64 bits, y aun cuando han pasado al menos 8-10 años desde que los procesadores de 64 bits aparecieron en los PCs, la mayoría de las aplicaciones que usamos NO SON COMPILADAS PARA 64 BITS. Navegadores Webs, reproductores de música, gestores de correo… en su 90% son aplicaciones de 32 bits todas, y como digo ya han pasado cuanto.. 8-10 años?? Cuando se invierte tiempo en compilar y optimizar una aplicación para 64bits es porque realmente interesa de algún modo, o por rendimiento o por que requiere un acceso a una mayor cantidad de RAM 🙂

De cara a la cantidad de RAM, al igual que le pasó al PC dentro de unos años le llegará el turno a los móviles. Los PCs, repito una vez más, no cambiaron a arquitectura de 64 bits por el rendimiento aumentado ni mucho menos, sino por su limitación a poder manejar cantidades superiores de 4GB. Si la tecnología continúa el ritmo actual, esta limitación pronto llegará también a los dispositivos portátiles, es cuestión de unos… ¿de 2 años? Actualmente el Nexus 5 se sirve con 2GB de RAM, de aquí a un par de años tendremos posiblemente dispositivos de 4GB y los procesadores de 32bits ARM entrarían en el límite impuesto de dicha tecnología, con lo que el salto a 64 bits sería obligado. Pero de nuevo, este salto no se produce por rendimiento ni mucho menos, sino por saltar esta limitación. Dado que el iPhone está muy lejos de llegar a los 4GB de RAM, esta características de los procesadored de 64 bits (Que es la más importante) carece igualmente de sentido, al igual que carecería de sentido en el Nexus 5 que posee 2GB de RAM.

El procesador A7 de Apple por tanto, aun cuando efectivamente usa una arquitectura de 64 bits, está muy muy por debajo del procesador SnapDragon 800. Cual es entonces el motivo de Apple de usar esta nueva arquitectura? Bueno eso es fácil adivinarlo, dos motivos básicos. El primero una cuestión pura de marketing, pongo en todos sitios que es el primer procesador de 64bits y eso parece que vende. En cambio si hubiese sido por ejemplo Samsung o LG quien se hubiese adelantado Apple diría algo como: No sirve para nada, aun queda mucho tiempo para llegar al límite de lso 4GB de RAM, como hizo y hace con NFC por ejemplo, o HDMI o tantas otras tecnologías que no implementan. El segundo motivo es que Apple podría empezar a plantearse abrir una nueva línea de portátiles o ultraportátiles que estén gobernados por una arquitectura ARM en vez de una arquitectura x64, y un PC a fin de cuenta si requiere mucha más RAM. De este modo y poco a poco Apple intentaría acercar más sus sistemas operativos. No es mala idea desde luego, pero no olvidemos que la arquitectura ARM aunque posee la ventaja de ser una arquitectura mucho más conservadora energéticamente (por ahora), posee un rendimiento muy muy inferior a las arquitecturas x86/x64 actuales. Es decir, Apple podrá sacar en el futuro portátiles con procesadores ARM que durarán mucho la batería, pero el rendimiento estará muy lejos de cualquier dispositivo x86… pero podrá vender portátiles mucho más baratos. Como digo… marketing.

El iPhone 5s incorpora un chip específico para la gestión de sensores, cosa nada nueva de echo si vemos el Motorola X lanzado este verano. Este chip llamado M7 lo que viene a realizar es algo así como un “acelerador” a la hora de gestionar los sensores, para de este modo descargar a la CPU principal de estas tareas. Para procesadores más deficitarios o menos potentes no es mala idea tener un pequeño acelerador para ciertas tareas que ayude realmente. En procesadores más potentes y más modernos (y por tanto con menor consumo) este tipo de aceleradores no poseen demasiado sentido realmente. Aun así, por supuesto, es algo que es mejor tener a no tener, aunque de forma global no afectaría el rendimiento, como digo solo se encarga de gestionar y recopilar/centralizar todos los sensores.

 

Respecto al iPhone 5c realmente poco podemos decir que no se sepa ya, usa el mismo procesador A6 que el viejo iPhone 5, no ha evolucionado absolutamente nada, un procesador ARMv7 cortex a9 con algunas funciones de Coretx A15. No digo que sea malo ni mucho menos, digo que es tecnología de hace ya un año. Aun así, volviendo un poco a la arquitectura de 32bits/64bits, muchos podrían creer que el iPhone 5s posee un procesador muy superior al iPhone 5c, pero NO ES CIERTO!!, realmente ambos deberían de tener un rendimiento muy muy similar, de echo estoy seguro de ello! por supuesto hablando siempre de la CPU, en la GPU si hay más diferencia entre ambos.

Tanto el iPhone 5s como el iPhone 5c usan “solo” 1GB de memoria RAM (de nuevo vemos que el punto fuerte de los 64 bits no tiene sentido en cantidades de 1GB de RAM), la mitad que posee el Nexu 5. ¿Mucho o poco? Bueno volvemos a lo que necesite el usuario. Con 2GB de RAM puedo asegurar que el cambio de tareas, multitareas, navegación pesada por internet, juegos… no es un problema. Con 1GB os puedo asegurar que PUEDE SER un problema, sobre todo si el usuario visita páginas web pesadas mientras tiene de fondo cualquier otra cosa. Desde mi punto de vista 1GB de RAM a día de hoy es impensable con la gran cantidad de aplicaciones que tenemos que podrían hacer uso fácilmente de una mayor cantidad.

¿Resumiendo? Es evidente que el procesador A7 de doble núcleo no puede alcanzar el procesador SnapDragon de 4 de 2.3GHz (que se dice pronto). Me fastidia la fanfarronería, que no la falta de innovación. Aplaudo el echo de que los fabricantes comiencen poco a poco la transición a 64bits, y de echo es una evolución lógica! y estoy seguro que es algo que veremos como digo de aquí a uno o dos años si todo evoluciona igual, dado que la RAM será llegado un momento de nuevo un punto crucial donde el uso de procesadores de 64 bits en móviles será igualmente obligado. Como ya he dicho, arquitectura de 64bits no implica directamente ni mucho menos un mayor rendimiento, sí significa que ciertas aplicaciones concretas sí podrán verse recompensada con ese incremento extra, aunque para ello también es cierto que dichas aplicaciones concretas se actualizasen y preparasen específicamente para hacer uso de 64bits. En términos generales, el sistema operativo completo iOS 7 por hacer uso de esos 64 bits no debería de experimentar un rendimiento mayor al 2-5%. Repito una vez mas, me alegra ver que se innova y aplaudo CUALQUIER incremento en rendimiento por pequeño que sea, pero aun así el procesador A7 está muy por atrás de lo que pueda ser el procesador SnapDragon 800. Una cosa no quita la otra, y quien me conoce sabe que diría sobre 64 bits exactamente lo mismo si fuese Samsung o LG o… quien lo usase SI LO USA COMO MARKETING.

Evolución lógica?? SI. Revolución? Para nada.

 

GPU, Adaptador de vídeo

En realidad este apartado quedaría dentro del anterior, dado que los mismos procesadores/conjuntos de chips incorporan unos u otros adaptadores. Pero llegan un momento en que es necesario sacarlo y tratarlo aparte, puesto que merece la pena señalar algunas cuestiones que creo interesantes.

Pese lo que yo pueda pensar al respecto y el concepto que yo pueda tener de móviles, parece que los móviles se estan convirtiendo junto a los tablets en las nuevas plataformas de juego. Personalmente no concibo el móvil para jugar a juegos complejos o que requieran un gran potencial gráfico o… pero ni en los móviles ni en los tablets ojo!! Lo que le pido a un móvil es primero que sea móvil, segundo que pueda hacer un poco de todo con un gran surtido de servicios y aplicaciones, y por último en todo caso que pueda jugar a cualquier cosillas sencillita y rápida para pasar el rato en esos momentos que uno tiene que esperar sentado por cualquier razón. Para todo ello sinceramente no se requiere un potencial gráfico importante, y si un día quiero volver a mis años de gamer, os aseguro que será en una pantalla no menor de 24 pulgadas. Por supuesto… esto es solo mi opinión personal, que nada tiene que ver con aspectos técnicos.

Pese a mis gustos, reconozco que se ha convertido a día de hoy como primeras plataformas de juegos, solo hay que ver sendos markets de aplicaciones para verlos a reventar de juegos 3D, así que las compañías se frotan las manos porque si hay demanda… hay negocio. Pero claro, un movil no es un PC, y un adpatador de vídeo tiene un consumo importante. Aun así se están haciendo verdaderas maravillas en este aspecto, quizás la máxima expresión de ello sea nVidia con sus plataformas Tegra, con un consumo muy muy bajo y de ya os digo que si SnapDragon 800 está por encima en la cadena de las CPU, nVidia lo está gráficamente hablando… no tienen competencia. En este caso no, ninguno de nuestros 3 amigos de hoy usa Tegra.

Nexus 5 aparece con una GPU Adreno 330 que está dentro de su plataforma SnapDragon 800. Se trata de una GPU compatible con OpenGL ES 3.0 por supuesto (la API más actual del mercado móvil), y aunque no será nunca nVidia, posee un rendimiento inesperadamente alto y bueno, capaz de hacer volar cualquier juego 3D por exigente que sea, y OJO Y MAS IMPORTANTE!! En una pantalla Full HD… esto hablaremos ahora.

iPhone 5s aparece con PowerVR G6430, tampoco nada detestable, y por primera vez en productos de Apple, compatible con OpenGL ES 3.0. Comparar el rendimiento de un adaptador y otro es complicado, puesto que el conjunto de chips es totalmente diferente. Sabemos que el rendimiento es excelente igualmente en este caso, y que estaría muy a la par al Nexus 5. De echo, lo extraño del caso es que se esperaba que el adaptador Adreno 330 mostrase un rendimiento significativamente inferior, pero los datos que tenemos son diferentes, y muestran lo contrario, que en la mayoría de las veces, y como media, el adaptador de Apple PowerBR G643 estaría algo por debajo del adaptador Adreno 330.

iPHone 5c por su parte, al usar el mismo A6 que su predecesor posee el mismo adaptador, PowerVR SGX543MP3, adaptador que no soporta OpenGL ES 3.0 (recordemos como nota que el Nexus 4 sí es compatible con OpenGL ES 3.0). No es un adaptador de bajo perfil, pero como ya hemos dicho del resto de las características… es tecnología antigua. Apple ha cogido los restos que le han sobrado del Iphone 5 este año atrás para sacar otro iPhone. Evidentemente su rendimiento está muy por debajo a los otros dos amigos descritos.

 

Permitirme una vez más un paréntesis para hablar de nuevo sobre algo que la mayoría desconoce y que en la gran mayoría de sitios web, foros, blogs… olvidan mencionar cuando hacen CUALQUIER pruena de benchmarks

Actualmente, está generalizado el demostrar el rendimiento de diferentes dispositivos sometiéndolos a lo que llamamos benchmarks, test sintéticos que intentan demostrar que un dispositivo es más rápido que otro sometiéndolos a diferentes pruebtas, test, demos… así, cuando se quiere supuestamente demostrar que A es mejor que B, se someten A y B al mismo test y quien saque mejor puntuación gana… o al menos esa es la teoría. El problema de los benchmarks principalmente es que son falsos, jamás un benchmark escenificó un entorno real, un test representativo de lo que encontramos en la realidad, con lo que los datos que aporta sinceramente me dicen poco. Pero segundo y más importante es quien programa dichos test, quien los ejecuta y con que intenciones, y si los fabricantes (que saben como se usan los benchmarks) no tienen códigos específicos para dichos benchmarks (que de ya os digo que si crean código específico para ellos para que los resultados siempre estén inflados).

Bien, pues aun así, aun en el hipotético caso que el benchmark fuese infalible y escenificase al 100% un juego o una demo, tendríamos el problema de la plataforma, no puedes comparar adaptadores de vídeo cuando dos plataformas son radicalmente diferentes! no tiene sentido. Demos un paso más, ignoremos también este echo, imaginemos que queremos solo medir el rendimiento general de CPU+GPU+sistema de dos plataformas aunque sepamos que son diferentes, suponiendo que también todos somos buenos amigos y que nadie hace trampas… bueno pues aun cuando ese escenario irreal se diese, vemos que la mayoría de sitios olvida algo igualmente importante y francamente gracioso: RESOLUCIÓN

La resolución de una pantalla nos dice el número de píxeles que el adaptador de vídeo tiene que mover. Así pues, una pantalla FullHD (1920×1024) como en el Nexus 5 posee 1.966.080 píxeles (2MP prácticamente). Una pantalla como la del iphone 5s/5c (1136xx640) posee 727.040 (0.7MP más o menos). Dicho de otro modo, el Nexus 5 posee un 270% más de píxeles que el iPhone, eso es que duplica y casi triplica lo en píxeles. De este modo el adaptador de vídeo del Nexus 5 cuando tiene que trabajar, trabaja casi el triple. Es por eso que no tiene sentido cualquier tipo de benchmark que no tenga esto en cuenta y se obligue a realizarlo en lo que llamamos offscreen a nua resolución FullHD. Es decir, en un modo en el que la resolución física de la pantalla no influya. Sabéis que tenemos cuando sometemos a los 3 dispositivos a test de este tipo?? Que gana Adreno 330 por extraño que parezca. Repito… aun así, los resultados de cualquier benckmark son cuanto menos dudosos, falsos, irreales. Solo explico y doy motivos por los cuales el 99% de todas las comparativas basadas en benchmarks son cuanto menos poco fiables a menos que se adjunten datos explicativos concretos y detallados.

Resumiendo en cuanto adaptadores de vídeo se refiere, Adreno 330 posee un rendimiento soberbio, personalmente pensé sinceramente que en este punto el iPhone 5s muy superior… pero me equivocaba. Aun así no descarto aun que sea un problema de Apple a nivel de software que degrada de algún modo el rendimiento de su adaptador, o puede ser realmente que es lo que hay. Me ha sorprendido realmente.

 

Pantalla

 Tenemos por un lado el precio, por otro tenemos las tripas de nuestros dispositivos, las cuales aunque sean muy importantes no es algo que podamos ver… o al menos no como podemos ver la pantalla, que a fin de cuenta es lo que atraerá nuestra atención de nuestros dispositivos el 99% del tiempo que estemos con él. Si hay guerras abiertas en cuanto a dispositivos, una de los flancos siempre abiertos es sin duda alguna la pantalla. De nuevo, parte de esta guerra la tiene precisamente el marketing, y no las necesidades del usuario, el cual muchas veces ni comprende ni quiere comprender realmente los por mayores o menores de las pantallas.

Hablar de pantallas no es tan sencillo, porque realmente aquí entramos en una de las pocas cosas que son relativas, que depende realmente del punto de vista de cada uno, y no precisamente por la calidad de estas, sino por su tamaño. A día de hoy tenemos terminales que van desde las 3 pulgadas hasta las 5.6. Parece que se ha convertido en un “estándar” 3 medidas, la que llamaríamos tablet-phones como los Galaxy note por ejemplo, bajando hasta las pantallas “grandes” como el Nexus 5 que van desde las 4 a 5 pulgadas, y los que nos parecen pequeños, que pueden ir desde las 3.5 hasta las 4 pulgadas o así. El problema es que no solo es el tamaño de la pantalla, sino que la pantalla repercute directamente con todo el teléfono, el formato del terminal a fin de cuenta se construye entorno a esto. ¿Pero cual es el tamaño ideal?

Steve Jobs cuando aun vivía aseguraba que el tamaño perfecto de un teléfono según diversos estudios y bla bla bla estaba exactamente en las 3.6 pulgadas que tenía su iPhone. En cambio el mercado se abrió rápidamente a las 4 pulgadas en adelante, después fuerno 4.5 y a día de hoy parece que el estándar está entre 4.5-5.0. ¿Pero es realmente este tamaño el ideal? Recordemos que tuvieron que pasar 3-4 años para que Apple anunciase el iPhone 5, y con el aseguraron que, por supuestos supuestamente nuevos estudios ahora parecía que lo perfecto eran 4 pulgadas por otros tantos motivos, curiosamente el tamaño de pantalla del iPhone 5. En realidad, Jobs mentía, al igual que lo hace a día de hoy Tim Cook cuando asegura que el mejor tamaño y el más ideal son sus 4”, e igualmente mentirá cualquiera que sugiera siquiera que existe un tamaño perfecto. No existe tamaño perfecto. Si el usuario no ha sido en modo alguno aconsejado u orientado hacia un tamaño concreto, es el usuario quien tendrá su tamaño ideal. Para muchos, un apantalla de 3 pulgadas será la ideal porque buscan algo pequeño manejable y funcional. Otros dirán que una pantalla de 3 pulgadas es algo impensable y que no hay nada más cómodo que una pantalla de 5.4 pulgadas. Aquí, como los colores, es a cuestión de gusto. Evidentemente cuanto mayor sea la pantalla, esta requiere una mayor resolución para poder conservar la misma densidad de píxeles, y por supuesto al ser la pantalla más grande el peso aumenta en igudad de condiciones, y el hardware necesario para una pantalla de mayor resolución y mayores prestacionese debe de ser igualmente superior, como la batería dado que la pantalla es lo que posee mayor consumo… luego no es algo que haya que tomar a la ligera.

Es por esto que no podemos decir que una pantalla sea mejor que otra por su tamaño. Personalmente las 4 pulgadas del iPhone 5s/5c puede ser pequeña, al igual que me parece grande la pantalla dele Galaxy Note, pero para otros una pantalla de 4.8 le puede parecer igualmente enorme… o pequeña. Así que ese aspecto lo dejaré a gusto de cada cual, aunque aun así, diré que por mucho que desde el iPhone 5 pusiesen una pantalla de 4 pulgadas, parece ser que las personas en general, en su mayoría, prefieren pantallas mas grandes, o al menos eso es lo que vemos en la tendencia de los productos… y os aseguro algo… realmente las pantallsa de 5+ pulgadas fuesen realmente grandes para todos, no las venderían.

Hablado ya del tamaño, que cada cual prefiera uno u otro, queda la polémica de siempre: ¿Que resolución? Tenemos de nuevo otra de esas cosas que hasta muy poco (y aun para algunos) es reclamo inmediato por marketing, que no significa que sea algo realmente importante, pero como vende el ponerlo en un cartel… Y quiero decir que aunque esta guerra la empezó Apple y causó una guerra absurda, no son pocos los que se han unido a esta lucha, de tal modo en este caso que el tiro le salió por la culata a Apple y fue en su contra.

Apple hace unos años creó un término que a día de hoy intenta usar en todos sus productos, aunque lo ha usado según le ha convenido desdiciedose cuando ha querido. Sea como sea, fue hace unos años cuando Jobs apareció en pantalla diciendo que habían creado la pantalla perfecta, llamada Retina. Esta pantalla se llamó así porque según Jobs, todos los estudios realizados dictaban que la densidad máxima que el ojo humano es capaz de apreciar en una pantalla son los 300 dpi (puntos por pulgada). Lo cierto es que en parte es cierto lo que dice, no los estudios de los cuales sacó ese número mágico claro, eso es discutible, pero si el echo de que la resolución de un dispositivo realmente no nos dice nada, pues depende del tamaño de esa pantalla para poder realmente saber si la pantalla tiene una resolución suficiente o no. Entender esto es muy sencillo, y lo he explicado muchas veces. Todos sabemos que la resolución es el número de líneas o puntos que una pantalla dibuja/muestra, cuanto más píxeles tenga tendrá más definición, y de ahí la cuestión de ¿cual es la resolución suficiente para que la imagen tenga la definición suficientemente alta para que su incremento nuestro ojo humano no note la diferencia? Pero el problema no es la resolución realmente, sino el tamaño de la pantalla. Si tenemos una pantalla que tiene un ancho de por ejemplo 20 cm y posee una resolución de 20×20, cada pixel tiene un tamaño de un centímetro, puntos enormes!! tendríamos la sensación de una calidad de imagen malísima. Pero si ahora cogemos una pantalla de 10cm y mantenemos la misma resolución, ahora el punto se ha reducido a la mitad, pq en 10 centimetros siguen existiendo 20 puntos, ergo cada pnto mide medio centímetro. Esa pantalla tendrá más definición por tanto, a expensas evidentemente de ser la mitad de grande.

A día de hoy las pantallas Full HD son comunes en cualquier casa, sobre todo en sus televisiones. En cambio, las pantallas FullHD que son 1920×1080 píxeles, si los distribuimos en una pantalla de 42 pulgadas que podría tener una anchura de 37 pulgadas aproximadamente, nos daría 1920/37 = 54píxeles por pulgada, es decir, 54dpi. En cambio, si nuestra pantalla es de 24 pulgadas, pasamos a tener una densidad de 92dpi!! una televisión con muchísima más definición. Lo que está claro es que si queremos mantener una densidad de píxeles estables, tenemos que aumentar la resolución al aumentar la pantalla de tamaño.

Volviendo al tema que nos atañe, realmente existen las pantallas retinas? Es solo un truco de marketing? En realidad es todo marketing. Es cierto que podemos decir que ciertas densidades de píxeles son bajas o elevadas, pero de ahí a establecer un umbral fijo que dictamine si el ojo humano es capaz de percibir más o menos, es una locura!! Para empezar, y más importante, porque esta apreciación de nuestro ojo humano tiene una dependencia absoluta a la distancia desde la que miramos la pantalla. Así por ejemplo, nuestra pantalla de 42 pulgadas con una densidad de 54dpi parece una densidad muy pobre, pero es una pantalla de 42 pulgadas, estoy seguro que la distancia mínima a la que nos situaremos para verla será a lo mejor 3 metros? 5 metros?? Imaginad por un momento que a 7 metros de distancia, la densidad máxima de píxeles que pudiese apreciar nuestro ojo fuese de 54 dpi, significaría entonces esto que nuestra pantalla es Retina? Cmo vemos no es algo tan sencillo. Evidentemente una pantalla de un movil la vemos muy de cerca, a unos centímetros de nuestros ojos, y os aseguro que si nuestras pantallas de móviles fuesen de 54 dpi, notaríamos una definición pésima. Aun así, no podemos dar una cifra, ni 200, ni 300 ni 400. Depende de cada persona, depende de la distancia desde la que la persona suele mirar la pantalla. De echo, si el ojo humano realmente no fuese capaz de interpretar más de 300dpi, cada punto de más que tuviese la pantalla sería contraproducente, porque nuesetro dispositivo tendría que trabajar más. Por tanto, para que aumentar la resolución si el ojo es incapaz de notar diferencia ni siquiera mirándola a medio centímetro? La respuesta ya la he dicho… no hay una cifra. Yo os aseguro de todos modos, que me extrañaría que alguno de vosotros fuese capaz de diferenciar en test ciegos una pantalla de 200dpi a una de 400dpi, la inmensa mayoría las vería igual. Que por qué se hacen entonces? ya lo he dicho, marketing.

Curiosamente, Apple ha llamado a pantallas de los iPad Retina, sin tener una resolución de los 300 dpi como vimos en comparativas anteriores. En realidad sí que critico eso por usar el doble rasero, cuando ellos sacaron la primera pantalla que tenía 300dpi la suya era la única retina, años posteriores la competencia ganó a Apple a su propio juego y aun así ellos han seguido llamando Retina a lo que les ha dado la gana a ellos, llegasen a 300 dpi o no. Sea como sea, parece que la guerra (no todas las guerras son malas) ha causado algo bueno, las pantallas han evolucionado de forma rápida, y casi todas las pantallas actuales cuentan con una densidad de píxeles suficientes como para que el usuario pueda disfrutar de una imagen completamente nítida.

El nexus 5 en este caso, posee una pantalla de 4.9 pulgadas (un pelín grande para mi gusto, aunque te acostumbras de inmediato), pero lo que realmente sorprende es que posee una resolución de Full HD, lo que hace que posea una densidad de píxeles rara vez vista: 444 dpi. Recordemos que el Nexus 4 poseía una resolución HD Ready, con 4.7 pulgadas tenía una densidad de 318 dpi. No digo que no me parezca totalmente sorprendente y de una calidad y definición excelente el Nexus 5, lo que digo es que cualquiera que posea un Nexus 4 difícilmente va a notar ninguna diferencia en cuanto a definición se refiere, apreciar de 318 a 444 dpi… el usuario tendría que coger una lupa o tener un ojo realmente bueno. Quitando la resolución, que como ya he dicho me parece impresionante pero igualmente innecesario, hay que destacar que posee una calidad excepcional, tecnología IPS lo cual hace que permita verse perfectamnete hasta en ángulos extremos, y un contraste y tiempo de respuesta (importante para los gamers) muy bajo. Para terminar, y si creo que es más destacable es que usa tratamiento Gorilla Glass de última generación para evitar en lo posible roturas, ralladuras y otros. Y esto puedo testificar que es cierto, a día de hoy en realidad las pantallas que tenemos son casi imposible de rallar, generalmente se rompen y tan solo después de un golpe seco, duro y dramático.

El iPhone 5s/5c por contra usan una pantalla muy similar (entre ellos). Los dos optan por tamaño de 4”, recordemos como he dicho que según sus nuevos estudios bla bla bla es el tamaño perfecto. Dentro de un año o dos cuando aumenten el tamaño dirán que realmente el udeal y el tamaño perfecto es otro. Sea como sea, poseen una resolución de 640×1136, lo que nos da una densidad de 326dpi. Mucho o poco me remito exactamente a lo mismo… muy buen ojo tendría que tener uno para notar ninguna diferencia entre una pantalla de 326 a otra de 444 dpi. Tendrías que poner una imagen muy concreta de gran calidad y detalle y fijar la vista atentamente en un punto y… En cuanto a definición se refiere, realmente es que no se requiere más, ya he dicho que fue una guerra absurda injustificada en su mayoría que comenzó Apple, nunca fue una guerra real. Me da igual una pantalla de 326 que otra de 444, sé de verdad que mi ojo es incapaz de notar diferencia alguna, el efecto placebo se lo dejo a otros. Ahora bien, quitando el tamaño y la resolución, si es verdad que las pantallas de Apple pecan en poseer un bajo rango de contraste y un tratamiento de peor calidad contra ralladuras y roturas, dicho de otro modo, suele ser más sencillo rallar-romper una pantalla de Apple como la del iPhone 5s a una como la del Nexus 5.

Como conclusión en este apartado, tengo que decir que aunque técnicamente la pantalla del Nexus 5 no tiene rival y es evidentemente muy superior a la pantalla del iPhone 5s o 5c, también tengo que decir que me extrañaría enormemente que cualquier lector fuese capaz de notar diferencia alguna en cuanto a calidad. La resolución y la densidad de píxeles importa… pero siempre hasta cierto punto. Sí es cierto que en el caso del Nexus 5 podemos hablar de un éxito en mayúsculas en su pantalla porque posee un tamaño de pantalla muy superior, casi una pulgada más de pantalla!! Y aun así posee una densidad aun mayor. Eso hace que cualquiera que tenga un Nexus 5 disfrute de una gran pantalla de 5 pulgadas que mantienen una definición y una calidad sin igual. Es mejor? Sin duda… aunque personalmente creo que es indiferente, que el usuario realmente no iba a notar la diferencia :), a fin de cuenta la pantalla de ambos iPhone nuevos es también muy buena.

 

Almacenamiento

 Aunque vivimos en un mundo que cada vez la sincronización de servicios y el trabajo en la Nube es más común, es evidente que también necesitamos una buena capacidad de almacenamiento en nuestros dispositivos. Sobre el cuanto es suficiente, también es una cuestión de cada uno, y de cada plataforma que usemos, puesto que los servicios que ofrecen tanto Google como Apple son bien diferentes. Google por ejemplo apuesta de principio a fin por servicios puramente en nube cuando hablamos de contenido audiovisual y sincronización para pequeñas cosas como el correo/calendario/agenda… Apple por su parte opta por centralizarlo casi todo en servicios de sincronización, dejando realmente lo que es la nube para copias de seguridad. Esto es importante, ya que el almacenamiento de nuestros dispositivos puede depender íntegramente de que tipo de servicios usemos. Lo que está claro, es que no por comprar un dispositivo de 32GB frente a uno de 16GB es mejor compra, sería un desperdicio de dinero y de espacio si solo vamos a usar por ejemplo 10GB de esos 16/32.

Yo, de nuevo hablando de forma totalmente personal, creo que 16GB a día de hoy es más que suficiente para el 99% de los usuarios, ni hacen falta 32 ni mucho menos 64. Analizar esto es muy sencillo. Apostaría a decir que el 80% del volumen usado de nuestros dispositivos se divide en música, vídeos e imágenes, y de esos 3 elementos, sin duda alguna vídeos y música. Muchos dirán que evidentemente en 16GB es imposible meter toda la colección de música de uno… y estoy convencido de ello, pero tampoco entraría en la de 32GB o incluso en el de 64GB (depende de lo que le guste a uno la música). Aun así, personalmente claro, también sería una solemne estupidez tener 16GB de música en el dispositivo, eso es tal cantidad de horas de música que estoy seguro que el usuario no iba a escuchar en años, con lo que al final lo que tienes es el almacenamiento del dispositivo totalmente colapsado por música que a lo mejor escuchas una vez en un año… o ni eso.

Aun así, aquí vemos la gran diferencia que implica usar unos servicios u otros. Por ejemplo, quien sea afín de usar los servicios de Google por ejemplo  Google Music (lo que para mi es uno de los mejores inventos del mundo), puede tener absolutamente toda su colección musical en Google, tanto las canciones compradas como las suyas propias, de forma que puede reproducirla como si la tuviese metida en su propio dispositivo! pero sin consumir absolutamente nada de espacil. Sí, la reproduce y la usaría en Streaming y necesitaría siempre una conexión a datos/wifi para poder escucharla, pero para eso podríamos usar las mismas prestaciones de Music para que si queremos hacer un viaje o vamos a estar en algún sitio que no vayamos a tener cobertura, solo hay que darle a la aplicación para que la música que queramos se descargue en local… solo con un toque en la pantalla. Me encanta la música, tengo decenas y decenas de GB… y toda ella está en la nube, no tengo que llevarla conmigo nunca, ni en el móvil ni en el PC, solo requiero de una conexión a Internet ya sea en el navegador del PC o en el móvil, y en el peor de los casos sencillamente descargo la que quiera en local por si voy a estar off. Molestia? Mínima. Espacio usado? Cero (realmente no es cero pq se guarda una base de datos con la información de todas las canciones que tenemos… a lo mejor unos 50MB). Music, usado correctamente, no solo te da acceso a toda tu música, sino que a cualquiera que adore la música puede hacer que el espacio de almacenamiento que necesita se reduzca abruptamente. Sobre imágenes puedo decir exactamente lo mismo. Google permite subir las fotos a Google Photos donde tener toda nuestra colección si lo deseamos (ilimitadas en resolución normal, 15GB máx en máxima resolución).

El concepto de Apple en este sentido es peor para mi gusto, ya que ellos la música y las imágenes no hacen uso de la nube, sino de sincronización. Es decir, puedes tener sincronizada toda tu música entre tu PC y todos tus dispositivos de Apple, pero existirá una copia física en cada uno de ellos. Si tu biblioteca de iTunes es de 10GB y la sincroniza, tu dispositivo usará 10GB. Básicamente lo que hace iCloud en este caso es iTunes sube la música a iCloud, el móvil la descarga íntegramente en él… lo que al final obtienes es un almacenamiento precioso agotado e igualmente un gasto enorme de datos, ya sea WIFI o un plan de datos móvil.

En términos generales la sincronización es una herramienta potentísima, pero su gran virtud está para pequeñas cosas, para archivos y contenido más pesado a día de hoy tenemos afortunadamente la nube. Esto es curioso, puesto que el nombre de Apple a sus servicios es iCloud (Cloud = nube), y realmente usa bien poco lo que son servicios en Nube. Eso no quiere decir que los usuarios de Apple no puedan usar los servicios de Google ni mucho menos, cualquier usuario de iOS puede acceder con su navegador a Music por ejemplo y reproducir como si de su reproductor de música se tratase cualquier canción. No estoy comparando sistemas operativos, ni siquiera entro que servicio es mejor o peor, solo el impacto que estos puedan tener a nuestro almacenamiento.

Los vídeos sufren un tratamiento similar. En el caso de los vídeos, ni Google ni Apple permiten sincronizar ni subir a la nube de ningún modo, lo cual es comprensible. En todo caso con Google se podría enviar a Drive, pero tampoco podríamos almacenar demasiados. Las películas o vídeos que se compran en Play Store es diferente porque Google si permite su reproducción en Streaming de forma directa en cualquier dispositivo, pero quitando esto, me temo que en este caso sí, quien quiera usar su dispositivo para ver películas sin parar tendrá que disponer de una gran capacidad. Personalmente, creo que es una tontería en mayúsculas, porque para eso tenemos nuestro discos duros externos con capacidades que llegan a más de 2TB.

Resumiendo todo un poco, aquí no valoramos aun así que espacio es más óptimo o no, sino que dispositivo ofrece mejores configuraciones en este aspecto. Y lo cierto es que Apple en su iPhone 5s es el único que ofrece 64GB de almacenamiento. Sea necesario o no, lo que está claro es que es el único que lo ofrece, y cualquier elección siempre es buena. Con lo que evidentemente en este aspecto ganaría nuesetro iPhone 5s frente al resto. Ninguno de ellos puede expandirse por medio de uSD, con lo que sería un empate técnico.

Por último, si hay que destacar que el Nexus 5 es el único que posee un conector estándar uUSB, y que encima es compatible con OTG. Muchos podrán no estar de acuerdo conmigo cuando digo que es mejor un conector uUSB al conector Lighning de Apple, pero creo que si hacemos un juicio justo al respecto, veremos que realmente al final el uso de un conector uUSB es mejor. Es cierto que a lo mejor el conector de Apple es reversible o menos propenso a poder sufrir un deterioro, pero cualquier usuario de conector uUSB sabe que existe una característica mucho más importante al echo de que sea reversible o más sólido… y es el echo de que es totalmente universal. Puedes ir con tu dispositivo móvil, tablet o lo que quieras a cualquier casa si quieres, que seguro que puedes cargar en ellos el móvil, y ya no solo cargarlo, sino transferir cualquier archivo de/desde él si es necesario, todos tienen al menos algún cable en su casa. Muchos pueden decir ante esto que eso se soluciona con meter un cable en el bolso de Apple o que a ellos eso no le afecta porque todo su círculo usan el mismo cable… bien, no digo que esto pueda ser o no cierto, pero no deja de ser un modo de intentar ocultad una realidad mucho más práctica. Eso sin entrar por supuesto en el precio que tiene un cable uUSB a uno que tienen un cable Lighning.

En el caso del Nexus 5, posee otra característica peculiar como viene siendo habitual, y es que el conector uUSB es compatible con el estándar OTG. Esto quiere decir que dicho puerto uUSB puede usarse como un USB Host! Dicho de otro modo, podemos conectar en él virtualmente cualquier dispositivo USB: Teclados/ratones USB, cámaras, mandos para juegos, lectores de tarjeta, pendrives o discos duros incluso si queremos. A nadie se le escapa las posibilidades que esto puede tener. No es ni mucho meno algo esencial, si es un extra bien avenido.

 

Comunicaciones

 A nadie se le escapa que en el siglo XXI sea fundamental no solo tener un cacharro con una buena pantalla. Necesitamos que nuestros dispositivos estén cada día más preparados y compatibles con el boom tecnológico que estamos viviendo, a fin de cuenta precisamente de esto va todo, de comunicaciones. Pero no nos engañemos, una vez más no confundamos lo que podría ser una… “necesidad”, a lo que es un marketing barato que intentan tanto fabricantes como compañías meter por los ojos, porque algo hay que vender a los usuarios. En esta ocasión, aquí entramos en otra guerra, aunque en este caso es más orquestada por los operadores móviles que por los fabricantes.

Es evidente que cada día que pasa tenemos unas necesidades mayores de consumo de datos, ya sea por WIFI o ya sean por redes móviles. Es evidente que por tanto también necesitamos una velocidad de acceso a dichos servicios que sea cuanto menos decente. Al igual que sería totalmente inviable los enlaces via Modem en un PC para conexiones a Internet, tampoco son viables conexiones de segunda generación para satisfacer nuestras necesidades. Pero entonces, ¿por qué estoy hablando de guerra abierta y de marketing? Bueno, hay que saber diferenciar y conocer un mínimo las tecnologías que tenemos a día de hoy, lo que pueden afectarnos unas y otras, y con todo ello ver donde está el truco. Así que empecemos un poco enumerando los enlaces actuales a redes móviles que tenemos, eso aclarará la mayoría de confusiones que tiene la mayoría:

 

-GSM:

Es el estándar en el que se basan nuestras comunicaciones móviles a día de hoy. Es tecnología 2G pura y dura, y aunque permite la transmisión de datos y voz, su uso está relegado a la comunicación voz pura y dura.

 

-GPRS

Es el sistema más viejo de transmisión de datos apoyado en GSM que tenemos, y el que más o el que menos lo recordará sobre todo de la era de los MMS o de los portales de navegación móviles WAP. Sigue siendo usado a día de hoy sobre todo en zonas rurales cuando no tenemos disponible una cobertura mejor que nos permita un mejor enlace. Es tecnología 2G, aunque en algunas literaturas la vemos como tecnología 2.5G

Su velocidad máxima es de 20Kbits por “slot”, siendo posible usar hasta 4 slots simultáneos, llegando por tanto a una velocidad máxima teórica de descarga de 80Kbit = 10KB/s. Su cobertura prácticamente engloba al menos el 90% de todo el territorio nacional, siempre y cuando por supuesto tengamos cobertura GSM.

 

-EGPRS/EDGE

Es una mejora sustancial a GRPS, pero está fundamentado lo mismo. Esta si se consideraría una tecnología 2.5G, aunque aquí en España es raro que nos veamos en este escenario, por lo general caeremos a GRPS cuando abandonamos 3G. En otros países se ha usado de forma extensa EDGE como sustitución a tecnología UMTS (3G).

Su velocidad máxima por slot se eleva a los 62Kbits aproximadamente, siendo posible un máximo de 8 teóricos, lo que haría posible una velocidad máxima de 496Kbit, lo que nos daría una velocidad máxima de 62KB/s, que es también insuficiente en los tiempos que corren, aunque mejor esto que nada, y es a fin de cuenta una gran evolución con respecto a GRPS.

 

-UMTS

Es un cambio total en los sistemas de comunicaciones móviles, no es una sencilla evolución, sino un cambio tanto en las comunicaciones de voz y de datos. Realmente se le considera la tecnología 3G pura y dura, y aunque aumentó en mucho la velocidades de conexión, esta tecnología no fue demasiado amable con las baterías. Se diseñó principalmente para realizar videollamadas, aunque lo cierto es que su uso nunca se extendió demasiado para ello. Muchos aun recordaremos la publicidad de aquellos años que vendían cada terminal con la promesa de videollamadas.

Su velocidad máxima se situa a los 2Mbits, lo que significa unos 256KB/s , de nuevo una gran mejora en comparación con las tasas anteriores. Los enlaces 3G son suficientes para mensajería instantánea, correos electrónicos, GPS… incluso consultas sencillas por Internet, aunque la navegación puede resultar lenta. No es necesario decir, que cada salto tecnológico que damos hacia delante en redes móviles la cobertura de dichos servicios se ve realmente reducido. En el caso de redes  UMTS, su ámbito suele cubrir incluso la mayoría de carreteras, pero suele dejar fuera a zonas rurales que estén más alejadas.

 

-HSDPA

Es una enorme evolución a UMTS, y es a día de hoy el tipo de enlace más usado en la actualizada en zonas pobladas. Nos permite obtener velocidades más que decentes para cualquier tipo de tarea. Hablaríamos en este caso de tecnología 3.5G, aunque como vemos el ponerme nombre a la tecnología sería un poco subjetivo.

HSDPA es un gran salto hacia adelante, permitiendo enlaces de una velocidad de hasta 14Mb, lo que nos permitiría en teoría alcanzar unas velocidades de descarga máximas de 1.2MB/s!! Es decir, que si estuviésemos en el mejor de los casos, dispondríamos de enlaces más rápidos en este caso que la mayoría de conexiones ADSL de domicilios, si tomamos que de media puedan tener 10Mb.
En contrapartida, como vamos viendo, su uso está mucho más restringido, siendo común las conexiones HDSPA en la mayoría de los núcleos medianamente poblados, pero no suelen extenderse mucho más allá.

 

-HSDPA+

Aunque no deja de ser una mejora de su predecesora, es otro gran salto cualitativo. Muchos llaman a esta tecnología 4G porque comparte algunas característica de este tipo de tecnología, pero en realidad pertenecería más bien a tecnología 3.5G o en todo caso a 3.75G.

La velocidad de descarga de HSDPA+ puede llegar teóricamente incluso a 337Mb, aunque como evidentemente supondrá la mayoría no existen redes que soporten las especificaciones más avanzadas de esta (o al menos yo no las conozco). De echo si miramos la tabla de especificaciones mostradas, los terminales en la comparativa soportan de máxomo la especificación de la 3GGP 8, que son 42.2Mb, lo que sería en descarga un máximo teórico de nuevo de 5.2MB. A día de hoy, nadie se le escapa que para alcanzar una velocidad así en un domicilio es necesario hacer uso de tecnologías de fibra o VDSL, cosa que a día de hoy tan solo una minoría tiene acceso a dicha tecnología, sin embargo en telefonía móvil al menos nuestros dispositivos están preparados para ello.

En contrapartida tenemos la cobertura de nuevo, cada vez más recortada. En este caso, HDSPA+ en España suele estar disponible tan solo en la mayoría de las ciudades y núcleos muy poblados.

 

-LTE

Llegamos a lo más novedoso que tenemos a día de hoy y es donde como ya he dicho está el marketing. LTE es otra evolución más a la tecnología 3G, siendo LTE la tecnología 4G pura. No obstante, a priori no representa otro salto tan claro y exagerado como pudo ser HSDPA o HSDPA+, pero porque al principio se basa de nuevo en un sistema de comunicación diferente, mejorando la calidad de las llamadas de voz y la calidad y estabilidad de las conexiones de datos.

Su velocidad máxima teórica es de 300Mb, como vemos paradógicamente menor a la máxima que podría alcanzar una red HDSPA+. Aun así como viene siendo normal, ningún operador ofrece conexiones a dicha velocidad, siendo lo habitual en el mejor de los casos ofrecer enlaces de 50Mb, lo que serían 6.25MB/s.

LTE posee otro grave problema, al menos en España. Si ya se complicado poseer cobertura HSDPA+, lograr un enlace LTE es casi imposible. Actualmente tan solo los núcleos principales de España poseen cobertura 4G, si no recuerdo mal la lista era bien cortita: Mi querida Sevilla, Madrid, Valencia, Bilbao y Barcelona. Por supuesto, solo en la ciudad.

 

He hablado sobre guerra y marketing. Creo que con las cifras y los pros y contras encima de la mesa vemos el motivo. Ahora mismo las operadoras anuncian por todo lo alto y lo venden como si de algo especial se tratase eso del 4G. Claro que LTE es una buena evolución y estoy seguro que dentro de unos años se afianzará y aparecerá una revisión más avanzada que permitirá velocidades muy superiores, ese no es el problema. El problema, y lo que me parece indecente, es que se quiera vender algo que solo un 1% podrá apreciar en el mejor de los casos como la panacea de las comunicaciones actuales. Y esto lo digo por tres motivos:

a) Cobertura: De nada vale poder disponer de una tecnología superior si hasta dentro de 2-4 años las redes LTE no estarán siquiera disponibles en núcleos poblados. Poca cobertura ademas, implica que la batería se freirá muy rápidamente, pues en el mejor de l os casos que vivamos en un lugar donde exista cobertura 4G, nuestro móvil estará constantemente cambiando entre 3G+/4G, y eso se traduce como un aumento del consumo de la batería brutal.

b) LTE puede ofrecer una buena velocidad, pero el problema no es la velocidad, es la calidad de las redes. Vemos como HSDPA+ es capaz de alcanzar velocidades incluso mayores! Y sencillamente las redes no se actualizan, si ya de por sí tienes que tener suerte para lograr enlaces HSDPA+ teniendo buena cobertura, que suerte tienes que tener para poder lograr un enlace LTE de 50Mb?? Seamos sinceros, cualquiera que se conecte por redes 4G a día de hoy al menos en españa, o se encuentra justo debajo de una antena 4G o que no espere tener un enlace de más de 4-5Mb/s. Lo que tienen que preocuparse las compañías es menos marketing barato y más mejorar sus redes y aumentar la cobertura.

c) Aun en el mejor de los casos que dispusiésemos de cobertura LTE en todo el territorio nacional… ¿para qué? Si alguien me dice que es para usar la conexión de datos móvil para un PC puedo entenderlo, pero si me dice que es que él/ella necesita una conexión a 50Mb/s en su móvil… sinceramente no me lo creo, y por muchas razones. Seamos serios, estamos de acuerdo que una velocidad de 1Mb/s es insuficiente para navegar o descargar contenidos, pero un enlace estable de 10Mb/s o incluso de 20Mb/s si queremos es más que suficiente para el 95% de la población mundial! ¿El principal uso que le damos cual es? Mensajería instantánea? No consume datos prácticamente. Correos? Poco. El mayor consumo es contenido audiovisual, y con 20Mb/s es más que suficiente para realizar el streaming más exigente que exista. Me parece de chiste el anuncio que vemos de la chica en el tren que le da a un botón y se descarga en 5-6 segundos un CD, NADIE HACE ESO. A todo ello hay que sumarle un pequeño detalle que parece que se olvidan. No tenemos tarifas planas en las tarifas de datos amigos, las limitaciones más habituales están en ¿1-2GB mensuales? Sinceramente, alguien me puede decir quien va a descargarse en 6 segundos de un tirón un CD que puede ocupar perfectamente 50-60MB cuando tiene un límite de 1GB al mes? Si la mayoría llega a duras penas a final de mes simplemente navegando, redes sociales, mensajería instantánea… ¿para que queremos realmente más velocidad?

Ahora entendemos un poco más que me refería. Claro que todo tiene una evolución natural, y es evidente que es bueno usar siempre las últimas tecnologías, pero que eso no se convierta en una necesidad que crean ellos, porque la verdad es que a día de hoy LTE para lo único que vale en España es para consumir más batería en su móvil, sin tener ningún beneficio real. Es más, casi seguro que cualquier Español aun teniendo cobertura 4G obtendrá mejor velocidad en enlaces HSDPA+. No sé como aun hay quien se fía de las mismas compañías que llevan años reteniéndolas con compromisos de permanencia y tarifas leoninas. Eso sí, se pone el cartelito de 4G y la gente pica. Mi no comprender.

 

 Dicho todo esto, que no es poco, creo que mirando la tabla de características queda un poco dicho todo lo referente a redes LTE. El nexus 5 es compatible con revisiones LTE superiores (posee 3 “antenas”) capaces de nuevo teóricamente de velocidades de 150Mb, frente a los 100Mb de los iPhone. De nuevo, cualquier extra es siempre bienvenido, pero de verdad os digo que el consejo que le puedo dar a cualquiera que lea estas letras si tiene un dispositivo 4G es el siguiente: Deshabilita el acceso a 4G, al menos durante un par de años, vas a ganar en velocidad y en batería.

El resto de dispositivos para las comunicaciones que cuentan son más sencillos de explicar y no nos vamos a enredar demasiado en ellos.

Todos disponen de Bluetooth 4.0 que es la última especificación, y todos soportan las especificaciones WIFI 802.11 a/b/g/n. No obstante, tan solo el Nexus 5 ha sido actualiado y es compatible con el wifi más actual que disponemos a día de hoy, que e sel estandar 802.11 ac. En este caso, si disponemos de un router WIFI ac podremos establecer enlaces de hasta 433Mb/s, lo que desde luego es otra pequeña victoria para el Nexus 5 de LG/Google. No creo que sea algo radicalmente necesario a menos que se deseasen trasferir archivos por WIFI de forma masiva, pero bueno… es otro poquito más que el iPhone 5s ni el 5c poseen.

Otra victoria para el Nexus 5 es de nuevo un chip NFC que permite la comunicación por medio de esta tecnología inalámbrica. Como es habitual en Apple, si la competencia saca algo innovador y una tecnología puntera, ellos no la usarán y diran que es una tecnología abocada al fracaso, sin futuro o muy precipitada. Si son ellos, es que son unos adelantados. Sea como sea, el Nexus S (aka Nexus 2) ya disponía de NFC, con lo que hablamos de hace ya unos 3 años que tenemos teléfonos NFC en el mercado, y creerme… tengo uno a mi lado, y no solo se usa, sino que es tremendamente útil para compartir información de teléfono a teléfono de forma inmediata de forma sencilla sin emparejamientos ni historias. Es cierto que en España no se hace uso de sus prestaciones para realizar pagos, pero como digo su utilidad para trasnferir información entre dispositivos y para hacer uso como lectores/grabadores de tags NFC es indiscutible (aunque no ensencial)

 

Cámara

 Partamos de la base de que un móvil nunca (al menos a largo plazo) será capaz de poder hacer fotos como una cámara de fotos compacta o SLR. Es cierto que los sensores que actualmente podemos encontrar han mejorado y evolucionado de una forma notable, pero la óptica sigue siendo muy deficitaria en comparación. Quizás la mejor pregunta que podamos hacernos es que esperamos o que le pedimos a una cámara en nuestros móviles, si realmente esperamos que nuestro móvil sustituya una buena cámara de fotos/video.

Hay una extraña y expandida creencia que lo más importante en una cámara de fotos es la sensibilidad del sensor, que a cuantos más Megapíxeles mejor. Evidentemente es un factor muy importante a la hora de medir el nivel de detalle que un sensor es capaz de tomar, pero eso no significa que llegados a un punto sean más importante otros factores. Así por ejemplo vemos la carrera desmedida de Nokia por vender terminales con sensores capaz de tomar fotos a más de 40MP, y cuando analizamos las fotos vemos sin embargo que aunque es cierto que las fotos pueden tener mayor detalle en algunos aspectos, la calidad general de estas es muy pobre, a veces inferior a las fotos realizadas con un móvil con un sensor mucho menos sensible. 

Los móviles, todos, tienen un gran problema, y es el tamaño del sensor y la óptica que pueden integrar. Cualquiera que compare la lente de una cámara de fotos y la de un móvil, lo primero que destaca es su tamaño. Aquí, como en muchas otras cosas, el tamaño importa. Un sensor/lente mayor, significa que es capaz de captar mucha más luz, y la luz es factor imprescindible. Esto lo vemos a diario, la mayoría de las cámara de los móviles hacen un trabajo relativamente decente en condiciones de una alta luminosidad, pero suelen fracasar cuando las condiciones de luminosidad externa son deficientes, y como es natural los flash que tenemos son limitados. Las fotos tomadas en dichas condiciones suelen introducir un alto ruído, los sensores no son los suficientemente grandes como para tomar la suficiente luz. Otro efecto inmediato que tenemos, como cualquier aficionado a la fotografía sabrá, es que para compensar la falta de luz por las razones que sean, el obturador permanece abierto más tiempo para poder captar más luz, lo que produce a su vez una imagen movida o borrosa a menos que se tenga un pulso bien sólido… u otras medidas para compensarlo.

Ante estas limitaciones, tanto el iPhone 5s como el Nexus 5 (no aplicable al iPhone 5c) toman diferentes caminos para poder sortear en la medida de lo posible estas deficiencias. El iPhone 5s apuesta por un mejor sistema de Flash, un sensor algo más grande y un procesamiento de software más intensivo. El Nexus 5 apuesta por un sensor notablemente más grande y la inclusión de un estabilizador de imagen óptico. En ambos casos, lo que se persigue en realidad es lo mismo, lograr aumentar la cantidad de luz que el móvil es capaz de tomar, y por otro lado mejorar en lo posible la imagen cuando las condiciones ambientales son malas.

Evidentemente en las condiciones adecuadas cualquiera de las 3 cámaras realizan un trabajo excepcional, siendo en este caso la cámara del Nexus 5 la que sobresaldría por encima de las otras dos, con un sistema de enfoque superior, y las características avanzadas HDR+ y Zero Shutter Lag son siempre ese poquito más que a todos nos encanta. Por desgracia, y es por ello que en este punto tengo que dar como ganadora la cámara de iPhone 5s, es que el software actual del Nexus 5 (que no el hardware) no está bien equilibrado, y posee algunos defectos que hacen que las fotos no son todo lo buenas que podrían ser. No quiere decir que sean malas, quiere decir que podrían ser mucho mejores para la cámara que posee. Es por ello que el iPhone 5s balancea mejor los colores y tonalidades (software como digo), y la cámara Slow Motion es también un agregado interesante. Estoy seguro que en futuras actualizaciones del Nexus 5 la mayoría de estas deficiencias se verán solventadas, pero si hay que ser honestos, aun tienen que pulir algunos problemillas.

Es una pena que el Nexus 5 no incluyese una cámara Slow Motion o que Google no haya afinado del todo en la configuración del software, porque sin duda alguna el software fotográfico de Google no tiene igual actualmente, su sistema HDR, fotografía panorámica y Photosphere, estan ahora mismo muy muy lejos de cualquier solución que ofrece la competencia. Supongo que en esta vida nunca se podrá tener todo…

 

Sensores

La mayoría de todos los terminales que encontramos ya en el mercado, comparten los mismos sensores, la tecnología de integración de hoy en día permite crear cada vez sensores más pequeños, precisos y con menor consumo. A día de hoy todo el mundo sabe que es un acelerómetro gracias a los móviles, pero esto que a día de hoy está tan extendido y que francamente funcionan excepcionalmente bien, hace unos años hubiese sido de ciencia ficción. Si aplicamos la lógica, veremos como los sensores poco a poco se van expandiendo, y mejorando en mucho su precisión.

Acelerómetros, brújulas digitales, sensores de proximidad y luminosidad o giroscopios estan presentes casi en el 100% de dispositivos móviles (al menos en SmartPhones).

En los últimos años, se han introducido algunos sensores más, como el barómetro que ya incluyen la mayoría de fabricantes en sus gamas altas. Un barómetro mide la presión atmosférica, y esto tiene una aplicación inmediata en dos campos: Predicción del tiempo por cambio de presión y más habitual, como sensor de altitud. Esto hace que cualquier dispositivo móvil con barómetros tendrán un tiempo de fijación de GPS mucho menor, además de ser más exacto.

El barómetro ya lo encontramos hace un par de años atrás desde el Galaxy Nexus y no es una novedad, aunque Apple aun no lo implementa. En esta ocasión se han empezado a usar dos nuevos sensores, que hasta la fecha no se han usado con anterioridad. Lector de Huella dactilar y Detector/contador de pasos (aka pedómetro)

Lector de Huellas: El iPhone 5s incluye un lector de huellas en su botón home, y como cualquier lector de huellas su función es evidente… un escáner dactilar. Apple es el primero en implementarlo en sus dispositivos aunque son muchos los que tienen patentes y pensamiento de usarlos en el futuro. Bien usado y confiando siempre en un software que lo respalde de forma correcta, personalmente creo que es una buena medida de seguridad para nuestros dispositivos, tanto como control de acceso como para su uso en aplicaciones internas y externas. El problema que suponen este tipo de dispositivos es que hay que fiarse del software que lo respalda, y que por supuesto como se ha demostrado en múltiples ocasiones no es un sistema “fiable”. Como idea inicial está bastante bien, el problema es que como con todas las cosas que hace Apple, es tan restrictivo su uso que pierde la mayoría de su valor, y es que Apple no permite su uso, tan solo puede usarse para desbloquear el terminal en vez de usar un PIN. Espero que esto pueda cambiar también en el futuro, pero o mucho me equivoco o antes de que esto ocurra tendremos en el mercado dispositivos con lectores de huellas capaces de usarse en cualquier aplicación en Android.

Pedómetro: Esta es una de las novedades del Nexus 5 y una de las pocas cosas que no se han sabido hasta el momento de su lanzamiento, lo cual ya es raro teniendo en cuenta la cantidad de filtraciones que han existido. Detallar que es un pedómetro es un poco absurdo, como lo es explicar su uso. Es un sensor tremendamente útil para los amantes del deporte, pero lo cierto es que para la mayoría de las personas pasará totalmente desapercibido. No digo que no sea útil en momentos concretos y que todo lo que sea un añadido es positivo, pero yo lo calificaría como un extra menor. Por supuesto, repito, para un deportista esto no solo sería un extra, sino algo tremendamente útil, pero hay que hablar un poco por boca de la mayoría.

Por lo general, si hacemos por tanto balance completo sobre los sensores del iPhone 5s o el Nexus 5 (recordemos que el iPhone 5c tampoco lleva el lector de huellas), creo que es más útil un barómetro y pedómetro que un lector de huellas, si tenemos en cuenta por supuesto que el lector de huellas solo vale para desbloquear la pantalla en el iPhone, que en Android puedes desbloquearlo por PIN, patrón o rasgos faciales y que el barómetro es algo que sí se usará de forma extensa y sí es a mi juicio un valor añadido. Al igual que el pedómetro, la mayoría de usuario no va a usar nunca el lector de huellas, os lo puedo asegurar, la mayoría de echo no usa siquiera un PIN de bloqueo.

 

Dimensiones

 Al igual que la pantalla, es una cuestión de gustos asociada en su gran mayoría al tamaño de esta. Lo único que puede ser más medible sería el groso del dispositivo, pero indirectamente también es muy dependiente del hardware que le rodea. Para poder realmente medir este tipo de cuestiones sería necesario que ambos dispositivos tuviesen el mismo tamaño, lo cual es evidente que no. Esto creo que es más que sencillo de comprender, un dispositivo de 5 pulgadas evidentemente va a tener unas medidas y por consiguiente un peso diferente que otros de 4 pulgadas.

Lo que sí podemos medir no obstante son las diferencias de los dos iPhone, el iPhone 5s y el 5c, dado que los dos poseen la misma pantalla. En este caso, vemos que es evidente que el iPhone 5s supera con creces al iPhone 5c, siendo bastante más delgado y más ligero.

También simultáneamente podemos comparar el Nexus 5 con el iPhone 5c, puesto que aun cuando el Nexus 5 es evidentemente más grande, vemos que pesa menos y es más delgado que el iPhone 5c que es una pulgada más pequeños! Esto resulta aun más increíble, lo que nos preguntamos si realmente Apple ha hecho a posta algunas cosillas del iPhone 5c… aunque eso lo desarrollaré en las conclusiones.

Comparar el Nexus 5 con el iPhone 5s en cambio sería imposible. Si el Nexus 5 pesase menos y fuese más delgado que el iPhone 5s, entonces es cuando Apple tendría un serio problema de diseño como pasa con el iPhone 5c (Que es totalmente inexplicable), pero en este caso es una cuestión de lógica. Si tienes una pantalla más grande, la estructura es igualmente más grande y por tanto lado, ancho, grosor y peso es igualmente superior.

Para cualquiera que pueda decir o pensar que el peso de un dispositivo u otro es mucho o poco, o si en sí el dipsositivo es grande o pequeño, sencillamente es que se equivoca de formato, aunque como ya dijimos en el apartado de pantallas, el mercado está tendiendo a pantallas más grandes, es lo que los usuarios están cada vez más exigiendo. No quiero decir con esto que para muchos el tamaño ideal sean las 3 pulgadas, las 4 o las 4.5, por supuesto es una cuestión de gustos, aquí solo podemos hablar de una mayoría, y que lo que quiere es caballo grande.

 

Batería

 Posiblemente la queja mayoritaria que tiene cualquier usuario de Smartphone es la corta duración de la batería. Tiene sentido, hemos pasado de tener móviles que duraban días y días sin necesidad de recargar a otros que no pasa un dia o dos a lo sumo de tener que pasar por el enchufe. Pero nos guste o no es el precio a pagar por dispositivos que poseen un consumo muy superior a lo que consumían anteriormente, y a eso debemos sumarle el echo que las baterías por desgracia no han evolucionado a la misma velocidad que el resto de la tecnología… y no es por falta de financiación o interés, es que por desgracia los límites actuales de la tecnología para las baterías es el que tenemos. Hay estudios para usar baterías basadas en polímeros de alternativos prometedores, pero aun pasaran unos años posiblemente en ver la luz, los prototipos que hay aunque poseen unas densidades de carga muy superiores son baterías que no tendrían ni 6 meses de vida útiles… con lo que no son una opción a día de hoy.

Dicho esto, el tema de las baterías actuales es sencillo, cuanto más grande sea la batería, más duración. Eso por supuesto de cara a la batería en sí, el tiempo que un teléfono pueda mantenerse encendido dependerá no solo del tamaño de la batería, sino de los componentes, el uso, optimizaciones… y mil cosas más.

En el caso del iPhone 5s/5c usan baterías similares y (supuestamente) tiempos de vida similares. Por supuesto las horas en conversación y espera que muestran los datos son poco fiables, dado que es el propio fabricante quien los da.

En el caso del Nexus 5, posee una batería de mayor tamaño,y pese al consumo ingente que debe de tener su pantalla, de nuevo si nos creemos los datos que nos da el fabricante, posee una duración mayor. A parte de esto, el Nexus 5 cuenta con capacidad nativa para permitir su carga por inducción, es decir, sin cables.

Por desgracia, estimar realmente que dispositivo posee un menor consumo o una batería de mayor duración es complicado. Si hacemos caso a los números oficiales decimos sin duda alguna que el Nexus 5, pero no creo que nadie simultaneamente cojas los 3 terminales con la batería cargada al máximo e inicie 3 conversaciones de voz simultaneas hasta agotar la batería. Dicho esto, no nos queda otra que fiarnos de los datos oficiales (poco fiables).

 

Conclusiones

Es evidente que en casi todos los aspectos técnicos el nuevo Nexus 5 de Google/LG supera con crece todos los aspectos del nuevo iPhone 5s, que ni decir ya del iPhone 5c. Pero si esto fuese insuficiente, para rematarlo todo, tenemos que el precio del Nexus 5 es prácticamente la mitad de lo que cuesta un solo iPhone 5s. Pagando la mitad, un usuario obtiene un hardware más potente, una pantalla de mayor calidad definición y tamaño, una cámara excepcional (aunque sin llegar a ser perfecta ni mucho menos), un dispositivo preparado para las últimas tecnologías tanto en comunicaciones como en sensores se refiere, y una gran calidad, eso sin contar con pequeños e interesantes extras. Las mayores crítica que puedo poner es sin duda alguna un mal ajuste en el software que gestionan los colores en la cámara, y personalmente me hubiese gustado verlo con 3 o 4 GB de RAM.

El iPhone 5s por otro lado, no es un terminal que podamos llamar de segunda categoría ni mucho menos. Posee un hardware sólido, pero a parte de un novedoso sensor de huellas dactilares no aporta ninguna novedad que lo pueda hacer… único. Querer hacer pasar un procesador de 64bits como algo necesario o maravilloso es para cualquiera que conozca un mínimo de arquitectura de computadores un chiste, lo cual no quiere decir que sea malo (como ya hemos dicho) un procesador de 64bits, eso no lo critico, lo que critico es el marketing barato que usan las empresas para hacer pasar algo novedoso como algo maravilloso, cuando no tiene absolutamente nada que ver una cosa con la otra. Mis mayores críticas son un precio extremadamente elevado para el hardware que posee, una pantalla muy pequeña para los tiempos que corre, un lector de huellas que solo sirve para desbloquear el teléfono y un procesador y memoria de clase media, cuando debería de ser un hardware del más alto nivel.

El iPhone 5c por otro lado es un misterio que dudo muchos puedan explicarlo. El iPhone 5c no es más que un iPhone 5 en su 90% con un precio absurdamente elevado. A este iPhone 5c si me atrevería llamarlo teléfono de segunda a día de hoy si vemos los terminales de alta gama que tenemos a día de hoy. Lo que me pregunto realmente es el sentido que Apple haya podido tener para sacar al mercado un terminal así, puesto que estoy convencido que ni ellos mismos podrían creerse que venderían muchos, como ya ha quedado demostrado en los últimos no números publicados. Lo único que se me ocurre sinceramente es que Apple misma esperase este fracaso, nadie puede tomarse en serio que una compañía llame a un terminal de 550€ como de bajo coste, ni siquiera Apple. Con esto en mente, querrían sencillamente sacar al mercado un iPhone de segunda para que sus propios clientes pudiesen comparar lo bueno o malo que es su otro terminal de 650€, a fin de cuenta quien va a gastarse 550€ en un terminal cuando por 100€ pueden comprarse el iPhone superior, es decir, persuadir a aquellos que quieren gastarse menos para que al final terminen gastándose más. Lo que está claro es que dudo mucho que Apple con su iPhone 5c pueda robar un solo cliente a la competencia, y difícilmente a sus propios fanboys

 

Sea como fuese, al margen de opiniones personales, hay números que son imposibles de refutar. Actualmente, Android copa el mercado con un 80%, mientras que el resto se lo reparten otras plataformas, y antes de que se diga que Android se venden muchos, solo Samsung es actualmente el mayor fabricante de terminales móviles, solo ellos venden casi el doble de terminales Galaxy S4 que Apple iPhone 5/iPhone 5s (cuando recordemos el precio es similar en ambos). Al margen de fanatismos y precios, parece que aunque poco a poco, el sentido común se impone. Esto no es así en todas partes del mundo, de echo en EEUU Apple aun ostenta un poder enorme, pero fuera de sus fronteras este “poder” cae cada día aun más.

Si el iPhone 5s/5c será un éxito o no, la respuesta está contestada desde hace tiempo, solo hay que mirar los últimos 3-4 años. Se venderán millones, habrá criticas por un lado y por otro, Apple anunciará enormes ingresos gracias a los márgenes de beneficio tan enormes que tiene gracias al sobreprecio de sus terminales, y aun cuando eso pase, sus acciones ese día bajaran de golpe unos puntos porque los inversores no estarán de acuerdo.

De cara al Nexus 5 es más complicado saberlo. El Nexus 4 fue todo un éxito de ventas, tanto es así que LG mejoró y en mucho sus previsiones económicas gracias fundamentalmente a esto. Por otro lado el sello “nexus” aun no está demasiado bien recibido por muchos, que ven que un dispositivo de 350€ no puede ser para nada tan bueno o competitivo puesto que posee un precio más bien de gama media. Personalmente creo que lo único que Google tendría que replantearse sería intentar obligar a dar un mejor soporte a los fabricantes, que estos extendiesen su soporte de actualizaciones mucho más allá de los 18 meses que parece que tienen “pactado” entre unos y otros. Aun así, gracias a Google Play Services y a la iniciativa de Google de ir sacando de su Android sus propias aplicaciones (Drive, G+, Hangout, TTS, Maps, Calendario…), Google casi ha eliminado la famosa fragmentación que tanto se ha criticado a Google. Paradógicamente hoy, es más factible instalar una aplicación actualizada a un terminal viejo que cuente por ejemplo con Android 2.2/2.3 que hacerlo a un iPhone viejo con los mismos años de antiguedad.

 

Y ahora sí, creo que por hoy ha sido todo. Un saludo amigos y hasta la próxima.

La cadena de texto “de la muerte” de iOS y OSX: سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ

Share on Google+Share on FacebookTweet about this on Twitter

Por desgracia no he tenido tiempo antes para hablar sobre la ya famosa “cadena de la muerte” que afecta a los productos de Apple, así que aprovecho para dedicarle unas cuantas letras a ello, puesto creo sin duda alguna que merece la pena por lo absurdo del caso. Pero antes que nada hagamos un poco de recapitulación para aquellos que no saben nada de ello.

¿Algún usuario de iPhone ha observado últimamente que sus aplicaciones se cierran sin mucho sentido?

Hace ya más de 6 meses, expertos de seguridad reportaron a Apple un fallo crítico en sus sistemas operativos, tanto iOS como OSX, afectando en ambos casos incluso sus versiones más actuales. El fallo provoca un ataque de denegación de servicio (DoS) producido por el motor de renderizado de texto del sistema operativo ante una cadena unicode concreta: “سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ”. En términos profanos, cada vez que cualquier dispositivos de Apple (iPhone, iPod Touch, OSX…) tiene que renderizar (dibujar/interpretar) en pantalla dicha cadena de texto (pues usa el motor de texto del OS), la aplicación que esté en primer plano que esté accediendo a dicho texto se cerrará. Si mandamos un WhatsApp con dicha cadena, el usuario de iOS no podrá abrir WhatsApp (por poner un ejemplo sencillo)

En primer lugar, encontrar un fallo en cualquier aplicación que pueda producir un DoS en ella, no es algo demasiado extraño. Encontrar un fallo en un OS que pueda producir un DoS en él es algo que suele ser mas extraño pero todos los años solemos tener unos cuantos. Lo que realmente hace peculiar este fallo (y de ahí su gran importancia) es el método para “dispararlo”, puesto que tan solo es necesario una sencilla cadena de texto unicode que cualquiera puede enviar, copiar/pegar… o hacer el uso que sea de ella. No es necesario dispararlo por medio de un exploit complejo, no es necesario un conocimiento avanzado informático, no es necesario ser un experto… cualquier persona puede producirlo en un dispositivo objetivo, sencillamente haciendo llegar al objetivo dicha cadena de texto. Tan simple como eso.

En segundo lugar, otra cosa que hace de este fallo crítico en los productos de Apple algo tan severo, es la inacción por parte de Apple (como de costumbre) ante un fallo de seguridad o de cualquier otra índole en su software y sistema operativo. El error fue reportado hace más de 6 meses, 6 meses en los que cualquiera ha podido estar explotando dicha vulnerabilidad a su antojo. Pero aun peor que todo ello, es que después de que hace una semana saltara en todos los medios de noticias, Apple sigue sin hacer absolutamente nada, siendo afectados todas las versiones de iOS (exceptuando la beta de iOS 7) y prácticamente todas las versiones de OSX.

Para cualquier usuario de iOS (y mayoría de OSX) no pueden hacer sencillamente nada. Si el texto es puesto en cualquier sitio y sus dispositivos lo reciben, la aplicación que lo muestre en pantalla se cerrará sin remedio alguno. Esto es un problema, porque incluso el simple echo de escribir un artículo con ello, provocará que a los usuarios de iOS/OSX se les cierre el navegador web si abren mi blog. Para tener constancia de la gravedad de ello, voy a exponer unos sencillos ejemplos y el efecto que tendría en los dispositivos de Apple. Otro gran problema de todos los ejemplos que veamos, es que el usuario de Apple ni siquiera será consciente de que ha pasado o porqué sus aplicaciones no funcionan correctamente.

-En una página web

El navegador del dispositivo se cerrará cada vez que se intente acceder a dicha web, puesto que la cadena de texto hará por mostrarse en él. La única solución pasa por no acceder a dichas webs, lo cual es complicado, cualquier webmaster podría poner la cadena de texto en cualquier parte de su web/blog/foro… En este caso el ataque sería indiscriminado, no iría dirigido concretamente a nadie.

-En un correo electrónico

En el caso sencillo, bastaría incluir la cadena de texto en el cuerpo de cualquier correo electrónico dirigido a cualquier usuario de Apple. Este al abrir dicho corro provocará que el gestor de correo electrónico o el navegador web (en caso de acceso por web) se cierre.

Un caso más maligno de este sería usar dicha cadena de texto como asunto y no como cuerpo de mensaje. En este caso, dado que los gestores de correo y los webMail tienen a mostrar directamente el asunto del mensaje SIN NECESIDAD de abrir el correo, sería suficiente de nuevo para provocar el cierre del navegador web o del gestor de correo.

Usado de forma “maligna”, cualquier usuario de forma muy muy sencilla podría dejar inutilizable de un modo efectivo el gestor de correo de los usuarios de iOS o de OSX (puesto que por lo general el asunto se muestra directamente lo cual provocaría el cierre de la aplicación), y de forma menos agresiva también el navegador cuando se acceda por webMail

En este caso, tan solo sería necesario conocer el correo electrónico del usuario al que dirigirse.

-Facebook, Twitter, Google+…

Independientemente de si se accede a estas aplicaciones desde una aplicación móvil o desde el navegador, parece evidente pensar que pasaría si se publicase en las redes sociales dicha cadena de texto, y el efecto que tendría a todos los usuarios de Apple. Este pensamiento no son pocos los que lo han tenido… y muchos los que lo han hecho. Así pues, son muchos los que han twitteado el mensaje, haciendo que a los usuarios de Apple les fallase tanto la aplicación como e navegador web al intentar visualizar dichos Twitts.

En caso de Facebook, estos bloquearon prudentemente la posibilidad de poder escribir dicha cadena de texto de forma directa, pero existen multitud de formas de evadir este sistema, como por ejemplo estableciendo manualmente como ubicación de la publicación la cadena de texto, pero las opciones son múltiples. La cuestión siempre es la misma, cuanto más ingenioso se sea a la hora de exponer la cadena de texto…

En este caso, se podría usar las redes sociales sin tener un objetivo concreto, o por supuesto bastaría con poder enviar un mensaje o publicar lo que fuese en el perfil del usuario.

-HangOut, SMS, WhatsApps…

A nadie se le escaparía tener en cuenta la mensajería instantánea y los SMS. En estos casos posiblemente el vector de ataque sería mucho peor.

En el caso de los SMS el daño a provocar es evidente, tan solo basta con mandar un SMS a cualquier iPhone para bloquear de forma sencilla la aplicación iMessage del dispositivo. Si la aplicación realiza un pequeño preview del texto maligno, será suficiente para provocar el cierre de la aplicación, y de volver a intentarlo el resultado sería el mismo. En este caso tan solo sería necesario tener el número de teléfono de la persona a afectar.

En el caso de WhatsApp las opciones son múltiples. En primer lugar sería suficiente con mandar un WhatsApp a cualquier dispositivo. Esto provocaría que al abrirse (o incluso en la previsualización) fuese suficiente para provocar la inutilización de WhatsApps. El usuario se vería forzado a tener que reinstalar WhatsApps en algunos casos. Otra opción de WhatsApps sería establecer el texto como mensaje de estado, un sistema pasivo que provocaría que cualquier usuario que nos tuviese en su lista de contactos (usuario de iPhone) no pudiese acceder a su lista de contactos, puesto que cargaría nuestro estado y de este modo WhatsApp se cerraría. Como tercera opción en WhatsApp, y la más efectiva, pasaría por crear un grupo de WhatsApp y establecer en su nombre el texto dañino. Dado que los grupos se regrean aun cuando WhatsApp se reinstala, a cualquier atacante le bastaría el número de telefono de cualquier usuario con iPhone para crear un grupo de WhatsApp, establecer el nombre a la cadena de texto dañina y añadir a dicho miembro al grupo. Dado que el nombre del grupo es visible en la lista misma de WhatsApp, el usuario de iPhone no podría abrir WhatsApp, y aun cuando reinstalase los grupos se recrearían igualmente, haciendo muy complicado evitarlo. De este modo se quedaría totalmente inutilizada la aplicación, se cerraría nada más abrirla constantemente.

En realidad, cualquier sistema de mensajería instantanea los efectos serían similares. La diferencia quizás radica en quien puede o no mandarnos mensajes. En el caso de los SMS por ejemplo, cualquiera con nuestro teléfono puede mandarnos uno. En caso de WHatsApp cualquiera con nuestro número puede hacerlo… esto hace de este fallo de Apple un problema en mayúsculas sin duda alguna.

 

Podríamos expandir la lista todo lo que quisiésemos. Desde establecer el SSID de nuestra red WIFI al texto en cuestión y ver que le ocurre a los iPhone cercanos, códigos QR, firmas… en realidad cualquier sitio donde podamos escribir un texto en unicode y que vaya a ser leído por el usuario en sus pantallas.

Lo peor de todo ello como ya he dicho, es que al contrario de otros fallos de seguridad, en este caso puede dispararse el error sencillamente con una cadena de texto, lo cual no solo hace que el vector de ataque sea increiblemente grande, sino que cualquiera puede explotar esta vulnerabilidad. Si a eso le sumamos que Apple continúa sin solucionar este problema que se conoce desde hace más de 6 meses…

Cada cual que haga sus propias conclusiones… o pruenas

Un saludo amigos, y ser buenos… no seamos demasiado… “traviesos” con los fanboys 🙂

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Creative Commons License
Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.