Un gran paso en el desarrollo de la próxima gran versión de Mac OS X ha sido el anuncio por parte de Apple del cierre en el desarrollo de las API (Interface de programación de aplicaciones) de Snow Leopard.
Con esto, los desarrolladores se enfocarán en asegurar compatibilidad entre sus aplicaciones y el próximo sistema operativo. Ahora solo faltará pulir los demás detalles que rodean al desarrollo de Snow Leopard.
Finalmente, se espera que Apple lance o por lo menos presente una versión final de Snow Leopard en la World Wide Developers Conference, evento que se llevará a cabo el próximo mes de junio.
Eso que veis en el vídeo es una API que Google ofrece para embeber el asombroso Google Earth en una página web.
¿Problema? Que el plug-in necesario para tirar con esto en el explorador de Internet sólo estaba disponible para Windows. Pero ahora, lo acaban de anunciar también disponible para Mac y en Binario Universal ni más ni menos.
Enlace: Google Earth plug-in | Vía: El plugin de Google Earth ya está disponible para Mac
Ya lo sospechábamos y con la presión de los medios ha tenido que hablar el gigante de Mountain View: Google usó APIs no documentadas para la creación de su aplicación Google Mobile.
La API específicamente aprovecha el sensor de proximidad para poder activar algo, en el caso de Google Mobile es la búsqueda por voz; esto actualmente no se puede hacer con las APIs a las que se tiene acceso con el SDK del iPhone.
Lo que sí han negado es el uso de frameworks privados o dinámicos, lo cual está estrictamente prohibido en los términos de contrato y que metería a Google en serios problemas (para empezar, su aplicación sería inmediatamente expulsada del App Store).
Aún así, esperamos la reacción de Apple ya que quizá pidan a Google re-escribir su aplicación o puede que tengan que hacerlo obligatoriamente porque una actualización de software rompería el código de la aplicación y evitaría su correcto funcionamiento.
Enlace: Google admits breaking App Store rules
Las API, queridos lectores, son herramientas que ayudan a los programadores a desarrollar una aplicación, de ahí su nombre: Application Programming Interface. Existen varias APIs para el desarrollo de software para el iPhone, que permiten el acceso a el acelerómetro, la cámara, la librería de música, etc.
John Gruber se ha dado cuenta de algo muy curioso: Google Mobile tiene acceso al acelerómetro (algo muy común) pero también al sensor de proximidad, el cual regularmente es muy limitado ya que dentro de una aplicación puede ser activado pero ésta no sabrá cuándo fue activado o desactivado.
En cambio, la aplicación de Google no sólo puede activarlo sino que también sabe en que momento está activada y así capturar tu voz a la hora de realizar una búsqueda (una de las novedades que presentaron hace poco). Así que John cree que hay 3 posibilidades:
- En Google descubrieron esta API secreta pero Apple no se dio cuenta de esto en el proceso de selección.
- Apple sí se dio cuenta pero lo dejó pasar.
- Apple facilitó el acceso a esa API a la gente de Google.
Él descarta la tercera posibilidad por el oscuro proceso de selección que se tiene en el App Store, y puede que tenga razón pues hay manera de utilizar a APIs privadas del iPhone SDK, pero también se trata de Google, un gran aliado y consentido de Cupertino.
Enlace: Google Mobile Uses Private iPhone APIs
Cocotron es un interesante proyecto open-source que pretende “implementar una API multi-plataforma de Objective-C similar a la descrita por Apple Inc. en su documentación de Cocoa.”
Esto supondría un paso importante a la hora de que aplicaciones de OS X puedan ser portadas a Windows, ya que lo haría todo más fácil. No será coser y cantar, pero una gran parte del trabajo ya estaría hecho gracias a Cocotron. Sólo bastaría con adaptar el código propio de Mac a Windows, amén de otros pequeños detalles. Con lo que los desarrolladores ahorrarían en tiempo y dinero.
Esto podría provocar que aparezcan aplicaciones en Windows que antes eran exclusivas para Mac, haciendo que el argumento evangelista de “Esta aplicación sólo está disponible para Mac…” careciera totalmente de sentido. Hablo de aplicaciones de la envergadura de Pixelmator, Coda o el futuro Espresso.
¿Perdería Apple posibles switchers si la mayoría de sus aplicaciones exclusivas estuvieran en Windows? ¿Qué opináis vosotros?
Enlace: Cocotron | Imagen: dirkstoop Flickr | Vía:TUAW
Buenas noticias para los desarrolladores de parte del equipo de Google encargado de la implementación de la API (interfaz de programación de aplicaciones) para Mac OS X ya que, además de poder escribir aplicaciones para el sistema operativo de Apple que hablen directamente con los servidores del buscador, ahora también podrán ser desarrolladas para iPhone.
De esta forma se simplifica todo lo posible el soporte a las aplicaciones en red de Google permitiendo, por ejemplo, integrar la exportación a álbumes de Picassa las fotografías tomadas en el terminal e incluso ideas tan interesantes como mantener un registro de llamadas directamente en Blogger así como el uso de Google Spreadsheet ó Google Base como fuentes de información en forma de base de datos.
Tienes toda la información disponible y el código fuente de la librería en su propia página en Google Code listo para ser utilizado.
Enlace: New frontiers with Google Data APIs and Objective-C
Está claro que ahora tenemos acceso a mucha más información y de manera más sencilla que hace 10 años y vemos con más detalle todos los procesos de la compañía, incluso los de desarrollo de software. Según Vladimir Vukicevic, del equipo de desarrollo de Firefox, Apple usa ciertas API (interfaces de programación de aplicaciones) no documentadas en Safari con las cuales podría dotarle de mayor rendimiento con respecto a las demás aplicaciones.
Todo apunta a que con la actualización de Mac OS X 10.4.4 se introdujo un cambio en la forma de refrescar el contenido de la ventana de los programas que conllevaba la modificación de los archivos de propiedades (.plist) de los mismos para solventarlo. Esto no sería noticia si no fuera porque Safari no implementaba dicho cambio, lo cual indica que no estaba afectado por el problema debido a que utilizan un método de aceleración propio no documentado en su código.
Estas funciones no documentadas no tienen por qué ser un acto de mala fé por parte de los ingenieros, lo que comenta Vukicevic es que estas prácticas no tienen lugar en un proyecto de código abierto como es Webkit y piensa que sería conveniente el acceso por parte de terceros a las mismas para poder realizar mejoras en sus programas.
Enlace: Finding the OS X Turbo Button | Vía: Slashdot
