Pensaba que ya lo había dicho todo sobre el cacharrejo de los cojones, pero parece ser que no es así. Me falta un aspecto (bueno, realmente dos, y el segundo seguro que da para una nueva entrada, pero más adelante), y es el de desarrollar para dicho aparato.
Tengo un iMAC de 24 pulgadas (de los de antes, los que no tienen el problema de rendimiento ni de calor), y un iPod. Y ahora un iPad con el que estoy contentísimo, y de hecho mi Tablet está criando malvas en su funda (de momento).
Cuando me compré el iMAC me dio por mirar cómo se desarrolla para él, y me instalé QT y el SDK oficial. También compré dos libros de desarrollo, pero al final el tema no me convenció nada. QT es una porquería con más bugs que funcionalidades, y el Objetive-C ese es una purita mierda de lenguaje (IMHO). Si decimos que el C o el C++ es críptico no te digo ya el Objetive-C. Para mi es incluso antinatural, más antinatural incluso que el VB6. Sí, ya sé que soy un bicho raro egocéntrico, monomaníaco, con mala hostia y lo que es peor, las suelto conforme las pienso. Lo siento por vosotros, pero es como dijo Nietschze, el que esté mal visto y sea políticamente incorrecto no quita que no sea cierto (no es eso lo que dijo, eso lo digo yo, yo me refiero a lo otro que dijo). Hala, ya podéis crucificarme a gusto.
Así que rápidamente perdí el interés y de hecho el iMAC se pasa grandes temporadas sin otra función que ocupar sitio en mi sala de estar, o como mucho, actualizando mi iPod de forma más o menos mensual. A veces no, a veces me tiro todo un fin de semana con él, como el pasado a causa del iPad, pero son las menos.
Y ahora ha venido el iPad y de nuevo me ha entrado el gusanillo del desarrollo, y esta vez algo justificado por la carencia de buenas aplicaciones para lectura de libros-e. El que haya leído mis entradas anteriores habrá visto que he calificado como positivas varias revisiones de programas, pero aun así adolecen de ciertas carencias ya que no es lo mismo leer en un iPod que en un iPad por el tema del tamaño de la pantalla.
Es decir, allí donde una lectura a una columna y sin márgenes tiene sentido, en el iPad no porque la pantalla es demasiado ancha. El único que se libra de ellos es el iBooks en modo apaisado, pero este tiene otras cosas que no me gustan, como el enorme desperdicio de pantalla.
Por lo tanto me decidí a hacer algo para el aparato, y encima darme la posibilidad de ganarme una pelillas (que no es precisamente el fin de todo esto)… Primero me bajé todos los documentos sobre desarrollo para el iPad y, como vi que hacían referencia a los del iPhone/iPod, también me los bajé. Pero apenas empecé a leer me surgió una duda: ¿cómo pruebo los programas? ¿Cómo los subo a la tienda? ¿Cómo está el tema de los impuestos y ganancias?
Pues me puse a mirar a ver cómo se hacía y, adelantando acontecimientos, se me quitaron las ganas de golpe y no me han vuelto ni creo que lo hagan. Os comento el procedimiento.
Te tienes que dar de alta como jodío developer en Apple (eso lo tengo hecho desde hace tiempo), luego te tienes que dar de alta en otro sitio también de Apple y pagar una cuota de 99$ anuales. Luego te das de alta en la Hacienda americana, y finalmente ya puedes subir tu aplicación para que sea evaluada y ver si la aceptan o no.
El proceso parece sencillo, pero hay que hacer una buena cantidad de papelorios y trámites bastante oscuros, y no me ha quedado claro si, aparte de los 99$ anuales, tienes que pagar otros 99$ con cada aplicación diferente que subas, ya sea gratuita o no. Además, tienes que instalar varios certificados digitales en tu xCode (la herramienta de desarrollo oficial), y como pierdas o te equivoques en algo tienes que volver a empezar de nuevo.
Pero ahí no termina la cosa, para probar tus aplicaciones en tus aparatos de pruebas (al parecer hasta 5), también tienes que instalar otra espuerta de certificados en el ordenador de desarrollo… y en los aparatos, y si he leído bien, dichos aparatos quedan inservibles para uso normal y no se pueden volver hacia atrás.
En resumen: ¡Y una mieeeeerda pinchada en un palo voy a desarrollar para el iPad!
Viéndolo un poco más frío… ahora empiezo a entrever el control totalitarista que Apple hace de los desarrolladores. Básicamente, que les den.
Además, me he puesto en contacto con los autores de los programas que me gustan y los que no tenían ya la idea de la multicolumna y los márgenes en la cabeza, han acogido muy bien la sugerencia.
***
No obstante, la idea que tengo no creo que sea tan mala y, antes de explicarla, voy a exponeros los pasos que he dado para implementarla. La idea es vieja, casi desde la época en que me compré mi iLiad, pero Linux siempre me ha tirado para atrás porque los pocos proyectos que he hecho con él han sido más que hijos, abortos duramente paridos. No quiero entrar en detalles ni en guerras sobre la porquería que es desarrollar para Linux, pero ahí está.
Por lo tanto, hace un par de meses me decidí. Elegí C# porque en principio construir algo para Windows Mobile/Windows CE/Windows compartiría casi el mismo fuente, sobre todo en las diferentes versiones del Mobile/CE. En C++ y MFC (o sin MFC), hay que crear diferentes diálogos y diferente código para cada versión y tamaño de pantalla, por lo que vi que la opción .NET iba a ser la mejor, y mejoró cuando me enteré de que el nuevo Windows Phone eliminaba el C++ del juego (lo que considero un error, y si no, tiempo al tiempo).
Así que ni corto ni perezoso me puse manos a la obra con el front-end, porque era el elemento más sensible a la plataforma elegida, y ciertamente .NET es la mejor opción para contender con tanto tamaño de pantalla en los sistemas embebidos. Para poder empezar hice un pequeño esqueleto del back-end para que suministrara al front-end los datos de la configuración, así como especificar formalmente dichos datos. Y me puse al tajo. Diseñé las pantallas de configuración. Las construí con Windows Forms. Y las probé.
Juas, qué risa, María Luisa. ¡No funcionaba bien nada! ¡El .NET Compact, pese a ir por el SP2, está no sólo completamente lleno de bugs, sino que tiene regresiones de los más curioso!
El hecho está en que debido a esos bugs no pude hacer casi nada, y la idea se enfrió y fría está. La semana que viene o la siguiente (está programada desde hace más de un mes), saldrá una entrada en mi blog de Geeks sobre dichos problemas, y ahí veréis mi frustración con el tema. Evidentemente el .NET Compact funciona bien mientras no te salgas de lo políticamente correcto por decirlo suavemente, pero en cuanto te pones con cosas serias falla estrepitosamente. (Si quieres leerlo de otra forma, en cuanto te sales de lo que Microsoft piensa que el programador de nivel medio –por no decir bajo, juego de palabras mediante-, va a hacer, nada funciona bien).
No es la primera vez que los bugs en una plataforma me echan para atrás en un proyecto personal, como en su momento me pasó con QT y con C++ Builder, y de hecho tengo cosas personales a medio acabar porque no consiento en perder el tiempo rodeando cosas que deberían funcionar y no lo hacen. No es mi tarea, es la del fabricante del producto, y más si he pagado religiosamente. Para problemas que no tengo más cojones que solventar ya tengo los de los proyectos de mi curro.
Bueno, tras esta diatriba os voy a explicar mi idea.
***
Como ya he dicho, llevo varios meses en la cabeza hacer una especie de visor universal multiplataforma de libros-e. Sí, ya sé que son palabras grandilocuentes –demasiado-, pero esa fue la idea. Básicamente el concepto es tener un solo back-end (al menos en código fuente) y tantos front-end como sean necesarios para cada una de las plataformas.
La idea del backend es la de un motor básico al que se le van anexando procesadores de formatos. Es decir, se trataría de crear una infraestructura genérica que mirara en algún sitio una serie de extensiones que serían las que realmente ofrecieran el trabajo al front-end.
Por ejemplo, en la plataforma Windows tendríamos un motor principal que buscaría en una carpeta varias DLL, cada una para procesar un formato de libro. Cada una de esas DLL ofrecería un interfaz público común que suministraría el flujo de texto/gráficos y anotaciones guardadas.
El flujo de texto sería una versión simplificada de HTML en Unicode, de modo que, independientemente del formato del libro, el motor back-end recibiría texto html satanizado. Ante una imagen, el html contendría una referencia a la citada, que sería obtenida como bitmap por otra función. Las anotaciones irían por otro flujo paralelo haciendo referencia a una posición del flujo html original. Cada DLL tendría, al menos tres funciones diferentes: flujo de texto, imágenes, y flujo de comentarios en relación al texto.
También recibirían un nuevo flujo de anotaciones sobre el html, que deberían guardar de alguna forma paralela al documento. De todos modos, el tema de las anotaciones también podría ir en la parte back-end y ser éste el que las guardara. Quizás así se ahorrara duplicar el mismo código en cada DLL, pero entonces la ventaja de guardar cada anotado conforme a su estándar de anotado se perdería.
El back-end se encargaría entonces de centralizar todas las DLL, de inicializar la correcta frente al tipo de libro abierto y de almacenar/recuperar la posición actual del libro en relación al html satanizado. Para evitar tener que abrir y suministrar el texto html por completo al back-end, este se ofrecería en gaps de 64KB u otro valor configurable.
Un problema potencial es el retardo en que la DLL abra el libro, lo empiece a recorrer y llegue al lugar indicado, por lo que posiblemente el salvado de la posición debería ir tanto en el back-end como en la DLL, que podría optimizar de alguna forma la recuperación (por ejemplo, en ePub, qué sub-fichero html abrir).
Evidentemente si se trabaja con flujos cortados, el back-end o la DLL debería guardar también el nivel de tags con el que inicia el flujo cortado.
Luego, el front-end sería el encargado de tomar ese flujo html y componer la página en un formato bitmap compatible con el equipo y su pantalla, así como de cachear siguientes pantallas. También debería trastear con las anotaciones y ponerlas en el lugar adecuado. Las citas a pie de página originales del libro se deberían suministrar en el propio flujo html y el encargado de integrarlas sería la DLL pertinente.
Las anotaciones podrían ser de tres tipos: marca página que realmente sería marca punto de lectura, subrayado sobre el texto y nota de texto. El pintarrajeado se presenta difícil por los distintos tipos de pantalla, aunque se podría tomar la nube de puntos que lo conformen con un origen relativo y una escala en relación al tamaño de la pantalla y luego escalarla en otros tamaños.
Junto a la forma de mostrar las opciones, que serían pasadas al back-end para ser guardadas en disco, esas serían las tareas del front-end. O quizás se podría poner una tercera capa encargada de construir el bitmap de la imagen a partir de los flujos suministrados por el back-end y de las opciones gráficas (tamaño de pantalla, fuente, interlineado, márgenes, columnas, etc) ofrecidas por el front-end, aligerando a éste. Así podríamos tener un mismo mid-end para plataformas con bitmaps compatibles entre sí.
Excepto las especificaciones para los datos de configuración a guardar, que están por escrito en código C#, las demás están terminadas pero en mi cabeza (tampoco es tan complicado), y no creo que las ponga con más detalle en ningún otro sitio.
