Windows Phone y las petisoperías

Hay que joderse, que dijo aquél. Este podría ser el resumen de esta entrada. Ahora mismo veréis por qué.

***

Estoy empezando a jugar de forma más o menos seria con Windows Phone. Ya cuando salió, el no poder ejecutar código nativo básicamente me hizo pensar que Microsoft había perdido el tiempo y que WP iba a ser un gran y nuevo fracaso de la compañía que había perdido el norte, el sur, el este y el oeste…

Pasa el tiempo y pese a todos los intentos de MS, WP no levanta cabeza. Ni cuota de mercado ni aplicaciones, comparándolo con Android e iOS, que crecieron mucho más rápido.

Ahora sé algunas razones, imposibilidad de usar C++ incluída.

***

Windows Phone 7.0 no tiene sockets. Toma ya. Increíble. Para los legos: no hay posibilidad de crear ningún tipo de aplicación de chat, ni de comunicación remota a servidores ni nada parecido. Todo hay que hacerlo mediante HTTP, que no conserva el estado y necesita sobredimensionar el lado servidor frente al cliente…

Whidows Phone 7.5 tiene sockets… de aquella manera. Cuando la aplicación pasa a background el socket se cierra, con lo que pierdes la persistencia en la comunicación. Aquí lo puedes solucionar mediante técnicas Push (que todavía no he visto e ignoro las limitaciones y ventajas que puedan tener). Pero de momento, aplicaciones verticales que requieran una conexión permanente tampoco están permitidas.

***

Ahora llega la última versión, con dispostivos de 256 MB de memoria… Y la vuelven a cagar. Dadas las limitaciones de los mismos, dejan de funcionar las tareas periódicas y las intensivas… Y te dicen que cuando lances la aplicación mires en qué dispositivos estás ejecutando y uses secuencias if/else para cambiar el comportamiento.

En primer lugar eso es una soberana imbecilidad como una casa. ¿Tienes que codificar las cosas dos veces? Pues no, tendrás que hacerlo todo con la limitación predicha, porque si lo puedes hacer sin esos elementos, es una soberana gilipollez repetir el código. El problema vendrá cuando sin eso no puedas hacerlo.

En segundo lugar, mientras los demás fabricantes implementan mejoras y optimizan el código de sus sistemas operativos, Microsoft hace lo contrario. Apple pasa de dispositvos de 256 MB de RAM a 512 y luego a 1024. Microsof pasa de 512 a 256, llevándose cosas de en medio.

***

Recuerdo la presentación de Windows Phone: que si sólo .NET, que si sólo procesadores multicore, que si sólo dispositivos de gama alta… Al final tienen que pasar por el aro, pero en lugar de abrir el Windows CE interno al lenguaje C y/o C++ y quitar la mierda del .NET, que seguro consume 40 de los 60 MB de la huella de memoria de cada proceso, van y quitan prestaciones… porque lo de las tareas asíncronas es sólo una de tantas limitaciones impuestas, que podéis leer en la entrada que os enlazo más arriba.

***

Resumendo, que van de mal en peor. RFOG dixit.

14 comentarios en “Windows Phone y las petisoperías”

  1. No conozco nada de desarrollo de movilidad (Android, IOS, WP7), pero por los posts de geeks sobre WP7 (J.Yeray, J.Serrano, etc) sería un debate interesante y aclararía mucho a los profanos. Saludos.

  2. Creo que no es bueno escribir cuando se está tan caliente. Voy a intentar justificar, que no defender, los puntos por los que te quejas.
    No dejan atacar directamente con C/C++ y solo lo dejan con .Net porque ahora los móviles funcionan sobre arquitectura ARM, pero eso no quita que mañana Intel cree un micro de bajo consumo. Además he odio rumores de que Windows Phone 8 tendrá el mismo núcleo que su hermano mayor, así que mejor no hagas nada que te puedas arrepentir y luego no funcione en la próxima versión.

    ¿Por qué han sacado una versión de 256Mb? Porque quieren vender móviles más baratos. No nos equivoquemos, Windows Phone no es una estación de trabajo, es un juguete caro.

    ¿Por qué pone tantas limitaciones en tareas en segundo plano? Pues porque los micros ARM gastan poco, porque trabajan poco. Si se les mete un poco de caña se calientan y se comen la batería. Así que lo que hacen es ir encolando tareas y ejecutarlas todas de una vez, que por lo visto es más eficinte.

    Windows Phone no se come una mierda, por la mala prensan que tiene Microsoft. Porque todo el mundo sabe que Windows es una mierda (aunque nadie sabe porque). Llegó tarde al tren y ahora la mayoría de los usuarios quieren un iPhone que es más pijo o un Android que es más friky y tiene tropecientos mil aplicaciones. Microsoft necesita un lavado de cara, aunque le cueste una millonada en publicidad.

  3. @andrechi
    Algunas reconsideraciones… 🙂
    >No dejan atacar directamente con C/C++ y solo lo dejan con .Net porque ahora los móviles funcionan sobre arquitectura ARM, pero eso no quita que mañana Intel cree un micro de bajo consumo

    No veo que importe demasiado, técnicamente se puede solventar. Sin ir más lejos WindowsCE soporta varios tipos de hard y admite desarrollos en C.
    Para mi el tema no es ese, para mi es porque MS sabe de la importancia de contar con una comunidad de desarrolladores importante. Y la de .NET lo es 🙂
    Sobre el tema del footprint de .NET, pues ni idea, pero a Android le ocurre algo parecido con Dalvik. Seguro que está muy optimizado todo pero pesa. Luego pillas un iPhone, con una app nativa hecha en Objective-C y se nota diferencia.

    Del resto no opinaré, salvo una cosa: ojo con los teléfonos “de baja gama”. Hay mucha gente que dice que Android es una mierda porque lo ha probado con el Wildfire. Luego les das un Galaxy S2 y se les cae la baba. La gente no distingue entre terminales, para ellos todo es Android. Alguien que pruebe Android en un Wildfire es alguien que muy probablemente salte a iPhone cuando se pille su siguiente smartphone. O sea que, cuidado no le pase eso a WP con los dispositivos baratos. Y de todos modos hacer el salto a dispositivos “de baja gama” capando ciertas cosas y haciendo que eso “se lo coman los desarrolladores” no lo termino de ver del todo claro.

    Un saludo!

  4. @andrechi

    Como ya te ha respondido Eduard, el que sean ARM no es problema alguno para escribir programas en C y C++, de hecho Microsoft cuenta con unos compiladores para ARM increíblemente buenos, que venían con las versiones de Windows CE, y de hecho tenía para MIPS, SHS y otras arquitecturas.

    Y para Windows 8 también habrá uno para ARM, aunque todavía no lo han puesto al público, seguro que soportará todo el C++11 como la versión de PC.

    Tu tesis sobre la poca potencia de los micros ARM no se sostiene, porque tanto los móviles con Android como lo de Apple ejecutan sobre ARM sin ningún problema, y de hecho son los mismos micros (al menos WP7 y Android), y en Android las tareas en segundo plano funcionan perfectas (te puedes dejar el navegador cargándose, irte a otra cosa y cuando vuelvas ya se ha cargado la página)…

    Microsoft ha perdido el norte, porque no se trata de campañas de publicidad (y menos aún la del premio ese que negaron cuando perdieron con un Android más rápido), sino de fomentar la base de programadores para que hagan aplicaciones chulas y potentes, y si el sistema impide eso, no se harán programas útiles porque simplemente no se podrá o el coste sería excesivo, y los programadores se irán a otro sitio.

    PS: Por cierto yo sí que sé por qué Windows es una mierda: lo es cuando se ejecuta en hardware que lo es o usa drivers que lo son. Desde que MS exigió una serie de requisitos para certificar y firmar los drivers, los fallos serios de Windows se acabaron. De hecho, si te compras un equipo de los listados en la WHQL (que por algún lado andará) no vas a tener ni un solo problema. Y por las aplicaciones, claro, que meten mierda y más mierda.

  5. Rafa tio eres un crack. Ademas del excelente post y los comentarios, la frase “Por cierto yo sí que sé por qué Windows es una mierda” me ha hecho terminar la semana con una :)).

    Saludos

  6. Bruno, no veas cómo me toca los cojones el tema de que Windows es una mierda cuando la mierda suele estar entre la silla y el teclado (y no lo digo por @andrechi ni mucho menos)…

    Las BSOD en windows que he tenido yo las puedo contar con los brazos de un tetrapléjico…

  7. Hola tocayo.

    Me parece un post interesante aunque estoy en contra de lo que dices, me explico.

    Cuando afirmas que MSFT no alcanza una cuota de mercado tan rápido como iPhone y Android, debemos de tener en cuenta que es precisamente por eso, porque están ellos dos, iPhone en su momento no tubo rival, Android se come la gama y gratuita de dispositivos. Las condiciones de partida no son las mismas, obviamente la culpa de eso no la tiene nadie mas que MSFT.

    Una de las cosas que muchos consideran es que con el tiempo que han tenido y la experiencia de los rivales, esta vez no hayan hecho lo que normalmente se atribuye a MSFT, copiar. Si bien es cierto que han sacado un sistema totalmente innovador, que efectivamente tiene muchas, o muchísimas carencias de inicio. El tema de la programación nativa no creo que sea tan grave (al menos para mi), la limitación del uso de sockets pues bueno tampoco estaba disponible en otros sistemas al inicio (de ahí la queja de muchos en no copiar esta vez), y su utilización es limitada debido a la utilización de las aplicaciones en background como bien dices.

    El hecho de las limitaciones en los dispositivos de 256Mb creo que es un acierto, debido a la limitación de funcionalidad para que el sistema siga siendo un buen sistema en este tipo de dispositivos y no se arrastre, como pasa (y dice otro comentario mas arriba) con los dispositivos de gama baja en Android y los terminales antiguos de iPhone, que si, si, muy retro compatibles pero los iPhone 3Gs y quizás también los 4G se arrastran con el sistema iOS 5.

    No es codificar las cosas dos veces, simplemente es restar funcionalidad. Además esto hará que la expansión sea a partir de ahora mucho mas rápida (en teoría) al poder montar el sistema en dispositivos de gama muy baja y de precios muy asequibles para mercados asiáticos. Nunca he oído a nadie decir que Windows Phone iba a ser un SO elitista.

    A parte de todo esto, considerar .NET una mierda, en fin cada uno tiene sus opiniones muy respetables y este es tu blog faltaría mas, pero creo que cada vez la mejoría en la ejecución de código manejado por parte de MSFT es mas que considerable y bueno obviamente eso ayuda a que el proceso de desarrollo también sea mas rápido y productivo, vamos creo yo.

  8. Rafa: ese mismo es el problema. Por un lado, en su momento dijeron por activa y por pasiva que no iban a bajar los requisitos, y que tampoco eliminarían características para evitar la fragmentación.

    En segundo lado, sin .NET, teniendo cada aplicación 60M de memoria, si quitas los 40 del .NET, y teniendo en cuenta que un exe optimizado empieza con 1.5KB de huella de memoria en Windows CE, mira a ver si queda memoria para añadir lo que quieras…

    Por otro lado una cosa es ser más productivo y demás. En eso el .NET está bien, pero es en lo único en que lo está. C# es un aborto de lenguaje, y más con cada nueva versión que sacan, un lenguaje incoherente a más no poder y complejo (sí, complejo, y si no date una vuelta por el tema de los atributos y la reflexión). No permiten variables globales pero sí métodos extensores de una clase, pero permiten clases “selladas” de las cuales no se pueden heredar… Permiten constructores y clases estáticas pero la construcción de estas no está garantizada que sea la adecuada y en el orden adecuado, permiten interfaces pero no herencia múltiple, un mismo código fuente genera diferente funcionalidad (y fallos) según se compile con AnyCPU, x86 o x64, y si se compila en AnyCPU funcionará diferente (y fallará de forma diferente) en según qué arquitectura ejecutes…

  9. Sólo quería comentar algunas cosas sobre los defectos que atribuyes a C#.

    Según tú es un defecto que no tenga herencia múltiple y si admitan múltiples interfaces. En realidad muy pocos lenguajes permiten herencia múltiple, y por lo general está aceptado por casi todos los especialistas que produce más inconvenientes que ventajas. Eliminado el gran problemas que es la herencia múltiple de código, basta con aprovechas la única ventaja que aporta la herencia múltiple. Poder aplicar polimorfismo en varias direcciones. Y eso se consigue con la herencia múltiple de interfaces. Los diseñadores de C# han tomado la decisión correcta, desde mi punto de vista, y que casualmente coincide con la de la mayor parte de lenguajes.

    Lo mismo puedo decir de todo lo demás. ¿Que C# no admite variables globales? Obvio, es un lenguaje verdaderamente orientado a objetos, así es que no admite construcciones fuera de ellos. Sin embargo una variable static de una clase se puede utilizar de la misma forma que una variable global, con la ventaja de que para nombrarla es necesario especificar la clase a la que pertenece, lo que puede ayudar a reducir el acoplamiento.

    ¿Los atributos son un defecto? En todo caso serían un defecto de .NET, no de C#, puesto que todos los lenguajes en .NET deben tenerlos en cuenta. Desde mi punto de vista son la mejor forma de ampliar la información de los miembros de una clase. ¿Se te ocurre alguna alternativa? ¿La reflexión otro defecto? Cierto, debe ser mejor no poder hacerla. Alucino con algunos comentarios.

    Por cierto, sobre el tema central del artículo. ¿Así es que sería mejor que Windows Phone pudiese programarse en nativo? Al parecer sería mejor volver a los tiempos de fragmentación de Windows Mobile, en los que había que buscar la aplicación para el tipo de procesador de tu máquina. Sencillísimo para esa gran mayoría de usuarios que sólo quieren señalar con el dedo y utilizar. Eso sin valorar el inconveniente de que se limitaría la transición futura hacia otros procesadores.

    Y todo por apoyar un lenguaje, C++, que desde su nacimiento ya era un lenguaje obsoleto y pésimamente diseñado.

  10. @jcbadiola, en este blog puedes encontrar bastantes razonamientos sobre todo lo que comentas y por qué digo lo que digo… y la verdad, estoy ya cansado de defender y rebatir todo lo que se dice por ahí…

    Solo te digo una cosa: el AnyCPU del .NET es una mierda pinchada en un palo que, dependiendo de la arquitectura en que ejecutes un ensamblado, y de la versión del .NET, hará unas cosas u otras, e incluso fallará sin motivo aparente…

    Que una cosa es la teoría, y otra muy diferente la práctica y la implementación.

  11. Yo lo que se es que las aplicaciones Windows Phone se descargan desde el marketplace sin preocuparse del procesador de la máquina en la que se descargan. Eso por no entrar a valorar la inseguridad implícita en el desarrollo nativo, sin seguridad de tipos, en el que casi todo es posible.

  12. Hola Rafa,

    No suele entrar a comentar en los blogs pero dado que me has involucrado via twitter creo que es lógico que lo haga.

    No voy a entrar a valorar los comentarios para evitar generar más polémica, como ya hemos comentado la plataforma de Windows Phone es algo que evoluciona con cada versión y como en cualquier proyecto de software necesitas priorizar las funcionalidades.

    Yo te recomiendo que cualquier funcionalidad o mejora para la plataforma, al margen de lo que quieras escribir libremente en tu blog, la encauces a través del site que el equipo de producto ha habilitado para ello http://wpdev.uservoice.com/forums/110705-app-platform

    En el site verás que tanto sockets como soporte de C++ son funcionalidades solicitadas por más gente con un número de votos muy muy diferentes entre sí y respecto a otras funcionalidades.

    Un saludo

  13. José, gracias por aparece por aquí y por la URL de feedback, que desconocía por completo.

    Entiendo lo de las prioridades, pero también entiendo que hay cosas completamente incomprensibles. Me refiero a que si un móvil, cuyo propósito final es la comunicación, no tiene sockets o estos son prácticamente inusables debido a su arquitectura (y para más inri que esos sockets estén disponibles en la plataforma interna, Windows CE), el que tenga todavía peores carencias hacen que no termine de despegar… y si encima se le limitan y recortan las prestaciones, os aseguro un nuevo fracaso garantizado.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *