E-Mail: 2 en 1 en android

Aupa,

Ya que comentas lo del miedo de Windows a Android, hay una cosa que me gustaría comentarte.

El gran acierto de Windows 10 es unificar tablets y PC, me encantan los 2 en 1, aunque el ecosistema de apps UWP aun es muy escaso, pero con un buen ecosistema sería la leche.

Se rumorea que apple esta fusionando iOS y OSX, y lo suyo sería que Android hiciese lo mismo.

De forma extraoficial ya es posible, usando GNURoot Debian he conseguido migrar una app de esccritorio hecha con Qt a Android:

https://github.com/corbinlc/GNURootDebian

Yo creo que la proxima versión de Android traera algo así de serie. ¿Que opinas ? Fijate en ese repositorio, abandonado de forma abrupta, eso es que Google ha contratado al tio para integrarlo en Android.

Saludos,

Jorge

En primer lugar no creo que Apple integre OS X e iOS como un SO unificado o al menos veamos algo como el UWP de Microsoft en Windows, es decir… Una API común de aplicaciones. En el caso de Apple pese a que el SO es el mismo las APIs generales no son las mismas, aún hay una serie de diferencias. La primera de ellas es que en iOS no esta Carbon… ¿Y que es Carbon? Es una API que Apple creo en su día para facilitar la transición de Mac OS a Mac OS X, no utiliza toda la funcionalidad de Mac OS X pero fue clave para el salto de un SO a otro en el entorno Mac ya que Apple hizo borrón y cuenta nueva al pasar de esto…

macos9folders

a esto…

leopard

La API principal por otro lado es CocoaTouch y no Cocoa… ¿Que diferencias hay? Cocoa utiliza el Framework AppKit… ¿Y que es App Kit? Dejemos que la propia Apple nos lo defina:

Captura de pantalla 2016-05-06 a las 11.31.22

Es decir, el entorno gráfico utilizado por las aplicaciones en Cocoa para OS X utiliza AppKit pero esto no ocurre en iOS que utiliza el Ui Kit.

Captura de pantalla 2016-05-06 a las 11.33.39

Es decir, para acceder a ciertas funciones y servicios del SO en Mac OS X e iOS las cosas no se hacen de la misma manera, no hay unificación en el lado del software en forma de una API general, es decir, una aplicación bajo Cocoa no funcionara en iOS de forma directa porque hay una serie de diferencias importantes.

Captura de pantalla 2016-05-06 a las 11.36.33 Captura de pantalla 2016-05-06 a las 11.36.52

Captura de pantalla 2016-05-06 a las 11.37.45

Hay muchas más diferencias pero son lo suficientemente importantes como para que pese a que el SO sea el mismo hayan discrepancias, las cuales en el fondo son las mismas discrepancias que existen entre WIN32 y el UWP pero con una diferencia en el planteamiento de Microsoft que se ve en la siguiente diapositiva de Microsoft:

applewrong

Apple podría coger y unificar bajo un mismo SO tanto CocoaTouch como Cocoa tranquilamente, las bases que hay debajo son las mismas en ambos sistemas operativos, es la API superior que se utiliza para realizar las aplicaciones la que cambia, aunque también ciertos elementos de la capas inferiores como por ejemplo el uso de OpenGL ES en iOS en vez del OpenGL estándar.

Claro esta que las cosas han cambiado mucho y ahora nos encontramos en el mercado con esto:

theonetrueipad1_2040.0.0

Y la gente esta recordando el Surface de Microsoft pero hay una diferencia fundamental con el Surface que es el SO y su entorno, es decir… No hay un equivalente real al Surface en Apple porque esta se niega a que exista una unificación y porque entre otra cosas esto significaría otra transición como la de PowerPC a Intel y no tiene sentido porque los chips ARM pese a tener un excelente rendimiento en dispositivos embebidos no son tan buenos en gama media de escritorio. Es decir, si los comparas con un Atom y similares están a la par pero frente a una CPU más seria no lo están. Lo normal sería pensar en una fusión de ambos SOs o una API universal pero pienso que la mala situación del UWP de Microsoft es lo que tira atrás a Apple, pensándolo bien la situación actual es simple de explicar, no tiene sentido convertir las aplicaciones complejas Win32 a UWP cuando Win32 sigue soportado por el SO y el hecho de eliminarlo por parte de Microsoft supondría el suicidio.

En todo caso después de esta larga introducción lo mejor es hablar de Android.

android-logo-239-264

Android no tiene tradición en los ordenadores de escritorio, esto significa que los mismos problemas que tiene Microsoft para entrar en el mercado móvil los tiene Google para entrar en el mercado de escritorio. Es decir, Microsoft tiene una API de escritorio consolidada con una enorme influencia, Google tiene una API de móvil consolidada con una enorme influencia y ambas trabajan en dos entornos distintos… ¿Pero que ocurre si ahora Android decidiese dar el salto a escritorio? No tienen legado y no tienen base de software de la que agarrarse. Antes he comentado lo de Carbon por un tema, el legado del Mac OS clásico fue lo que facilito la transición, sin legado no tienes clientes fijos de los que agarrarte y el legado de Windows es lo suficientemente grande y poderoso como para que Microsoft pese Android no se preocupe en escritorio.

Pero hay un tema más oscuro que es el gubernamental y con esto acabo, en estos momentos el candidato del Establishment estadounidense es la Clintonta, una tipa de baja moral con ínfulas de grandeza que sería capaz de tener sexo con Satanas si eso le diese la presidencia. La directiva de Google anda muy cerca de la Clintonta y lo que ha hecho Microsoft con tal de mantener sus contratos es apoyar también a Hillary para que la administración federal estadounidense no se pase a Android y acabe por joder al mejor cliente que tiene Microsoft en el mundo, el Estado Federal de los EEUU

Anuncios